00:00:09 | cronix | the firmware flashing is damn dangerous |
00:00:21 | cronix | i cant fiddle to much with it or im risking a expensive brick |
00:01:29 | cronix | https://file-cloud.eu/public.php?service=files&t=8a42782613be966425cbb4e65290788a |
00:01:29 | | Quit mirak_ (Quit: Ex-Chat) |
00:01:36 | cronix | thats the complete firmware of that pono |
00:01:46 | cronix | all inside of a jar file renamed to .update |
00:01:51 | | Join mirak_ [0] (~mirak@static-176-182-184-17.ncc.abo.bbox.fr) |
00:04:40 | wodz | cronix: considering there are *lots of* test points on the PCB and some names on silkscreen are meaningful you may try to find UART pads |
00:05:19 | cronix | dmesg tells me about 4! serial ttys devices |
00:05:25 | | Quit Bluefoxicy (Ping timeout: 256 seconds) |
00:06:15 | | Join saratoga_ [0] (123e0ddb@gateway/web/freenode/ip.18.62.13.219) |
00:06:25 | saratoga_ | bertrik: ping |
00:06:36 | bertrik | hi saratoga_ |
00:07:14 | saratoga_ | i'm trying to figure out why increasing the PCLK causes the clipv2 to have trouble with phantom button presses, but the clip+ and zip are fine |
00:07:21 | saratoga_ | any idea what is special about the v2? |
00:07:23 | wodz | considering the number of test points I am wondering if they test the units using oldfashioned nailed |
00:07:35 | saratoga_ | i thought it was nearly the same as clip+ |
00:07:38 | | Quit AlexP (Remote host closed the connection) |
00:07:53 | saratoga_ | i tried changing some delays at random when reading GPIOs but it didn't seem to help |
00:08:26 | saratoga_ | perhaps i am looking at the wrong things |
00:08:42 | wodz | what is this 'high' PCLK? |
00:09:22 | | Join Bluefoxicy [0] (~Bluefoxic@c-73-173-208-251.hsd1.md.comcast.net) |
00:09:26 | saratoga_ | previously we kept the system bus low frequency but the main cpu high frequency since we dind't have scaling and increasing hte bus clock uses a lot of power |
00:09:40 | saratoga_ | now that scaling is working, we can adjust the bus clock too, and its very helpful |
00:09:52 | saratoga_ | the system is much faster and battery life is a lot better |
00:10:17 | wodz | my question was about a value |
00:10:27 | saratoga_ | oh |
00:10:32 | saratoga_ | it was 24 MHz before |
00:10:44 | saratoga_ | now its 19.2 when low, and 96 (IIRC) when high |
00:12:16 | wodz | 96MHz is a lot for PCLK. I can't recall any SoC with peripherials driven from PCLK rated higher then 66MHz |
00:12:43 | wodz | unless PCLK means something else then I am used to |
00:13:09 | bertrik | hm, obviously it could have somethign to do with not having enough setup or hold time. I remember some sansa targets use the button pins for more things than just buttons |
00:13:23 | saratoga_ | yes i added a few delays to the display driver |
00:13:26 | saratoga_ | but maybe not enough |
00:13:30 | bertrik | like the fuze using the display bus as button pins |
00:13:55 | saratoga_ | wodz: IIRC the PCLK is divided as needed to generate most of the clocks, except DRAM |
00:13:59 | bertrik | clip+ and zip are very similar indeed |
00:14:45 | wodz | saratoga: ok, if that is the case driving it as high as possible makes sense |
00:15:12 | saratoga_ | i'm not sure what the rated maximum is, but i was able to do an entire battery bench with it at 96MHz with no issues |
00:15:21 | saratoga_ | so i don't think we're too high |
00:15:44 | saratoga_ | both the clip+ and zip have put tens of hours using it without a single crash |
00:15:47 | wodz | It would be extremely weird for dram not supporting 100+ |
00:15:51 | fs-bluebot | Gerrit review #100 at http://gerrit.rockbox.org/r/100 : IAP rework patch 8: Revert to static buffers by Ralf Ertzinger |
00:15:56 | wodz | lol |
00:15:58 | saratoga_ | ha |
00:16:15 | saratoga_ | but we could use more testing if anyone wants to try the builds i posted on the forums |
00:16:59 | saratoga_ | my clipv2 mostly works with the changes, skip's doesn't even boot |
00:17:04 | saratoga_ | so there is some variation between devices |
00:17:56 | wodz | how is gpio block clock derived? Maybe this is as simple as changing the divider somewhere |
00:18:22 | saratoga_ | IIRC its divided down from the pclk, but it should be the same on the clip+ and zip as well |
00:21:50 | bertrik | saratoga_: it seems most buttons are read using the matrix method where the new row are selected at the end of the button_read_device function, so there should be plenty of time (10 ms) for the voltage to settle I think |
00:23:02 | | Join saratoga__ [0] (123e0ddb@gateway/web/freenode/ip.18.62.13.219) |
00:23:05 | saratoga__ | my device thinks that most buttons are being held all the time |
00:23:08 | saratoga__ | although hold works fine |
00:24:04 | wodz | hold looks like regular GPIO readout |
00:24:48 | | Quit saratoga_ (Ping timeout: 246 seconds) |
00:25:17 | kugel | I'll be offline for about a week, just to let you guys know |
00:25:51 | saratoga__ | i'll be super busy until the holidays as well |
00:25:57 | saratoga__ | although i'd like to do a release |
00:26:35 | bertrik | I wonder if the logic at button-clip.c lines 108 and 111 is correct |
00:28:07 | bertrik | the idea should be that there is either a walking 0 or 1 (depending on the "INITIAL" value) on the row lines |
00:30:45 | | Quit RiD (Quit: A good plan today is better than a perfect plan tomorrow.) |
00:30:48 | bertrik | hm, looks ok, but the code is a bit complex |
00:33:48 | | Nick [Franklin] is now known as NO_IT_ISNT (~franklin@unaffiliated/franklin) |
00:33:53 | | Nick NO_IT_ISNT is now known as [Franklin] (~franklin@unaffiliated/franklin) |
00:35:49 | prof_wolfff | wodz: ATA error -2147483542 seems to be related to CEATA, http://forums.rockbox.org/index.php?topic=48562.0 |
00:36:23 | | Quit bertrik (Remote host closed the connection) |
00:36:28 | prof_wolfff | wodz: I don't have CEATA HDD, probably for that reason i can't see these ATA errors, but i think i found the cause of some USB disconnects... |
00:38:37 | prof_wolfff | actually USB current drain is limited to 200/1000mA instead of 100/500mA, when a current peak occurs some USB HOST/HUBs are allowing more than 500mA, as load increases USB voltage decreases and this voltage drop produces the USB disconnects, these peaks usually occurs when HDD if off and starts spinning-on |
00:39:49 | prof_wolfff | usually i use an external self powered USB HUB (5.05 V.) with no problems, but i experiment USB disconnects on my motherboard USB (4.9 volts), problems disappears configuring the maximum drain current to 500mA |
00:40:22 | wodz | prof_wolfff: hmm indeed it seems that ATA error plagues only 'Thick' model |
00:41:32 | wodz | but 7gen is NOT CEATA AFAIK |
00:42:07 | prof_wolfff | no, AFAIK the only CEATA is the 160 thick |
00:43:46 | wodz | Right. The forum thread you linked is named ATA Error -2147483542 iPod Classic 7thGen |
00:44:52 | wodz | although most 'me too' in the thread are for 160GB thick model |
00:45:31 | prof_wolfff | TheSeven comments this error is generated by CEATA code |
00:45:58 | wodz | prof_wolfff: No. TheSeven commented that such error code is impossible :P |
00:47:12 | wodz | The error code provides sort of backtrace and this particular error code decodes simultaneously to CEATA path and non-CEATA path |
00:51:09 | | Quit wodz (Quit: Leaving) |
00:51:51 | prof_wolfff | if i am not wrong, it is generated in ata_bbt_reload() -> ata_power_up() 1,0 -> ata_set_feature (ata_bbt...) 3,5 -> ceata_wait_idle() 2,2 |
00:56:58 | | Quit GeekShadow (Ping timeout: 250 seconds) |
01:00 |
01:04:00 | | Join GeekShadow [0] (~antoine@nzf.turmel.info) |
01:04:00 | | Quit GeekShadow (Changing host) |
01:04:00 | | Join GeekShadow [0] (~antoine@reactos/tester/GeekShadow) |
01:06:51 | | Quit mirak_ (Quit: Ex-Chat) |
01:07:50 | | Quit ender` (Quit: #define sizeof(x) ((rand() % 100 == 42) ? sizeof(x)-1 : sizeof(x))) |
01:11:49 | [Franklin] | wouldn't #define sizeof(x) sizeof(x) be a recursive macro? |
01:12:41 | | Join AlexP [0] (~alex@rockbox/staff/AlexP) |
01:14:30 | | Quit saratoga__ (Ping timeout: 246 seconds) |
01:21:38 | [Franklin] | foolsh: zoom works without rotation now |
01:21:48 | [Franklin] | can't figure out rotated zoom |
01:22:10 | saratoga | i think its just a null statement since the preprocessor just does a find and replace |
01:22:29 | saratoga | its basically s/sizeof(x)/sizeof(x) |
01:22:36 | TheSeven | hm... |
01:22:50 | TheSeven | prof_wolfff: lots of people confuse generations all over the place |
01:22:59 | TheSeven | so I wouldn't trust anyone saying "7g" |
01:24:15 | [Franklin] | saratoga: actually it expands to sizeof(x) |
01:24:19 | TheSeven | prof_wolfff: do you have a clue what ceata_wait_idle() 2,2 is? |
01:24:24 | TheSeven | IIUC that code doesn't exist |
01:24:42 | [Franklin] | (which I now see is what you meant) |
01:24:48 | TheSeven | at least not in git as of the time when I analyzed that (and nothing should have changed in the meantime) |
01:25:18 | saratoga | isn't that what i said? |
01:25:36 | prof_wolfff | i have it, i am going to verify where i am... |
01:26:15 | * | TheSeven has another look |
01:26:48 | | Quit ZincAlloy (Quit: Leaving.) |
01:27:14 | TheSeven | error -2147483542 is 8000006A |
01:28:07 | prof_wolfff | yes, i am updated, PASS_RC(ceata_wait_idle(),2,2) is at line 567 |
01:28:33 | TheSeven | what's the root of that function tree? |
01:28:40 | TheSeven | ata_init? |
01:29:09 | [Franklin] | 19:24 < [Franklin]> (which I now see is what you meant) ;) |
01:29:26 | prof_wolfff | yes, i think it comes from main()->storage_init() |
01:30:02 | TheSeven | so yeah, that's PASS_RC(ata_bbt_reload(), 0, 0); |
01:30:35 | prof_wolfff | old driver version doesn't executes ata_set_feature() function for CEATA |
01:30:58 | TheSeven | 6a is 1101010, so that's PASS_RC(ata_power_up(), 1, 0); with 110101 left |
01:32:29 | TheSeven | oh, I think I see what happened |
01:32:45 | TheSeven | looks like I thought I was still in that else branch in ata_power_up when I last looked at that |
01:32:52 | TheSeven | that explains a lot of things |
01:33:22 | TheSeven | so it's "enable write cache" that's failing? |
01:33:50 | TheSeven | so fixing the (completely broken) ata_set_feature from the old driver actuall broke things. dammit. |
01:36:08 | TheSeven | so that buggy drive fails ata_set_feature despite advertizing the feature in its IDENTIFY response? or do we have another bug there? |
01:36:54 | prof_wolfff | i also see line 592 is the same as line 603, y don't what is that GPIO, could influence? |
01:37:10 | | Quit krabador (Ping timeout: 265 seconds) |
01:37:59 | prof_wolfff | i don't know what is that GPIO, line 592 was not there before |
01:38:25 | TheSeven | hm, pulling something high, but no idea what |
01:39:32 | TheSeven | btw, I'm a bit surprised by that USB current thing... highest I've seen so far was ~650mA which most mainboards seem to handle just fine |
01:39:58 | TheSeven | I haven't fully figured out what controls this current though - the behavior doesn't quite align with the datasheet of the charger chip |
01:39:59 | prof_wolfff | pulling it before writing the following registers could broke things ? |
01:40:06 | TheSeven | there's likely something in parallel to it |
01:40:43 | TheSeven | the *((uint32_t volatile*)0x3cf00200) = 0xb000f; line does indeed look redundant |
01:41:02 | TheSeven | I guess we didn't know what that GPIOCMD reg was back when we transcribed that from a disassembly |
01:42:09 | TheSeven | hm, one possible explanation for that pin could be a supply for SDIO pullup resistors |
01:42:19 | TheSeven | which you want to shut down when unpowering the disk |
01:42:33 | TheSeven | but that's just a wild guess |
01:42:42 | TheSeven | it does seem to be ceata-specific though |
01:42:55 | prof_wolfff | PCON(11) |= 0xf was introduced in the new driver version, it was not there before |
01:43:12 | TheSeven | yes, along with a shitload of other missing GPIO accesses |
01:43:20 | TheSeven | those were transcribed from some disassembly |
01:44:23 | TheSeven | probably missed that other line doing effectively the same because it was doing it in a different way |
01:44:29 | *** | Saving seen data "./dancer.seen" |
01:44:35 | prof_wolfff | IIRC OF puts GPIO as output high for lowest power consumption, it makes more sense that configuring them as input |
01:44:51 | TheSeven | not if the drive is powered down |
01:44:53 | prof_wolfff | sorry, OF puts GPIO as output LOW |
01:44:56 | TheSeven | ok |
01:45:05 | TheSeven | where does it do that? |
01:45:26 | | Join mirak_ [0] (~mirak@static-176-182-184-17.ncc.abo.bbox.fr) |
01:45:36 | TheSeven | I'm not sure what I used as a reference, could have been a bootloader, diagmode, or something like that |
01:46:15 | prof_wolfff | need to find it, but i think it is at OSOS |
01:47:10 | prof_wolfff | about USB, there are a couple of GPIO to limit current drawn at 100,200,500 or 1000 mA |
01:47:31 | * | TheSeven never looked into that much after having understood the important things while disassembling smaller binaries |
01:47:42 | TheSeven | where do the 200/1000mA steps come from? |
01:48:32 | TheSeven | http://cds.linear.com/docs/en/datasheet/4066fc.pdf |
01:48:33 | prof_wolfff | i suspect one GPIO controls LTC4066 HPWR pins who selects 100 o 500 mA (it is configured with a resistor, CLPROG IIRC) |
01:48:58 | TheSeven | so you think they messed with the CLPROG pin somehow? |
01:49:16 | TheSeven | by pulling it low through an additional resistor and a GPIO? |
01:49:30 | prof_wolfff | the other GPIO modifies this resistor and doubles these limits, i have tested the 100,200 and 500 limit, the 1000 limit could not be tested because iPod doesn't consumes that much |
01:49:35 | TheSeven | but pulling it up would have weird effects then and I didn't observe any of those while messing with that area |
01:50:07 | TheSeven | then again that has been ages ago and I might be misremembering things |
01:50:52 | * | TheSeven needs to build a USB current meter again some day |
01:51:01 | TheSeven | my old one died a while ago |
01:51:21 | TheSeven | but I guess for that kind of test I can just use a multimeter - doesn't need to be sub-mA accurate ;) |
01:52:47 | [Franklin] | Is there any way I can get the xworld strings translated? |
01:52:48 | prof_wolfff | i also need some time to calibrate a couple of vu-meter from an old audio equipment, there is another GPIO that disables battery charge, so the measured current is all consumed by the iPod |
01:53:30 | TheSeven | heh, way too many things on our todo list |
01:53:46 | prof_wolfff | that's good :) |
01:53:47 | * | TheSeven would rather clean out that bootloader mess than worry about USB charging at this point ;) |
01:54:56 | prof_wolfff | I am going to send to gerrit a set of patches including a new DMA driver, i would like if you revise it, knowing you are busy i am not asking for a full code review (great if you do it), just a quick glance to know your thoughts and suggestions about including these patches in RB |
01:55:49 | TheSeven | what kind of issues is that one addressing? |
01:56:24 | TheSeven | DMA seems like one of the things that work reasonably well these days - mostly thanks to that being a well-documented core by ARM |
01:56:34 | | Quit AlexP (Remote host closed the connection) |
01:58:11 | prof_wolfff | i am finishing to write a complete description for the patches, it is a queue DMA driver, it is very easy to use and experiment with different configurations and includes a peak_buffer function who is working well for me |
01:58:45 | prof_wolfff | there are other patches for HAVE_RECORDING, HAVE_SERIAL and HAVE_IAP |
01:59:59 | | Quit mirak_ (Quit: Ex-Chat) |
02:00 |
02:00:41 | prof_wolfff | the current playback algorithm and configuration is not modified, it uses the DMA driver API instead of dealing with LLIs, buses, widths... |
02:01:14 | | Join mirak_ [0] (~mirak@static-176-182-184-17.ncc.abo.bbox.fr) |
02:05:47 | | Quit mirak_ (Ping timeout: 250 seconds) |
02:23:55 | [Franklin] | what would I put for the copyright in xworld? |
02:24:27 | [Franklin] | Do I leave the original author's name, or delete it? |
02:31:23 | | Join Guest66888 [0] (Slayer@c-73-173-172-175.hsd1.va.comcast.net) |
02:34:10 | | Quit Guest66077 (Ping timeout: 244 seconds) |
02:44:43 | | Quit yuriks (Read error: Connection reset by peer) |
02:46:17 | | Join yuriks [0] (~quassel@opentyrian/developer/yuriks) |
02:56:34 | sakax | is someone still working on fixing nano2g? just wondering :D |
02:57:45 | [Franklin] | sakax: TheSeven is overloaded right now |
03:00 |
03:03:59 | | Quit [Franklin] (Quit: Lost terminal) |
03:43:29 | | Quit michaelni (Quit: Leaving) |
03:44:33 | *** | Saving seen data "./dancer.seen" |
03:49:46 | | Join michaelni [0] (~michael@chello084114129144.4.15.vie.surfer.at) |
04:00 |
04:32:29 | | Quit bzed (Remote host closed the connection) |
04:32:36 | | Join bzed [0] (~bzed@devel.recluse.de) |
04:41:21 | | Join AlexP [0] (~alex@rockbox/staff/AlexP) |
05:00 |
05:12:34 | | Join ruhan [0] (~M@unaffiliated/ruhan) |
05:16:58 | | Quit Scr0mple (Ping timeout: 245 seconds) |
05:25:00 | | Quit TheSeven (Ping timeout: 244 seconds) |
05:26:24 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
05:44:34 | *** | Saving seen data "./dancer.seen" |
05:48:26 | | Join prontotest [0] (pronto@tasty.bagels.xxx) |
05:48:28 | | Part prontotest |
06:00 |
06:06:49 | | Quit AlexP (Remote host closed the connection) |
06:29:17 | | Quit Strife89 (Ping timeout: 264 seconds) |
06:33:29 | | Quit sakax (Remote host closed the connection) |
07:00 |
07:01:50 | | Join dfkt_ [0] (dfkt@unaffiliated/dfkt) |
07:02:00 | | Quit dfkt (Disconnected by services) |
07:02:15 | | Nick dfkt_ is now known as dfkt (dfkt@unaffiliated/dfkt) |
07:13:01 | | Part ruhan ("Leaving") |
07:13:44 | | Join Scr0mple [0] (~Simon@27.127.199.230) |
07:44:36 | *** | Saving seen data "./dancer.seen" |
08:00 |
08:23:37 | | Quit amiconn (Remote host closed the connection) |
08:23:38 | | Quit pixelma (Remote host closed the connection) |
08:25:36 | | Join ender` [0] (krneki@foo.eternallybored.org) |
08:25:44 | | Join pixelma [0] (~pixelma@rockbox/staff/pixelma) |
08:25:45 | | Join amiconn [0] (~amiconn@rockbox/developer/amiconn) |
08:27:52 | | Join olspookishmagus [0] (~pookie@snf-137798.vm.okeanos.grnet.gr) |
08:36:20 | | Join JdGordon_ [0] (~jonno@rockbox/developer/JdGordon) |
08:37:37 | | Quit JdGordon (Ping timeout: 250 seconds) |
08:39:44 | | Join mortalis|2 [0] (~kvirc@212.44.150.238) |
08:40:05 | | Quit kugel (Ping timeout: 264 seconds) |
08:59:58 | | Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) |
09:00 |
09:13:42 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
09:22:17 | | Join wodz [0] (~wodz@89-75-106-114.dynamic.chello.pl) |
09:24:08 | wodz | pamaury: BF_CLR, BF_SET and BF_TOG are pretty much imx specific. I'd expect BF_CLR to expand into BF_WR(reg, field, 0) and BF_SET to BF_WR(reg, field, 1) |
09:24:41 | wodz | pamaury: And it would be good to document those macros anyway |
09:24:43 | pamaury | well, BF_SET is really just a write to the _SET variant of the register |
09:25:00 | pamaury | imx is not the only target with SCT variants |
09:25:42 | wodz | pamaury: sure but for targets without SCT BF_SET/CLR/TOG still have a merit (but obtained differently) |
09:26:10 | pamaury | why not use BF_WR then ? |
09:26:40 | wodz | You can, sure. |
09:27:50 | pamaury | Maybe we can change this but my initial way: |
09:27:50 | wodz | for clear its simple, for SET you need to remember to use mask instead of simple 1 if this is multibit field. Toggle doesn't have simple equivalent |
09:27:50 | pamaury | - BF_SET/CLR/TOG only apply to register variants, because they have a different semantic |
09:27:50 | pamaury | - BF_WR applies to all, it always work but does RMW |
09:28:40 | pamaury | hum, however there is a slighlt complication: the macro BF_SET cannot determine if the register has a SET variant or not |
09:28:46 | wodz | what about BF_SCT_{SET,CLR,TOG} |
09:29:31 | wodz | and regular BF_{SET,CLR,TOG} |
09:29:40 | pamaury | isn't it a bit confusing ? |
09:30:09 | wodz | I understand why you did this that way but it is not correct for non SCT |
09:31:39 | pamaury | hum, give me a moment to think about it, maybe we just need to come up with better names for the alternative |
09:32:11 | pamaury | I'd suggest like BF_OR, BF_XOR, BF_NAND but that might be confusing |
09:32:14 | wodz | anyway preprocessor can't check if you are using SCT variant for non SCT register so the code writer needs to be aware of the nature of register anyway |
09:32:39 | pamaury | yes absolutely, that's a safetey mechanism: you just can't BF_SET a register without a _SET variant |
09:33:32 | pamaury | hell BF_OR is already used anyway |
09:34:42 | pamaury | what about BF_BIT_{SET,CLR,TOG} ? |
09:36:39 | wodz | you will know instantly as there will be no definition of _SET variant and compiler will tell you that |
09:37:22 | pamaury | yes, that's the intended behaviour |
09:37:51 | wodz | BF_BIT_* name implies single bit manipulation which is not generally true |
09:38:30 | pamaury | the only alternative I see would to rewrite *all* current instances of BF_SET(reg, field) to reg_SET = REG_BM(reg,field) |
09:38:50 | wodz | yeah, kinda stupid but grep should do |
09:39:09 | pamaury | but that's far less readable imo, you need to write the register twice |
09:39:32 | pamaury | although I agree it has the advantage of not requiring knowledge about the variants |
09:40:41 | pamaury | maybe I could create a macro like BF_ASSIGN(reg, variant, field) which would do this |
09:41:05 | wodz | how reg_SET = xxx solve anything? It is still not right for non SCT |
09:41:32 | wodz | ah, I read it wrong |
09:41:36 | pamaury | that for existing code |
09:42:05 | pamaury | there is a lot of code (114 lines of BF_SET, 114 lines of BF_CLR and 2 BF_TOG) |
09:42:07 | wodz | you mean eliminate *current* SCT aware BF_SET from existing code |
09:42:18 | pamaury | yes |
09:43:14 | wodz | hmm, whats wrong with BF_SCT_* then? simple substitution of name in code and freeing up BF_* for generic variant |
09:43:42 | pamaury | I don't like the mix of both, it's too confusing |
09:44:37 | *** | Saving seen data "./dancer.seen" |
09:45:10 | pamaury | I need to go, I'll think about it but I'm confident we can find a solution to free up BF_{SET,CLR,TOG}, I just need to find a good substitution name |
09:45:58 | wodz | SCT_{SET, CLR, TOG} maybe? |
09:46:13 | wodz | to not confuse with BF_ |
09:46:22 | pamaury | maybe, very easy to misread though, and yes documenting the macros would be a good idea |
10:00 |
10:08:06 | | Quit wodz (Quit: Leaving) |
10:16:26 | | Join LinusN [0] (~linus@giant.haxx.se) |
10:18:04 | | Quit pamaury (Ping timeout: 250 seconds) |
10:35:51 | | Quit mc2739 (Ping timeout: 258 seconds) |
10:39:19 | | Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) |
10:52:44 | | Join pamaury [0] (~quassel@sphinx.lix.polytechnique.fr) |
10:52:44 | | Quit pamaury (Changing host) |
10:52:44 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
11:00 |
11:34:14 | | Join einhirn_ [0] (~Miranda@bsod.rz.tu-clausthal.de) |
11:34:20 | | Quit einhirn (Ping timeout: 252 seconds) |
11:40:47 | | Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) |
11:44:41 | *** | Saving seen data "./dancer.seen" |
12:00 |
12:09:54 | | Quit Ketturi (Ping timeout: 264 seconds) |
12:13:05 | | Join Ketturi [0] (ketturi@hilla.kapsi.fi) |
12:29:36 | | Quit einhirn_ (Ping timeout: 240 seconds) |
13:00 |
13:07:34 | | Join ZincAlloy [0] (~Adium@pD9EEBD39.dip0.t-ipconnect.de) |
13:39:09 | | Join sakax [0] (~sakax@unaffiliated/sakax) |
13:44:43 | *** | Saving seen data "./dancer.seen" |
13:45:55 | cronix | wodz: i gathered quite a bit info on the pono player internals: http://forum.xda-developers.com/android/development/dump-player-firmware-update-file-1-0-3-t2967757/post57377220#post57377220 |
13:47:02 | cronix | this is the part where Rockbox for android crashes: http://pastebin.com/uBDxKGLA |
13:57:00 | foolsh | cronix: Please take what I say with a grain of salt, I'm no expert, but is the android ndk support build in to the pono player? |
13:57:40 | wodz | looks like it can't find rockbox.so |
13:58:03 | cronix | foolsh: is there a way to find out? |
14:00 |
14:02:40 | foolsh | cronix: Does the path "/sdcard/rockbox" exist? |
14:03:16 | wodz | foolsh: isn't rockbox.so searched in internal storage? |
14:04:05 | cronix | foolsh: jep i created it to test if it extracts the so files to sdcard instead of the internal lib path |
14:04:56 | cronix | ive put a rockbox-info.txt file there |
14:05:05 | cronix | it does not extract anything at all |
14:05:14 | cronix | (running on android 2.3.3 device) |
14:05:26 | cronix | and rockbox crashes instantly when i start the app |
14:09:11 | foolsh | cronix: Hmm.. how about the "/data/data/org.rockbox/app_rockbox/rockbox" directory does it exist on the player? I also wonder about it's file permissions |
14:09:32 | foolsh | it should, just ckecking |
14:09:52 | cronix | lemme check |
14:10:33 | cronix | its a pain i have to use the terminal emulator with on screen keyboard on a 240x320 screen because adb does not work at all |
14:22:08 | cronix | mhm /data/data/org.rockbox/ exists with drwxr-x−−x app_0 app_0 |
14:23:20 | cronix | /data/data/org.rockbox/app_rockbox/rockbox does not though |
14:25:08 | cronix | /data/data/org.rockbox/ just contains a lib folder |
14:26:22 | cronix | that one is empty though |
14:26:31 | cronix | owned by system:system |
14:26:58 | cronix | drwxr-xr-x |
14:29:24 | | Quit wodz (Quit: Leaving) |
14:29:51 | foolsh | the file /data/data/org.rockbox/lib/libmisc.so doesn't exist hmm... it's like it's never installed correctly, or has someother trouble with the apk |
14:30:17 | cronix | the libs are embedded inside of the apk tough |
14:30:37 | cronix | and ive tested the exact same apk on the android emulator with an android 2.3.3 image before |
14:30:45 | cronix | it works fine over there |
14:30:55 | cronix | just not on the pono player |
14:31:13 | foolsh | do you have root? can you manually put them in place? |
14:31:30 | cronix | i have root, that was archived about an hour ago |
14:31:33 | cronix | just not adb |
14:31:38 | foolsh | Are you using linix then btw? |
14:31:43 | cronix | jep |
14:32:03 | foolsh | have you created a udev rule for your pono player? |
14:32:08 | cronix | jep aswell |
14:32:12 | foolsh | hmm |
14:32:24 | foolsh | rebooted since then? |
14:32:26 | cronix | SUBSYSTEM=="usb", SYSFS{idVendor}=="2aa1", MODE="0666" |
14:32:28 | cronix | nope |
14:32:39 | cronix | but i tried yesterday at home on my laptop aswell |
14:32:41 | foolsh | couldn't hurt but might not help |
14:32:44 | cronix | windows and linux |
14:32:48 | cronix | rebooted several times |
14:32:49 | foolsh | geez |
14:32:51 | cronix | did not work |
14:32:57 | cronix | its a pain :o |
14:33:21 | cronix | i also modified the build.prop to enable adb |
14:33:28 | cronix | and the adbd is running fine |
14:34:12 | cronix | but the logcat shows this when i connect a usb cable: http://pastebin.com/66GGapMY |
14:34:44 | foolsh | usb debug enabled on the player? |
14:34:48 | cronix | jup |
14:34:51 | foolsh | dang |
14:34:59 | cronix | also dis and reanabled it already |
14:35:23 | foolsh | got yourself a real pickel there |
14:35:31 | cronix | jup :D |
14:35:43 | foolsh | are you building the pono image yourself? |
14:35:48 | cronix | but first steps are already done, i got it rooted ^ |
14:35:53 | cronix | no access to pono sourcecode |
14:36:01 | cronix | im just carefully copying files |
14:36:21 | cronix | https://file-cloud.eu/public.php?service=files&t=8a42782613be966425cbb4e65290788a |
14:36:29 | cronix | thats the image updater zip |
14:37:29 | cronix | thats the adbd related stuff inside of my initram init.rc: http://pastebin.com/TRiDCwPJ |
14:37:52 | cronix | and i checked with getprop for persist.service.adb.enable=1 and that one is indeed @ 1 |
14:39:07 | foolsh | so your modifying this update image? |
14:39:21 | cronix | exactly |
14:39:32 | foolsh | ah, |
14:39:46 | cronix | resigning with android test-keys is enough for the pono's recovery to accept that image |
14:40:12 | cronix | thing is, there is no key kombination to force the pono to boot to recovery |
14:40:25 | cronix | and no fastboot or any other method of debricking |
14:40:38 | cronix | thats why im pretty damn careful about what to modify |
14:41:22 | | Join amayer [0] (~amayer@mail.weberadvertising.com) |
14:42:05 | cronix | firmware update is triggered by putting a *.update file onto the .pono directory on the internal sd card |
14:42:12 | cronix | and unplug the usb cable from the pc |
14:42:34 | cronix | then the player scans for that update file and prepares the update, reboots to recovery and flashes the new zip |
14:42:49 | cronix | all fully automated and triggered by the official pono player apk |
14:43:00 | cronix | it does not happen when im inside of laucher2.apk |
14:43:15 | cronix | that thing is pretty damn weird |
14:43:50 | cronix | preparation is done by copyting said update file to /cache/recovery/ |
14:44:29 | foolsh | Offtopic but sounds like it needs someone to modify that update process to flash a custom boot loader ;) |
14:45:07 | cronix | jep indeed |
14:45:26 | cronix | afaik its boot loader is an u-boot |
14:45:42 | cronix | i still want to dump all the partitions on the device |
14:45:52 | cronix | will do that in the evening (about 3-4 hours from now) |
14:47:36 | cronix | package_extract_file("boot.img", "/dev/block/platform/mmci-omap-hs.1/by-name/boot"); |
14:47:44 | cronix | that is default android behaviour though |
14:48:01 | cronix | where as boot.img contains the kernel and ramdisk |
14:51:25 | foolsh | well unpacking the resources to /data/data/org.rockbox/app_rockbox/rockbox and giving them the right permissions "should" work, but don't hold me to it. "Why" it doesn't is still a mystery. |
14:51:56 | cronix | which ressources? |
14:52:02 | cronix | just unzip the whole apk there? |
14:52:45 | foolsh | no I believe it should be a rockbox.zip but I'm not sure, it looking for the native binaries I believe |
14:53:11 | foolsh | It's been a long time since I delved into the android port |
14:54:34 | | Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) |
15:00 |
15:04:18 | foolsh | cronix: /data/data/org.rockbox/lib/libmisc.so needs to exist and.... |
15:04:52 | foolsh | "/data/data/org.rockbox/app_rockbox/rockbox/rockbox.so" OR "/sdcard/rockbox/rockbox.so" I think |
15:05:10 | foolsh | and they need proper permissions |
15:07:04 | | Join xorly [0] (~xorly@wced-243-218-32-147.feld.cvut.cz) |
15:08:34 | foolsh | there may be more though |
15:25:01 | cronix | okay thanks |
15:25:16 | cronix | i just dumped all the nand and mmc partitions :D |
15:31:47 | cronix | Texas Instruments X-Loader 1.51 -> u-boot -> android |
15:32:27 | cronix | for the x-loader there is source code: https://gitorious.org/x-loader/x-loader/source/master: |
15:33:46 | foolsh | cronix: this is becoming off topic head over to #rockbox-community so the public logs don't become clobbered |
15:34:02 | cronix | sorry |
15:34:26 | foolsh | :) |
15:34:37 | * | gevaerts thinks it's borderline :) |
15:43:27 | | Join AlexP [0] (~alex@rockbox/staff/AlexP) |
15:44:45 | *** | Saving seen data "./dancer.seen" |
16:00 |
16:02:35 | | Part LinusN |
16:07:40 | | Quit xorly (Ping timeout: 260 seconds) |
16:16:40 | | Quit pamaury (Remote host closed the connection) |
16:21:03 | | Quit sakax (Remote host closed the connection) |
16:28:00 | | Quit shamus (Read error: Connection reset by peer) |
16:28:56 | | Quit Topy44 (Ping timeout: 265 seconds) |
16:32:00 | | Join shamus [0] (~shmaus@ip-206-192-193-180.marylandheights.ip.cablemo.net) |
16:32:03 | | Join Topy44 [0] (topy@cl-406.cgn-01.de.sixxs.net) |
16:44:04 | | Join mortalis [0] (~kvirc@212.44.150.238) |
16:47:18 | | Quit mortalis|2 (Ping timeout: 265 seconds) |
16:50:30 | | Join mortalis|2 [0] (~kvirc@212.44.150.238) |
16:53:36 | | Quit mortalis (Ping timeout: 240 seconds) |
16:58:48 | | Join RiDD [0] (~RiD@bl17-226-13.dsl.telepac.pt) |
17:00 |
17:15:20 | | Join mortalis [0] (~kvirc@194.133.18.67) |
17:17:10 | | Join mortalis|3 [0] (~kvirc@212.44.150.238) |
17:17:32 | | Quit einhirn (Ping timeout: 252 seconds) |
17:19:39 | | Quit mortalis|2 (Ping timeout: 272 seconds) |
17:20:55 | | Quit mortalis (Ping timeout: 272 seconds) |
17:25:14 | | Join mortalis [0] (~kvirc@212.44.150.238) |
17:29:09 | | Quit mortalis|3 (Ping timeout: 272 seconds) |
17:33:04 | | Quit alucryd (Ping timeout: 260 seconds) |
17:35:16 | | Join edhelas [0] (~edhelas@77-173-17-40.ip.telfort.nl) |
17:37:49 | | Join alucryd [0] (quassel@archlinux/trusteduser/alucryd) |
17:43:36 | | Quit [Saint] (Ping timeout: 240 seconds) |
17:44:47 | *** | Saving seen data "./dancer.seen" |
17:45:57 | | Quit williamtdr (Ping timeout: 258 seconds) |
18:00 |
18:01:38 | | Quit RiDD (Read error: Connection reset by peer) |
18:01:53 | | Join RiDD [0] (~RiD@bl17-226-13.dsl.telepac.pt) |
18:15:07 | | Join [Saint] [0] (~saint@rockbox/staff/saint) |
18:21:02 | | Join chrisb [0] (~chrisb@pool-71-162-227-3.phlapa.east.verizon.net) |
18:48:58 | | Join y4n [0] (~y4n@unaffiliated/y4ndexx) |
18:54:16 | | Quit [Saint] (Ping timeout: 240 seconds) |
18:55:07 | | Quit mortalis (Ping timeout: 250 seconds) |
19:00 |
19:01:29 | | Join williamtdr [0] (uid27909@gateway/web/irccloud.com/x-oysjxqjfpnadeycn) |
19:03:49 | | Join [Saint] [0] (~saint@rockbox/staff/saint) |
19:04:31 | | Join meh [0] (981a1ad5@gateway/web/freenode/ip.152.26.26.213) |
19:13:50 | | Join rela [0] (~x@pdpc/supporter/active/rela) |
19:21:05 | | Join rela_ [0] (~x@p20030066841C3C00303F10C0A33A5FFF.dip0.t-ipconnect.de) |
19:21:34 | | Quit rela_ (Client Quit) |
19:22:36 | | Join krabador [0] (~krabador@host171-55-dynamic.244-95-r.retail.telecomitalia.it) |
19:22:42 | | Quit krabador (Changing host) |
19:22:42 | | Join krabador [0] (~krabador@unaffiliated/krabador) |
19:23:08 | | Quit rela (Ping timeout: 272 seconds) |
19:28:55 | | Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
19:28:55 | | Quit bertrik (Changing host) |
19:28:55 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
19:44:48 | *** | Saving seen data "./dancer.seen" |
19:52:55 | prof_wolfff | i just sent to gerrit a bunch of patches for iPod Classic, probably contains numerous errors, inaccuracies, typos... all reviews, suggestions, questions.. are welcome! |
19:53:04 | | Quit edhelas (Ping timeout: 260 seconds) |
19:53:24 | prof_wolfff | all code is tested on ipod 80 and 160 slim, but some of the patches are modifying sensible things and needs more testing |
19:54:16 | gevaerts | You've been busy :) |
19:57:43 | prof_wolfff | gevaerts: :) at this moment i was trying to ask you for a review of the iAP code, see you were involved in the last iAP big update |
19:58:03 | gevaerts | I was? |
19:58:12 | | Join lebellium [0] (~chatzilla@128-79-0-151.hfc.dyn.abo.bbox.fr) |
19:59:01 | prof_wolfff | you aren't in the las iAP commit?, maybe i am wrong, will look it again |
19:59:16 | gevaerts | Hmmm |
19:59:35 | gevaerts | I took part in discussions about how much review was needed I think, but it's really not my area |
19:59:57 | * | gevaerts is good at such meta-discussions :) |
20:00 |
20:00:18 | prof_wolfff | oh yes, i see the commit was done by Ralf Ertzinger |
20:05:34 | | Quit ZincAlloy (Quit: Leaving.) |
20:08:51 | | Quit meh (Ping timeout: 246 seconds) |
20:11:54 | | Join ZincAlloy [0] (~Adium@pD9EEBD39.dip0.t-ipconnect.de) |
20:26:43 | | Join edhelas [0] (~edhelas@77-173-17-40.ip.telfort.nl) |
20:39:12 | | Join rela [0] (~x@pdpc/supporter/active/rela) |
20:39:36 | fs-bluebot | Build Server message: New build round started. Revision b320bba, 255 builds, 32 clients. |
20:43:25 | | Quit edhelas (Quit: Quitte) |
20:43:57 | | Join TheLemonMan [0] (~lemonboy@unaffiliated/thelemonman) |
20:47:39 | fs-bluebot | Build Server message: Build round completed after 484 seconds. |
20:58:08 | | Quit rela (Ping timeout: 272 seconds) |
21:00 |
21:02:52 | | Join thomasjfox_ [0] (~thomasjfo@rockbox/developer/thomasjfox) |
21:09:22 | | Join rela [0] (~x@pdpc/supporter/active/rela) |
21:29:41 | | Join mirak_ [0] (~mirak@static-176-182-184-17.ncc.abo.bbox.fr) |
21:32:29 | | Quit chrisb (Ping timeout: 258 seconds) |
21:40:25 | | Quit y4n (Quit: PANTS OFF!) |
21:44:50 | *** | Saving seen data "./dancer.seen" |
21:48:40 | | Quit bertrik (Quit: Lost terminal) |
21:50:31 | | Join bertrik [0] (~quassel@rockbox/developer/bertrik) |
22:00 |
22:01:02 | | Quit RiDD (Read error: Connection reset by peer) |
22:13:30 | | Quit fs-bluebot (Ping timeout: 272 seconds) |
22:13:33 | | Quit bluebrother (Ping timeout: 265 seconds) |
22:39:48 | | Join mikebeauc [0] (~mike@98.143.75.194) |
22:47:37 | | Join [Franklin] [0] (~franklin@cpe-071-071-039-006.triad.res.rr.com) |
22:47:42 | | Quit [Franklin] (Changing host) |
22:47:42 | | Join [Franklin] [0] (~franklin@unaffiliated/franklin) |
22:48:24 | [Franklin] | prof_wolfff: man your patches do everything :) |
22:50:55 | | Join sakax [0] (~sakax@unaffiliated/sakax) |
22:52:08 | prof_wolfff | Franklin: :) i wish it were true, there are still many things to do |
22:52:55 | [Franklin] | so you implemented the microphone? |
22:53:34 | prof_wolfff | the iAP microphone works but i am preparing a patch for the HP jack microphone |
22:53:54 | [Franklin] | nice |
22:54:16 | * | [Franklin] doesn't think the classic is "unusable" anymore :) |
22:54:17 | prof_wolfff | anyway the line-in can also be used |
22:54:37 | [Franklin] | what's the difference between line in and the headphone jack mic? |
22:56:03 | prof_wolfff | i have an old line-in microphone (it was made for iPod Video but works on Classic OF), it is stereo an has better quality than the jack mic (mono) |
22:56:29 | [Franklin] | ah |
22:56:57 | prof_wolfff | but jack mics are cheap, no more than $3 and acceptable quality for voice recording |
22:58:37 | prof_wolfff | jack mic consumption is very low, not tested but probably it could record for more than 25 hours |
22:58:44 | [Franklin] | wow |
22:59:22 | prof_wolfff | unboosted recording works well |
22:59:51 | [Franklin] | perhaps someday DAPs /will/ ship with rockbox pre-installed :) |
23:00 |
23:00:20 | * | gevaerts very much doubts that |
23:01:07 | prof_wolfff | IIRC i have seen it on eBay |
23:01:35 | * | [Franklin] queries "rockbox" on ebay |
23:01:55 | [Franklin] | yep |
23:02:21 | gevaerts | Well yes, and there are (or were) also some people selling sansas with rockbox targeted at blind people, but that's really not the same thing |
23:02:33 | gevaerts | They still leave the factory with something else installed |
23:06:21 | mikebeauc | someone do a kickstarter for a rockbox branded DAP :) |
23:07:12 | gevaerts | I think we have way too many features for any QA department to feel comfortable with |
23:07:55 | gevaerts | It would cost a lot more to polish all that than to just tweak whatever you get from the SoC manufacturer a bit |
23:08:09 | mikebeauc | it's probably easier to let other companies deal with the hardware side of things anyways |
23:08:18 | [Franklin] | perhaps a deal with sansa? |
23:08:20 | [Franklin] | :) |
23:08:28 | | Quit thomasjfox_ (Quit: Konversation terminated!) |
23:09:46 | | Quit bzed (Remote host closed the connection) |
23:09:53 | | Join bzed [0] (~bzed@devel.recluse.de) |
23:10:22 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
23:11:00 | | Quit shamus (Ping timeout: 258 seconds) |
23:11:01 | | Quit ps-auxw (Ping timeout: 258 seconds) |
23:11:07 | | Join shamus [0] (~shmaus@ip-206-192-193-180.marylandheights.ip.cablemo.net) |
23:11:39 | | Join ps-auxw [0] (~arneb@2001:470:c807:0:1532:4e5f:2ad3:4123) |
23:11:46 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
23:25:38 | | Quit amiconn (Disconnected by services) |
23:25:38 | | Join amiconn_ [0] (~amiconn@rockbox/developer/amiconn) |
23:25:41 | | Nick amiconn_ is now known as amiconn (~amiconn@rockbox/developer/amiconn) |
23:26:03 | | Quit pixelma (Ping timeout: 265 seconds) |
23:26:10 | | Join pixelma_ [0] (~pixelma@rockbox/staff/pixelma) |
23:26:12 | | Nick pixelma_ is now known as pixelma (~pixelma@rockbox/staff/pixelma) |
23:31:56 | | Quit pamaury (Ping timeout: 245 seconds) |
23:32:05 | | Quit amayer (Quit: Leaving) |
23:32:55 | | Quit advcomp2019 (Read error: Connection reset by peer) |
23:33:17 | | Join advcomp2019 [0] (~advcomp20@65-131-165-138.sxct.qwest.net) |
23:33:18 | | Quit advcomp2019 (Changing host) |
23:33:18 | | Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) |
23:44:31 | | Quit bertrik (Remote host closed the connection) |
23:44:52 | *** | Saving seen data "./dancer.seen" |
23:47:19 | | Quit TheLemonMan (Ping timeout: 260 seconds) |
23:52:22 | [Franklin] | how do I link with tlsf? |
23:58:31 | | Quit mikebeauc (Ping timeout: 260 seconds) |