--- Log for 10.12.114 Server: weber.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 6 days and 16 hours ago 00.00.09 # the firmware flashing is damn dangerous 00.00.21 # i cant fiddle to much with it or im risking a expensive brick 00.01.29 # https://file-cloud.eu/public.php?service=files&t=8a42782613be966425cbb4e65290788a 00.01.29 Quit mirak_ (Quit: Ex-Chat) 00.01.36 # thats the complete firmware of that pono 00.01.46 # 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 # 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 # 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 # bertrik: ping 00.06.36 # hi saratoga_ 00.07.14 # 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 # any idea what is special about the v2? 00.07.23 # considering the number of test points I am wondering if they test the units using oldfashioned nailed 00.07.35 # i thought it was nearly the same as clip+ 00.07.38 Quit AlexP (Remote host closed the connection) 00.07.53 # i tried changing some delays at random when reading GPIOs but it didn't seem to help 00.08.26 # perhaps i am looking at the wrong things 00.08.42 # what is this 'high' PCLK? 00.09.22 Join Bluefoxicy [0] (~Bluefoxic@c-73-173-208-251.hsd1.md.comcast.net) 00.09.26 # 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 # now that scaling is working, we can adjust the bus clock too, and its very helpful 00.09.52 # the system is much faster and battery life is a lot better 00.10.17 # my question was about a value 00.10.27 # oh 00.10.32 # it was 24 MHz before 00.10.44 # now its 19.2 when low, and 96 (IIRC) when high 00.12.16 # 96MHz is a lot for PCLK. I can't recall any SoC with peripherials driven from PCLK rated higher then 66MHz 00.12.43 # unless PCLK means something else then I am used to 00.13.09 # 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 # yes i added a few delays to the display driver 00.13.26 # but maybe not enough 00.13.30 # like the fuze using the display bus as button pins 00.13.55 # wodz: IIRC the PCLK is divided as needed to generate most of the clocks, except DRAM 00.13.59 # clip+ and zip are very similar indeed 00.14.45 # saratoga: ok, if that is the case driving it as high as possible makes sense 00.15.12 # 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 # so i don't think we're too high 00.15.44 # both the clip+ and zip have put tens of hours using it without a single crash 00.15.47 # It would be extremely weird for dram not supporting 100+ 00.15.51 # 3Gerrit review #100 at http://gerrit.rockbox.org/r/100 : 3IAP rework patch 8: Revert to static buffers by Ralf Ertzinger 00.15.56 # lol 00.15.58 # ha 00.16.15 # but we could use more testing if anyone wants to try the builds i posted on the forums 00.16.59 # my clipv2 mostly works with the changes, skip's doesn't even boot 00.17.04 # so there is some variation between devices 00.17.56 # how is gpio block clock derived? Maybe this is as simple as changing the divider somewhere 00.18.22 # IIRC its divided down from the pclk, but it should be the same on the clip+ and zip as well 00.21.50 # 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 # my device thinks that most buttons are being held all the time 00.23.08 # although hold works fine 00.24.04 # hold looks like regular GPIO readout 00.24.48 Quit saratoga_ (Ping timeout: 246 seconds) 00.25.17 # I'll be offline for about a week, just to let you guys know 00.25.51 # i'll be super busy until the holidays as well 00.25.57 # although i'd like to do a release 00.26.35 # I wonder if the logic at button-clip.c lines 108 and 111 is correct 00.28.07 # 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 # 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 # 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 # 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 # 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 # 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 # prof_wolfff: hmm indeed it seems that ATA error plagues only 'Thick' model 00.41.32 # but 7gen is NOT CEATA AFAIK 00.42.07 # no, AFAIK the only CEATA is the 160 thick 00.43.46 # Right. The forum thread you linked is named ATA Error -2147483542 iPod Classic 7thGen 00.44.52 # although most 'me too' in the thread are for 160GB thick model 00.45.31 # TheSeven comments this error is generated by CEATA code 00.45.58 # prof_wolfff: No. TheSeven commented that such error code is impossible :P 00.47.12 # 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 # 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.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 # i think its just a null statement since the preprocessor just does a find and replace 01.22.29 # its basically s/sizeof(x)/sizeof(x) 01.22.36 # hm... 01.22.50 # prof_wolfff: lots of people confuse generations all over the place 01.22.59 # so I wouldn't trust anyone saying "7g" 01.24.15 # <[Franklin]> saratoga: actually it expands to sizeof(x) 01.24.19 # prof_wolfff: do you have a clue what ceata_wait_idle() 2,2 is? 01.24.24 # IIUC that code doesn't exist 01.24.42 # <[Franklin]> (which I now see is what you meant) 01.24.48 # at least not in git as of the time when I analyzed that (and nothing should have changed in the meantime) 01.25.18 # isn't that what i said? 01.25.36 # 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 # error -2147483542 is 8000006A 01.28.07 # yes, i am updated, PASS_RC(ceata_wait_idle(),2,2) is at line 567 01.28.33 # what's the root of that function tree? 01.28.40 # ata_init? 01.29.09 # <[Franklin]> 19:24 < [Franklin]> (which I now see is what you meant) ;) 01.29.26 # yes, i think it comes from main()->storage_init() 01.30.02 # so yeah, that's PASS_RC(ata_bbt_reload(), 0, 0); 01.30.35 # old driver version doesn't executes ata_set_feature() function for CEATA 01.30.58 # 6a is 1101010, so that's PASS_RC(ata_power_up(), 1, 0); with 110101 left 01.32.29 # oh, I think I see what happened 01.32.45 # looks like I thought I was still in that else branch in ata_power_up when I last looked at that 01.32.52 # that explains a lot of things 01.33.22 # so it's "enable write cache" that's failing? 01.33.50 # so fixing the (completely broken) ata_set_feature from the old driver actuall broke things. dammit. 01.36.08 # 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 # 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 # i don't know what is that GPIO, line 592 was not there before 01.38.25 # hm, pulling something high, but no idea what 01.39.32 # 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 # 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 # pulling it before writing the following registers could broke things ? 01.40.06 # there's likely something in parallel to it 01.40.43 # the *((uint32_t volatile*)0x3cf00200) = 0xb000f; line does indeed look redundant 01.41.02 # I guess we didn't know what that GPIOCMD reg was back when we transcribed that from a disassembly 01.42.09 # hm, one possible explanation for that pin could be a supply for SDIO pullup resistors 01.42.19 # which you want to shut down when unpowering the disk 01.42.33 # but that's just a wild guess 01.42.42 # it does seem to be ceata-specific though 01.42.55 # PCON(11) |= 0xf was introduced in the new driver version, it was not there before 01.43.12 # yes, along with a shitload of other missing GPIO accesses 01.43.20 # those were transcribed from some disassembly 01.44.23 # 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 # IIRC OF puts GPIO as output high for lowest power consumption, it makes more sense that configuring them as input 01.44.51 # not if the drive is powered down 01.44.53 # sorry, OF puts GPIO as output LOW 01.44.56 # ok 01.45.05 # where does it do that? 01.45.26 Join mirak_ [0] (~mirak@static-176-182-184-17.ncc.abo.bbox.fr) 01.45.36 # I'm not sure what I used as a reference, could have been a bootloader, diagmode, or something like that 01.46.15 # need to find it, but i think it is at OSOS 01.47.10 # 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 # where do the 200/1000mA steps come from? 01.48.32 # http://cds.linear.com/docs/en/datasheet/4066fc.pdf 01.48.33 # 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 # so you think they messed with the CLPROG pin somehow? 01.49.16 # by pulling it low through an additional resistor and a GPIO? 01.49.30 # 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 # 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 # 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 # my old one died a while ago 01.51.21 # 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 # 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 # heh, way too many things on our todo list 01.53.46 # 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 # 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 # what kind of issues is that one addressing? 01.56.24 # 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 # 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 # there are other patches for HAVE_RECORDING, HAVE_SERIAL and HAVE_IAP 01.59.59 Quit mirak_ (Quit: Ex-Chat) 02.00.41 # 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 # is someone still working on fixing nano2g? just wondering :D 02.57.45 # <[Franklin]> sakax: TheSeven is overloaded right now 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.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.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.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.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.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.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 # 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 # pamaury: And it would be good to document those macros anyway 09.24.43 # well, BF_SET is really just a write to the _SET variant of the register 09.25.00 # imx is not the only target with SCT variants 09.25.42 # pamaury: sure but for targets without SCT BF_SET/CLR/TOG still have a merit (but obtained differently) 09.26.10 # why not use BF_WR then ? 09.26.40 # You can, sure. 09.27.50 # Maybe we can change this but my initial way: 09.27.50 # 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 # - BF_SET/CLR/TOG only apply to register variants, because they have a different semantic 09.27.50 # - BF_WR applies to all, it always work but does RMW 09.28.40 # 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 # what about BF_SCT_{SET,CLR,TOG} 09.29.31 # and regular BF_{SET,CLR,TOG} 09.29.40 # isn't it a bit confusing ? 09.30.09 # I understand why you did this that way but it is not correct for non SCT 09.31.39 # 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 # I'd suggest like BF_OR, BF_XOR, BF_NAND but that might be confusing 09.32.14 # 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 # yes absolutely, that's a safetey mechanism: you just can't BF_SET a register without a _SET variant 09.33.32 # hell BF_OR is already used anyway 09.34.42 # what about BF_BIT_{SET,CLR,TOG} ? 09.36.39 # you will know instantly as there will be no definition of _SET variant and compiler will tell you that 09.37.22 # yes, that's the intended behaviour 09.37.51 # BF_BIT_* name implies single bit manipulation which is not generally true 09.38.30 # 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 # yeah, kinda stupid but grep should do 09.39.09 # but that's far less readable imo, you need to write the register twice 09.39.32 # although I agree it has the advantage of not requiring knowledge about the variants 09.40.41 # maybe I could create a macro like BF_ASSIGN(reg, variant, field) which would do this 09.41.05 # how reg_SET = xxx solve anything? It is still not right for non SCT 09.41.32 # ah, I read it wrong 09.41.36 # that for existing code 09.42.05 # there is a lot of code (114 lines of BF_SET, 114 lines of BF_CLR and 2 BF_TOG) 09.42.07 # you mean eliminate *current* SCT aware BF_SET from existing code 09.42.18 # yes 09.43.14 # hmm, whats wrong with BF_SCT_* then? simple substitution of name in code and freeing up BF_* for generic variant 09.43.42 # I don't like the mix of both, it's too confusing 09.44.37 *** Saving seen data "./dancer.seen" 09.45.10 # 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 # SCT_{SET, CLR, TOG} maybe? 09.46.13 # to not confuse with BF_ 09.46.22 # maybe, very easy to misread though, and yes documenting the macros would be a good idea 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.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.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.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 # 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 # this is the part where Rockbox for android crashes: http://pastebin.com/uBDxKGLA 13.57.00 # 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 # looks like it can't find rockbox.so 13.58.03 # foolsh: is there a way to find out? 14.02.40 # cronix: Does the path "/sdcard/rockbox" exist? 14.03.16 # foolsh: isn't rockbox.so searched in internal storage? 14.04.05 # foolsh: jep i created it to test if it extracts the so files to sdcard instead of the internal lib path 14.04.56 # ive put a rockbox-info.txt file there 14.05.05 # it does not extract anything at all 14.05.14 # (running on android 2.3.3 device) 14.05.26 # and rockbox crashes instantly when i start the app 14.09.11 # 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 # it should, just ckecking 14.09.52 # lemme check 14.10.33 # 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 # mhm /data/data/org.rockbox/ exists with drwxr-x--x app_0 app_0 14.23.20 # /data/data/org.rockbox/app_rockbox/rockbox does not though 14.25.08 # /data/data/org.rockbox/ just contains a lib folder 14.26.22 # that one is empty though 14.26.31 # owned by system:system 14.26.58 # drwxr-xr-x 14.29.24 Quit wodz (Quit: Leaving) 14.29.51 # 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 # the libs are embedded inside of the apk tough 14.30.37 # and ive tested the exact same apk on the android emulator with an android 2.3.3 image before 14.30.45 # it works fine over there 14.30.55 # just not on the pono player 14.31.13 # do you have root? can you manually put them in place? 14.31.30 # i have root, that was archived about an hour ago 14.31.33 # just not adb 14.31.38 # Are you using linix then btw? 14.31.43 # jep 14.32.03 # have you created a udev rule for your pono player? 14.32.08 # jep aswell 14.32.12 # hmm 14.32.24 # rebooted since then? 14.32.26 # SUBSYSTEM=="usb", SYSFS{idVendor}=="2aa1", MODE="0666" 14.32.28 # nope 14.32.39 # but i tried yesterday at home on my laptop aswell 14.32.41 # couldn't hurt but might not help 14.32.44 # windows and linux 14.32.48 # rebooted several times 14.32.49 # geez 14.32.51 # did not work 14.32.57 # its a pain :o 14.33.21 # i also modified the build.prop to enable adb 14.33.28 # and the adbd is running fine 14.34.12 # but the logcat shows this when i connect a usb cable: http://pastebin.com/66GGapMY 14.34.44 # usb debug enabled on the player? 14.34.48 # jup 14.34.51 # dang 14.34.59 # also dis and reanabled it already 14.35.23 # got yourself a real pickel there 14.35.31 # jup :D 14.35.43 # are you building the pono image yourself? 14.35.48 # but first steps are already done, i got it rooted ^ 14.35.53 # no access to pono sourcecode 14.36.01 # im just carefully copying files 14.36.21 # https://file-cloud.eu/public.php?service=files&t=8a42782613be966425cbb4e65290788a 14.36.29 # thats the image updater zip 14.37.29 # thats the adbd related stuff inside of my initram init.rc: http://pastebin.com/TRiDCwPJ 14.37.52 # and i checked with getprop for persist.service.adb.enable=1 and that one is indeed @ 1 14.39.07 # so your modifying this update image? 14.39.21 # exactly 14.39.32 # ah, 14.39.46 # resigning with android test-keys is enough for the pono's recovery to accept that image 14.40.12 # thing is, there is no key kombination to force the pono to boot to recovery 14.40.25 # and no fastboot or any other method of debricking 14.40.38 # thats why im pretty damn careful about what to modify 14.41.22 Join amayer [0] (~amayer@mail.weberadvertising.com) 14.42.05 # firmware update is triggered by putting a *.update file onto the .pono directory on the internal sd card 14.42.12 # and unplug the usb cable from the pc 14.42.34 # then the player scans for that update file and prepares the update, reboots to recovery and flashes the new zip 14.42.49 # all fully automated and triggered by the official pono player apk 14.43.00 # it does not happen when im inside of laucher2.apk 14.43.15 # that thing is pretty damn weird 14.43.50 # preparation is done by copyting said update file to /cache/recovery/ 14.44.29 # Offtopic but sounds like it needs someone to modify that update process to flash a custom boot loader ;) 14.45.07 # jep indeed 14.45.26 # afaik its boot loader is an u-boot 14.45.42 # i still want to dump all the partitions on the device 14.45.52 # will do that in the evening (about 3-4 hours from now) 14.47.36 # package_extract_file("boot.img", "/dev/block/platform/mmci-omap-hs.1/by-name/boot"); 14.47.44 # that is default android behaviour though 14.48.01 # where as boot.img contains the kernel and ramdisk 14.51.25 # 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 # which ressources? 14.52.02 # just unzip the whole apk there? 14.52.45 # 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 # 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.04.18 # cronix: /data/data/org.rockbox/lib/libmisc.so needs to exist and.... 15.04.52 # "/data/data/org.rockbox/app_rockbox/rockbox/rockbox.so" OR "/sdcard/rockbox/rockbox.so" I think 15.05.10 # and they need proper permissions 15.07.04 Join xorly [0] (~xorly@wced-243-218-32-147.feld.cvut.cz) 15.08.34 # there may be more though 15.25.01 # okay thanks 15.25.16 # i just dumped all the nand and mmc partitions :D 15.31.47 # Texas Instruments X-Loader 1.51 -> u-boot -> android 15.32.27 # for the x-loader there is source code: https://gitorious.org/x-loader/x-loader/source/master: 15.33.46 # cronix: this is becoming off topic head over to #rockbox-community so the public logs don't become clobbered 15.34.02 # sorry 15.34.26 # :) 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.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.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.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.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 # 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 # 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 # You've been busy :) 19.57.43 # 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 # I was? 19.58.12 Join lebellium [0] (~chatzilla@128-79-0-151.hfc.dyn.abo.bbox.fr) 19.59.01 # you aren't in the las iAP commit?, maybe i am wrong, will look it again 19.59.16 # Hmmm 19.59.35 # 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.18 # 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 # Build Server message: 3New 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 # Build Server message: 3Build round completed after 484 seconds. 20.58.08 Quit rela (Ping timeout: 272 seconds) 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.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 # 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 # 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 # 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 # 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 # but jack mics are cheap, no more than $3 and acceptable quality for voice recording 22.58.37 # 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 # unboosted recording works well 22.59.51 # <[Franklin]> perhaps someday DAPs /will/ ship with rockbox pre-installed :) 23.00.20 # * gevaerts very much doubts that 23.01.07 # IIRC i have seen it on eBay 23.01.35 # * [Franklin] queries "rockbox" on ebay 23.01.55 # <[Franklin]> yep 23.02.21 # 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 # They still leave the factory with something else installed 23.06.21 # someone do a kickstarter for a rockbox branded DAP :) 23.07.12 # I think we have way too many features for any QA department to feel comfortable with 23.07.55 # 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 # 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)