Hi David.
+0000: magic1, 0x3B513B51 +0008: headerlength +0014: magic2, 0x00544F42 ("BOT") +0064: execaddress +0068: magic3, 0xB513B513 +006c: destination (0x04000000) +0070: imagetype 0 == plain 2 == compressed +0074: compressedlength
Aye - that pretty much matches whats on the E3.. only the header runs from 0x3B513B51 to 0xB513B513. The rest is image specific. fyi : in the E3 theres over a hundred of these sections - bits containing wavs, images, etc... magic2 is the "filename" - theres also a description string in there somewhere - fixed length/zero filled.. Theres also a simple image crc system there too - you crc the file and if the result is 0 then its a good image - theres a fix-up byte that must be introduced to make sure of the zero result.. Once you work out where that is ( or you can just hack the description :P ), you can either edit the existing image ( simpler under the e3 ), or reflash completely.
I've included what I think is a decompilation of the boot logic at the end (because it's big and antisocial). Basically, PBL supports both compressed and uncompressed images; the data is copied or decompressed to the target destination and the execution address called. Couldn't be simpler (although the code took me several hours to decipher... god, this stuff is hard. I couldn't have done it without Ralph's crib sheet).
What crib sheet ?
This should be dead easy to write code for.
Next order of business is to try and figure out how to reflash it, and then I can give it a try...
Does it do similar keypress checks to the E3 on boot ? I've a list of about 8 "special function" keys - Only 2 of which I can activate, so I'm assuming the others require some sort of special circumstance to be available - I'm still working through the disassembly on this.. Cheers Jake
On Sat, 2005-03-19 at 09:42 +0000, Otaku wrote: [...]
Aye - that pretty much matches whats on the E3.. only the header runs from 0x3B513B51 to 0xB513B513. The rest is image specific. fyi : in the E3 theres over a hundred of these sections - bits containing wavs, images, etc...
What, someone already worked it out? Gah!
BOT obviously means it's a boot block, then.
[...]
Theres also a simple image crc system there too - you crc the file and if the result is 0 then its a good image - theres a fix-up byte that must be introduced to make sure of the zero result..
The E2 only checks this if it's a compressed block, luckily for us. (Not that it would be hard to calculate, but it's fiddly.) For what we want to do, uncompressed is better; we just need to be able to run *something*, we can take it from there ourselves.
[...]
Does it do similar keypress checks to the E3 on boot ? I've a list of about 8 "special function" keys - Only 2 of which I can activate, so I'm assuming the others require some sort of special circumstance to be available - I'm still working through the disassembly on this..
I don't know; I didn't look. I found the boot code by searching through the diassembly for the ARM's distinctive indirect subroutine call instructions. (There are only two.)
The next stage is to figure out how to reflash the firmware, so I can upload a custom image. Request 14 seems to have something to do with it; it takes a pseudo-address into the flash section and a block of data, and when I do this everything seems to work, but the flash doesn't actually change. Possibly I need to erase a page first, but I'd expect to at least corrupt the flash if I didn't.
However, accessing the NAND control registers is also pretty distinctive so I should be able to track down the erasure code reasonably easily.
Oh, yeah, I pblq will now write data into the E2's SDRAM. Speed: 11000 Bps, which is a slight improvement to the download speed...
Hey David,
Well done with your hacking! Sounds like you're making great progress.
My $0.02:
The next stage is to figure out how to reflash the firmware, so I can upload a custom image. ... Oh, yeah, I pblq will now write data into the E2's SDRAM. Speed: 11000 Bps, which is a slight improvement to the download speed...
It sounds like this might be more of a convenient avenue: downloading/uploading things from flash can be slow as you say... I think having a route to getting a tiny loader of our own into DRAM via serial would make the flashing things much easier - e.g. if we can download a tiny routine via the slow route (PBL) we can use that to download stuff into DRAM (or reflash NAND) much quicker since it's in our control.
It's possible that getting PBL to execute something that it hasn't loaded from NAND (e.g. stuff we've poked into RAM) is completely impossible. But surely it must have an overflow somewhere.. maybe even a function to do so.. ;)
Also something that might be worth further investigation is the inbuilt recovery procedure; I've seen some code that checks the loaded DRAM image (from flash) with the magic numbers in the header, and tootles about picking 0800 numbers... Possible that if the header isn't tip-top it decides it's corrupt and will only try to dial the 1-800-FLASHME number. MAybe something to be careful of </paranoia>
Cheers,
Matt
-
David Given -
Matt Evans -
Otaku