--- Log for 20.11.116 Server: karatkievich.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 1 month and 13 days ago 00.54.59 *** Saving seen data "./dancer.seen" 01.09.45 # probably drawing too much 01.10.10 Quit petur (Remote host closed the connection) 01.10.17 # the battery seems to just stay in stasis, not quite charge but not drain 01.10.27 # the thing gets warm too. 01.10.59 # I might have to make a cable to charge from usb straight to the jack 01.11.09 # try a 2 amp charger? 01.11.34 # I've tried the yellow usb port on this thinkpad, it's supposed to be higher current 01.11.35 # although if the SSD is really drawing 500 mA, i wonder if the battery will even last long enough to matter 01.11.48 # yeah the battery lasts a long time 01.11.54 # how long? 01.12.29 # dunno. a few hours each day and a few days before it starts to get low? 01.12.58 # charging with the jack works fine 01.12.59 # <[Saint]> I would expect a thinkpad to actually be bothering to have the client enumerate its power requirements to the host over USB before dishing out 2A. 01.13.06 # if you get 10 hours from a 1700 mah battery, that is at most 170 mA, in which case your battery would be charging at more or less normal rate 01.13.22 # even on a 500 mA port 01.13.24 # it was a 2200mAh one but I doubt it still is now 01.13.55 # actually it's a couple of years old and probably shot, the thing gets warm with the whole unit powered up and trying to charge from a normal usb port 01.14.17 # but that's obviously with the drive active and mounted 01.16.12 # i continnue to recommend using a 2 amp charger and if that doesn't work, pulling out the ssd and seeing if it charges then 01.16.49 # it just heats up 01.16.55 # the wall charger works 01.21.44 Quit edhelas (Quit: Leaving.) 01.29.54 Quit saratoga_ (Ping timeout: 260 seconds) 02.06.52 # Bilgus: Thanks for the update. I'm installing it now on by brand new Zip. Will let you know how it goes. 02.08.36 Quit xorly (Ping timeout: 268 seconds) 02.24.31 Quit krnlyng (Ping timeout: 246 seconds) 02.25.28 # Bilgus: Only had a couple minutes to play with the new version so far. I'm pretty sure I once saw the backlight timer fail to reset with the 11/16 version, so I'll make sure to do some more testing of that. 02.25.59 Part robertd1 02.26.18 # Then again, as long as the issue is rare, now that you've solved (AFAICT) the issue with the delay in the screen turning on, it isn't a serious issue as long as it isn't common. 02.26.28 # Great work. Thank you very much. 02.37.48 Join krnlyng [0] (~liar@178.112.250.131.wireless.dyn.drei.com) 02.42.43 Quit ender` (Quit: Remember: A secretary isn't permanent until she's been screwed on the desk.) 02.45.17 Quit toli (Quit: ZNC - http://znc.in) 02.48.51 Join Bilgus [0] (41ba23be@gateway/web/freenode/ip.65.186.35.190) 02.49.49 Join toli [0] (~toli@ip-62-235-240-46.dsl.scarlet.be) 02.51.36 # TorC: let me know about the timeout thing especially what screen you are on when it happens AFAIK it shouldn't be an issue with this new method 02.55.00 *** Saving seen data "./dancer.seen" 03.25.44 # <[Saint]> Christ, seriously? 03.25.47 # <[Saint]> http://forums.rockbox.org/index.php/topic,51573.new.html#new 03.43.06 # On threads what does the stack hold? Does it push pop the current variables addresses and the current stack pointer? Any way to know how full it is? 03.44.09 # <[Saint]> Wow. I should look at the forums more often. 03.44.20 # <[Saint]> http://forums.rockbox.org/index.php/topic,51567.msg238388.html#msg238388 is absolutely savage, and hilarious. 03.44.47 # <[Saint]> Made even more hilarious by the fact that OP almost assuredly thinks he's right as he's a Very Smart Person. 03.45.34 # <[Saint]> >insults devs who donate their time 03.45.37 # <[Saint]> >gets rekt 03.46.22 Quit ZincAlloy (Quit: Leaving.) 04.19.38 Nick Guest39945 is now known as alexbobp (~alex@testificate.xen.prgmr.com) 04.27.15 Quit Bilgus (Ping timeout: 260 seconds) 04.32.37 Join Saratoga_ [0] (32b117cb@gateway/web/freenode/ip.50.177.23.203) 04.33.07 # I think that guy isn't quite right given some of his posts over the years 04.38.37 # <[Saint]> That's a far more deleicate way of putting it than I would like to. 04.38.45 # <[Saint]> I had to refrain personally. 04.40.23 # <[Saint]> The fact that even despite yourself and pamaury's best attempts to do so it is very difficult to explain to him the relation between source files and the resulting binar{ies|y} doesn't help. 04.41.00 # <[Saint]> Any given binary may contain assets from hundreds of individual files of which any amount may or may not have edits for that particular build. 04.41.09 # <[Saint]> Kinda breaks his assumptions horribly. 04.42.18 # <[Saint]> If the dude from the first thread responds in the way I believe he might I'm just locking the thread no questions. 04.42.38 # <[Saint]> I should probably have done so preemptively but I'll give the benefit of doubt. 04.55.04 *** Saving seen data "./dancer.seen" 05.03.48 Quit toli (Ping timeout: 256 seconds) 05.06.06 Quit scorche|sh (Remote host closed the connection) 05.14.35 Quit [Saint] (Remote host closed the connection) 05.15.28 # <__builtin> forums look down to me 05.16.11 Join [Saint] [0] (~sinner@rockbox/staff/saint) 05.25.55 Join toli [0] (~toli@ip-62-235-237-254.dsl.scarlet.be) 05.26.12 Quit fishbulb (Ping timeout: 248 seconds) 05.33.16 Quit toli (Ping timeout: 256 seconds) 05.46.33 Join toli [0] (~toli@62.235.88.46) 05.53.40 Quit toli (Ping timeout: 256 seconds) 05.57.19 Join Senji [0] (~Senji@85.187.103.250) 06.01.55 Quit x56 (Quit: Ծ-Ծ) 06.05.27 Join toli [0] (~toli@ip-62-235-239-79.dsl.scarlet.be) 06.18.37 Join Sasasu [0] (~li@180.212.140.37) 06.30.53 Quit Senji (Ping timeout: 245 seconds) 06.55.05 *** Saving seen data "./dancer.seen" 07.01.16 Quit TheSeven (Ping timeout: 240 seconds) 07.01.34 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 08.15.41 # Bilgus: I will if I catch the backlight timer issue again. I've now got the 16th version on one zip and the latest on another, so I can do a bit of testing if I find it. I don't plan on testing the 16th version any more unless it is to attempt finding regressions. 08.15.48 Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 08.15.48 Quit pixelma (Quit: .) 08.16.03 Join pixelma [0] (~pixelma@rockbox/staff/pixelma) 08.16.05 Join amiconn [0] (~amiconn@rockbox/developer/amiconn) 08.55.09 *** Saving seen data "./dancer.seen" 09.03.38 Join ender` [0] (krneki@foo.eternallybored.org) 09.34.06 Quit toli (Ping timeout: 256 seconds) 09.58.12 Join toli [0] (~toli@ip-62-235-212-227.dsl.scarlet.be) 10.02.40 Quit Saratoga_ (Ping timeout: 260 seconds) 10.04.09 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 10.06.14 # Bilgus: OK, I've found one repeatable case where the newest build you made will fail to reset the backlight off timer. 10.07.38 # That is when using the power button to step back in the file hierarchy - only when going from files to main menu. 10.09.05 Quit megal0maniac (Read error: No route to host) 10.09.06 # The main reason I've noticed is that I've been testing with a 3s timer and carefully making steps every 2s to find issues. 10.09.55 Join megal0maniac [0] (~megal0man@unaffiliated/megal0maniac) 10.29.47 Join johnb2 [0] (~johnb2@pD957D5DB.dip0.t-ipconnect.de) 10.38.04 # Bilgus: I just grabbed the clip+ version. 10.44.19 # First impression: responsiveness of display turn on is fine. One little quirk: I have not selected Seek. When starting to seek there is a brief noise in the beginning which is not there with the regular build (like volume is not turned down the same way). 10.55.12 *** Saving seen data "./dancer.seen" 10.59.17 # I should mention that the backlight turning off when it shouldn't only applies to the power button step, not to left button step. 10.59.35 # johnb2: Does your Clip+ exhibit the same behaviour? 11.00.08 # That if stepping back in directories using the power button, that the backlight off timer isn't reset when going from root to main menu? 11.00.58 # you mean the screen stays on forever? 11.01.37 # No. The screen goes off before the timer should make it go off - the last press that goes from root to main menu doesn't reset the timer, so the BL turns off early. 11.02.03 # I will try ... 11.02.21 # I've been using a 3s BL timer to troubleshoot this. 11.02.43 # Long enough to exhibit the issues clearly, not so long it gets horribly boring to test... 11.04.12 Quit toli (Ping timeout: 256 seconds) 11.06.11 # For me, it's only power, not left that does it. 11.10.47 Join toli [0] (~toli@ip-62-235-221-78.dsl.scarlet.be) 11.12.14 # TorC: Yes, I can confirm for timer set to 3 or 7 sec. For 10s I don't see it. 11.12.55 # Confirming also power vs. left button. 11.15.59 Join robertd1 [0] (~root@201.208.231.245) 11.19.08 # Bilgus: More an odd behaviour that isn't a big deal: When I turn on my Zip with a 3s BL timer, and let the BL expire, on the main menu (default turn on screen) the backlight won't turn on until the second button press. 11.20.02 # johnb2: Bilgus: I seem to still see the timer not resetting even with a 10s BL timer (/ to main menu) 11.21.33 # The longer the BL timer, the less obvious the failure to reset is, and the less likely it is to annoy someone, of course. 11.23.08 Join xorly [0] (~xorly@ip-89-176-10-118.net.upcbroadband.cz) 11.23.52 # *At least in practical usage. Corner cases is where it will show up obviously. 11.24.22 # Does anyone actually use the power button to step back in menus in normal usage? 11.27.12 # Seems like doing so will also stop current playback, so it probably is so rare that if this is the only case of failure to reset BL timer found, it might as well be a "Won't fix" 11.31.04 # *On turn on bug mentioned above (BL not responding to first button press): It applies to scrolling either direction in main menu or to entering file browser (default selection) with either select or right. 11.32.54 # Thought of something else to test: Resuming playback with the Home? button. Also exhibits issue. 11.35.31 # Turn on bug doesn't happen with noBLsel turned off, so it's definitely related to the function. 11.35.54 # Heading to bed now. Will review the logs for anything I miss. 11.40.33 Quit advcomp2019 (Ping timeout: 250 seconds) 11.48.31 # TorC: No, I don't ever use the Power button for navigating, only Left, Right and Home. 11.53.12 Quit johnb2 (Ping timeout: 268 seconds) 11.57.05 Join advcomp2019 [0] (~advcomp20@65-131-157-74.sxct.qwest.net) 11.57.05 Quit advcomp2019 (Changing host) 11.57.05 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) 11.57.07 Quit PurlingNayuki (Ping timeout: 245 seconds) 12.01.26 Join johnb2 [0] (~johnb2@pD957D5DB.dip0.t-ipconnect.de) 12.20.10 # TorC: Do you mean " Go back to WPS" instead of "Resume Playback"? 12.21.47 Quit pamaury (Ping timeout: 260 seconds) 12.21.50 Join pamaury_ [0] (~pamaury@rockbox/developer/pamaury) 12.22.20 # Then I don't see this with the Home button. Here is what I am doing: Timer set to 5s. While playing a song, I am in the file browser, wait for 3s and then go to WPS with quick clicks of Home. Screen goes of after 5s. 12.34.51 Quit toli (Ping timeout: 256 seconds) 12.48.00 Join toli [0] (~toli@ip-62-235-215-137.dsl.scarlet.be) 12.50.43 Quit xorly (Ping timeout: 260 seconds) 12.55.15 *** Saving seen data "./dancer.seen" 12.57.56 Quit fs-bluebot_ (Ping timeout: 248 seconds) 12.58.57 Quit bluebrother (Ping timeout: 258 seconds) 13.04.19 Quit idonob (Ping timeout: 256 seconds) 13.05.44 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:203b:5666:a7e1:3f7e) 13.06.16 Join idonob [0] (~Owner@S010610c37b922980.vs.shawcable.net) 13.20.03 Join fs-bluebot [0] (~fs-bluebo@xd9befef3.dyn.telefonica.de) 13.20.36 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 13.22.27 Join xorly [0] (~xorly@ip-89-176-10-118.net.upcbroadband.cz) 13.23.18 Quit idonob (Ping timeout: 260 seconds) 13.25.19 Join idonob [0] (~Owner@S010610c37b922980.vs.shawcable.net) 13.29.19 Quit johnb2 (Ping timeout: 250 seconds) 13.31.33 Quit GodEater (Quit: Coyote finally caught me) 13.33.16 Quit Moarc (Ping timeout: 240 seconds) 13.34.06 Join Moarc [0] (~chujko@a105.net128.okay.pl) 13.35.23 Quit bluebrother (Ping timeout: 244 seconds) 13.35.26 Join GodEater [0] (~whoknows@90.218.131.42) 13.35.27 Quit GodEater (Changing host) 13.35.27 Join GodEater [0] (~whoknows@rockbox/staff/GodEater) 13.36.41 Quit fs-bluebot (Ping timeout: 265 seconds) 13.38.34 Quit benedikt93 (Remote host closed the connection) 13.39.06 Join benedikt93 [0] (~quassel@unaffiliated/benedikt93) 13.42.29 Join edhelas [0] (~edhelas@mic92-11-82-245-215-98.fbx.proxad.net) 13.46.59 Join johnb2 [0] (~johnb2@pD957D5DB.dip0.t-ipconnect.de) 13.50.19 Quit Moarc (Ping timeout: 258 seconds) 13.50.48 Join Moarc [0] (~chujko@a105.net128.okay.pl) 14.02.05 Quit edhelas (Ping timeout: 268 seconds) 14.05.31 Quit toli (Ping timeout: 256 seconds) 14.12.23 Quit pamaury_ (Ping timeout: 260 seconds) 14.12.37 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 14.16.21 Join petur [0] (~petur@rockbox/developer/petur) 14.17.15 Quit johnb2 (Ping timeout: 250 seconds) 14.17.59 Join toli [0] (~toli@ip-62-235-221-153.dsl.scarlet.be) 14.24.06 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 14.36.48 Join TheLemonMan [0] (~root@unaffiliated/thelemonman) 14.39.08 Join fs-bluebot [0] (~fs-bluebo@xd9befef3.dyn.telefonica.de) 14.45.27 Part robertd1 14.45.57 Join Bilgus [0] (ae6611d9@gateway/web/freenode/ip.174.102.17.217) 14.54.23 # TorC i'll keep trying to reproduce, Johnb2 I'm not able to hear anything on seek on my clip+ and I havent touched the functionality of what the buttons do 14.55.17 *** Saving seen data "./dancer.seen" 14.58.01 # TorC i can try making the timeout reset on context change probably a good idea anyways 15.00.58 Join lebellium [0] (~chatzilla@ren77-h01-176-151-188-9.dsl.sta.abo.bbox.fr) 15.06.09 Quit toli (Ping timeout: 256 seconds) 15.17.55 Quit krnlyng (Quit: krnlyng) 15.18.04 Join krnlyng [0] (~liar@178.112.250.131.wireless.dyn.drei.com) 15.22.02 Join toli [0] (~toli@62.235.64.51) 15.22.03 Join johnb2 [0] (~johnb2@pD957D5DB.dip0.t-ipconnect.de) 15.22.53 # Bilgus: Try an accustic guitar track, have the screen black for a while and seek backwards 15.23.44 # I tried it with flac and mpc. 15.24.01 # s/tried/verified 15.25.02 # if anything it's probably the little bit of added delay due to the thread but it has lower priority than any of the playback stuff I'll keep looking once I fix these other items 15.27.07 Quit toli (Ping timeout: 256 seconds) 15.29.56 # Not sure if related, but with this build on the clip+ it suddenly fails to mount properly on two different PCs running Win10: I hear the connection sound, drive letters show up, but nothing visible. Holding Select while connecting works. I will monitor this ... 15.34.53 # It could have to do with the base build idk if you could try patching to an older build or install a clean current build and see if it persists 15.35.34 # give me a few and I have some fixes/memory savings going up 15.36.07 Quit johnb2 (Ping timeout: 250 seconds) 15.56.44 Quit guest12345 (Ping timeout: 260 seconds) 16.05.45 Join johnb2 [0] (~johnb2@pD957D5DB.dip0.t-ipconnect.de) 16.10.53 Quit lebellium (Quit: ChatZilla 0.9.93 [Firefox 50.0/20161104212021]) 16.14.00 # Current dev build works fine! 16.14.19 # regarding USB mounting ... 16.26.59 Join einhirn [0] (~Miranda@p4FC11B99.dip0.t-ipconnect.de) 16.27.32 # <__builtin> hey, it looks like puzzles requires a bunch of floating-point math 16.27.57 # <__builtin> can I work around this, stopping short of rewriting everything to use fixed-point? 16.28.11 # <__builtin> and it also doesn't fit in the plugin buffer 16.32.14 # <__builtin> apparently it's nearly twice as big as the pluginbuf on the classic 16.33.13 # <__builtin> I guess an overlay plugin would solve the problem 16.33.24 # <__builtin> but then where do I get memory for the malloc pool? 16.34.32 # <[Saint]> You'd probably be a fan of my thinking that a fixed plugin buffer is pretty retarded when we have buflib. 16.34.54 # <[Saint]> But then you'd just create monstrous plugins. 16.34.58 # <[Saint]> :p 16.35.01 Quit johnb2 (Ping timeout: 268 seconds) 16.35.16 # <__builtin> so overlays go in the audiobuf usually 16.35.41 # <__builtin> so can I still use plugin_get_audio_buffer? 16.36.22 # <[Saint]> I don't see why not. 16.36.49 # <__builtin> so the function is smart enough to skip over wherever the plugin is loaded, right? 16.37.29 # <[Saint]> Might want to double-check this, but...yes? 16.37.43 # <[Saint]> It's been an age since I looked. 16.38.21 # <__builtin> it looks like the actual function has some buflib magic in it 16.38.45 # <[Saint]> What you're wanting to do was a large part of the point of buflib. 16.38.57 # <__builtin> also, the floating-point functions 16.39.15 # <[Saint]> That, you're gonna have to eat. 16.39.35 # <__builtin> can I just write a bunch of floating-point wrappers around the fixedpoint lib? 16.40.05 # <[Saint]> In theory, I guess. Is there really that many? 16.40.52 # <__builtin> there's not too many, but it's not a small number either 16.41.15 # <__builtin> it's mostly vanilla trig though 16.41.29 # <__builtin> sin, cos, atan, and sqrt make up the vast majority of the calls 16.42.17 # <[Saint]> Might be easier to just do fixed point conversion on a case by case basis. 16.42.36 # <[Saint]> Unless it's riddled with them. 16.42.50 # <__builtin> I'm actually just hoping I can leave the actual puzzles untouched as was Tatham's intention 16.43.19 # <[Saint]> Fair. 16.43.33 # <[Saint]> Wrappers it is then. 16.45.25 # <__builtin> looks like lua already has a bunch 16.47.24 # <__builtin> actually, nope :( 16.47.41 # <__builtin> whoever ported it #if'd out everything I was looking for 16.49.11 # <[Saint]> They saw you coming a mile away. 16.49.36 Join toli [0] (~toli@ip-83-134-73-184.dsl.scarlet.be) 16.51.03 # <__builtin> this whole port was a hack from the very beginning 16.51.38 # <__builtin> pretty much "vsprintf_wrapper(buf, va_list ap) { rb->vsnprintf(buf, 99999, ap); }" 16.55.19 *** Saving seen data "./dancer.seen" 16.56.24 Join Saratoga_ [0] (32b117cb@gateway/web/freenode/ip.50.177.23.203) 16.57.08 # I think for plugins you can use floating point, however it will be very slow since the compiler generates software for operations 16.57.49 # <__builtin> Saratoga_: ok, I was just wondering how I would fix the missing math functions 16.57.52 # <__builtin> sin, cos, etc. 16.58.23 # Hmm yeah I guess we don't have math.h 16.58.50 # We have fixed versions of them 16.59.07 Quit Sasasu (Quit: WeeChat 1.0.1) 16.59.15 # Or you could do a look up table if you don't need too much accuracy 16.59.17 # <__builtin> so I was thinking, just "convert the float to fixed and then back again" 16.59.46 # That will work 17.01.11 # <__builtin> now the issue is with the functions that aren't in the fixed-point library 17.01.18 # What does this plugin use trig functions for ? 17.01.28 # <__builtin> I have no idea, actually 17.02.01 # * __builtin is trying to port sgtatham's puzzles 17.02.35 # What functions are missing? 17.03.14 # <__builtin> atan 17.03.39 # <__builtin> basically just the trig inverses 17.03.47 # <__builtin> and pow 17.04.43 # <__builtin> and a good sqrt, the one now only does integers 17.05.38 # <__builtin> I found Sun's "fdlibm" I'm not sure it's GPL-compatible 17.06.00 # <__builtin> "Permission to use, copy, modify, and distribute this software is freely granted, provided that this notice is preserved." 17.09.01 # MIT license I believe, which is GPL compatible 17.09.13 # <__builtin> ok, good 17.17.02 # arggg, dammit, toolchain nightmare is a nightmare 17.18.36 # <[Saint]> We're really in a sorry state in this regard. 17.19.01 # <[Saint]> We dont even compile against modern distros anymore with armeabi. 17.19.28 # I will fix it at the same time as I will create the sony toolchain 17.19.33 # <[Saint]> And if we fix armeabi (at least the way I handle it), we break elsewhere. 17.19.55 # arm is easy to fix, mips really needs an upgrade though 17.20.05 # <[Saint]> Unless you're also talking switching to the new MIPS as well? 17.20.16 # <[Saint]> We break it as is fixing arm. 17.20.51 # <[Saint]> And ypr0 is an unsatisfiable clusterfuck mess. 17.21.05 # I am going to introduce a new mips toolchain, fix arm, it's going to break old mips but not new mips. Then we are fine as long as we have buildclient with old mips 17.21.12 # <[Saint]> I've literally never managed to compile it, ever. 17.21.36 # and then I'll try to find someone to make sure the new mips works on the old mips targets, so we can drop old mips 17.21.45 # <[Saint]> I, and you, and everyone I know is using a bi are set kugel built years ago. 17.21.58 # <[Saint]> I've been passing it down like a family heirloom for years. 17.22.25 # <[Saint]> *binary set 17.22.38 # for ypr0, I have been thinking about it and I think there is simple way out of it: change the parameters of the ypr0 toolchain to use more "modern" components so that it builds again 17.22.57 # <__builtin> what is the atob() function!? 17.23.12 # <[Saint]> I would really love [7] to clarify how the hell he managed it. 17.23.18 # after all it's pretty much like the sony toolchain: we can use modern libraries as long as they support/are compatible with old systems. Which in the case of glibc is well documented 17.23.28 # <[Saint]> He just commented out a giant hunk of it I believe. 17.24.14 # <[Saint]> I chased the dependency dragon so far down the train but there's only so many times you can fail a build like that without wanting to slit your wrists. 17.25.58 # for me the biggest problem with current ypr0 is that the old glibc/binutils seems to rely on old make stuff, which inevitably breaks on modern systems 17.27.22 # like binutils 2.21 and gcc 4.4.6 and eglibc 2.12 17.27.55 Quit Moarc (Ping timeout: 260 seconds) 17.28.00 # we could try it with binutils 2.26, gcc 4.9.x and a modern recent eglibc (would have to check which version is still compatible with kernel 2.6.24 installed on ypt0 (iirc)) 17.29.28 Join Moarc [0] (~chujko@a105.net128.okay.pl) 17.34.44 Quit Saratoga_ (Ping timeout: 260 seconds) 17.35.50 # <[7]> [Saint]: with a lot of messing around ;) 17.38.02 # <[7]> [Saint]: want a tarball of my build VM? (including .bash_history of setting it up I'd hope) 17.38.10 # <[7]> ubuntu 16.04 IIRC 17.40.39 # Who created the toolchain in the first place? And why did he choose such old components? 17.41.16 Quit Moarc (Ping timeout: 260 seconds) 17.41.28 # <[Saint]> Kugel, and, lord knows. 17.42.01 # <[Saint]> I think he piece mealed it together from someone else's partial tool chain. 17.42.56 Join Moarc [0] (~chujko@a105.net128.okay.pl) 17.44.20 # <__builtin> how do I convert a plugin to an overlay plugin? 17.44.50 # good question, if you tell me, let me know ;) 17.44.59 # I would say, have look at overlayed plugin 17.45.52 # <__builtin> time to copy+paste pictureflow.make --> puzzles.make 17.47.21 # pictureflow makefile is more complicated than needed for you 17.48.04 Join devsnd [0] (~devsnd@p200300D46BC07800FA68FF258211A6DA.dip0.t-ipconnect.de) 17.51.08 # Hi rockboxers, I'm trying to extract the firmware of a GoGear Ariaz (SA2ARA08K). I've gotten as far as finding the firmware online and also found the 'utils/imxtools/sbtools' to extract the firmware, but I'm missing the key. Does anybody know how to get the key to extract the firmware? 17.51.35 # <__builtin> holy crap it just compiled!!!!! 17.52.33 # devsnd, try with an all zero key, that's what samsung used on the yp-q2 17.53.01 # devsnd: most firmware use the zero key 17.53.05 # (option -z iirc) 17.53.14 # but GoGear might be an exception 17.53.26 # in this case, it's getting more complicated 17.53.41 # <[Saint]> __builtin: but does it run, and, if so, function? ;) 17.53.55 # <[Saint]> Compilation does not a functioning build make. 17.54.12 # <__builtin> well, it currently has a frontend that does pretty much nothing 17.54.20 # Compiling and linking is still a great milestone! 17.54.31 # <__builtin> so it will probably either run and crash or run and draw random stuff 17.54.39 # pamaury, just tried -z, but no luck. I saw that the source has brute force for version 1 sb files, but non for 2 17.54.52 # is the key space to big in v2? 17.54.59 # for v2 it's hopeless, AES128 ;) 17.55.10 # but there is another way using a rom exploit 17.55.20 # that works sometimes 17.55.29 # can you point me to the firmware? 17.55.40 # <[Saint]> How do you know hes not going to live for thousands of years, huh? 17.55.41 # <__builtin> [Saint]: "FATAL ERROR: out of memory" 17.55.48 # http://download.p4c.philips.com/files/s/sa2ara08k_17/sa2ara08k_17_hf1_deu.zip 17.56.09 # that's the german version, but 'eng' at the end might just as well work 17.56.55 # <[7]> so [Saint], do you want an image of that VM? 17.57.37 # devsnd: thanks, downloading 17.57.40 # <[Saint]> Hm? Oh. Sorry. I missed that. It couldn't hurt. 17.57.45 # [Saint], no need for thousands of years, just a bit of luck 17.57.55 # <[Saint]> :) 17.58.05 # * pamaury prefers to bypass luck when it's possible 17.58.43 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.") 17.59.11 # <__builtin> or someone could push a build that hijacks the build nodes to brute-force it 17.59.45 # <__builtin> [Saint]: looks like plugin_get_audio_buffer returns NULL in overlays 18.00.04 # <[Saint]> Interesting. 18.00.24 # <__builtin> time for char giant_buffer[1024*1024*16]; 18.01.49 # <__builtin> well, that gets me past the OOM error 18.02.05 # <__builtin> now I just have a data abort, yay 18.02.55 # devsnd: that's your lucky day, I think an exploit will work 18.03.19 # you have the device I presume? 18.03.43 # yeah, got the device next to me 18.03.53 # do you have linux? 18.03.56 # yees 18.04.35 # ok, give me couple hours, I will craft a fake firmware that you can upload in recovery mode and hopefully use to recover the key 18.05.00 # do you already have a copy of rockbox repository? 18.05.11 # yes, just checked it out to get the sbtools 18.06.47 # the player currently has no battery. that's the reason I even took a look at the thing, wanted to repair it just to find out that the battery was busted. I hope I won't need the battery for flashing... 18.07.33 # <__builtin> oh great, the sim doesn't even support overlays 18.08.29 # devsnd: as long as you can reach recovery mode, you can run some code. But may I ask what you plan to do with it if it has no battery? 18.09.12 # I wanted to use it as a status display for my storage server 18.10.06 # I have no idea what I am doing :) I wanted to see how the firmware worked to see if I could bitbang an image over USB or something 18.10.10 Join krabador [0] (~krabador@unaffiliated/krabador) 18.12.46 # pamaury, so I don't know if it's worth the hassle; maybe I should just solder in another battery and be done with it and try hacking those keychain picture frames instead 18.12.54 # well the firmware is a pretty big beast but the soc is well-supported by rockbox. If the device uses eMMC and not nand, with a little reverse engineering, you could easily reflash rockbox on it. Otherwise I see another option (that still involves reverse engineering) but it's a bit less practical 18.13.22 # (or if it has a microsd port that could work as well) 18.14.29 # can I spot the difference between eMMC and nand on the PCB or is it just a question of internal protocol? 18.14.41 # (it has not microsd port) 18.14.47 # s/not/no 18.17.30 # devsnd: if you upload a picture of the pcb I can tell 18.17.39 # or if you manage to read what is on it 18.18.52 # as a rule of dumb, nand flash is usually (I say usally) in a tsop package (google it for picture) whereas emmc usually in bga 18.19.31 # but if you can read what is on the die, that's probably a simpler solution 18.21.46 Join JanC_ [0] (~janc@lugwv/member/JanC) 18.22.13 Join johnb2 [0] (~johnb2@pD957D5DB.dip0.t-ipconnect.de) 18.22.15 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 18.22.19 # here's a picture of the PCB http://fomori.org/upload/month/IMG_20161120_181955.jpg 18.22.42 # looks like TSOP to me, so probably nand 18.22.59 Quit JanC (Ping timeout: 260 seconds) 18.23.01 Nick JanC_ is now known as JanC (~janc@lugwv/member/JanC) 18.25.45 Quit Guest7162 (Read error: Connection reset by peer) 18.26.55 # hum suspiciously like NAND indeed, problem with nand is that freescale uses a FTL that is hard to reverse engineer. But you could still use the player in recovery mode 18.29.20 # johnb2 http://gerrit.rockbox.org/r/#/c/1420/ 18.31.43 # I lowered the memory usage, shrunk the stack, and lowered the thread proirity.. if you have the usb issue can you go into system>debug> view OS stacks> and 1 tell me the % and 2 how many slots are --- and how many total slots 18.32.38 # the thread is 'sel backlight thread' you can hold the right button and it will scroll over the names 18.34.07 Quit toli (Ping timeout: 256 seconds) 18.34.45 # <[Saint]> Maybe. Iirc it's possible to disable that behavior, though it is default. 18.36.06 # pamaury, what do you mean by using it in recovery mode? I thought recovery mode was a direct interface to write to the nand and nothing else 18.39.58 # devsnd: recovery mode is in fact just an interface to run code 18.40.16 # you can use it to write to the nand, but you can also use it for anything else 18.40.37 # (so long as you have the key and the code) 18.40.46 Join toli [0] (~toli@62.235.115.102) 18.41.36 # so the recovery mode code needs to be encrypted using the same key as is used for the firmware? 18.41.42 # yes 18.42.17 # well, seems like a chicken and egg problem to me. 18.43.04 # so you wanted to bypass the encryption by directly writing to the eMMC, if it had existed. But now that it's nand, it's harder? 18.43.08 # <[Saint]> If the man you're talking to wasn't a ninja I might be tempted to agree. 18.43.32 # <[Saint]> He is, though. So you have a fighting chance. 18.45.15 # * devsnd puts the katana back in the sheath 18.45.50 Join Miles [0] (63fe171e@gateway/web/freenode/ip.99.254.23.30) 18.46.12 # devsnd: that's because there is a bug in the recovery mode 18.46.23 # Selective BL/SL Clip+ http://www.mediafire.com/file/pewaw8dci3wo3j3/Clip%2BSelBL-REl11-20-rockbox-full.zip, Clipzip http://www.mediafire.com/file/05xdhqh0i7tgyx1/CLIPZIP_SelBL_REl_11-20-rockbox-full.zip Fuze+ http://www.mediafire.com/file/f2v2zmss9b1be9b/Fuze%2BSelBL_REl11-20-rockbox-full.zip 18.46.37 # actually emmc/nand just makes a difference if you want to permanently write the firmware 18.49.42 # for my purpose it does not make any difference, if I use the thing as a display I can just write a udev rule that writes the correct code on the device once it's connected 18.50.34 # yes that's the idea, ok so I have a firmware for you to try, I will upload it 18.50.46 # wow, great :) 18.51.10 # in the mean time, run 'make' in the following directories: 18.51.10 # utils/imxtools/sbtools 18.51.10 # utils/hwstub/lib 18.51.10 DBUG Enqueued KICK pamaury 18.51.10 # utils/hwstub/tools 18.51.10 # you might need to install a few dev packages 18.51.17 # I've got the device in recovery mode, it's detected as HID device 18.51.37 # yeah that's correct 18.52.15 # rockbox/utils/hwstub/tools does not compile :( 18.52.15 # ‘lua_pushunsigned’ was not declared in this scope 18.52.58 # all the other Makefiles ran through no problems 18.53.15 # devsnd: you probably have an old version of lua, you need lua 4.3 iirc 18.53.27 # or lua 4.2 (look at the makefile, there is the version somewhere) 18.53.42 # https://www.dropbox.com/s/n9zq8qtfp3bzhbw/hwstub_sa2ara.sb?dl=0 18.54.01 # err 5.2 18.54.04 # I've got lua 5.3.3 18.54.13 # weird 18.54.38 # let me check, in the mean time: download the file 18.54.43 # mom, I'll check if the lua package for arch also contains all the headers or if theres another package 18.55.01 Quit Galois (Ping timeout: 250 seconds) 18.55.14 # then run 18.55.15 # sudo /path/to/sbtools/sbloader /path/to/hwstub_sa2ara.sb 18.55.22 *** Saving seen data "./dancer.seen" 18.55.36 # if it worked, your device should renumerate using usb IDs fee1:dead 18.55.41 # you can check with lsusb 18.56.20 Quit froggyman (Ping timeout: 250 seconds) 18.56.22 # devsnd: apparently lua_pushunsigned got removed 18.56.53 # you can sed 's/lua_pushunsigned/lua_pushinteger/' I think 18.57.03 # (in hwstub/tools/hwstub_shell.cpp) 18.57.35 # aight, there seem to be more of those: luaL_checkunsigned, lua_tounsigned 18.57.38 Join froggyman [0] (~frogs@unaffiliated/froggyman) 18.57.49 # so I guess they all have changed to integer 18.57.51 # ah damn, yeah it applies to all of them :-/ 18.58.10 # ok it does not matter for now, try to run sbloader and see if it works 18.58.16 # we can care about the lua after that 18.58.24 # aight 18.59.55 # Hi. Does someone have a moment? 19.00.40 # Miles: ask your question, someone will answer if he knows 19.01.37 # I'm experiencing this bug: https://www.rockbox.org/tracker/task/12883 19.01.51 # I tested the solution of turning up the CPU boost counter, and that works. 19.02.02 # So I'm just wondering if there's a permanent way to do that now. 19.02.54 # (the one in the System -> Debug -> CPU Frequency menu) 19.02.55 # pamaury, the sbloader says "Status: Passed" then the device shuts down. Then it boots up normally. Should I keep the vol-up pressed so it stays in recovery, or does it mean that it crashed and rebooted? 19.03.20 # devsnd: if it reboots, it means that it somehow crashed and that I failed somewhere 19.03.23 # <__builtin> do codecs control cpu boost? 19.04.02 # Miles: __builtin: I *think* buffering is supposed to boost on low watermark, so I would expect it to boost automatically 19.04.12 # maybe saratoga knows something about it 19.04.15 Quit Moarc (Ping timeout: 240 seconds) 19.04.16 # Oh and this is on a Sansa Clip+. 19.04.55 # is it any opus file? 19.05.02 # devsnd: give me some time to think about it, I need to understand what I may have done wrong 19.05.10 # and only opus files? 19.05.26 # pamaury, sure, tell me if there's anything I could help you with 19.06.03 # With the nightly build. Just opus files. Seemingly any folder containing a dozen or more of them will do it. 19.06.06 # devsnd: well the problem with that kind of hacking is that it's a bit of a trial and error, when it fails you are left with no clue... 19.06.18 Quit johnb2 (Ping timeout: 260 seconds) 19.06.19 # 90 kbps, was using libopus 1.1.3 before, now same thing with 1.2 alpha. 19.06.33 Join Moarc [0] (~chujko@a105.net128.okay.pl) 19.07.45 # It keeps playing but after a certain point it begins to ignore all button presses. 19.10.47 # pamaury, if you want to keep trying, I could hook the thing up to a raspberry pi, tape the vol-up button in pushed mode and give you root access... But I don't know if all the rockbox tools will compile on arm 19.11.35 # <__builtin> devsnd: IIRC they should 19.11.40 # <__builtin> someone runs a rpi build node 19.13.16 # devsnd: not sure it's going to help, also not sure about compiling on arm 19.15.04 # I wonder if Philips could be sneaky enough to use different keys for different languages 19.15.26 # (I took the eng version of the firmware) 19.17.27 # I have another idea of patching, stay tuned 19.18.18 # will do 19.23.00 # give me a few miles 19.23.59 # Thanks Bilgus. 19.26.01 # <__builtin> is the plugin buffer size on the sim differnet from the actual target? 19.26.04 # <__builtin> *different 19.27.55 # I have a very vague recollection about the plugin code not being in the plugin buffer in the sim 19.28.04 # As a side project I am writing an audio meta data parser. Is anyone familiar with mp3? 19.28.06 # Vague enough that it might easily be wrong 19.28.57 # builtin- I'm pretty sure any buffer in the sim is 19.32.46 Join johnb2 [0] (~johnb2@pD957D5DB.dip0.t-ipconnect.de) 19.37.02 Quit cc___ (Quit: WeeChat 1.6) 19.39.08 # <__builtin> oh great, now tlsf crashes 19.40.06 # Miles I haven't been able to reproduce it as of yet is the problem that key presses are un responsive? you say it keeps playing, does it skip/stutter? does the progress bar continue to move? 19.40.29 # devsnd: can you try this file: https://www.dropbox.com/s/n9zq8qtfp3bzhbw/hwstub_sa2ara.sb?dl=0 19.42.17 # it crashed again, sorry 19.42.25 Join cc___ [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627) 19.43.11 # Bilgus: Stack usage: 6: B 20 20 5% sel backlight 19.43.21 # 10 lines in total 19.43.37 # how many have --- 19.44.12 # now its up at 67% 19.44.27 # 11 to 15 have --- 19.44.42 # I assume the usb still isn't working.. is while the usb is plugged? 19.45.01 # <__builtin> ok, nice, puzzles now doesn't crash 19.45.58 # Right, still not working. When plugged it get the USB logo, but w/o the HID lines, just the logo. So I have unplug to be able to navigate the menu. 19.46.30 # pamaury, what is it you do exactly? I'm curious, but I'm not a hardware guy. I really would like to help you solve that puzzle 19.46.37 # Is percentage the cpu usage? 19.46.43 # Bilgus IIRC the progress bar and title scrolling stop until the next song. 19.47.31 # And it can take several uninterrupted songs for the problem to show up. 19.48.19 # ok i'm gonna throw you a firmware together for the clip+ with a longer cpu boost and we will see if that helps 19.48.27 # Bilgus in case the files actually do have something to do with it I can upload some that I've mostly tested this on. 19.48.51 # But I'll try that firmware first, thanks a bunch. 19.49.03 # Bilgus: I meant 10 lines in total with text, 5 more with --- 19.49.25 # if its just boost, then probably the codec isn't yielding enough 19.50.11 # devsnd: well I can show you: I go to the directory where there is updater.sb, then I run: 19.50.11 # mkdir updater 19.50.11 # /path/to/sbtoelf -z -o updater/ updater.sb 19.50.11 # then I modify make.db into this: https://gist.github.com/pamaury/01248109753a122de5842ff5d5244266 19.50.11 # I copy hwstub.bin from the build result of createing hwstub binary for stmp (ie cd /path/utils/hwstub/stub/stmp; make; cp build/hwstub.bin ....) 19.51.33 # then it gets tricky: I want to recreate the updater but I cannot because I am missing the key. So I create an invalid updater and then patch its header using the original one: 19.51.54 # ~/project/rockbox/myrockbox/utils/imxtools/sbtools/elftosb -d -c make_fake.db -o hwstub_sa2ara.sb --real-key "78D87B95BF94252E4CD85E7E1B9FAC11" --crypto-iv "820F744BF35546571D55B513C8371D3C" -zz 19.51.54 # dd if=../updater.sb bs=1 count=208 conv=notrunc of=hwstub_sa2ara.sb 19.52.08 # johnb2: this is on the clip+ correct? 19.52.26 # Yes.Does it make sense to try on a different device? 19.52.41 # if you have 10/15 to spare I can explain you why it (should) works ;) 19.53.12 # I have several clip+, i.e. both AMS variant 0 and 1 19.55.11 # pamaury, yeah, please tell me. I do not get how mashing another key and IV ontop of this firmware should work; Theoretically the chances for it to work are as great as brute forcing the correct key, no? 19.56.13 # Miles: http://www.mediafire.com/file/bm5adafc6dsa9zu/Clip%2BDEV_MOAR_BOOST-rockbox-full.zip 19.56.33 # <[7]> [Saint]: https://mega.nz/#!rIxgRSDI!dD1g5R8KNoIoOPdcxfoZfmTJMLiRaC6kYrLHiXO2D-8 19.56.42 # <[7]> [Saint]: https://mega.nz/#!qB5XAQrD!vEOiG2DfNfKa6fHox9DSxDLGifUaXk_AqWGzkOvfWyA 19.56.42 # johnb2 if you turn off selective BL and then replug does it work then? 19.57.17 # johnb2 % is how full the stack is 19.57.40 # <[7]> [Saint]: tell me once you've got them 19.57.44 # I shurnk the stack by 3/4 because it wasquite empty 19.58.13 # Bilgus: Nope, same behaviour. 19.58.42 # ok turn off the selective BL and softlock turn the player off power it back on and then try 19.59.20 # devsnd: so, the sb file format (I'm simplifying) consist in three parts: the header, the key store and the code/data 20.01.00 # the header is not encrypted and gives information about the file (size, number of sections, number of keys, version, etc). 20.01.27 # Now the thing is, the code/data is not encrypted using the device key, it is encrypted using what I can the real key. It is chosen at random when the file is created 20.01.29 # johnb2: my clip+ does this even with the dev build so i'm not sure.. 20.01.34 # Good point, before I hadn't turned off the player. Following your instructions, it now mounts correctly! 20.02.17 # ok now unplug turn selbl on do a few buttons and then replug 20.02.24 # okay, but how does the device then decrypt it? 20.02.39 # devsnd: so the key store serves two purposed: authenticate the file and give the device the real key 20.03.22 # so the real key is "signed" by being encrypted using the device key? 20.03.34 # to do that, for each key, the tool packs together the CBC-MAC of the of the header using the key, and the encrypted real key (using the key) 20.04.01 # also it's quite important to understand that with this, you can one file that works for several keys 20.04.16 # Again just the drive letters, no content. 20.04.36 # because the device will just compute the CBC-MAC of the header using its key, and compare it to the key store: if one entry matches, it then decrypts the real key and uses that for the rest of the file 20.04.46 # ok give me a few 20.05.22 # allright, but still you need bazillion entries for the device to try then, don't you? 20.07.14 # well that's the thing: updater.sb contains two keys in the store: zero and the device key 20.07.28 # which means that sbtoelf can decrypts updater.sb using the zero key 20.07.45 # but it cannot create a valid file for the device, because we do not know the device key 20.08.36 # Bilgus thanks, file recieved. I'll try it out at work tonight. 20.09.40 # that's where the trick is: when we create a file for the device, the only thing we cannot create is the key store (because we don't know the device key). So what I do is that I tell elftosb to create a file but instead of using a random real key, I use the same the original updater.sb. I also ask elftosb to create a key store with two entries (twice the zero key). The resulting file is perfectly valid but the device won't accept it because the 20.09.40 # key store does not contains its key 20.09.48 # johnb2 turn off selbl exit the menu and then go back to debug menu and verify that the thread sel backlight is gone 20.09.52 # Then I patch the header of the file with the header of the original file 20.10.28 # now what happens is that header and the key store are valid, and they describe a code/data encrypted using a real key. And I just so happened to use the same real key when I produce the file 20.11.05 # ah, now I get it 20.11.10 # so magically by patching the header, I get a file that that looks like it has been encrypted using the zero key and the device key, but in fact I did not 20.11.34 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) 20.11.43 # that really clever 20.12.28 # so the problem is not getting any code to run, but that you are running the code completely blindly to fish out the real device key? 20.12.30 # the devil is in the details after that: AES uses an IV, and the IV is obtained by CBC-MACing the header (I don't recall how to be honest). So when we create the fake file, we override the IV using a value that we know is wrong (thus the file produced is invalid), but when we patch the header, it suddenly works 20.14.06 # also there is the issue that the header describes partly the content of the code/data and we are using a bug of the ROM that does not double check this information 20.14.25 # as for the code, I use hwstub which provides a usb interface to read/write any registers on the device 20.14.31 # so in theory, it should just work (TM) 20.14.35 # so you use the IV from the original header, to create the fake file; But the IV of the fake file does not match its own CBC-MAC? 20.15.10 # no, not until you patch the header 20.16.24 # alright, now I get it. So what exactly then keeps crashing the device? 20.18.48 # well either the ROM (for some reason) finds out that the file is not valid and moves to do a real boot 20.18.57 # or for some reason, the hwstub code crashes 20.19.08 # (which would be surprising since it is well tested) 20.21.24 # my guess is more on the first option but I cannot be sure of course 20.22.31 # I have an idea 20.22.41 # So I should be able to boot from recovery mode directly by sending the original ROM over the write? 20.22.49 # I am all ears 20.22.52 # we could simply recreate updater.sb (ie no modification beside repacking and patching) to see if it crashs as well 20.23.10 # thats what I thought :) 20.23.12 # devsnd: yes and no 20.23.29 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 20.23.29 # * [7] wonders if [Saint] is still awake ;) 20.23.36 # it works as long as the original firmware does not expect any of its data to com from NAND 20.23.45 # which is unfortunately the case 20.24.35 # so you can boot updater.sb but it's unlikely you will succeed in booting firmware.sb unless it is the same version (or very close) to the one already on the nand 20.25.04 # devsnd: wait a minute, I'll send you another file, as I just suggested 20.26.47 # <__builtin> alright, now I need to figure out how to actually make it draw stuff 20.26.56 # Bilgus: yes, it is gone in the stack list 20.27.33 # ok I have a fix ill give you a compiled firmware to try 20.32.35 # devsnd: https://www.dropbox.com/s/amtwnjpn1757pho/updater_sa2ara.sb?dl=0 20.32.47 # beware is has a different name (updater_sa2ara.sb) 20.34.15 # it also crashed :( 20.35.42 # devsnd: can you try the original updater.sb? 20.35.54 # ok 20.36.01 # * pamaury starts to wonder if there might be a mismatch between the firmware and the device 20.37.15 # hm same same with the original updater.sb, goes strait into MSC mode 20.38.36 # the model number is correct, there's a little sticker on the bottom that has the same number 20.38.40 # johnb2: http://www.mediafire.com/file/lq8jxq3wrucbq3d/rockbox.sansa 20.38.54 # let me know if that stops the problem 20.41.17 # devsnd: well actually there is another possibility, I don't even know what updater.sb is supposed to do, maybe it shows MSC mode 20.41.32 # which means there is no real way of knowing if updater.sb executes or not 20.43.10 # maybe... I actually had the feeling that the MSC was booting more quickly using the original updater.sb 20.43.44 # Maybe in case of success it boots into MSC and in case of crash it does so as well, but takes longer to cold boot 20.43.47 # what about the updater_sa2ara.sb? 20.43.48 # I'll time it 20.44.04 # Yeah, I'll time all 3 variants 20.46.00 # Bilgus: Great job. Now it mounts properly both with SelBl turned on and off! 20.46.33 # well almost good job since that worked I have one more for you to try possibly two 20.47.00 Quit prof_wolfff (Ping timeout: 260 seconds) 20.47.20 # I will be around for another hour, then travelling for the next three days. 20.49.09 # pamaury: there's no measurable difference between all the *.sb files 20.49.17 # johnb2 https://www.mediafire.com/?48c5d7dtkaf3qkd 20.50.06 # see if that one works too the last one just wiped out selective BL on USB plug my hope is this one won't 20.50.28 # <__builtin> yay!!! 20.50.45 # <__builtin> ladies and gentlemen, we have output! 20.51.47 # <__builtin> https://fwei.tk/puzzles.png 20.51.57 # <__builtin> gevaerts: ^ 20.52.18 # Yay! 20.52.21 # Miles: opus works fine for most people, so if you've got some strange bug you need to give some instructions to reproduce it 20.54.01 # try deleting your config file to reset settings, then find the minimum set of files needed to trigger the problem, and then upload them 20.54.47 # pamaury, I found another firmware that matches the model number http://download.p4c.philips.com/files/s/sa2ara08k_02/sa2ara08k_02_hf1_deu.zip 20.55.12 # Bilgus: this one works! 20.55.23 *** Saving seen data "./dancer.seen" 20.55.34 # I used to have a GoGear one which I tried this and it worked, so the question is, why is this not working 20.55.53 # ok it was my fault for not looking closely when the usb is plugged it expects an ACK 20.56.48 # <[Saint]> [7]: he is. 20.56.55 # ill update the patch but not the fw files I upped earlier 20.57.25 # <[Saint]> We really fucked up with our gerrit build system integration. 20.57.33 # <[Saint]> I should look in to this and finally finish it. 20.57.58 # <[Saint]> It was always the intention to supply the ability to hook gerrit to the build system to do build proofs and testbuilds. 20.58.13 # <[Saint]> But people got so damn angry about git/gerrit in general it never happened. 20.58.24 # <[Saint]> We never really recovered from that mess. 20.59.07 # I don't know why people are so angry about git 20.59.16 Join nlogex [0] (~filip@dhcp-198-2-91-25.cable.user.start.ca) 20.59.18 # <[Saint]> Funny to think of these days, if submitters asked themselves how much they gave a shit about subversion /now/, I suspect people would give zero fucks. 20.59.23 # <[Saint]> ~10 years ago, however... 20.59.33 Join prof_wolfff [0] (~prof_wolf@82.159.0.123.dyn.user.ono.com) 20.59.36 # pamaury, when I search for the serial number "SA2ARA08K/02" I find images of similar looking players. They seem to have really strange model numberings 20.59.45 # git really frustrating to use unless you have a lot of experience with it 20.59.55 # <[Saint]> pamaury: it's hard to think about it with the mindset of now, compared to then. 21.00.08 # only one way to get experience.. 21.00.38 # devsnd: don't mention it, Philips numbering scheme is braindead 21.00.41 # <[Saint]> I *hate* it when a find a relic project still using subversion. 21.00.44 # [Saint]: I was there when we switched 21.00.56 # <[Saint]> pamaury: I'm aware. 21.01.06 # It's true that git is not easy to master, but subversion is just bad 21.01.18 # unfortunately we lost a few devs in the switch 21.01.23 # <[Saint]> I'm saying it made sense to a lot of people /then/, but we're thinking about it /now/, and it makes less sense. 21.01.40 # yeah you are right 21.02.08 # It's basically the cvs/svn story all over again I guess 21.02.32 # <[Saint]> or */mercurial, or mercurial/* 21.02.42 # <[Saint]> or */*, really. 21.02.48 # devsnd: what is the sticker showing on your player exactly? 21.02.49 Join TheLemonMan [0] (~root@unaffiliated/thelemonman) 21.02.51 # <[Saint]> people just get passionate about version control. 21.03.10 # pamaury: just to make sure I'm not braindead http://fomori.org/upload/month/IMG_20161120_204142.jpg this is the version number on the device. It matches with the second URL to the firmware I sent you. Could you please retry with that one? 21.03.44 # devsnd: wait, your devices show sa3ara (3 not 2) 21.03.59 # damn, I am officially a complete idiot 21.04.06 # lol 21.04.23 # I've done worse 21.05.00 # sorry! I'll try to find the firmware... 21.05.05 # *guesses URLs 21.05.21 Join Galois [0] (djao@efnet.math.uwaterloo.ca) 21.06.11 # also Philips does not provide direct URLs which is super annoying 21.06.34 # http://download.p4c.philips.com/files/s/sa3ara08k_02/sa3ara08k_02_hf1_deu.zip 21.06.38 # got it! 21.06.40 # and it works 21.06.49 # http://download.p4c.philips.com/files/s/sa3ara08k_02/sa3ara08k_02_hf1_eng.zip seems to work 21.06.57 # ok downloading 21.08.30 # johnb2: thanks for your help with that I'd have never figured it out as all my players use usb in the bootloader or have to go into the original firmware 21.11.50 # devsnd: https://www.dropbox.com/s/zg7mgvcxu8khf31/hwstub_sa3ara.sb?dl=0 21.12.00 # You are very welcome, thanks for digging into it! I will be off now. 21.12.37 Quit johnb2 (Quit: Nettalk6 - www.ntalk.de) 21.13.21 # :D 21.13.23 # Bus 003 Device 036: ID fee1:dead 21.13.29 # ah, good news :) 21.13.42 # ok, so now I need to fix hwstub_shell.cpp 21.14.02 # give me a minute to look into that 21.14.28 # pamaury: I'll have help my wife cooking, I'll be back in 45min, will you be still there? 21.14.35 # yes 21.14.42 # nice :) 21.14.49 # you said you are using lua 5.3 right? so I can try to reproduce 21.19.04 # * __builtin uploads a 1MB patch 21.19.47 # <__builtin> it's going to be lots of fun to review, I'm sure 21.24.09 Join lebellium [0] (~chatzilla@89-93-179-5.hfc.dyn.abo.bbox.fr) 21.28.38 # saratoga: the Flyspray ticket has more info about reproducing it, but I'll come back with more information and a set of test files if things don't look better after I get around to thoroughly testing Bilgus' firmware later 21.28.56 # Here it is again: https://www.rockbox.org/tracker/task/12883 21.29.06 # i checked the ticket and theres a 3 year old request to post sample files...which no one did 21.30.07 # bug reports that can't be reproduced get ignored 21.30.19 # Fair enough. I do have some time now. 21.30.31 # let us know either way and send us some sample files 21.30.35 # I hope you like the Undertale OST cause that's where I first found the behaviour. 21.30.43 # anyway, i spent a few minutes looking at that problem and concluded that opus works fine 21.30.49 # if there is something new, let me know 21.31.00 # Gonna upload it... 21.31.23 # also, i'd suggest trying to reproduce it with just 2 files if possible (use repeat) 21.31.31 # also for anyone that continues with this the FW I gave him was the latest dev all I did was move cpu boost timeout in action.c to 10 seconds instead of 1 21.31.48 Quit xorly (Ping timeout: 260 seconds) 21.33.45 Quit toli (Ping timeout: 256 seconds) 21.34.44 # Miles it is a 2hr long file? 21.36.02 # 99MB zip, 100 tracks. Good thing Opus is efficient eh. 21.36.20 # http://www.mediafire.com/file/g043qgzh6svss8e/UNDERTALE_-_OST.zip 21.37.50 # ok so you have a folder with these 100 files and it craps out after a few or after 1 or randomly? 21.38.33 # So, Sansa Clip+, dev build, play the first file and don't touch the device. It may take half an hour before it locks but usually sooner. 21.38.54 # Doesn't seem to actualyl matter which one you start with, or the order. 21.39.42 Join xorly [0] (~xorly@ip-89-176-10-118.net.upcbroadband.cz) 21.40.06 # This was just the largest folder of Opus files so it's impossible to get even a quarter way through it. 21.40.56 Join toli [0] (~toli@62.235.124.203) 21.41.44 # devsnd: I pushed a fix for lua, when you are back, be sure to rebase to get the latest version 21.41.58 # ok gives me something to reproduce 21.42.36 # No problem. I wish reproduction were less random. 21.42.48 # So I appreciate the time. 21.44.54 # so are you making a playlist of these files or database or just clicking on one in the folder? 21.45.19 # Just selecting from the file browser. 21.45.37 # ok so using auto generated playlist 21.45.43 # Mhmm. 21.46.52 # The database exists but I'm only using it for playback statistics, if that matters. 21.47.53 # it might.. I just want to try to have the conditions as close as possible 21.50.10 # Apart from that default settings should do it. I've formatted and reflashed a few times. 21.51.36 # I wondered if maybe the size of my collection was a factor as well. I'm using a 128 GB micro SD and it's stuffed to the brim. 21.52.32 # Mostly 96kb/s Opus with some other assorted lossy files. 21.55.57 # doubtful but who knows yet lol 21.59.34 # * __builtin needs to get a polygon-drawing function going here 22.00.07 # <__builtin> meh, I'll just trace its outline for now 22.00.52 Quit xorly (Ping timeout: 245 seconds) 22.02.07 # Gotta sign off for now, see you around tomorrow hopefully Bilgus. 22.02.22 # I'll know if the modified firmware helped by then. 22.06.24 Quit Miles (Quit: Page closed) 22.06.47 Quit petur (Remote host closed the connection) 22.09.01 # <__builtin> does rockbox have a function to copy a rectangular section of the framebuffer to a buffer? 22.09.47 Quit krabador (Quit: Leaving) 22.12.48 Join xorly [0] (~xorly@ip-89-176-10-118.net.upcbroadband.cz) 22.14.01 # __builtin: I don't think so 22.19.31 # gevaerts: ping 22.22.53 # pamaury: I'm back, just rebased your changes 22.24.23 # devsnd: ok, now run ./hwstub_shell 22.24.31 # (you might need a udev rule or run as sudo) 22.25.09 # FYI, this is the udev rule I use: SUBSYSTEMS=="usb", ATTRS{idVendor}=="fee1", ATTRS{idProduct}=="dead", GROUP="users", MODE="0666" 22.25.35 # still got compile errors :/ 22.27.08 # http://pastebin.com/igwfB9sk 22.27.19 # __builtin: V_CopyRect though it isn't in rockbox persay 22.27.31 # devsnd: you don't have lua5.2 installed 22.27.59 # option #1 is to install lua5.2, option #2 is to replace 5.2 by 5.3 in the Makefile 22.28.27 # aight, downgrading might be hard, so I'll go with the makefile change... 22.28.38 # unfortunately there is no easy way around it because pkg configs for lua are always versioned 22.32.42 # pamaury: hm, changing the version to 5.3 in the makefile did not help, maybe i need a lua-headers/dev/git/something package 22.33.33 # devsnd: did you change it both in cflags and ldflags? 22.33.39 # yeah 22.33.47 # you need the -dev version 22.34.17 # you need liblua5.3-dev 22.34.53 # Bilgus: Just tried the latest build you posted on my Zip (fb45a3d), and the failure to turn on BL with first button press after boot (if the BL is allowed to expire after boot) is fixed. 22.35.48 # pamaury: it seems on arch lua is not versioned in the same way. I just s/lua5.2/lua/ and it worked 22.35.51 # Still fails to reset the timer going from / to main menu using power button, but that's the only case of that bug I can find so far, so I would call that a "Won't fix". 22.35.55 # what about the one coming out of file menu with the power button? 22.36.05 # See ^ 22.36.47 # pamaury: I'm in. 22.37.27 # I'll keep looking for other cases, but I haven't found any yet. 22.37.44 # devsnd: ok, ah the weird of pkg-config... 22.37.59 # devsnd: in the shell, type: 22.37.59 # for i=0,3 do HW.DCP.DBGSELECT.INDEX.write(0x10+i); print(string.format("%08x", HW.DCP.DBGDATA.read())); end 22.38.08 # I hope it is correct 22.38.14 # 063737c6 22.38.15 # 9bf2c99d 22.38.15 # 1a48fe1b 22.38.15 DBUG Enqueued KICK devsnd 22.38.15 # 1193e6ca 22.38.55 Quit ender` (Ping timeout: 244 seconds) 22.39.11 # that one is pretty subtle I tried doing a backlight on call on context change unfortunately it has to wait till the next button press to see the change either that or read the context again but i'm reluctant to do that So agreed its a won't fix unless there becomes a reason to do so 22.39.13 # is that the key? 22.39.54 # devsnd: looks like it, give me a minute to check that 22.40.00 Join ender` [0] (krneki@foo.eternallybored.org) 22.41.36 # Realistically, I think no one is likely to be in the habit of using the power button for anything except "Stop" or to actually turn the player off, so I suspect it's only those testing it to destruction who will find that particular bug. 22.42.00 # devsnd: yes, the key is c63737069dc9f29b1bfe481acae69311 22.42.27 Quit xorly (Ping timeout: 260 seconds) 22.43.08 # nice, thanks a bunch pamaury, you really showed me a lot 22.43.14 # Half the time, I'm not particularly concerned about power and just let the auto-off handle things. The time I use the power button is mostly when I know I want the bookmark to be created to make sure I see it happen, or sometimes to turn the player off. 22.43.19 # devsnd: to unpack firmware.sb, use 22.43.20 # sbtoelf -d -a c63737069dc9f29b1bfe481acae69311 -o directory/ firmware.sb 22.44.01 # I've just installed the latest BL patch version on the zip I use most. Great work, Bilgus. Thank you very much. 22.44.04 # devsnd: however I warn you that reverse engineering might prove tricky. If you just want to have the screen working, I can have a look and try to provide you with a lua script 22.44.41 Join xorly [0] (~xorly@ip-89-176-10-118.net.upcbroadband.cz) 22.44.48 # that would be really great, yes 22.44.58 # np 22.46.02 # devsnd: I'll see what I do. You can use hwstub_shell to run some code but obviously it is very slow. I works to upload images to the screen but it will be horribly slow. 22.46.23 # horribly slow would be enough for me, to be honest 22.46.31 # I think what is happening is probably another event in the queue masking the button release 22.46.46 # Ill see what I can figure out 22.48.00 # One image every once in a while would be more than enough for me. I want to show the smart status of my RAID etc 22.48.39 # Could be. Certainly if something is playing, the power button also calls stop - even when not on WPS, so there's one possible culprit right there - but all my tests that exhibited the problem were already in stop mode at the time. 22.50.01 # devsnd: ok let me have a quick look, just to see if the code is similar to other targets I have RE'd 22.50.29 # Still, with only that button known to be affected, and only rarely, it's still doubtful that normal users will find it. I only found it because I got lucky and triggered it with semi-random button presses. 22.50.58 # Then, was lucky enough to remember the button that did it, so I could find it again more systematically. 22.51.42 # essentially I have a blocking button get and another that times out if you press the power button and then another event takes the slot of the button release on the next call the blocking one gets the button release 22.52.18 # so ill have to figure out a way around that 22.52.36 # devsnd: apparently the firmware supports both nand and mmc, so it's not impossible your device has an mmc in a nand package 22.53.32 # Or conclude it doesn't matter unless it is proven to be triggered by a sequence that is actually likely to occur in real usage. Which the only known cause is not. 22.54.06 # But, I know: Pride in workmanship. 22.54.30 # If you want to track it down, I'll gladly run tests for you. 22.55.25 # I've got work to do away from the computer, so I'll check the logs later. 22.55.27 *** Saving seen data "./dancer.seen" 22.56.17 # k i'll dig into it later on 22.56.26 # is there a manual for hwstub_shell somewhere? 23.00.49 # devsnd: not really, there is some builtin help but I don't think it's up to date 23.01.03 # but there are lots of scripts in lua/ for the imx233 (the soc used in this device) 23.01.20 # and examples of scripts for various devices based on this soc 23.01.40 # basically it's lua, with a table called HW that gives you access to all register 23.01.56 # (so you need the imx233 manual to understand what you are doing) 23.02.17 # yeah, I've started speluncing around there, I'm trying to turn on the backlight ;) 23.02.48 # the generic syntax being HW.block.reg.ACTION where ACTION can be read(), write(val), set(val), clear(val) or field.read(), field.write(val), etc 23.03.11 # for backlight it's hard to tell without reverse engineering, it can be either a pin or more likely a pwm 23.05.01 # Is it a bad idea just to try something? can I easily break something just wiggling some pins from the inside? 23.06.07 # I doubt it but just give me 5 min 23.06.22 # I have located the lcd init sequence, I should be able to figure out backlight 23.09.20 Quit xorly (Ping timeout: 260 seconds) 23.09.32 # pamaury: what do you use to disassemble the code? 23.09.58 # IDA pro 23.11.31 Join xorly [0] (~xorly@ip-89-176-10-118.net.upcbroadband.cz) 23.16.15 # the firmware seems to support 3 different types of lcd 23.21.13 # Do you think that I could find the part number of the LCD if I disassembled the device some more? 23.22.09 Quit lebellium (Quit: ChatZilla 0.9.93 [Firefox 50.0/20161104212021]) 23.22.23 # probably not, usually even if you find it's unhelpful because there is no datasheet 23.26.43 # pamaury: It's late, I will go to bed. Thanks a lot for your help, you're a real wizzard! 23.26.56 # devsnd: I have located backlight, I think uses one those weird chips where you toogle the line in a specific wait to tell the controll the intensity 23.27.14 # I also have to go to bed, see you 23.27.19 # oh cool! 23.28.04 # I will be back. I have downloaded IDA Pro and got the ARM instruction set as well. I'll try to follow along, but hardware is not at all my field 23.28.18 # I hope that we can complete this together :) 23.28.24 # have a good night! 23.29.54 Quit devsnd (Remote host closed the connection) 23.30.11 Join devsnd [0] (~devsnd@p200300D46BC07800FA68FF258211A6DA.dip0.t-ipconnect.de) 23.33.37 Quit devsnd (Client Quit) 23.39.12 Quit pamaury (Ping timeout: 245 seconds) 23.40.58 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.")