Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2013-08-06

00:05:48 Quit uwe_ (Ping timeout: 245 seconds)
00:06:45 Join uwe_ [0] (
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: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 (
01:49:42 Quit Gallomimia (Ping timeout: 240 seconds)
01:50:10 Join Gallomimia [0] (
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:23:04***Saving seen data "./dancer.seen"
02:45:07 Join dewlap [0] (~dewlap@2001:5c0:1000:a::68d)
03:05:42 Quit soap (Ping timeout: 268 seconds)
03:11:45 Quit lebellium (Quit: ChatZilla [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] (
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] (
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: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:28:03 Quit Bagder (Ping timeout: 264 seconds)
05:30:53 Join Bagder [241] (~daniel@rockbox/developer/bagder)
05:35:12 Join rdn [0] (
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:02:42 Quit JdGordon (Ping timeout: 268 seconds)
06:02:56 Join JdGordon [0] (~jonno@
06:02:56 Quit JdGordon (Changing host)
06:02:56 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon)
06:07:51 Join soap [0] (
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] (
06:48:58 Quit Raptors (Read error: Connection reset by peer)
07:00:21 Nick x56 is now known as plop (
07:02:00 Join Raptors [0] (
07:10:45 Quit Bagder (Ping timeout: 256 seconds)
07:17:47 Join dys [0] (
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@
07:43:50 Quit dys (Remote host closed the connection)
07:45:15 Quit kevku (Read error: Connection reset by peer)
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@
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] (
08:35:49 Join ender` [0] (
08:36:07 Join Bagder [241] (~daniel@rockbox/developer/bagder)
08:37:07 Join einhirn [0] (
08:38:49 Join kevku [0] (~kevku@2a01:d0:ffff:34a::8:3)
08:51:16 Join Zagor [0] (
08:51:16 Quit Zagor (Changing host)
08:51:16 Join Zagor [242] (~bjst@rockbox/developer/Zagor)
09:16:49 Nick SuperBrainAK is now known as DormantBrain (
09:18:12 Quit Xerion (Read error: Connection reset by peer)
09:18:47 Join Xerion [0] (
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] (
09:55:47 Join habys [0] (
09:59:19 Join liar [0] (
10:23:11***Saving seen data "./dancer.seen"
11:04:57 Join lebellium [0] (
11:22:43 Join Highlander [0] (
11:24:13 Join wodz [0] (
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:28wodzpamaury: Did you try rk27xx usb on your dap?
11:43:36 Quit Highlander (Quit: ChatZilla [Firefox 22.0/20130618035212])
12:09:29pamaurywodz: oops no, completely forget that, i'll try this afternoon, sorry
12:10:40 Join funman_ [0] (
12:11:23 Nick funman is now known as namnuf (~fun@rockbox/developer/funman)
12:11:31 Nick funman_ is now known as funman (
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@
12:59:22 Quit fs-bluebot (Ping timeout: 240 seconds)
13:00:08 Quit Xerion (Read error: Connection reset by peer)
13:01:23 Join fs-bluebot [0] (
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:07:04 Join Xerion [0] (
14:23:17***Saving seen data "./dancer.seen"
14:44:10 Join amayer [0] (
14:44:53 Quit mortalis (Quit: KVIrc 4.3.1 Aria
14:55:52coppermodified iBox theme for the iPod Classic, with playback indicators:
15:11:02 Join kevku [0] (~kevku@2001:470:27:773:0:feed:c0f:fee)
15:14:00copperupdated with "next song" indicator
15:16:33 Join SovonHalder [0] (SovonHalde@
15:18:13copperthere seems to be a problem
15:18:21copperthe HDD indicator disappears on my iPod
15:18:26SovonHalderthe bitrate disappeared ?
15:20:09SovonHalderI see the bitrate indicator is not in the latest upload. did you do that on purpose ?
15:20:18copperit doesn't show on the sim because the HDD indicator never returns anything on the sim
15:20:30copperSovonHalder: 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@
15:22:08SovonHalderthat's a okay.. awesome work..
15:23:22copperhold on, I need to fix the HDD indicator thing
15:23:54SovonHalderI'm patient :)
15:26:44 Quit DexterLB (Read error: Connection reset by peer)
15:26:51 Join Dexter_LB [0] (~dex@
15:27:31copperSovonHalder: please download and extract again
15:27:37copperHDD indicator should be fixed
15:29:48copperhmmm, I'm quite satisfied with the changes.
15:31:18SovonHalderI'm more satisfied than you...
15:31:20SovonHalderthank you
15:31:22 Part LinusN
15:31:24copperSovonHalder: thanks for asking, I probably wouldn't have done it otherwise (not any time soon, anyway)
15:33:18copperSovonHalder: 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:40copperI can't display too many lines without it getting cramped
15:34:45SovonHaldershowing bitrate is not very essential's kinda distraction when listening to music..I am overly joyed to see current theme
15:35:09SovonHalderHow do I install it anyway ?
15:35:19SovonHalderI already have your previous theme
15:35:58copperjust unpack the archive at the root directory of your iPod with "overwrite" on
15:36:16SovonHalderthanks..will do now
15:36:16copperif 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@
15:37:07copperjesus, the Classic can get really loud
15:37:33SovonHalder:D hell yeah
15:37:46SovonHalderdid you just got one for yourself ?
15:38:41copperI bought it a year ago
15:39:31SovonHalderis a restart required ?
15:40:24copperat the very least, reload the theme
15:40:33copperor just turn off and back on
15:42:33copper[Saint] (or anyone): it is valid to store tracknumber information in the APEv2 "Track" field in the form of '<tracknumber>/<totaltracks>'
15:44:07coppernever mind
15:44:17copperI answered my own question :3
15:48:00copperSovonHalder: I need to fix the tracknumber too
15:48:06copperdunno wtf I did there
15:51:05pamaury[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">
15:53:12 Quit DexterLB (Ping timeout: 256 seconds)
15:55:13copperSovonHalder: 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:18wodzpamaury: impressive
15:57:56 Join DexterLB [0] (~dex@
15:58:26pamauryIn 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:50pamauryMy 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:29pamauryAnd 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:00pamaurywodz: did you make any work on hwstub ?
16:02:18wodzpamaury: I am going to do some work later today
16:02:53wodz[7]: Do you still need tests of umsboot (or how it is called) on n2g?
16:03:05pamauryok, 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:51pamaury[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:35pamauryadding 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:12pamaurybut 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:00wodz[7]: which is broken for quite some time
16:07:16SovonHalderCopper: 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:36copperSovonHalder: I'm pretty much done on the Classic theme for now
16:07:38SovonHalderIf all the issues are fixed, can you provide me the download link again please ?
16:07:41copperI'm updating my Fuze+ theme now
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:41wodz[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@
16:13:56pamaury[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] (
16:35:08 Quit Dexter_LB (Ping timeout: 256 seconds)
16:35:52 Join DexterLB [0] (~dex@
16:45:20 Quit DexterLB (Ping timeout: 256 seconds)
16:46:50copperwhy does the SBS menu have a slight margin on the Classic, and not on the Fuze+?
16:47:12copperI'm using exactly the same code, I don't see how I could be doing it
16:47:59copperthe scrollbar
16:48:24 Join DexterLB [0] (~dex@
16:48:25[Saint]blargh, lag.
16:49:14 Quit DexterLB (Client Quit)
16:53:50 Join DexterLB [0] (~dex@
16:56:03coppergoddamn 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: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:40Tornegood editors would just not insert any trailing whitespace ever to begin with :)
17:03:12 Join Zagor [0] (~bjst@
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: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:16copperis 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:33copperhmmm, 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:04lebelliumsome 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:59[Saint] /probably/ not the best idea to ping Jd at ~2am, lol. :)
17:14:58lebelliumI 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:31[Saint](even though it would technically be his own fault ;))
17:16:33lebelliumsorry :D
17:17:37lebelliumand 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:04copperSovonHalder: final fix (alignment of metadata, and removed erroneous scrollbar specification):
17:19:07[Saint]roughly +12GMT
17:19:31 Quit Zagor (Quit: Leaving)
17:22:57 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier.
17:25:00 Quit petur (Quit: Nettalk6 -
17:26:17 Join n1s [0] (~n1s@
17:26:17 Quit n1s (Changing host)
17:26:17 Join n1s [0] (~n1s@rockbox/developer/n1s)
17:31:21copperupdated both themes
17:31:24copperall's good now
17:49:51pamaury[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:48pamauryI 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:20pamauryI 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:50pamaurythe 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:36pamauryI 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:57:21wodzpamaury: look for some graphic data
17:57:57pamauryThat 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:25wodzwhat 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:20wodzthe stub is small
17:59:51pamauryI'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:22pamauryFor what it's worth, I'm nearly sure the resources don't contain any code
18:02:08wodzyou can also steal some space from the stack (bottom of the ram probably) and patch startup code
18:02:42pamauryclever, indeecd
18:04:05pamauryIf 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] (
18:04:44pamauryyep, maybe there is another trick going on
18:05:57pamauryah 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:02pamauryyeah, 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] (
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] (
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:09DBUGEnqueued 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:32pamauryappart 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:47pamaury[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:26pamauryah I see
18:17:31pamaurytricky ^^
18:17:46wodzadd gdbserver implemented on top of this framework and you can do virtually everything with standard tool
18:17:53pamauryOne 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:31pamauryright, that's my point
18:19:18[7]use my generic USB stack if you like :)
18:19:23pamauryLast 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:23pamauryvendor specific has the advantage of being smaller
18:20:29[7]not only that, also faster
18:20:33wodzvendor 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:39pamauryDo 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:04pamaurydo 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:23:15pamauryfor 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:28pamaury(driver from rockbox)
18:24:05 Nick DormantBrain is now known as SuperBrainAK (
18:24:22pamauryYou 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] (
18:26:31wodzrk27xx 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:04pamauryugly ^^
18:28:27pamauryit 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:41pamaurybut 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:19pamaurykindof :)
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:55pamaurythere is a doc, look for RK27xx datasheet or Porche9 datasheet
18:31:08pamauryYou 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:34pamaurysame for a set_config
18:31:58pamauryyou can leave without in our case
18:32:26 Join y4n [0] (~y4n@unaffiliated/y4ndexx)
18:33:03pamauryOk so, how much of your "umscore" can we reuse ?
18:33:25pamaurysorry, 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:54pamauryAppart 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:05[7]and I think that's about it
18:40:03pamauryok, 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:45:20pamaurythe driver can be found here: 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:58pamauryif possible that would be nice, since our stub is basically just a different "app", which somewhat specific use ^^
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:46pamaurywhat 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:51:35[7]this also means that we have full support for the ipods for free
18:52:19pamauryDo you some time to spend on this ? If yes you could start by making your umsboot in a good shape for it
18:52:22pamaury*you have
18:52:38[7]not terribly much time, but this should be mostly trivial
18:53:02pamauryThere 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] (
18:54:24[7]if we just need to move it around for different purposes/applications, that's trivial
18:54:43pamauryno, but that means the patcher need to relocate it, or can a tool to do so
18:55:11[7]the patcher could just call make BASE_ADDRESS=whatever
18:55:19[7]that would be easy to implement
18:56:16[7]then you'd add a -DBASE_ADDRESS=$(BASE_ADDRESS) in
18:56:16 Quit wodz (Quit: Leaving)
18:56:26[7]and just use BASE_ADDRESS in the linker script
18:56:41pamauryto 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:34pamauryand 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:29CtcpIgnored 1 channel CTCP requests in 0 seconds at the last flood
18:59:29*copper resents nicks enclosed in square brackets
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:01pamaury[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@
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:05:23[7]which CPU model?
19:05:27pamauryI 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:03pamauryyes, 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:53[7]and soc_name would be imx233?
19:09:48 Join liar [0] (
19:10:37[7]what kind of input vectors would it get?
19:11:09pamaurywhat do you mean ?
19:11:15[7]init, IRQ, pagefault, undefined_instr, anything else?
19:12:32pamauryI 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:56pamauryyeah, 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:27pamaurythe 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:54pamauryyes, 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:55pamauryhum, yes, it could imx or mxs. Maybe mxs/mx23 but that's a bit redundant
19:19:28pamauryor imx/233, usually these are called i.MX something
19:20:14pamauryyeah imx/233 should be fine
19:22:37 Join lorenzo92 [0] (
19:23:49[7]what kind of interrupt controller?
19:24:59pamaurycustom, it's imx233 specific, called ICOLL
19:26:38[7]cache line size is 16 bytes?
19:27:56 Join Zarggg [0] (
19:27:58[7]should build_target be application/device or device/application? what's more convenient?
19:29:13pamauryI 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:47pamauryit should be common to all
19:33:18copper[Saint]: yeah, I just configured my vim to display tabs and EOL
19:33:30copperthat 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:33pamauryhum, that's a good question
19:36:46[7]also do I need to take care of clearing .bss?
19:37:26pamauryyou 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:03lorenzo92am i missing a new port in progress? :)
19:41:34pamauryerr, 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:52bertrikI 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:40pamaurybertrik: me too but no idea how to investigate this
19:43:56bertrikany bright ideas how we can prove that code is actually run?
19:44:07pamaurydo you have the code which is run in this mode ?
19:44:16pamauryIf yes I can have a try at disassembling it
19:44:25bertrikthe bricked clip I have doesn't have a backlight, that would be too easy
19:44:45 Join ikeboy [0] (
19:44:56[7]it it would be an ipod i'd just make it beep
19:44:58pamaury[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:23pamauryin any case having a magic value around would be good
19:45:29pamauryjust to check everything is fine
19:45:58pamaurybertrik: bright idea, disconnect usb
19:46:30[7]hang vs. reboot might be worth a try
19:46:33bertrikpamaury: 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:44pamaurybertrik: no no I mean, to check the theory of running code, the code should connect/disconnect usb in software
19:47:54pamaurythat 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:23pamaury[7]: yes, that's a safe bet, it's the case for the OF fuze+, don't know for others
19:48:37bertrikah, 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:44lorenzo92pamaury: very interesting ;)
19:49:22pamauryhum, 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:46pamaurybertrik: do you have the ROM code for this mode ?
19:49:53lorenzo92by the way, which cpu? since I know quite well imx37 if necessary (unfortunately only based on experience, no datasheet)
19:50:02bertrikpamaury: yes, we have the ROM code I think
19:50:09bertrikor at least we should be able to dump it
19:50:18pamaurybertrik: 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:48pamaurylorenzo92: the aim is to be as cpu agnostic as possible, we will start with imx233/fuze+, and some ipods
19:50:54bertrik[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:29lorenzo92pamaury: 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:20pamauryyes, except we have no idea how it works if I understand correctly
19:52:33pamauryit could be scrambled, or using some weird format
19:52:41pamaury[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:50pamauryI'm confident someone around has a bricked clip+
19:53:54bertrikI did once start at the ROM dump too, but got stuck
19:54:29 Join Zarggg [0] (
19:54:30bertrikI have a bricked clip+, but it's probably really borken
19:54:46bertrikit does still connect as a 4 MB drive
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:21bertrikmine says it's a Sandisk M200Plus in dmesg
19:56:32*[7] checks where his one is
19:57:09bertrikhm, seems it just re-attached itself to USB after dumping with dd
19:57:23 Join wodz [0] (
19:58:00pamauryhum, not that small ROM ^^
19:58:14*[7] even found the donated one in a bin somewhere
19:58:49wodzthe rom is not small at all, it interleaves thumb and arm and looks like c++ shit
19:58:54[7]it connects :)
19:59:37pamauryI'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:38pamauryhow large is the DRAM on that thing ?
20:00:40lorenzo92haha 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:02:14pamauryOk i'll pick up the disassembly, only 1400 functions to go :D
20:02:45lorenzo92*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:01lorenzo92it 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:04pamauryhow 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:33bertrikI 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:21:44 Quit lorenzo92 (Ping timeout: 264 seconds)
20:23:24***Saving seen data "./dancer.seen"
20:30:18[7]compiles, but completely untested
20:30:34pamaurythanks, 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@
20:36:34 Quit lorenzo92 (Client Quit)
20:37:36pamaury[7]: which toolchain do you use ?
20:38:50[7]pamaury: the one generated by
20:38:58[7]it should also work with the rockbox one thougjh
20:39:21pamauryit's much more than ours
20:39:26pamaury*more recent
20:39:50[7]I typically use that because I need support for cortex M4 etc.
20:40:05copperDoes anyone actually look at Rockbox icons?
20:40:21copperuse them as visual cues?
20:40:45bertrikeh, 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:19gevaertsYou 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:42gevaertsOr maybe even bigger
20:41:52[7]in the main menu I think they're important though
20:42:24copperyeah I meant the SBS icons
20:42:38*copper doesn't even know what SBS stands for
20:42:45gevaertsstatusbar screen
20:43:05 Quit SovonHalder ()
20:43:07gevaertsDoesn't make much sense, but it fits the general xxS theme :)
20:43:26[7]s/screen/skin/ might make more sense
20:44:40gevaertsRight, it might have been retrofitted to that at some point
20:44:53gevaertsIt 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:32copperShiny 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:56bertrikmaybe have a look at PCB scans
20:50:14[7]also 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:04pamauryurg 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:19pamaury[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:01:32wodzpamaury: what is USB_STATUS_BY_EVENT define?
21:02:34pamaurymean 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:40pamaury[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:25pamaurythe 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:20pamaurywtf, the compiler must have been dumb, didn't seem to optimise the trivial access to the classes
21:14:23wodzor the code is compiled with optimization turned off :-)
21:15:27pamauryit must have been completely turned off then, this is really the basics
21:15:48wodzthis should help to reveng
21:16:31pamaurywell 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:41pamauryah my tree is not clean
21:22:51wodzI can send you rkw
21:24:02pamauryno no I'll compile it don't worry
21:24:17 Quit Topy44 (Ping timeout: 240 seconds)
21:25:06fs-bluebotBuild Server message: 3New build round started. Revision 21672ba, 217 builds, 20 clients.
21:25:09 Quit Zambezi (Remote host closed the connection)
21:26:36pamaurywodz: /home/pamaury/project/rockbox/myrockbox/apps/keymaps/keymap-rk27xx-generic.c:70:1: error: unterminated #ifdef
21:27:05wodzpamaury: just uploaded cleaned a bit version
21:27:14pamauryah wait, the didn't apply cleaning on HEAD
21:27:26wodztry again with new version
21:28:13wodzah, and you need to tweak firmware/export/config/rk27generic.h to expose only SD disk.
21:32:17fs-bluebotBuild Server message: 3Build round completed after 431 seconds.
21:32:41pamaurythe problem was with big transfers right ?
21:33:08 Join Rower [0] (
21:34:49pamaurywodz: root@destiny:/home/pamaury/project/rockbox/myrockbox/build_rk27generic# dd if=/dev/sdb of=/dev/null bs=1M count=100
21:34:49pamaury104857600 octets (105 MB) copiés, 39,8045 s, 2,6 MB/s
21:35:04wodzthe same here :-)
21:36:37pamauryso 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:03pamauryoh 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:51wodz[7]: you need solder paste + good flux
21:49:54 Quit kevku (Quit: KVIrc 4.3.1 Aria
21:50:46*[7] finally has a "dead bug" clip+ :)#
21:52:53*[7] powers up the flyswatter
21:53:11pamauryseriously, 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:32pamauryyeah, I'm tracking the usb irq and it seriously does several allocations unconditionally
21:56:38 Join amayer_ [0] (
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:52pamauryI have already find at least 3 different classes, two of them having at least one derivative
22:00:55wodzpamaury: 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:38pamauryit 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:40pamaurygood :)
22:24:34wodzhmm, 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:54bertrik[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:14pamaury[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:21[7]that was quite some fiddly soldering today!
22:28:56wodzthis 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] (
22:31:35pamaury[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:35pamauryall temporaries are going to stack !!
22:36:39pamauryin some functions you clearly see the compiler never tried to use anything except r0 and r1
22:36:53wodzThis must be compiler optimization turned off.
22:37:15wodzhave you tried to apply flirt sigs scan?
22:37:24[7]which ida version are you working with?
22:39:04[7]ok, I'm gonna use the old one as well then
22:39:10wodzpamaury: 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:32pamaury[7]: which one do you have ?
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:56pamaurywodz: 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:11pamaurywow 6.1, how did you get it ?
22:40:14[7]or hid, has a similar effect
22:40:27*wodz tries
22:40:38gevaertswodz: 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:28gevaertsI 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:25[7]pamaury: yay, debugging that clip+ in ida :)
22:44:38gevaertsIn that case a -v, and possibly a -d to avoid spamming unrelated devices
22:45:46 Join saratoga [0] (123e1c0a@gateway/web/freenode/ip.
22:50:31 Quit madcat1990 (Quit: Leaving)
22:54:19 Quit mrtux2 (Quit: ZNC -
22:57:25pamaury[7]: do you have the full output of lsusb on the device ?
22:57:42[7]the clip+ recovery thing?
23:00:15[7] (with root access)
23:01:06wodzhid + lsusb -vv kills transfer. With hid turned off spamming with lsusb -vv only slightly affect transfer rate.
23:03:46wodzdd'ed file during lsusb spamming is md5sum correct
23:04:20wodzso the question to mortalis is if he tested usb with HID turned on.
23:04:47 Join pystar89 [0] (
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@
23:12:02pamaury[7]: I will soon convinced myself that all descriptor are dynamically built and allocated using several temporaries objects
23:13:31pamauryoh 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: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:33pamaurywhy not ?
23:16:30wodzok, *very* high rate of lsusb -vv also kills the transfer but not instantaneous.
23:16:32 Quit n1s (Quit: Ex-Chat)
23:17:50wodzthe device is locked in usb screen but reacts on keypress and backlight timer runs properly
23:19:53pamaurywodz: could you check if for example a setup packet arrives before the last one has been processed ?
23:22:08pamauryhum, not sure, otherwise I'll try, how do you trigger the bug ?
23:23:53wodzdd if=some_file of=/media/xxxxxxx/test bs=1M && md5sum /media/xxxxx/test
23:24:07wodzduring the copy run lsusb -vv in loop
23:26:13wodzwith hid turned on it is much faster
23:27:26 Quit Rower (Quit: sover :D)
23:34:48pamauryok, 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:38pamaury[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:56:46wodz[7]: but the only somewhat universal way (excluding roms)

Previous day | Next day