| 00:54:59 | *** | Saving seen data "./dancer.seen" |
| 01:00 |
| 01:09:45 | fishbulb | probably drawing too much |
| 01:10:10 | | Quit petur (Remote host closed the connection) |
| 01:10:17 | fishbulb | the battery seems to just stay in stasis, not quite charge but not drain |
| 01:10:27 | fishbulb | the thing gets warm too. |
| 01:10:59 | fishbulb | I might have to make a cable to charge from usb straight to the jack |
| 01:11:09 | saratoga_ | try a 2 amp charger? |
| 01:11:34 | fishbulb | I've tried the yellow usb port on this thinkpad, it's supposed to be higher current |
| 01:11:35 | saratoga_ | although if the SSD is really drawing 500 mA, i wonder if the battery will even last long enough to matter |
| 01:11:48 | fishbulb | yeah the battery lasts a long time |
| 01:11:54 | saratoga_ | how long? |
| 01:12:29 | fishbulb | dunno. a few hours each day and a few days before it starts to get low? |
| 01:12:58 | fishbulb | 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 | saratoga_ | 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 | saratoga_ | even on a 500 mA port |
| 01:13:24 | fishbulb | it was a 2200mAh one but I doubt it still is now |
| 01:13:55 | fishbulb | 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 | fishbulb | but that's obviously with the drive active and mounted |
| 01:16:12 | saratoga_ | 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 | fishbulb | it just heats up |
| 01:16:55 | fishbulb | the wall charger works |
| 01:21:44 | | Quit edhelas (Quit: Leaving.) |
| 01:29:54 | | Quit saratoga_ (Ping timeout: 260 seconds) |
| 02:00 |
| 02:06:52 | TorC | 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 | TorC | 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 | TorC | 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 | TorC | 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 | Bilgus | 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:00 |
| 03:25:44 | [Saint] | Christ, seriously? |
| 03:25:47 | [Saint] | http://forums.rockbox.org/index.php/topic,51573.new.html#new |
| 03:43:06 | Bilgus | 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:00 |
| 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 | Saratoga_ | 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:00 |
| 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:00 |
| 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:00 |
| 07:01:16 | | Quit TheSeven (Ping timeout: 240 seconds) |
| 07:01:34 | | Join [7] [0] (~quassel@rockbox/developer/TheSeven) |
| 08:00 |
| 08:15:41 | TorC | 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:00 |
| 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:00 |
| 10:02:40 | | Quit Saratoga_ (Ping timeout: 260 seconds) |
| 10:04:09 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 10:06:14 | TorC | 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 | TorC | 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 | TorC | 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 | johnb2 | Bilgus: I just grabbed the clip+ version. |
| 10:44:19 | johnb2 | 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 | TorC | 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 | TorC | johnb2: Does your Clip+ exhibit the same behaviour? |
| 11:00 |
| 11:00:08 | TorC | 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 | johnb2 | you mean the screen stays on forever? |
| 11:01:37 | TorC | 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 | johnb2 | I will try ... |
| 11:02:21 | TorC | I've been using a 3s BL timer to troubleshoot this. |
| 11:02:43 | TorC | 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 | TorC | 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 | johnb2 | TorC: Yes, I can confirm for timer set to 3 or 7 sec. For 10s I don't see it. |
| 11:12:55 | johnb2 | Confirming also power vs. left button. |
| 11:15:59 | | Join robertd1 [0] (~root@201.208.231.245) |
| 11:19:08 | TorC | 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 | TorC | johnb2: Bilgus: I seem to still see the timer not resetting even with a 10s BL timer (/ to main menu) |
| 11:21:33 | TorC | 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 | TorC | *At least in practical usage. Corner cases is where it will show up obviously. |
| 11:24:22 | TorC | Does anyone actually use the power button to step back in menus in normal usage? |
| 11:27:12 | TorC | 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 | TorC | *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 | TorC | Thought of something else to test: Resuming playback with the Home? button. Also exhibits issue. |
| 11:35:31 | TorC | Turn on bug doesn't happen with noBLsel turned off, so it's definitely related to the function. |
| 11:35:54 | TorC | Heading to bed now. Will review the logs for anything I miss. |
| 11:40:33 | | Quit advcomp2019 (Ping timeout: 250 seconds) |
| 11:48:31 | johnb2 | 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:00 |
| 12:01:26 | | Join johnb2 [0] (~johnb2@pD957D5DB.dip0.t-ipconnect.de) |
| 12:20:10 | johnb2 | 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 | johnb2 | 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:00 |
| 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:00 |
| 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 | Bilgus | 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 | Bilgus | TorC i can try making the timeout reset on context change probably a good idea anyways |
| 15:00 |
| 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 | johnb2 | Bilgus: Try an accustic guitar track, have the screen black for a while and seek backwards |
| 15:23:44 | johnb2 | I tried it with flac and mpc. |
| 15:24:01 | johnb2 | s/tried/verified |
| 15:25:02 | Bilgus | 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 | johnb2 | 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 | Bilgus | 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 | Bilgus | 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:00 |
| 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 | johnb2 | Current dev build works fine! |
| 16:14:19 | johnb2 | 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 | Saratoga_ | 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 | Saratoga_ | Hmm yeah I guess we don't have math.h |
| 16:58:50 | Saratoga_ | We have fixed versions of them |
| 16:59:07 | | Quit Sasasu (Quit: WeeChat 1.0.1) |
| 16:59:15 | Saratoga_ | 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 | Saratoga_ | That will work |
| 17:00 |
| 17:01:11 | __builtin | now the issue is with the functions that aren't in the fixed-point library |
| 17:01:18 | Saratoga_ | 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 | Saratoga_ | 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 | Saratoga_ | MIT license I believe, which is GPL compatible |
| 17:09:13 | __builtin | ok, good |
| 17:17:02 | pamaury | 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 | pamaury | 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 | pamaury | 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 | pamaury | 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 | pamaury | 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 | pamaury | 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 | pamaury | 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 | pamaury | 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 | pamaury | 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 | pamaury | 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 | pamaury | 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 | pamaury | good question, if you tell me, let me know ;) |
| 17:44:59 | pamaury | I would say, have look at overlayed plugin |
| 17:45:52 | __builtin | time to copy+paste pictureflow.make −−> puzzles.make |
| 17:47:21 | pamaury | pictureflow makefile is more complicated than needed for you |
| 17:48:04 | | Join devsnd [0] (~devsnd@p200300D46BC07800FA68FF258211A6DA.dip0.t-ipconnect.de) |
| 17:51:08 | devsnd | 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 | TheLemonMan | devsnd, try with an all zero key, that's what samsung used on the yp-q2 |
| 17:53:01 | pamaury | devsnd: most firmware use the zero key |
| 17:53:05 | pamaury | (option -z iirc) |
| 17:53:14 | pamaury | but GoGear might be an exception |
| 17:53:26 | pamaury | 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 | gevaerts | 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 | devsnd | 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 | devsnd | is the key space to big in v2? |
| 17:54:59 | pamaury | for v2 it's hopeless, AES128 ;) |
| 17:55:10 | pamaury | but there is another way using a rom exploit |
| 17:55:20 | pamaury | that works sometimes |
| 17:55:29 | pamaury | 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 | devsnd | http://download.p4c.philips.com/files/s/sa2ara08k_17/sa2ara08k_17_hf1_deu.zip |
| 17:56:09 | devsnd | 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 | pamaury | devsnd: thanks, downloading |
| 17:57:40 | [Saint] | Hm? Oh. Sorry. I missed that. It couldn't hurt. |
| 17:57:45 | devsnd | [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 |
| 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 | pamaury | devsnd: that's your lucky day, I think an exploit will work |
| 18:03:19 | pamaury | you have the device I presume? |
| 18:03:43 | devsnd | yeah, got the device next to me |
| 18:03:53 | pamaury | do you have linux? |
| 18:03:56 | devsnd | yees |
| 18:04:35 | pamaury | 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 | pamaury | do you already have a copy of rockbox repository? |
| 18:05:11 | devsnd | yes, just checked it out to get the sbtools |
| 18:06:47 | devsnd | 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 | pamaury | 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 | devsnd | I wanted to use it as a status display for my storage server |
| 18:10:06 | devsnd | 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 | devsnd | 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 | pamaury | 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 | pamaury | (or if it has a microsd port that could work as well) |
| 18:14:29 | devsnd | can I spot the difference between eMMC and nand on the PCB or is it just a question of internal protocol? |
| 18:14:41 | devsnd | (it has not microsd port) |
| 18:14:47 | devsnd | s/not/no |
| 18:17:30 | pamaury | devsnd: if you upload a picture of the pcb I can tell |
| 18:17:39 | pamaury | or if you manage to read what is on it |
| 18:18:52 | pamaury | 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 | pamaury | 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 | devsnd | here's a picture of the PCB http://fomori.org/upload/month/IMG_20161120_181955.jpg |
| 18:22:42 | devsnd | 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 | pamaury | 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 | Bilgus | johnb2 http://gerrit.rockbox.org/r/#/c/1420/ |
| 18:31:43 | Bilgus | 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 | Bilgus | 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 | devsnd | 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 | pamaury | devsnd: recovery mode is in fact just an interface to run code |
| 18:40:16 | pamaury | you can use it to write to the nand, but you can also use it for anything else |
| 18:40:37 | pamaury | (so long as you have the key and the code) |
| 18:40:46 | | Join toli [0] (~toli@62.235.115.102) |
| 18:41:36 | devsnd | so the recovery mode code needs to be encrypted using the same key as is used for the firmware? |
| 18:41:42 | pamaury | yes |
| 18:42:17 | devsnd | well, seems like a chicken and egg problem to me. |
| 18:43:04 | devsnd | 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 | pamaury | devsnd: that's because there is a bug in the recovery mode |
| 18:46:23 | Bilgus | 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 | pamaury | actually emmc/nand just makes a difference if you want to permanently write the firmware |
| 18:49:42 | devsnd | 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 | pamaury | yes that's the idea, ok so I have a firmware for you to try, I will upload it |
| 18:50:46 | devsnd | wow, great :) |
| 18:51:10 | pamaury | in the mean time, run 'make' in the following directories: |
| 18:51:10 | pamaury | utils/imxtools/sbtools |
| 18:51:10 | pamaury | utils/hwstub/lib |
| 18:51:10 | DBUG | Enqueued KICK pamaury |
| 18:51:10 | pamaury | utils/hwstub/tools |
| 18:51:10 | pamaury | you might need to install a few dev packages |
| 18:51:17 | devsnd | I've got the device in recovery mode, it's detected as HID device |
| 18:51:37 | pamaury | yeah that's correct |
| 18:52:15 | devsnd | rockbox/utils/hwstub/tools does not compile :( |
| 18:52:15 | devsnd | ‘lua_pushunsigned’ was not declared in this scope |
| 18:52:58 | devsnd | all the other Makefiles ran through no problems |
| 18:53:15 | pamaury | devsnd: you probably have an old version of lua, you need lua 4.3 iirc |
| 18:53:27 | pamaury | or lua 4.2 (look at the makefile, there is the version somewhere) |
| 18:53:42 | pamaury | https://www.dropbox.com/s/n9zq8qtfp3bzhbw/hwstub_sa2ara.sb?dl=0 |
| 18:54:01 | pamaury | err 5.2 |
| 18:54:04 | devsnd | I've got lua 5.3.3 |
| 18:54:13 | pamaury | weird |
| 18:54:38 | pamaury | let me check, in the mean time: download the file |
| 18:54:43 | devsnd | 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 | pamaury | then run |
| 18:55:15 | pamaury | sudo /path/to/sbtools/sbloader /path/to/hwstub_sa2ara.sb |
| 18:55:22 | *** | Saving seen data "./dancer.seen" |
| 18:55:36 | pamaury | if it worked, your device should renumerate using usb IDs fee1:dead |
| 18:55:41 | pamaury | you can check with lsusb |
| 18:56:20 | | Quit froggyman (Ping timeout: 250 seconds) |
| 18:56:22 | pamaury | devsnd: apparently lua_pushunsigned got removed |
| 18:56:53 | pamaury | you can sed 's/lua_pushunsigned/lua_pushinteger/' I think |
| 18:57:03 | pamaury | (in hwstub/tools/hwstub_shell.cpp) |
| 18:57:35 | devsnd | aight, there seem to be more of those: luaL_checkunsigned, lua_tounsigned |
| 18:57:38 | | Join froggyman [0] (~frogs@unaffiliated/froggyman) |
| 18:57:49 | devsnd | so I guess they all have changed to integer |
| 18:57:51 | pamaury | ah damn, yeah it applies to all of them :-/ |
| 18:58:10 | pamaury | ok it does not matter for now, try to run sbloader and see if it works |
| 18:58:16 | pamaury | we can care about the lua after that |
| 18:58:24 | devsnd | aight |
| 18:59:55 | Miles | Hi. Does someone have a moment? |
| 19:00 |
| 19:00:40 | pamaury | Miles: ask your question, someone will answer if he knows |
| 19:01:37 | Miles | I'm experiencing this bug: https://www.rockbox.org/tracker/task/12883 |
| 19:01:51 | Miles | I tested the solution of turning up the CPU boost counter, and that works. |
| 19:02:02 | Miles | So I'm just wondering if there's a permanent way to do that now. |
| 19:02:54 | Miles | (the one in the System -> Debug -> CPU Frequency menu) |
| 19:02:55 | devsnd | 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 | pamaury | 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 | pamaury | Miles: __builtin: I *think* buffering is supposed to boost on low watermark, so I would expect it to boost automatically |
| 19:04:12 | pamaury | maybe saratoga knows something about it |
| 19:04:15 | | Quit Moarc (Ping timeout: 240 seconds) |
| 19:04:16 | Miles | Oh and this is on a Sansa Clip+. |
| 19:04:55 | Bilgus | is it any opus file? |
| 19:05:02 | pamaury | devsnd: give me some time to think about it, I need to understand what I may have done wrong |
| 19:05:10 | Bilgus | and only opus files? |
| 19:05:26 | devsnd | pamaury, sure, tell me if there's anything I could help you with |
| 19:06:03 | Miles | With the nightly build. Just opus files. Seemingly any folder containing a dozen or more of them will do it. |
| 19:06:06 | pamaury | 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 | Miles | 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 | Miles | It keeps playing but after a certain point it begins to ignore all button presses. |
| 19:10:47 | devsnd | 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 | pamaury | devsnd: not sure it's going to help, also not sure about compiling on arm |
| 19:15:04 | pamaury | I wonder if Philips could be sneaky enough to use different keys for different languages |
| 19:15:26 | pamaury | (I took the eng version of the firmware) |
| 19:17:27 | pamaury | I have another idea of patching, stay tuned |
| 19:18:18 | devsnd | will do |
| 19:23:00 | Bilgus | give me a few miles |
| 19:23:59 | Miles | 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 | gevaerts | I have a very vague recollection about the plugin code not being in the plugin buffer in the sim |
| 19:28:04 | devsnd | As a side project I am writing an audio meta data parser. Is anyone familiar with mp3? |
| 19:28:06 | gevaerts | Vague enough that it might easily be wrong |
| 19:28:57 | Bilgus | 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 | Bilgus | 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 | pamaury | devsnd: can you try this file: https://www.dropbox.com/s/n9zq8qtfp3bzhbw/hwstub_sa2ara.sb?dl=0 |
| 19:42:17 | devsnd | it crashed again, sorry |
| 19:42:25 | | Join cc___ [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627) |
| 19:43:11 | johnb2 | Bilgus: Stack usage: 6: B 20 20 5% sel backlight |
| 19:43:21 | johnb2 | 10 lines in total |
| 19:43:37 | Bilgus | how many have −−- |
| 19:44:12 | johnb2 | now its up at 67% |
| 19:44:27 | johnb2 | 11 to 15 have −−- |
| 19:44:42 | Bilgus | 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 | johnb2 | 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 | devsnd | 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 | johnb2 | Is percentage the cpu usage? |
| 19:46:43 | Miles | Bilgus IIRC the progress bar and title scrolling stop until the next song. |
| 19:47:31 | Miles | And it can take several uninterrupted songs for the problem to show up. |
| 19:48:19 | Bilgus | 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 | Miles | 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 | Miles | But I'll try that firmware first, thanks a bunch. |
| 19:49:03 | johnb2 | Bilgus: I meant 10 lines in total with text, 5 more with −−- |
| 19:49:25 | saratoga | if its just boost, then probably the codec isn't yielding enough |
| 19:50:11 | pamaury | devsnd: well I can show you: I go to the directory where there is updater.sb, then I run: |
| 19:50:11 | pamaury | mkdir updater |
| 19:50:11 | pamaury | /path/to/sbtoelf -z -o updater/ updater.sb |
| 19:50:11 | pamaury | then I modify make.db into this: pamaury/01248109753a122de5842ff5d5244266">https://gist.github.com/pamaury/01248109753a122de5842ff5d5244266 |
| 19:50:11 | pamaury | 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 | pamaury | 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 | pamaury | ~/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 | pamaury | dd if=../updater.sb bs=1 count=208 conv=notrunc of=hwstub_sa2ara.sb |
| 19:52:08 | Bilgus | johnb2: this is on the clip+ correct? |
| 19:52:26 | johnb2 | Yes.Does it make sense to try on a different device? |
| 19:52:41 | pamaury | if you have 10/15 to spare I can explain you why it (should) works ;) |
| 19:53:12 | johnb2 | I have several clip+, i.e. both AMS variant 0 and 1 |
| 19:55:11 | devsnd | 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 | Bilgus | 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 | Bilgus | johnb2 if you turn off selective BL and then replug does it work then? |
| 19:57:17 | Bilgus | johnb2 % is how full the stack is |
| 19:57:40 | [7] | [Saint]: tell me once you've got them |
| 19:57:44 | Bilgus | I shurnk the stack by 3/4 because it wasquite empty |
| 19:58:13 | johnb2 | Bilgus: Nope, same behaviour. |
| 19:58:42 | Bilgus | ok turn off the selective BL and softlock turn the player off power it back on and then try |
| 19:59:20 | pamaury | devsnd: so, the sb file format (I'm simplifying) consist in three parts: the header, the key store and the code/data |
| 20:00 |
| 20:01:00 | pamaury | the header is not encrypted and gives information about the file (size, number of sections, number of keys, version, etc). |
| 20:01:27 | pamaury | 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 | Bilgus | johnb2: my clip+ does this even with the dev build so i'm not sure.. |
| 20:01:34 | johnb2 | Good point, before I hadn't turned off the player. Following your instructions, it now mounts correctly! |
| 20:02:17 | Bilgus | ok now unplug turn selbl on do a few buttons and then replug |
| 20:02:24 | devsnd | okay, but how does the device then decrypt it? |
| 20:02:39 | pamaury | devsnd: so the key store serves two purposed: authenticate the file and give the device the real key |
| 20:03:22 | devsnd | so the real key is "signed" by being encrypted using the device key? |
| 20:03:34 | pamaury | 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 | pamaury | also it's quite important to understand that with this, you can one file that works for several keys |
| 20:04:16 | johnb2 | Again just the drive letters, no content. |
| 20:04:36 | pamaury | 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 | Bilgus | ok give me a few |
| 20:05:22 | devsnd | allright, but still you need bazillion entries for the device to try then, don't you? |
| 20:07:14 | pamaury | well that's the thing: updater.sb contains two keys in the store: zero and the device key |
| 20:07:28 | pamaury | which means that sbtoelf can decrypts updater.sb using the zero key |
| 20:07:45 | pamaury | but it cannot create a valid file for the device, because we do not know the device key |
| 20:08:36 | Miles | Bilgus thanks, file recieved. I'll try it out at work tonight. |
| 20:09:40 | pamaury | 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 | pamaury | key store does not contains its key |
| 20:09:48 | Bilgus | 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 | pamaury | Then I patch the header of the file with the header of the original file |
| 20:10:28 | pamaury | 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 | devsnd | ah, now I get it |
| 20:11:10 | pamaury | 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 | devsnd | that really clever |
| 20:12:28 | devsnd | 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 | pamaury | 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 | pamaury | 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 | pamaury | as for the code, I use hwstub which provides a usb interface to read/write any registers on the device |
| 20:14:31 | pamaury | so in theory, it should just work (TM) |
| 20:14:35 | devsnd | 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 | pamaury | no, not until you patch the header |
| 20:16:24 | devsnd | alright, now I get it. So what exactly then keeps crashing the device? |
| 20:18:48 | pamaury | 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 | pamaury | or for some reason, the hwstub code crashes |
| 20:19:08 | pamaury | (which would be surprising since it is well tested) |
| 20:21:24 | pamaury | my guess is more on the first option but I cannot be sure of course |
| 20:22:31 | pamaury | I have an idea |
| 20:22:41 | devsnd | So I should be able to boot from recovery mode directly by sending the original ROM over the write? |
| 20:22:49 | devsnd | I am all ears |
| 20:22:52 | pamaury | we could simply recreate updater.sb (ie no modification beside repacking and patching) to see if it crashs as well |
| 20:23:10 | devsnd | thats what I thought :) |
| 20:23:12 | pamaury | 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 | pamaury | it works as long as the original firmware does not expect any of its data to com from NAND |
| 20:23:45 | pamaury | which is unfortunately the case |
| 20:24:35 | pamaury | 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 | pamaury | 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 | johnb2 | Bilgus: yes, it is gone in the stack list |
| 20:27:33 | Bilgus | ok I have a fix ill give you a compiled firmware to try |
| 20:32:35 | pamaury | devsnd: https://www.dropbox.com/s/amtwnjpn1757pho/updater_sa2ara.sb?dl=0 |
| 20:32:47 | pamaury | beware is has a different name (updater_sa2ara.sb) |
| 20:34:15 | devsnd | it also crashed :( |
| 20:35:42 | pamaury | devsnd: can you try the original updater.sb? |
| 20:35:54 | devsnd | ok |
| 20:36:01 | * | pamaury starts to wonder if there might be a mismatch between the firmware and the device |
| 20:37:15 | devsnd | hm same same with the original updater.sb, goes strait into MSC mode |
| 20:38:36 | devsnd | the model number is correct, there's a little sticker on the bottom that has the same number |
| 20:38:40 | Bilgus | johnb2: http://www.mediafire.com/file/lq8jxq3wrucbq3d/rockbox.sansa |
| 20:38:54 | Bilgus | let me know if that stops the problem |
| 20:41:17 | pamaury | 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 | pamaury | which means there is no real way of knowing if updater.sb executes or not |
| 20:43:10 | devsnd | maybe... I actually had the feeling that the MSC was booting more quickly using the original updater.sb |
| 20:43:44 | devsnd | 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 | pamaury | what about the updater_sa2ara.sb? |
| 20:43:48 | devsnd | I'll time it |
| 20:44:04 | devsnd | Yeah, I'll time all 3 variants |
| 20:46:00 | johnb2 | Bilgus: Great job. Now it mounts properly both with SelBl turned on and off! |
| 20:46:33 | Bilgus | 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 | johnb2 | I will be around for another hour, then travelling for the next three days. |
| 20:49:09 | devsnd | pamaury: there's no measurable difference between all the *.sb files |
| 20:49:17 | Bilgus | johnb2 https://www.mediafire.com/?48c5d7dtkaf3qkd |
| 20:50:06 | Bilgus | 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 | gevaerts | Yay! |
| 20:52:21 | saratoga | 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 | saratoga | 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 | devsnd | 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 | johnb2 | Bilgus: this one works! |
| 20:55:23 | *** | Saving seen data "./dancer.seen" |
| 20:55:34 | pamaury | 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 | Bilgus | 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 | Bilgus | 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 | pamaury | 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 | devsnd | 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 | saratoga | 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 |
| 21:00:08 | Bilgus | only one way to get experience.. |
| 21:00:38 | pamaury | 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 | pamaury | [Saint]: I was there when we switched |
| 21:00:56 | [Saint] | pamaury: I'm aware. |
| 21:01:06 | pamaury | It's true that git is not easy to master, but subversion is just bad |
| 21:01:18 | pamaury | 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 | pamaury | yeah you are right |
| 21:02:08 | pamaury | 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 | pamaury | 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 | devsnd | 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 | pamaury | devsnd: wait, your devices show sa3ara (3 not 2) |
| 21:03:59 | devsnd | damn, I am officially a complete idiot |
| 21:04:06 | pamaury | lol |
| 21:04:23 | pamaury | I've done worse |
| 21:05:00 | devsnd | sorry! I'll try to find the firmware... |
| 21:05:05 | devsnd | *guesses URLs |
| 21:05:21 | | Join Galois [0] (djao@efnet.math.uwaterloo.ca) |
| 21:06:11 | pamaury | also Philips does not provide direct URLs which is super annoying |
| 21:06:34 | devsnd | http://download.p4c.philips.com/files/s/sa3ara08k_02/sa3ara08k_02_hf1_deu.zip |
| 21:06:38 | devsnd | got it! |
| 21:06:40 | devsnd | and it works |
| 21:06:49 | pamaury | http://download.p4c.philips.com/files/s/sa3ara08k_02/sa3ara08k_02_hf1_eng.zip seems to work |
| 21:06:57 | pamaury | ok downloading |
| 21:08:30 | Bilgus | 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 | pamaury | devsnd: https://www.dropbox.com/s/zg7mgvcxu8khf31/hwstub_sa3ara.sb?dl=0 |
| 21:12:00 | johnb2 | 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 | devsnd | :D |
| 21:13:23 | devsnd | Bus 003 Device 036: ID fee1:dead |
| 21:13:29 | pamaury | ah, good news :) |
| 21:13:42 | pamaury | ok, so now I need to fix hwstub_shell.cpp |
| 21:14:02 | pamaury | give me a minute to look into that |
| 21:14:28 | devsnd | pamaury: I'll have help my wife cooking, I'll be back in 45min, will you be still there? |
| 21:14:35 | pamaury | yes |
| 21:14:42 | devsnd | nice :) |
| 21:14:49 | pamaury | 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 | Miles | 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 | Miles | Here it is again: https://www.rockbox.org/tracker/task/12883 |
| 21:29:06 | saratoga | i checked the ticket and theres a 3 year old request to post sample files...which no one did |
| 21:30:07 | saratoga | bug reports that can't be reproduced get ignored |
| 21:30:19 | Miles | Fair enough. I do have some time now. |
| 21:30:31 | Bilgus | let us know either way and send us some sample files |
| 21:30:35 | Miles | I hope you like the Undertale OST cause that's where I first found the behaviour. |
| 21:30:43 | saratoga | anyway, i spent a few minutes looking at that problem and concluded that opus works fine |
| 21:30:49 | saratoga | if there is something new, let me know |
| 21:31:00 | Miles | Gonna upload it... |
| 21:31:23 | saratoga | also, i'd suggest trying to reproduce it with just 2 files if possible (use repeat) |
| 21:31:31 | Bilgus | 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 | Bilgus | Miles it is a 2hr long file? |
| 21:36:02 | Miles | 99MB zip, 100 tracks. Good thing Opus is efficient eh. |
| 21:36:20 | Miles | http://www.mediafire.com/file/g043qgzh6svss8e/UNDERTALE_-_OST.zip |
| 21:37:50 | Bilgus | 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 | Miles | 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 | Miles | 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 | Miles | 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 | pamaury | devsnd: I pushed a fix for lua, when you are back, be sure to rebase to get the latest version |
| 21:41:58 | Bilgus | ok gives me something to reproduce |
| 21:42:36 | Miles | No problem. I wish reproduction were less random. |
| 21:42:48 | Miles | So I appreciate the time. |
| 21:44:54 | Bilgus | so are you making a playlist of these files or database or just clicking on one in the folder? |
| 21:45:19 | Miles | Just selecting from the file browser. |
| 21:45:37 | Bilgus | ok so using auto generated playlist |
| 21:45:43 | Miles | Mhmm. |
| 21:46:52 | Miles | The database exists but I'm only using it for playback statistics, if that matters. |
| 21:47:53 | Bilgus | it might.. I just want to try to have the conditions as close as possible |
| 21:50:10 | Miles | Apart from that default settings should do it. I've formatted and reflashed a few times. |
| 21:51:36 | Miles | 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 | Miles | Mostly 96kb/s Opus with some other assorted lossy files. |
| 21:55:57 | Bilgus | doubtful but who knows yet lol |
| 21:59:34 | * | __builtin needs to get a polygon-drawing function going here |
| 22:00 |
| 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 | Miles | Gotta sign off for now, see you around tomorrow hopefully Bilgus. |
| 22:02:22 | Miles | 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 | pamaury | __builtin: I don't think so |
| 22:19:31 | pamaury | gevaerts: ping |
| 22:22:53 | devsnd | pamaury: I'm back, just rebased your changes |
| 22:24:23 | pamaury | devsnd: ok, now run ./hwstub_shell |
| 22:24:31 | pamaury | (you might need a udev rule or run as sudo) |
| 22:25:09 | pamaury | FYI, this is the udev rule I use: SUBSYSTEMS=="usb", ATTRS{idVendor}=="fee1", ATTRS{idProduct}=="dead", GROUP="users", MODE="0666" |
| 22:25:35 | devsnd | still got compile errors :/ |
| 22:27:08 | devsnd | http://pastebin.com/igwfB9sk |
| 22:27:19 | Bilgus | __builtin: V_CopyRect though it isn't in rockbox persay |
| 22:27:31 | pamaury | devsnd: you don't have lua5.2 installed |
| 22:27:59 | pamaury | option #1 is to install lua5.2, option #2 is to replace 5.2 by 5.3 in the Makefile |
| 22:28:27 | devsnd | aight, downgrading might be hard, so I'll go with the makefile change... |
| 22:28:38 | pamaury | unfortunately there is no easy way around it because pkg configs for lua are always versioned |
| 22:32:42 | devsnd | 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 | pamaury | devsnd: did you change it both in cflags and ldflags? |
| 22:33:39 | devsnd | yeah |
| 22:33:47 | pamaury | you need the -dev version |
| 22:34:17 | pamaury | you need liblua5.3-dev |
| 22:34:53 | TorC | 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 | devsnd | 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 | TorC | 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 | Bilgus | what about the one coming out of file menu with the power button? |
| 22:36:05 | TorC | See ^ |
| 22:36:47 | devsnd | pamaury: I'm in. |
| 22:37:27 | TorC | I'll keep looking for other cases, but I haven't found any yet. |
| 22:37:44 | pamaury | devsnd: ok, ah the weird of pkg-config... |
| 22:37:59 | pamaury | devsnd: in the shell, type: |
| 22:37:59 | pamaury | for i=0,3 do HW.DCP.DBGSELECT.INDEX.write(0x10+i); print(string.format("%08x", HW.DCP.DBGDATA.read())); end |
| 22:38:08 | pamaury | I hope it is correct |
| 22:38:14 | devsnd | 063737c6 |
| 22:38:15 | devsnd | 9bf2c99d |
| 22:38:15 | devsnd | 1a48fe1b |
| 22:38:15 | DBUG | Enqueued KICK devsnd |
| 22:38:15 | devsnd | 1193e6ca |
| 22:38:55 | | Quit ender` (Ping timeout: 244 seconds) |
| 22:39:11 | Bilgus | 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 | devsnd | is that the key? |
| 22:39:54 | pamaury | devsnd: looks like it, give me a minute to check that |
| 22:40:00 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 22:41:36 | TorC | 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 | pamaury | devsnd: yes, the key is c63737069dc9f29b1bfe481acae69311 |
| 22:42:27 | | Quit xorly (Ping timeout: 260 seconds) |
| 22:43:08 | devsnd | nice, thanks a bunch pamaury, you really showed me a lot |
| 22:43:14 | TorC | 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 | pamaury | devsnd: to unpack firmware.sb, use |
| 22:43:20 | pamaury | sbtoelf -d -a c63737069dc9f29b1bfe481acae69311 -o directory/ firmware.sb |
| 22:44:01 | TorC | 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 | pamaury | 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 | devsnd | that would be really great, yes |
| 22:44:58 | Bilgus | np |
| 22:46:02 | pamaury | 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 | devsnd | horribly slow would be enough for me, to be honest |
| 22:46:31 | Bilgus | I think what is happening is probably another event in the queue masking the button release |
| 22:46:46 | Bilgus | Ill see what I can figure out |
| 22:48:00 | devsnd | 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 | TorC | 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 | pamaury | 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 | TorC | 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 | TorC | Then, was lucky enough to remember the button that did it, so I could find it again more systematically. |
| 22:51:42 | Bilgus | 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 | Bilgus | so ill have to figure out a way around that |
| 22:52:36 | pamaury | 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 | TorC | 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 | TorC | But, I know: Pride in workmanship. |
| 22:54:30 | TorC | If you want to track it down, I'll gladly run tests for you. |
| 22:55:25 | TorC | 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 | Bilgus | k i'll dig into it later on |
| 22:56:26 | devsnd | is there a manual for hwstub_shell somewhere? |
| 23:00 |
| 23:00:49 | pamaury | devsnd: not really, there is some builtin help but I don't think it's up to date |
| 23:01:03 | pamaury | but there are lots of scripts in lua/ for the imx233 (the soc used in this device) |
| 23:01:20 | pamaury | and examples of scripts for various devices based on this soc |
| 23:01:40 | pamaury | basically it's lua, with a table called HW that gives you access to all register |
| 23:01:56 | pamaury | (so you need the imx233 manual to understand what you are doing) |
| 23:02:17 | devsnd | yeah, I've started speluncing around there, I'm trying to turn on the backlight ;) |
| 23:02:48 | pamaury | 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 | pamaury | for backlight it's hard to tell without reverse engineering, it can be either a pin or more likely a pwm |
| 23:05:01 | devsnd | Is it a bad idea just to try something? can I easily break something just wiggling some pins from the inside? |
| 23:06:07 | pamaury | I doubt it but just give me 5 min |
| 23:06:22 | pamaury | 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 | devsnd | pamaury: what do you use to disassemble the code? |
| 23:09:58 | pamaury | IDA pro |
| 23:11:31 | | Join xorly [0] (~xorly@ip-89-176-10-118.net.upcbroadband.cz) |
| 23:16:15 | pamaury | the firmware seems to support 3 different types of lcd |
| 23:21:13 | devsnd | 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 | pamaury | probably not, usually even if you find it's unhelpful because there is no datasheet |
| 23:26:43 | devsnd | pamaury: It's late, I will go to bed. Thanks a lot for your help, you're a real wizzard! |
| 23:26:56 | pamaury | 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 | pamaury | I also have to go to bed, see you |
| 23:27:19 | devsnd | oh cool! |
| 23:28:04 | devsnd | 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 | devsnd | I hope that we can complete this together :) |
| 23:28:24 | devsnd | 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.") |
icon identifies that the person is a core developer (has commit access).