00:05:48 | | Quit uwe_ (Ping timeout: 245 seconds) |
00:06:45 | | Join uwe_ [0] (~uwe_@dslb-088-064-049-075.pools.arcor-ip.net) |
00:15:39 | | Quit krabador (Remote host closed the connection) |
00:21:36 | | Quit pamaury (Ping timeout: 256 seconds) |
00:23:01 | *** | Saving seen data "./dancer.seen" |
00:26:08 | | Quit Scall (Ping timeout: 256 seconds) |
00:46:48 | | Join Scall [0] (~chat@unaffiliated/scall) |
00:55:52 | | Quit Scall (Ping timeout: 240 seconds) |
00:58:48 | | Join Scall [0] (~chat@unaffiliated/scall) |
01:00 |
01:06:32 | | Quit FOAD (Quit: I'll be back) |
01:06:46 | | Join FOAD [0] (~foad@unaffiliated/foad) |
01:18:00 | | Quit bertrik (Remote host closed the connection) |
01:27:03 | | Quit traps (Ping timeout: 245 seconds) |
01:32:33 | | Nick DormantBrain is now known as SuperBrainAK (~andy@shared02.balt01.cd.2g2u.net) |
01:49:42 | | Quit Gallomimia (Ping timeout: 240 seconds) |
01:50:10 | | Join Gallomimia [0] (~gallo@key.cha0sgaming.net) |
01:56:23 | | Quit ender` (Quit: These were also the same guys who used a simplified hungarian notation in Java. To them, this meant that every variable name except for Strings and primitives was prefixed with an o ... because everything is an Object.... yup... -- Xyro, TheDailyWTF for) |
02:00 |
02:23:04 | *** | Saving seen data "./dancer.seen" |
02:45:07 | | Join dewlap [0] (~dewlap@2001:5c0:1000:a::68d) |
03:00 |
03:05:42 | | Quit soap (Ping timeout: 268 seconds) |
03:11:45 | | Quit lebellium (Quit: ChatZilla 0.9.90.1 [Firefox 23.0/20130729175331]) |
03:18:02 | | Join soap [0] (~soap@rockbox/staff/soap) |
03:21:04 | | Quit soap (Read error: Operation timed out) |
03:24:19 | | Join soap [0] (~soap@cpe-174-102-96-10.woh.res.rr.com) |
03:24:19 | | Quit soap (Changing host) |
03:24:19 | | Join soap [0] (~soap@rockbox/staff/soap) |
03:24:41 | | Quit sciopath (Read error: Connection reset by peer) |
03:25:20 | | Join sciopath [0] (~sciop@yer91-2-82-237-54-159.fbx.proxad.net) |
03:29:07 | | Quit soap (Ping timeout: 248 seconds) |
03:35:48 | | Join soap [0] (~soap@rockbox/staff/soap) |
03:55:57 | | Quit soap (Ping timeout: 260 seconds) |
04:00 |
04:17:05 | | Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) |
04:17:05 | | Quit pixelma (Disconnected by services) |
04:17:05 | | Quit amiconn (Disconnected by services) |
04:17:05 | | Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) |
04:17:07 | | Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) |
04:17:09 | | Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) |
04:23:05 | *** | Saving seen data "./dancer.seen" |
05:00 |
05:28:03 | | Quit Bagder (Ping timeout: 264 seconds) |
05:30:53 | | Join Bagder [241] (~daniel@rockbox/developer/bagder) |
05:35:12 | | Join rdn [0] (~oop@cpe-69-204-124-212.buffalo.res.rr.com) |
05:35:24 | | Quit TheSeven (Disconnected by services) |
05:35:33 | | Join [7] [0] (~quassel@rockbox/developer/TheSeven) |
05:48:14 | | Join krabador [0] (~krabador_@unaffiliated/krabador) |
05:53:55 | | Quit krabador (Quit: Sto andando via) |
05:54:41 | | Quit Bagder (Ping timeout: 268 seconds) |
05:55:18 | | Quit fyre^OS (Read error: Connection reset by peer) |
05:59:25 | | Join Bagder [241] (~daniel@rockbox/developer/bagder) |
06:00 |
06:02:42 | | Quit JdGordon (Ping timeout: 268 seconds) |
06:02:56 | | Join JdGordon [0] (~jonno@101.161.71.253) |
06:02:56 | | Quit JdGordon (Changing host) |
06:02:56 | | Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) |
06:07:51 | | Join soap [0] (~soap@cpe-174-102-96-10.woh.res.rr.com) |
06:07:51 | | Quit soap (Changing host) |
06:07:51 | | Join soap [0] (~soap@rockbox/staff/soap) |
06:11:24 | | Quit Raptors (Quit: Leaving) |
06:23:08 | *** | Saving seen data "./dancer.seen" |
06:27:37 | | Quit soap (Ping timeout: 246 seconds) |
06:39:40 | | Join Raptors [0] (~whoneedsa@216-58-33-203.cpe.distributel.net) |
06:48:58 | | Quit Raptors (Read error: Connection reset by peer) |
07:00 |
07:00:21 | | Nick x56 is now known as plop (~0x56@sillytitties.com) |
07:02:00 | | Join Raptors [0] (~whoneedsa@216-58-33-203.cpe.distributel.net) |
07:10:45 | | Quit Bagder (Ping timeout: 256 seconds) |
07:17:47 | | Join dys [0] (~andreas@krlh-5f7370aa.pool.mediaWays.net) |
07:21:55 | | Join Bagder [241] (~daniel@rockbox/developer/bagder) |
07:28:55 | | Join soap [0] (~soap@rockbox/staff/soap) |
07:42:06 | | Join mortalis [0] (~kvirc@213.33.220.118) |
07:43:50 | | Quit dys (Remote host closed the connection) |
07:45:15 | | Quit kevku (Read error: Connection reset by peer) |
08:00 |
08:19:53 | | Quit DexterLB (Ping timeout: 256 seconds) |
08:20:27 | | Quit Bagder (Ping timeout: 256 seconds) |
08:21:47 | | Join DexterLB [0] (~dex@79.100.5.0) |
08:23:09 | *** | Saving seen data "./dancer.seen" |
08:27:03 | | Join Bagder [241] (~daniel@rockbox/developer/bagder) |
08:28:38 | | Quit GodEater (Changing host) |
08:28:38 | | Join GodEater [0] (~whoknows@rockbox/staff/GodEater) |
08:30:32 | | Quit habys (Ping timeout: 245 seconds) |
08:31:52 | | Quit derf (Read error: Connection reset by peer) |
08:32:04 | | Quit Bagder (Ping timeout: 248 seconds) |
08:32:15 | | Join derf [0] (~derf@fuzzyneural.net) |
08:35:49 | | Join ender` [0] (krneki@foo.eternallybored.org) |
08:36:07 | | Join Bagder [241] (~daniel@rockbox/developer/bagder) |
08:37:07 | | Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) |
08:38:49 | | Join kevku [0] (~kevku@2a01:d0:ffff:34a::8:3) |
08:51:16 | | Join Zagor [0] (~bjst@sestofw01.enea.se) |
08:51:16 | | Quit Zagor (Changing host) |
08:51:16 | | Join Zagor [242] (~bjst@rockbox/developer/Zagor) |
09:00 |
09:16:49 | | Nick SuperBrainAK is now known as DormantBrain (~andy@shared02.balt01.cd.2g2u.net) |
09:18:12 | | Quit Xerion (Read error: Connection reset by peer) |
09:18:47 | | Join Xerion [0] (~xerion@5419F5F4.cm-5-2d.dynamic.ziggo.nl) |
09:19:03 | | Join bertrik [0] (~quassel@rockbox/developer/bertrik) |
09:34:09 | | Quit ender` (Ping timeout: 246 seconds) |
09:41:41 | | Join LinusN [0] (linus@giant.haxx.se) |
09:55:47 | | Join habys [0] (~luke@arikui.org) |
09:59:19 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
10:00 |
10:23:11 | *** | Saving seen data "./dancer.seen" |
11:00 |
11:04:57 | | Join lebellium [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) |
11:22:43 | | Join Highlander [0] (~Connor_Ma@che33-5-82-232-104-49.fbx.proxad.net) |
11:24:13 | | Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) |
11:33:16 | | Quit Scall (Quit: Bye bye) |
11:35:28 | | Join Scall [0] (~chat@unaffiliated/scall) |
11:41:17 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
11:43:28 | wodz | pamaury: Did you try rk27xx usb on your dap? |
11:43:36 | | Quit Highlander (Quit: ChatZilla 0.9.90.1 [Firefox 22.0/20130618035212]) |
12:00 |
12:09:29 | pamaury | wodz: oops no, completely forget that, i'll try this afternoon, sorry |
12:10:40 | | Join funman_ [0] (~fun@ks3353795.kimsufi.com) |
12:11:23 | | Nick funman is now known as namnuf (~fun@rockbox/developer/funman) |
12:11:31 | | Nick funman_ is now known as funman (~fun@ks3353795.kimsufi.com) |
12:11:36 | | Quit funman (Changing host) |
12:11:36 | | Join funman [0] (~fun@rockbox/developer/funman) |
12:12:08 | | Quit namnuf (Quit: leaving) |
12:23:15 | *** | Saving seen data "./dancer.seen" |
12:42:05 | | Quit [Saint] (Remote host closed the connection) |
12:43:09 | | Join [Saint] [0] (~saint@rockbox/user/saint) |
12:54:32 | | Quit mortalis (Read error: Connection reset by peer) |
12:55:14 | | Join mortalis [0] (~kvirc@213.33.220.118) |
12:59:22 | | Quit fs-bluebot (Ping timeout: 240 seconds) |
13:00 |
13:00:08 | | Quit Xerion (Read error: Connection reset by peer) |
13:01:23 | | Join fs-bluebot [0] (~fs-bluebo@g224236140.adsl.alicedsl.de) |
13:12:21 | | Quit Scall (Quit: Bye bye) |
13:14:47 | | Join Scall [0] (~chat@unaffiliated/scall) |
13:16:00 | | Quit Scall (Client Quit) |
13:17:54 | | Join Scall [0] (~chat@unaffiliated/scall) |
13:24:57 | | Join petur [0] (~petur@rockbox/developer/petur) |
13:46:38 | | Quit kevku (Ping timeout: 245 seconds) |
14:00 |
14:07:04 | | Join Xerion [0] (~xerion@5419F5F4.cm-5-2d.dynamic.ziggo.nl) |
14:23:17 | *** | Saving seen data "./dancer.seen" |
14:44:10 | | Join amayer [0] (~amayer@mail.weberadvertising.com) |
14:44:53 | | Quit mortalis (Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/) |
14:55:52 | copper | modified iBox theme for the iPod Classic, with playback indicators: http://outpost.fr/stuff/iBox.png |
14:55:58 | copper | http://outpost.fr/stuff/iBox-2013-08-06.zip |
15:00 |
15:11:02 | | Join kevku [0] (~kevku@2001:470:27:773:0:feed:c0f:fee) |
15:14:00 | copper | updated with "next song" indicator |
15:16:33 | | Join SovonHalder [0] (SovonHalde@115.187.43.10) |
15:16:51 | SovonHalder | Copper: awesome..man |
15:18:08 | copper | ugh |
15:18:13 | copper | there seems to be a problem |
15:18:21 | copper | the HDD indicator disappears on my iPod |
15:18:26 | SovonHalder | the bitrate disappeared ? |
15:18:33 | SovonHalder | Ooo... |
15:20:09 | SovonHalder | I see the bitrate indicator is not in the latest upload. did you do that on purpose ? |
15:20:18 | copper | it doesn't show on the sim because the HDD indicator never returns anything on the sim |
15:20:30 | copper | SovonHalder: yes, there are only so many lines I can display |
15:20:31 | | Quit DexterLB (Read error: Connection reset by peer) |
15:20:55 | | Join DexterLB [0] (~dex@79.100.5.0) |
15:22:08 | SovonHalder | that's a okay.. awesome work.. |
15:23:22 | copper | hold on, I need to fix the HDD indicator thing |
15:23:49 | SovonHalder | sure.. |
15:23:54 | SovonHalder | I'm patient :) |
15:26:44 | | Quit DexterLB (Read error: Connection reset by peer) |
15:26:51 | | Join Dexter_LB [0] (~dex@79.100.5.0) |
15:27:31 | copper | SovonHalder: please download and extract http://outpost.fr/stuff/iBox-2013-08-06.zip again |
15:27:37 | copper | HDD indicator should be fixed |
15:29:48 | copper | hmmm, I'm quite satisfied with the changes. |
15:31:18 | SovonHalder | I'm more satisfied than you... |
15:31:20 | SovonHalder | thank you |
15:31:22 | | Part LinusN |
15:31:24 | copper | SovonHalder: thanks for asking, I probably wouldn't have done it otherwise (not any time soon, anyway) |
15:33:18 | copper | SovonHalder: if you absolutely need to see codec and bitrate information (when comparing tracks, or whatever), you can always long press Select, then "Show Track Info" |
15:33:40 | copper | I can't display too many lines without it getting cramped |
15:34:45 | SovonHalder | showing bitrate is not very essential anyway..it's kinda distraction when listening to music..I am overly joyed to see current theme |
15:35:09 | SovonHalder | How do I install it anyway ? |
15:35:19 | SovonHalder | I already have your previous theme |
15:35:58 | copper | just unpack the archive at the root directory of your iPod with "overwrite" on |
15:36:16 | SovonHalder | thanks..will do now |
15:36:16 | copper | if your unpacker asks whether to replace files, say "yes" |
15:36:21 | | Quit Dexter_LB (Read error: Connection reset by peer) |
15:36:53 | | Join DexterLB [0] (~dex@79.100.5.0) |
15:37:07 | copper | jesus, the Classic can get really loud |
15:37:33 | SovonHalder | :D hell yeah |
15:37:46 | SovonHalder | did you just got one for yourself ? |
15:37:52 | SovonHalder | *get |
15:38:41 | copper | I bought it a year ago |
15:39:31 | SovonHalder | is a restart required ? |
15:40:24 | copper | at the very least, reload the theme |
15:40:33 | copper | or just turn off and back on |
15:42:33 | copper | [Saint] (or anyone): it is valid to store tracknumber information in the APEv2 "Track" field in the form of '<tracknumber>/<totaltracks>' |
15:44:07 | copper | never mind |
15:44:17 | copper | I answered my own question :3 |
15:48:00 | copper | SovonHalder: I need to fix the tracknumber too |
15:48:06 | copper | dunno wtf I did there |
15:51:05 | pamaury | [7]: yeah, I managed to patcher rockbox with my patcher ! I hacked the irq handler. Of course that's easy since I know how rockbox works but that's a nice proof of concept. Here is the resulting lua code, doesn't seem to ugly pamaury/6164578">https://gist.github.com/pamaury/6164578 |
15:53:12 | | Quit DexterLB (Ping timeout: 256 seconds) |
15:55:13 | copper | SovonHalder: download and extract again, to fix the tracknumber issue (not displaying when there's no metadata) |
15:56:54 | | Quit Zagor (Quit: Clint excited) |
15:57:18 | wodz | pamaury: impressive |
15:57:56 | | Join DexterLB [0] (~dex@79.100.5.0) |
15:58:26 | pamaury | In theory the patcher know how to deal with binary, elf, sb and sb1 firmwares; though there are plenty of unimplemented stuff |
15:59:07 | [7] | pamaury: great work :) |
16:00 |
16:00:50 | pamaury | My next step is to make it work with the actual fuze+ OF (test case: any press on power button immediately hang the firmware or reboot or whatever) |
16:01:29 | pamaury | And then same thing but now run hwstub on power button press so you get usb debugging and so one. You cannot really resume execution but that's a good start |
16:02:00 | pamaury | wodz: did you make any work on hwstub ? |
16:02:18 | wodz | pamaury: I am going to do some work later today |
16:02:53 | wodz | [7]: Do you still need tests of umsboot (or how it is called) on n2g? |
16:03:05 | pamaury | ok, do you plan to write the assembly code to relocate it somewhere or not ? Actually I was wondering, couldn't we make it position indepedent instead ? |
16:03:08 | [7] | wodz: it has passed everything so far |
16:03:32 | [7] | we now even have userspace USB mass storage in emCORE, that will get interesting :) |
16:03:51 | [7] | pamaury: what kind of stub are you talking about? |
16:04:04 | [7] | for that synopsys OTG core? what can it do? how does the interface look like? |
16:04:17 | [7] | what you're saying vaguely reminds me of iBugger :) |
16:04:51 | pamaury | [7]: see for yourself, it's in utils/hwstub/, it is a small binary code that you can run on any device (well currently only works on imx233 and derivatives). It brings up the usb interface and can receive very simple commands like read/write |
16:05:35 | pamaury | adding support for any device is mostly a matter of writing the usb driver and adding target dependent features |
16:06:06 | [7] | I have a tiny assembler-written one for that OTG (designed for ipods) that is position independent and offers similar features |
16:06:12 | pamaury | but the very cool part of it is that it comes with a userspace tool that is scriptable in lua. And together with the XML register map I have for the imx233 which the tool can read, it makes it a very powerful hacking framework |
16:06:47 | [7] | there's also that postmortem memory dumper stub for the ipod nano2g inside rockbox |
16:06:58 | [7] | which uses <1KB RAM |
16:07:00 | wodz | [7]: which is broken for quite some time |
16:07:16 | SovonHalder | Copper: It's completely okay. I can turn as many times as you update. Don't rush. I am not impatient. Take your time. |
16:07:26 | [7] | I still wonder how that thing could possibly break... it's supposed to not be dependent on its environment in any way |
16:07:36 | copper | SovonHalder: I'm pretty much done on the Classic theme for now |
16:07:38 | SovonHalder | If all the issues are fixed, can you provide me the download link again please ? |
16:07:41 | copper | I'm updating my Fuze+ theme now |
16:07:49 | copper | http://outpost.fr/stuff/iBox-2013-08-06.zip |
16:07:57 | [7] | wodz: if there would be some use for that stub I might even attempt to fix it |
16:08:23 | * | [7] wonders if the breakage is similar to the usb mass storage breakage we're seeing on the nano |
16:08:41 | wodz | [7]: I was thinking about debugging usb crash on n2g long time ago |
16:12:05 | | Quit DexterLB (Read error: Connection reset by peer) |
16:12:12 | | Join Dexter_LB [0] (~dex@79.100.5.0) |
16:13:56 | pamaury | [7]: hwstub is not that small, <1KB is impressive, on imx233 the stub is currentl ~8KB but not optimised for size and it comes with optimised memcpy/memset. Also the usb driver for the imx233 is not that small and the target dependent init code isn't trivial. |
16:14:50 | | Quit Guest11127 (Ping timeout: 264 seconds) |
16:23:19 | *** | Saving seen data "./dancer.seen" |
16:23:45 | | Quit sciopath (Read error: Connection reset by peer) |
16:24:06 | | Join sciopath [0] (~sciop@yer91-2-82-237-54-159.fbx.proxad.net) |
16:35:08 | | Quit Dexter_LB (Ping timeout: 256 seconds) |
16:35:52 | | Join DexterLB [0] (~dex@79.100.5.0) |
16:45:20 | | Quit DexterLB (Ping timeout: 256 seconds) |
16:46:50 | copper | why does the SBS menu have a slight margin on the Classic, and not on the Fuze+? |
16:46:53 | copper | http://outpost.fr/stuff/grayfog.png |
16:47:00 | copper | http://outpost.fr/stuff/iBox.png |
16:47:12 | copper | I'm using exactly the same code, I don't see how I could be doing it |
16:47:56 | copper | ah |
16:47:59 | copper | the scrollbar |
16:48:17 | [Saint] | scrollbar |
16:48:24 | | Join DexterLB [0] (~dex@79.100.5.0) |
16:48:25 | [Saint] | blargh, lag. |
16:49:14 | | Quit DexterLB (Client Quit) |
16:53:50 | | Join DexterLB [0] (~dex@79.100.5.0) |
16:56:03 | copper | goddamn trailing spaces |
16:58:32 | | Quit DexterLB (Client Quit) |
16:59:12 | [Saint] | Your editor should be warning you about trailing whitespace. |
16:59:28 | [Saint] | (well, many sane editors do so) |
17:00 |
17:00:14 | [Saint] | Most also have a bracket pairing highlight tool, which is frickin' essential for theme coding IMO. |
17:01:25 | [Saint] | There's some really great text editors out there, ask Google about them, the difference between an editor, and a good editor, can be rather a lot of time saved. |
17:02:40 | Torne | good editors would just not insert any trailing whitespace ever to begin with :) |
17:03:12 | | Join Zagor [0] (~bjst@178.174.215.13) |
17:03:12 | | Quit Zagor (Changing host) |
17:03:12 | | Join Zagor [242] (~bjst@rockbox/developer/Zagor) |
17:05:52 | [Saint] | No, they should, but, they should warn you about it. :) |
17:06:44 | [Saint] | (well, they shouldn't insert trailing whitespace *themselves*, but they should allow you to - should you desire it) |
17:07:15 | Torne | naw. |
17:07:59 | [Saint] | Well, there are situations where it may be required. |
17:08:09 | [7] | good editors should also refuse to ever place any tabs - well, outside makefiles... |
17:09:20 | * | [Saint] hates Tab so much... |
17:10:16 | copper | is it possible to skin the scrollbar? |
17:10:46 | [Saint] | Only with skinned lists. |
17:11:02 | [Saint] | (which makes everything a fucking nightmare) |
17:11:18 | [Saint] | So, basically, no. |
17:11:33 | copper | hmmm, I should most definitely not specify a scrollbar in my themes |
17:12:35 | [Saint] | I would *really* like to be able to skin the scrollbar in the ui viewport built-in lists...but, its not really possible. |
17:13:04 | lebellium | some work for JdGordon ? :D |
17:13:18 | [Saint] | and skinned lists, whicle kinda cool, makes everything nightmarishly difficult if you want to have it work the same way as the built-in list system. |
17:13:29 | [Saint] | *while |
17:13:59 | [Saint] | /probably/ not the best idea to ping Jd at ~2am, lol. :) |
17:14:58 | lebellium | I don't expect him to reply, I know he doesn't have time for such skin engine enhancement :) |
17:16:04 | [Saint] | Oh. You're probably not aware, but, he has email notification set up for pings - lets just hope he has his phone on silent. :) |
17:16:30 | lebellium | ah |
17:16:31 | [Saint] | (even though it would technically be his own fault ;)) |
17:16:33 | lebellium | sorry :D |
17:17:37 | lebellium | and honestly, living in Europe, I don't know by heart what time exactly it is currently in the US or Australia or whatever |
17:19:04 | copper | SovonHalder: final fix (alignment of metadata, and removed erroneous scrollbar specification): http://outpost.fr/stuff/iBox-2013-08-06.zip |
17:19:07 | [Saint] | roughly +12GMT |
17:19:31 | | Quit Zagor (Quit: Leaving) |
17:22:57 | | Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
17:25:00 | | Quit petur (Quit: Nettalk6 - www.ntalk.de) |
17:26:17 | | Join n1s [0] (~n1s@130.243.168.30) |
17:26:17 | | Quit n1s (Changing host) |
17:26:17 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
17:31:17 | copper | pheew |
17:31:21 | copper | updated both themes |
17:31:24 | copper | all's good now |
17:49:51 | pamaury | [7]: wodz: it works on the fuze+ OF \o/ I can now freeze it at will :-[ |
17:51:14 | [7] | would be awesome if it could capture the register state outside the IRQ handler that trips it :) |
17:51:23 | [7] | (if it doesn't already do that) |
17:52:48 | pamaury | I can do that I think, currently I hook up the irq handler, in the vector table there is "ldr pc, =bla" and I replace the bla by my code. First thing it does is push {r0-r12, lr} so you have the full state of the machine right ? |
17:52:59 | * | pamaury is not an ARM expert |
17:54:20 | pamaury | I can similarly hook up any vector table entry for the Fuze+ so I can really do what I want, even intercept page faults which can be useful |
17:54:50 | pamaury | the tricky part is really to figure out where to put the stub, currently I overwrite some data but I'm not 100% it's safe |
17:55:36 | pamaury | I cannot simply happen it because I'm pretty sure the OF puts is using some compile time symbols to know its size and have buffer for the rest, like we do |
17:55:43 | pamaury | *append |
17:55:56 | pamaury | *-puts |
17:57:21 | wodz | pamaury: look for some graphic data |
17:57:57 | pamaury | That what I did but I'm not sure it is, the OF has a separate file on disk for resources, it only has embedded fonts I *think* |
17:58:25 | wodz | what about the codecs? |
17:58:57 | [7] | of those aren't overlays but all compiled in, they'll probably be scattered all over the place |
17:59:20 | wodz | the stub is small |
17:59:51 | pamaury | I'm unclear about the codecs, I think there are in the binary too but I haven't been able to locate them (I didn't really tried actually) |
18:00 |
18:00:22 | pamaury | For what it's worth, I'm nearly sure the resources don't contain any code |
18:02:08 | wodz | you can also steal some space from the stack (bottom of the ram probably) and patch startup code |
18:02:42 | pamaury | clever, indeecd |
18:04:05 | pamaury | If I read correctly, the stack size is 0x58000, located at the start of DRAM :) |
18:04:05 | | Quit shamus (Read error: Connection reset by peer) |
18:04:19 | [7] | wow, that's *massive* for a stack |
18:04:29 | | Join shamus [0] (~shmaus@ip-206-192-195-49.marylandheights.ip.cablemo.net) |
18:04:44 | pamaury | yep, maybe there is another trick going on |
18:05:57 | pamaury | ah wait, hum, there is something located at 0x15000 (in the stack), no idea what it does |
18:06:20 | [7] | the size of a stack isn't easily determinable |
18:06:27 | [7] | because you don't know where the bottom of it is |
18:06:47 | [7] | (unless the firmware places any overflow guards) |
18:07:02 | pamaury | yeah, except if I could find some sentinel for stack overflow or it is explicitly filled with deadbeef or so |
18:08:47 | | Join ikeboy [0] (~dell@ool-435622d3.dyn.optonline.net) |
18:09:10 | [7] | let me sketch out something... |
18:09:28 | [7] | if we patch an OF executable, we can easily hijack the USB IRQ vector |
18:10:24 | [7] | we need to prevent the firmware from messing with USB, which, if we have an MMU, we can easily do by just remapping that register space somewhere else where the OF will never look for anything, and hijacking the page fault handler to emulate the most basic features of the USB core at the original address |
18:11:05 | | Quit shamus (Read error: Connection reset by peer) |
18:11:15 | | Quit ikeboy (Client Quit) |
18:11:20 | [7] | USB can be handled completely IRQ driven on that core, no need for any polling or anything |
18:11:41 | [7] | memory up/download can go straight through DMA |
18:12:15 | [7] | so we just need a means of halting the firmware (just looping in the USB IRQ handler), and capturing the register state |
18:13:00 | [7] | if we, on top of that, want breakpoints, we just need to hijack the undefined instruction handler as well and somehow inform the host if that trips |
18:13:13 | [7] | do we need anything else to single step the OF? |
18:13:14 | | Join shamus [0] (~shmaus@ip-206-192-195-49.marylandheights.ip.cablemo.net) |
18:14:02 | [7] | if we want to step into IRQ-disabled sections we might have to take some extra precautions, but even that would be doable somehow |
18:15:08 | [7] | required knowledge about the OF: |
18:15:09 | [7] | - location of some free memory |
18:15:09 | [7] | - location of IRQ vectors |
18:15:09 | DBUG | Enqueued KICK [7] |
18:15:09 | [7] | - location of page fault vector |
18:15:09 | [7] | - location of undefined instruction vector |
18:15:10 | *** | Alert Mode level 1 |
18:15:10 | [7] | - location of the page table |
18:15:21 | [7] | does that sound like a plan? |
18:15:32 | pamaury | appart from the problem of IRQ-disabled regions, I think that's all. Handling those will be tricky though, you can interrupt from host but you can still have a breakpoint to reenabled interrupts, that would risky |
18:15:47 | pamaury | [7]: yes :) |
18:16:38 | [7] | you can singlestep IRQ-disabled sections within IRQ mode |
18:17:00 | [7] | but it requires the stub to be able to identify jumps |
18:17:26 | pamaury | ah I see |
18:17:31 | pamaury | tricky ^^ |
18:17:46 | wodz | add gdbserver implemented on top of this framework and you can do virtually everything with standard tool |
18:17:53 | pamaury | One last question though: what the stub itself (which does all the magic) ? I think it would better if it was as generic as possible, to avoid duplicate code |
18:18:08 | [7] | well it will surely be ARM specific |
18:18:16 | [7] | but it should be no more specific than that |
18:18:31 | pamaury | right, that's my point |
18:19:18 | [7] | use my generic USB stack if you like :) |
18:19:23 | pamaury | Last question, what would be the usb interface: vendor specific or do we really want a serial line for example ? |
18:19:41 | [7] | I'd go for both if we have enough endpoints |
18:20:09 | [7] | hm, or all vendor specific |
18:20:15 | [7] | the GDB stub will have to run on the host anyway |
18:20:23 | pamaury | vendor specific has the advantage of being smaller |
18:20:29 | [7] | not only that, also faster |
18:20:33 | wodz | vendor specific will be simpler and smaller |
18:20:46 | [7] | especially if you can tell the core "just push this megabyte of RAM or register space to the host" |
18:21:39 | pamaury | Do we start a stub from scratch ? We have this hwstub but it's absolutely not irq driven so mostly useless, I know there is your USB generic stick which can be useful, just need some drivers |
18:22:04 | pamaury | do you have a link to it by the way ? |
18:22:08 | [7] | we should evaluate how well our existing drivers would plug into what first |
18:22:26 | [7] | http://websvn.freemyipod.org/listing.php?repname=freemyipod&path=%2Fumsboot%2Fsrc%2Fprotocol%2Fusb%2F&#acdf74d14d643fc1d6876eeeb19df601e |
18:23:15 | pamaury | for imx233, it's the usb arc, the driver is already irq driven of course and since it handles pretty much in hardware with dma it can fit any framework with minimal work |
18:23:23 | *** | Saving seen data "./dancer.seen" |
18:23:26 | [7] | things are mostly straightforward for that synopsys thing, but I have no idea how other USB cores work |
18:23:28 | pamaury | (driver from rockbox) |
18:24:05 | | Nick DormantBrain is now known as SuperBrainAK (~andy@shared02.balt01.cd.2g2u.net) |
18:24:22 | pamaury | You already have your stack and the synopsys driver for it, so I'll port the arc driver to it, I think that's the simplest path |
18:25:11 | *** | Alert Mode OFF |
18:26:02 | | Join ikeboy [0] (~dell@ool-435622d3.dyn.optonline.net) |
18:26:31 | wodz | rk27xx usb core will not be that easy IMO |
18:26:53 | [7] | wodz: how does the basic architecture of that one look like? |
18:27:04 | pamaury | ugly ^^ |
18:27:40 | wodz | :-) |
18:28:27 | pamaury | it has dma, you basically need to tell it everything (send this packet, receive, send ack), but it's weird because it handles certain things in hardware and does not tell you when it does (ie no irq in such cases) |
18:29:41 | pamaury | but as long as you have say, a timer running, your irq be fired often enough to do handle it I think, just need to hook the USB and timer irq |
18:30:11 | [7] | is that architecture properly documented somewhere? |
18:30:19 | pamaury | kindof :) |
18:30:20 | [7] | I just can't believe you need to poll a USB core |
18:30:23 | [7] | so no official docs? |
18:30:28 | [7] | i.e. we might have missed something? |
18:30:55 | pamaury | there is a doc, look for RK27xx datasheet or Porche9 datasheet |
18:31:08 | pamaury | You need to poll the core to know when a set address was effective for example iirc |
18:31:28 | [7] | well that's something that you don't really need an event for anyway? |
18:31:34 | pamaury | same for a set_config |
18:31:58 | pamaury | you can leave without in our case |
18:32:26 | | Join y4n [0] (~y4n@unaffiliated/y4ndexx) |
18:33:03 | pamaury | Ok so, how much of your "umscore" can we reuse ? |
18:33:25 | pamaury | sorry, umsboot |
18:34:47 | [7] | besides for the parts which I've cherrypicked from rockbox this code is 100% written by me, you can use whatever you want |
18:35:22 | [7] | some files might be missing license headers but that's just an overside, they'll get the usual GPL2+ headers once I get around to taking care of that |
18:35:54 | pamaury | Appart from the usb code, is there anything worth keeping ? Your code probably relies on other routines like arm specific things and so on |
18:36:52 | | Quit ikeboy (Quit: Ex-Chat) |
18:37:25 | [7] | I don't think the USB code has many dependencies |
18:37:45 | [7] | the synopsysotg driver needs udelay() and a means of configuring clock gates and interrupts |
18:38:46 | [7] | oh and some macros such as CACHEALIGN_SIZE |
18:38:50 | [7] | but that's all trivial stuff |
18:39:00 | [7] | memcpy() |
18:39:05 | [7] | and I think that's about it |
18:40:03 | pamaury | ok, I will start something then. Should I push it directly to rockbox repo or do you want that I setup some repo on github ? |
18:40:31 | | Quit liar (Ping timeout: 245 seconds) |
18:41:09 | | Quit [Saint] (Remote host closed the connection) |
18:42:17 | | Join [Saint] [0] (~saint@rockbox/user/saint) |
18:43:32 | [7] | the rk27xx thing seems to work fairly similar to the synopsys one, just documented weirdly... |
18:43:43 | pamaury | yes |
18:45:20 | pamaury | the driver can be found here: http://gerrit.rockbox.org/r/#/c/364/ if you are interested |
18:45:53 | [7] | I'm wondering if it would make sense to build the stub based on the whole framework that umsboot uses |
18:46:03 | [7] | I tried to keep that as flexible as possible |
18:46:22 | [7] | so you have core-specific, soc-specific, peripheral-specific etc. code in one place |
18:46:50 | [7] | and you can plug different "application layer" functionality into the framework, keeping it all in the same tree |
18:46:58 | pamaury | if possible that would be nice, since our stub is basically just a different "app", which somewhat specific use ^^ |
18:47:07 | [7] | yes |
18:47:39 | [7] | we'd probably need to add some simple ifdefs to have linker scripts and startup code supplied by the target tree instead of the soc tree |
18:47:46 | pamaury | what we need to be very careful though is to do a "light" init, because we don't want to break the OF |
18:47:53 | [7] | so that we can have different build targets for different purposes on the same device |
18:48:52 | [7] | I also have some "modules" for that framework that aren't included in the umsboot tree |
18:49:29 | [7] | such as cpu support for cortex m3/m4, soc support for stm32 and some peripherals of that |
18:49:48 | pamaury | nice |
18:51:35 | [7] | this also means that we have full support for the ipods for free |
18:52:19 | pamaury | Do you some time to spend on this ? If yes you could start by making your umsboot in a good shape for it |
18:52:22 | pamaury | *you have |
18:52:38 | [7] | not terribly much time, but this should be mostly trivial |
18:53:02 | pamaury | There is a slight issue which we need to think of: is the code position independent ? |
18:53:17 | [7] | this one isn't |
18:53:35 | [7] | that's the price for flexibility :) |
18:54:05 | [7] | do we need it to be able to relocate at runtime? |
18:54:21 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
18:54:24 | [7] | if we just need to move it around for different purposes/applications, that's trivial |
18:54:43 | pamaury | no, but that means the patcher need to relocate it, or can a tool to do so |
18:54:48 | pamaury | *call |
18:55:11 | [7] | the patcher could just call make BASE_ADDRESS=whatever |
18:55:19 | [7] | that would be easy to implement |
18:55:25 | pamaury | yes |
18:56:16 | [7] | then you'd add a -DBASE_ADDRESS=$(BASE_ADDRESS) in target.mk |
18:56:16 | | Quit wodz (Quit: Leaving) |
18:56:26 | [7] | and just use BASE_ADDRESS in the linker script |
18:56:41 | pamaury | to interact with the patcher, the simplest option would be to put a fake vector table at the beginning of the generated binary that the patcher can read |
18:57:03 | [7] | that's something that startup.S would take care of |
18:57:22 | [7] | you have full per-target control of the linker script and startup files |
18:57:31 | [7] | there's zero generic startup code being pulled in |
18:57:34 | pamaury | and maybe write the addresses of the old handlers in another table. Ah great |
18:58:05 | [7] | (right now it's controlled by the SOC tree, but we could easily define a flag to tell that to leave things alone) |
18:59:29 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
18:59:29 | * | copper resents nicks enclosed in square brackets |
19:00 |
19:01:38 | | Quit liar (Ping timeout: 264 seconds) |
19:01:47 | * | [7] wonders who asked copper about his opinion about that :P |
19:02:01 | pamaury | [7]: do you have time to make all this ? The plan would be to have something which compiles, no need to do USB for a start, just hanging or toggle a led is enough for a proof of concept |
19:02:15 | | Join madcat1990 [0] (~madcat199@216.185.65.74) |
19:03:00 | [7] | tell me the requirements? |
19:04:35 | [7] | target naming would be <device_name>/teststub for now? |
19:04:56 | [7] | output file name would be build/<device_name>/teststub/teststub-<BASE_ADDR>.bin |
19:04:59 | pamaury | ok |
19:05:23 | [7] | which CPU model? |
19:05:27 | pamaury | I would like to be able to do the make BASE_ADDRESS=, maybe create a fake imx233/fuze+ port with all the functions I need to fill, create the startup.S file and some stub handlers which only return |
19:05:34 | [7] | text/data/bss all in one consecutive chunk? |
19:06:03 | pamaury | yes, the fuze+ is arm926ej-s |
19:06:34 | [7] | the exact make command would be make TARGET=<device_name>/teststub TYPE=release BASE_ADDR=whatever MAX_SIZE=whatever or something like that |
19:07:16 | [7] | or we can forget about max_size and just check after the fact |
19:07:41 | [7] | what would be the device_name of your target? |
19:07:43 | [7] | fuzeplus? |
19:07:53 | [7] | and soc_name would be imx233? |
19:07:56 | pamaury | yes |
19:09:48 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
19:10:37 | [7] | what kind of input vectors would it get? |
19:11:09 | pamaury | what do you mean ? |
19:11:15 | [7] | init, IRQ, pagefault, undefined_instr, anything else? |
19:12:32 | pamaury | I can hook up them all but I think those are sufficient |
19:12:48 | [7] | how will control be returned to the old handler? |
19:12:57 | [7] | (especially for init and irq) |
19:13:56 | pamaury | yeah, that needs to be discussed. I think the simplest way is to give the tool the address of the old handler, so that it can decide what to do |
19:14:27 | pamaury | the patcher would patch the OF with the new addresses and patch the stub with the old ones |
19:14:54 | [7] | so I'll assume that the destination addresses for those are placed in the words after the input vectors? |
19:16:54 | pamaury | yes, I think virtually all vector table use the ldr pc, ... form so that's fine, except if you have a more generic way in mind |
19:17:37 | [7] | for the imx233, is there a category of similar devices? |
19:17:56 | [7] | i.e. should I place it in soc/imx233 or soc/imx2xx/223 or something like that? |
19:18:55 | pamaury | hum, yes, it could imx or mxs. Maybe mxs/mx23 but that's a bit redundant |
19:19:28 | pamaury | or imx/233, usually these are called i.MX something |
19:20:14 | pamaury | yeah imx/233 should be fine |
19:22:37 | | Join lorenzo92 [0] (~chatzilla@host220-105-dynamic.44-79-r.retail.telecomitalia.it) |
19:23:49 | [7] | what kind of interrupt controller? |
19:23:56 | [7] | PL192? |
19:24:59 | pamaury | custom, it's imx233 specific, called ICOLL |
19:26:38 | [7] | cache line size is 16 bytes? |
19:27:43 | pamaury | 32 |
19:27:56 | | Join Zarggg [0] (~zarggg@24.229.140.62.res-cmts.sm.ptd.net) |
19:27:58 | [7] | should build_target be application/device or device/application? what's more convenient? |
19:29:13 | pamaury | I think I prefer device/application but really that's similar ^^ |
19:29:57 | [7] | hm... I think there's a technical reason to do it the other way round |
19:30:28 | [7] | removes a bit of code duplication |
19:31:10 | [7] | hm, should the vector table etc. be target specific? or is that rather something that's common to the stub kind? |
19:31:26 | [7] | if we do flat linking the same applies to the linker script |
19:31:47 | pamaury | it should be common to all |
19:33:18 | copper | [Saint]: yeah, I just configured my vim to display tabs and EOL |
19:33:30 | copper | that was looong overdue |
19:35:43 | [7] | pamaury: do we need to set up our own stack (for the init code), or can we assume that has already been taken care of? |
19:36:33 | pamaury | hum, that's a good question |
19:36:46 | [7] | also do I need to take care of clearing .bss? |
19:37:26 | pamaury | you should clear bss since no one is going to do it for you in general ^^ For init, I think it's simpler if we setup our own stack (and restore the old one if any) |
19:40:03 | lorenzo92 | am i missing a new port in progress? :) |
19:41:34 | pamaury | err, not exactly, we are writing a generic software patcher and a stub which can do gdb-like debugging on target |
19:41:49 | [7] | b _init |
19:41:49 | [7] | b _irq_handler |
19:41:49 | [7] | b _pagefault_handler |
19:41:49 | [7] | b _undef_instr_handler |
19:41:59 | [7] | that will be the first 4 instructions of the resulting binary |
19:42:26 | [7] | the following 4 words will be the return vectors for each of those |
19:42:35 | [7] | or should we interleave them? |
19:42:52 | bertrik | I still have the suspicion that the AMS "bricked" mode allows some kind of RAM upload |
19:43:09 | * | [7] has that suspicion as well, but didn't get around to investigating it |
19:43:31 | [7] | the code is much harder to read than an old apple bootloader |
19:43:40 | pamaury | bertrik: me too but no idea how to investigate this |
19:43:56 | bertrik | any bright ideas how we can prove that code is actually run? |
19:44:07 | pamaury | do you have the code which is run in this mode ? |
19:44:16 | pamaury | If yes I can have a try at disassembling it |
19:44:25 | bertrik | the bricked clip I have doesn't have a backlight, that would be too easy |
19:44:45 | | Join ikeboy [0] (~dell@ool-435622d3.dyn.optonline.net) |
19:44:56 | [7] | it it would be an ipod i'd just make it beep |
19:44:58 | pamaury | [7]: as you wish, if you are paranoid you could do .word MAGIC_INIT \b init \b .word 0 |
19:45:23 | | Quit ikeboy (Client Quit) |
19:45:23 | pamaury | in any case having a magic value around would be good |
19:45:29 | pamaury | just to check everything is fine |
19:45:58 | pamaury | bertrik: bright idea, disconnect usb |
19:46:30 | [7] | hang vs. reboot might be worth a try |
19:46:33 | bertrik | pamaury: so the theory is that connecting would allow upload to RAM and disconnecting would reset the CPU? |
19:47:05 | [7] | this thing does expose a mass storage device? |
19:47:26 | | Quit Zarggg (Quit: Zarggg) |
19:47:44 | pamaury | bertrik: no no I mean, to check the theory of running code, the code should connect/disconnect usb in software |
19:47:54 | pamaury | that way you immediately spot it in dmesg |
19:47:58 | [7] | pamaury: I'll assume that caches will be off during init, ok? |
19:48:15 | [7] | or actually I don't really care |
19:48:23 | pamaury | [7]: yes, that's a safe bet, it's the case for the OF fuze+, don't know for others |
19:48:37 | bertrik | ah, but I assumed to disconnecting would be required to start the code in the first place |
19:48:42 | [7] | it very likely is |
19:48:44 | lorenzo92 | pamaury: very interesting ;) |
19:49:22 | pamaury | hum, what happen when you unplug and replug in this mode without any upload ? does it reboot ? |
19:49:43 | [7] | bertrik: what's the default behavior? it comes up as a mass storage device? what do the contents look like? do the contents stick if you overwrite them? even across reboots? what happens if you unplug and replug it? does it connect again or is it dead? |
19:49:46 | pamaury | bertrik: do you have the ROM code for this mode ? |
19:49:53 | lorenzo92 | by the way, which cpu? since I know quite well imx37 if necessary (unfortunately only based on experience, no datasheet) |
19:50:02 | bertrik | pamaury: yes, we have the ROM code I think |
19:50:09 | bertrik | or at least we should be able to dump it |
19:50:18 | pamaury | bertrik: is it big ? I guess someone has disassemble it ? |
19:50:30 | [7] | I have a rom dump of one of those sansas, but it's very hard to tell which code is actually being run in that mode |
19:50:40 | [7] | the one I looked into was C++ gibberish |
19:50:48 | pamaury | lorenzo92: the aim is to be as cpu agnostic as possible, we will start with imx233/fuze+, and some ipods |
19:50:54 | bertrik | [7]: yes, it comes up as a mass storage, size would fit in DRAM and the contents to stick, but not across reboots IIRC |
19:51:15 | [7] | maybe we can also tell something from the initial contents then |
19:51:28 | [7] | what's the exact size of the drive? |
19:51:29 | lorenzo92 | pamaury: indeed, haha I was trying to see that...and this "upload mode" sounds familiar with imx37 |
19:51:57 | [7] | lorenzo92: it seems like a less sophisticated version of UMSboot to me :) |
19:52:20 | pamaury | yes, except we have no idea how it works if I understand correctly |
19:52:33 | pamaury | it could be scrambled, or using some weird format |
19:52:41 | pamaury | [7]: if you have the ROM I can have a look |
19:53:09 | [7] | it's a clip+ in my case btw |
19:53:18 | [7] | want the bin file or IDA database? |
19:53:24 | pamaury | both |
19:53:50 | pamaury | I'm confident someone around has a bricked clip+ |
19:53:54 | bertrik | I did once start at the ROM dump too, but got stuck |
19:54:29 | | Join Zarggg [0] (~zarggg@24.229.140.62.res-cmts.sm.ptd.net) |
19:54:30 | bertrik | I have a bricked clip+, but it's probably really borken |
19:54:46 | bertrik | it does still connect as a 4 MB drive |
19:54:51 | [7] | theseven.bounceme.net/~theseven/tmp/clipplus.zip">http://theseven.bounceme.net/~theseven/tmp/clipplus.zip |
19:55:22 | [7] | pamaury: I have one around here, someone donated it in bricked state |
19:55:38 | [7] | never got around to actually messing with it though, I think I ran into some problems even accessing that drive |
19:55:46 | [7] | maybe it got damaged on its way to me or something |
19:56:21 | bertrik | mine says it's a Sandisk M200Plus in dmesg |
19:56:32 | * | [7] checks where his one is |
19:57:09 | bertrik | hm, seems it just re-attached itself to USB after dumping with dd |
19:57:23 | | Join wodz [0] (~wodz@89-75-41-78.dynamic.chello.pl) |
19:58:00 | pamaury | hum, not that small ROM ^^ |
19:58:14 | * | [7] even found the donated one in a bin somewhere |
19:58:49 | wodz | the rom is not small at all, it interleaves thumb and arm and looks like c++ shit |
19:58:54 | [7] | it connects :) |
19:59:20 | [7] | http://paste.pm/902.js |
19:59:37 | pamaury | I've seen too many reverse engineering horrors already, it can't worse |
19:59:43 | [7] | the size suggests that it's more than just DRAM |
20:00 |
20:00:38 | pamaury | how large is the DRAM on that thing ? |
20:00:40 | lorenzo92 | haha interesting having malloc in a so small rom ^^ |
20:01:06 | [7] | the contents of the volume seem to suggest uninitialized DRAM |
20:01:31 | [7] | lorenzo92: a 128KB rom, which is *massive* for an SoC boot rom |
20:01:36 | lorenzo92 | indeed |
20:02:14 | pamaury | Ok i'll pick up the disassembly, only 1400 functions to go :D |
20:02:45 | lorenzo92 | *it should have been small, that's what I actually meant :) anyways if you are unsure about DRAM you could in theory write a string and quickly shutdown - reboot the device: content in the ram may stay here |
20:03:01 | lorenzo92 | it happened to me, also in a lcd controller ^^ |
20:04:02 | [7] | yes, this is typical behavior |
20:04:08 | [7] | I actually dumped firmwares that way |
20:05:04 | pamaury | how do you access the DRAM then ? |
20:08:32 | [7] | I had already flashed something, but needed to dump some ram state after executing an OF that crashed |
20:08:33 | bertrik | I once did a FPGA project that did image processing and stored images in DRAM, images were still recognisable even after up to a minute of no refresh |
20:09:29 | [7] | I once, on a very old FPGA board, had a situation where SRAM memory contants seemed to have remained 100% intact after it was sitting around without power for 10+ minutes |
20:09:45 | [7] | that was fairly nasty for debugging an unrelated problem actually |
20:09:56 | [7] | contents* |
20:21:44 | | Quit lorenzo92 (Ping timeout: 264 seconds) |
20:23:24 | *** | Saving seen data "./dancer.seen" |
20:30:14 | [7] | pamaury: theseven.bounceme.net/~theseven/tmp/stub.zip">http://theseven.bounceme.net/~theseven/tmp/stub.zip |
20:30:18 | [7] | compiles, but completely untested |
20:30:34 | pamaury | thanks, i'll have a look |
20:31:04 | [7] | I compiled it using make TARGET=teststub/fuzeplus TYPE=release BASEADDR=0x01000000 LISTING=1 |
20:35:55 | [7] | I used a non-rockbox toolchain though |
20:36:27 | | Join lorenzo92 [0] (~chatzilla@46.18.27.126) |
20:36:34 | | Quit lorenzo92 (Client Quit) |
20:37:36 | pamaury | [7]: which toolchain do you use ? |
20:38:50 | [7] | pamaury: the one generated by https://github.com/EliasOenal/TNT/blob/master/toolchain.sh |
20:38:58 | [7] | it should also work with the rockbox one thougjh |
20:39:04 | [7] | though* |
20:39:21 | pamaury | it's much more than ours |
20:39:26 | pamaury | *more recent |
20:39:50 | [7] | I typically use that because I need support for cortex M4 etc. |
20:40:05 | copper | Does anyone actually look at Rockbox icons? |
20:40:21 | copper | use them as visual cues? |
20:40:45 | bertrik | eh, not really, they're really small on the player I use most frequently :) |
20:40:51 | [7] | which icons where? in the file browser? |
20:41:19 | gevaerts | You can make big icons |
20:41:23 | [7] | I think that I use them on my ipods that way... but for the average user they'd mostly have the same icon anyway |
20:41:25 | * | gevaerts has used 64x64 icons :) |
20:41:42 | gevaerts | Or maybe even bigger |
20:41:52 | [7] | in the main menu I think they're important though |
20:42:24 | copper | yeah I meant the SBS icons |
20:42:38 | * | copper doesn't even know what SBS stands for |
20:42:45 | gevaerts | statusbar screen |
20:43:00 | copper | ah |
20:43:05 | | Quit SovonHalder () |
20:43:07 | gevaerts | Doesn't make much sense, but it fits the general xxS theme :) |
20:43:26 | [7] | s/screen/skin/ might make more sense |
20:44:40 | gevaerts | Right, it might have been retrofitted to that at some point |
20:44:53 | gevaerts | It all comes from "while playing screen" |
20:45:30 | [7] | I think someone called the SBS a "system base skin" at some point |
20:45:58 | [7] | because, IIUC, it isn't really just a statusbar thing either anymore |
20:46:09 | * | gevaerts thinks we should just call it SBS and not try to figure out what it might stand for :) |
20:47:32 | copper | Shiny Base System? |
20:48:51 | [7] | bertrik, pamaury: do you have a clue of the sansas have jtag somewhere? |
20:48:58 | [7] | especially the clip+? |
20:49:25 | pamaury | no |
20:49:56 | bertrik | maybe have a look at PCB scans |
20:50:04 | wodz | http://www.rockbox.org/wiki/SansaClip#JTAG |
20:50:14 | [7] | also http://www.rockbox.org/wiki/SansaAMSJTAG seems to have a pinout |
20:51:39 | [7] | that might help a lot in identifying the code run in that recovery mode |
20:53:04 | pamaury | urg indeed, this is some kind of position independent C++ code in the ROM |
20:54:04 | * | [7] tries to locate his JTAG gear |
20:54:27 | * | [7] spots some shitty xilinx cable and a bus pirate |
20:55:00 | [7] | ah, and here's the flyswatter that I was looking for |
20:55:19 | pamaury | [7]: do you really create structure with name struc_N in ida ? |
20:55:49 | [7] | I don't remember what I've done with that database |
20:55:58 | [7] | I think I tried to identify some basic vtables |
20:56:23 | [7] | pamaury: you now know why I had given up on disassembling that one? :) that rarely ever happens... |
21:00 |
21:01:32 | wodz | pamaury: what is USB_STATUS_BY_EVENT define? |
21:02:34 | pamaury | mean usb connect/disconnect events are handled by an irq and don't need polling |
21:04:40 | * | [7] decides to do some soldering and fears that he'll rip the display cable |
21:05:40 | pamaury | [7]: yeah I understand, disassembling such a thing will be hard |
21:06:08 | [7] | it will be much easier with the help of JTAG |
21:06:22 | | Quit pystar89 (Ping timeout: 260 seconds) |
21:09:25 | pamaury | the trick is to identity all the low levels primitives like arrays, tread, muxes and so on. When you have this basis, everything is much simpler but it takes a lot of time to reverse |
21:12:20 | pamaury | wtf, the compiler must have been dumb, didn't seem to optimise the trivial access to the classes |
21:14:23 | wodz | or the code is compiled with optimization turned off :-) |
21:15:27 | pamaury | it must have been completely turned off then, this is really the basics |
21:15:48 | wodz | this should help to reveng |
21:16:31 | pamaury | well not really, it means all the method calls are virtual I fear |
21:18:11 | | Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox) |
21:18:57 | * | wodz timidly reminds pamaury about testing rk27xx usb driver |
21:20:14 | * | pamaury looks for his rk27xx |
21:21:41 | pamaury | ah my tree is not clean |
21:22:51 | wodz | I can send you rkw |
21:24:02 | pamaury | no no I'll compile it don't worry |
21:24:17 | | Quit Topy44 (Ping timeout: 240 seconds) |
21:25:06 | fs-bluebot | Build Server message: New build round started. Revision 21672ba, 217 builds, 20 clients. |
21:25:09 | | Quit Zambezi (Remote host closed the connection) |
21:26:36 | pamaury | wodz: /home/pamaury/project/rockbox/myrockbox/apps/keymaps/keymap-rk27xx-generic.c:70:1: error: unterminated #ifdef |
21:27:05 | wodz | pamaury: just uploaded cleaned a bit version |
21:27:14 | pamaury | ah wait, the didn't apply cleaning on HEAD |
21:27:26 | wodz | try again with new version |
21:27:26 | pamaury | thanks |
21:28:13 | wodz | ah, and you need to tweak firmware/export/config/rk27generic.h to expose only SD disk. |
21:29:13 | pamaury | ok |
21:32:17 | fs-bluebot | Build Server message: Build round completed after 431 seconds. |
21:32:41 | pamaury | the problem was with big transfers right ? |
21:33:08 | | Join Rower [0] (husvagn@v-413-alfarv-177.bitnet.nu) |
21:34:49 | pamaury | wodz: root@destiny:/home/pamaury/project/rockbox/myrockbox/build_rk27generic# dd if=/dev/sdb of=/dev/null bs=1M count=100 |
21:34:49 | pamaury | 104857600 octets (105 MB) copiés, 39,8045 s, 2,6 MB/s |
21:35:04 | wodz | the same here :-) |
21:36:37 | pamaury | so it's seems to work. What I don't get is why it didn't work without the cache when I was bug fixing it, maybe it is just too slow then |
21:45:03 | pamaury | oh my god, I can see all the artifacts generated by the c++ compiler, that's sooo horrible |
21:45:13 | [7] | dammit, it's almost impossible to solder that gnd pin |
21:45:17 | [7] | sinks way too much heat |
21:45:51 | wodz | [7]: you need solder paste + good flux |
21:49:54 | | Quit kevku (Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/) |
21:50:46 | * | [7] finally has a "dead bug" clip+ :)# |
21:52:53 | * | [7] powers up the flyswatter |
21:53:11 | pamaury | seriously, who allocates several objects on *each* irq ??!! |
21:53:37 | [7] | and that in a bootrom? |
21:53:44 | [7] | I didn't even realize it was *that* bad |
21:54:32 | pamaury | yeah, I'm tracking the usb irq and it seriously does several allocations unconditionally |
21:56:38 | | Join amayer_ [0] (~amayer@mail.weberadvertising.com) |
21:56:38 | | Quit amayer (Read error: Connection reset by peer) |
21:56:48 | [7] | AMs demonstrating how powerful their chips are? ;) |
21:57:31 | | Quit mrtux (Read error: Connection reset by peer) |
21:57:52 | pamaury | I have already find at least 3 different classes, two of them having at least one derivative |
22:00 |
22:00:55 | wodz | pamaury: I can't remember exactly the setup of rk27xx when you run experiment with caches turned off. But if it was running @50MHz I would not be surprised that it was too slow to sustain usb transfers. @200Mhz and caches turned off the device literally crawls. |
22:03:57 | | Join mrtux [0] (~colin@unaffiliated/mrtux) |
22:15:28 | [7] | caches shouldn't affect DMA activity |
22:15:43 | [7] | and everything that happens on the CPU should be latency tolerant |
22:16:04 | [7] | I think the tightest timeout from the USB spec is like 50 milliseconds to respond to some control requests |
22:16:38 | pamaury | it was bulk the problem |
22:17:16 | | Quit y4n (Quit: 6,000,000 ways to die — choose one.) |
22:20:08 | | Quit thomasjfox (Quit: Konversation terminated!) |
22:22:58 | [7] | Info : JTAG tap: as3525plus.cpu tap/device found: 0x07926f0f (mfg: 0x787, part: 0x7926, ver: 0x0) |
22:22:58 | [7] | Info : JTAG tap: as3525plus.etb tap/device found: 0x1b900f0f (mfg: 0x787, part: 0xb900, ver: 0x1) |
22:23:02 | [7] | looks good, eh? |
22:23:27 | *** | Saving seen data "./dancer.seen" |
22:23:40 | pamaury | good :) |
22:24:34 | wodz | hmm, interesting. If you leave the device connected to the usb for a while the backlight is very dimm after disconnect but you can reapply the setting and everything seems to back to normal state. |
22:25:54 | bertrik | [7]: did you come up with the name as3525plus, or this this autodetected by the jtag software? |
22:26:14 | [7] | pamaury: fyi, I just halted it and PC is at 0x80004cbc |
22:26:18 | [7] | with caches disabled |
22:26:29 | [7] | bertrik: that's from an openocd config file from our wiki |
22:27:14 | pamaury | [7]: that's main loop, ie branches it itself |
22:27:23 | [7] | ok, sounds good then |
22:27:28 | [7] | i.e. my debug setup is working :) |
22:27:55 | * | [7] wonders if he should try to link ida to openocd somehow :) |
22:28:05 | wodz | hehe |
22:28:21 | [7] | that was quite some fiddly soldering today! |
22:28:56 | wodz | this deserves a beer or two :-) |
22:29:50 | [7] | pamaury: this is a synopsysotg device, right? |
22:30:42 | | Nick mrtux is now known as mrtux2 (~colin@unaffiliated/mrtux) |
22:31:17 | | Join Zambezi [0] (Zulu@bnc.fran.hostbay.nu) |
22:31:35 | pamaury | [7]: yes |
22:33:11 | * | [7] wonders what the best way to tackle this is |
22:35:19 | * | pamaury is crying when he sees 30 instructions that an optimised compiler would reduce to 10 |
22:35:25 | | Quit Zambezi (Changing host) |
22:35:25 | | Join Zambezi [0] (Zulu@unaffiliated/zambezi) |
22:35:35 | pamaury | all temporaries are going to stack !! |
22:35:45 | wodz | wow |
22:36:39 | pamaury | in some functions you clearly see the compiler never tried to use anything except r0 and r1 |
22:36:53 | wodz | This must be compiler optimization turned off. |
22:37:15 | wodz | have you tried to apply flirt sigs scan? |
22:37:24 | [7] | which ida version are you working with? |
22:37:56 | pamaury | 5.5.0925t |
22:39:04 | [7] | ok, I'm gonna use the old one as well then |
22:39:10 | wodz | pamaury: any idea of the good usb stress test? I tried dd random values, dd huge file and md5sum it, cp, mv, etc. Any other ideas? |
22:39:32 | pamaury | [7]: which one do you have ? |
22:39:38 | [7] | 6.1 |
22:39:44 | [7] | but I also have a 5.5 somewhere |
22:39:54 | [7] | wodz: try spamming it with meaningless control requests while copying stuff |
22:39:56 | pamaury | wodz: not really, best would be to enable usb hid and do dd + hid stuff |
22:40:03 | [7] | that was the surefire way to crash the old synopsys driver |
22:40:11 | pamaury | wow 6.1, how did you get it ? |
22:40:14 | [7] | or hid, has a similar effect |
22:40:27 | * | wodz tries |
22:40:38 | gevaerts | wodz: one way to generate control requests is running lsusb |
22:41:03 | [7] | is lsusb sufficient or do you need lsusb -vv or something to make it actually load descriptors? |
22:41:28 | gevaerts | I believe plain lsusb will already have to get descriptors to show the device name |
22:43:51 | [7] | plain lsusb doesn't even show device names from the descriptors typically, but rather some from an internal incomplete database |
22:44:23 | gevaerts | right |
22:44:25 | [7] | pamaury: yay, debugging that clip+ in ida :) |
22:44:38 | gevaerts | In that case a -v, and possibly a -d to avoid spamming unrelated devices |
22:45:46 | | Join saratoga [0] (123e1c0a@gateway/web/freenode/ip.18.62.28.10) |
22:50:31 | | Quit madcat1990 (Quit: Leaving) |
22:54:19 | | Quit mrtux2 (Quit: ZNC - http://znc.in) |
22:57:25 | pamaury | [7]: do you have the full output of lsusb on the device ? |
22:57:42 | [7] | the clip+ recovery thing? |
22:58:09 | pamaury | yes |
22:59:32 | [7] | http://paste.pm/904.js |
22:59:40 | pamaury | thanks |
23:00 |
23:00:15 | [7] | http://paste.pm/905.js (with root access) |
23:01:06 | wodz | hid + lsusb -vv kills transfer. With hid turned off spamming with lsusb -vv only slightly affect transfer rate. |
23:03:46 | wodz | dd'ed file during lsusb spamming is md5sum correct |
23:04:20 | wodz | so the question to mortalis is if he tested usb with HID turned on. |
23:04:47 | | Join pystar89 [0] (~pystar89@ip-109-90-154-150.unitymediagroup.de) |
23:05:52 | [7] | so EP0 isn't affected but an interrupt endpoint having traffic screws it up. hm... |
23:06:20 | | Quit amayer_ (Quit: Leaving) |
23:11:40 | | Join olspookishmagus [0] (~pookie@91.132.63.143) |
23:12:02 | pamaury | [7]: I will soon convinced myself that all descriptor are dynamically built and allocated using several temporaries objects |
23:13:31 | pamaury | oh god, this is fun: the compiler doesn't have enough registers so instead of computing the right amount, it does a push {r0-r7, lr} straight away and recover the parameters of the function in the stack :D |
23:14:19 | [7] | lol |
23:14:27 | [7] | c++ gibberish as I said :) |
23:14:46 | [7] | anyway, looks like IDA can't properly debug code running from a ROM :/ |
23:15:33 | pamaury | why not ? |
23:16:30 | wodz | ok, *very* high rate of lsusb -vv also kills the transfer but not instantaneous. |
23:16:32 | | Quit n1s (Quit: Ex-Chat) |
23:17:50 | wodz | the device is locked in usb screen but reacts on keypress and backlight timer runs properly |
23:19:53 | pamaury | wodz: could you check if for example a setup packet arrives before the last one has been processed ? |
23:20:15 | wodz | how? |
23:22:08 | pamaury | hum, not sure, otherwise I'll try, how do you trigger the bug ? |
23:23:53 | wodz | dd if=some_file of=/media/xxxxxxx/test bs=1M && md5sum /media/xxxxx/test |
23:24:07 | wodz | during the copy run lsusb -vv in loop |
23:26:13 | wodz | with hid turned on it is much faster |
23:27:26 | | Quit Rower (Quit: sover :D) |
23:34:48 | pamaury | ok, apparently you need three inherited classes and malloc to create a config descriptor, *sigh* |
23:38:19 | | Quit liar (Remote host closed the connection) |
23:52:38 | pamaury | [7]: building the config descriptor in this bootrom litteraly triggers more than 10 memory allocations :-o |
23:54:12 | [7] | pamaury: looks like IDA tries to implement breakpoints by overwriting instructions - not a good idea in a rom |
23:54:46 | pamaury | indeed |
23:56:46 | wodz | [7]: but the only somewhat universal way (excluding roms) |