Subject: [E3-hacking] Re: The boot process, revealed!

From: Otaku <[email-masked]>
Date: Sat, 19 Mar 2005 09:42:13 +0000

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

---

From: David Given <[email-masked]>
Date: Sat, 19 Mar 2005 13:34:21 +0000

On Sat, 2005-03-19 at 09:42 +0000, Otaku wrote:
[...]
> E3 theres over a hundred of these sections - bits containing wavs, 

What, someone already worked it out? Gah!

BOT obviously means it's a boot block, then.

[...]
> 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.

[...]
> circumstance to be available - I'm still working through the disassembly 

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...

-- 
+- David Given --McQ-+ "Safe upon the solid rock
|  [email-masked]    | The ugly houses stand.
| ([email-masked]) | Come and see my shining palace
+- www.cowlark.com --+ Built upon the sand." --- Edna St.Vincent Millay

---

From: Matt Evans <[email-masked]>
Date: Sat, 19 Mar 2005 15:02:51 +0000

Hey David,

Well done with your hacking!  Sounds like you're making great progress.

My $0.02:

> upload a custom image.
> ...

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