small status update
I've done more disassembly and reverse engineering of the relevant parts in bootloader
i will list information here for the following reason: document it publicly so I can always look it up later, and others can jump in the discussion too if they want to. I'd really appreciate that
it will be very technical
, but I'll do a summary too.. and if you think I'm wrong about something then let me know.
basic facts:
the bsquare powerhandheld
(maui
) firmware consists of four parts and those are stored on the nand flash, called DOC, diskonchip from now on...
the DOC has two partitions, the binary partition
(BIPO
) has the second and third bootloader and the OS
(very unusual that it has the OS, WM devices never do, so this is why pdocread doesn't really see it
). and the internal disk that is user accessible. BIPO is 1000 blocks, blocksize is 0x8000, 32K
(sadly when trying to query size of BIPO using the block size information with pdocread we only got 1 block back
).
now the firmware parts.
1. 4K IPL stored in a special part of the DOC
(*not* at block 0
), loads to 0x0 in internal RAM on boot and does nothing except load the second bootloader.
(also copies itself to 0xA0000000 at RAM start and continues execution from there before loading second bootloader
)
2. second bootloader: DOCSPL.NB0, raw image stored in 0th block of DOC
(0x0 in flash
), 32K size
(just the size of one block
). gets loaded at 0xA0001400 and all it probably does is load third bootloader.
3. third bootloader: SABOOT.BIN
(from now on just called SABOOT or "the bootloader"
, it's stored as MS BIN from 1st block of DOC
(0x8000 in flash
), and has a backup of itself at 8th block at 0x40000. gets loaded at 0x940A0000
(=0xA4A00000
) and does everything, boot the OS, flash the firmware, send debug messages to terminal
(yeah I don't have access to the debug port
)
4. OS from 16th block at 0x80000 in flash until end of BIPO, ... loads to ram at 0x94200000.
+1: and the password is stored in 15th block after SABOOT ends
booting OS:
it supports NOR and DOC flash too, I wonder if that 64MB/32MB ram/flash bsquare version had NOR? I never saw any of those bsquare's, anyone else?
it supports loading a raw image only for NOR
(and executing it XIP from NOR flash
), and supports BIN and supports GZ compressed BIN for both NOR and DOC.
anyway forget NOR now, we have DOC bsquares
if the OS is a BIN file then it just loads it to ram at 0x94200000;
if it is GZ then it expects the following signatures before uncompression starts: first two bytes must be 1F 8B, next two bytes should be 08 08, though the fourth byte may be different from 08, but must not have 0xC0 or 0x20 bits sets, no idea what the rest means. we'll just stick to 08 08
then i think it expects compressed data at 0x80011. the standard zlib signature 78 9C is not needed.
at the end of the OS image, the last 4 bytes for standard zlib are missing
(adler32 checksum
) but instead there's the crc32 checksum of uncompressed image and size of uncompressed image, in the last 8 bytes.
then it gets uncompressed to BIN and that's copied to RAM and booted.
flashing firmware: this is the interesting part I guess
you can flash OS or do other things in the following ways
(not tested yet, will try today!
) :
- key combinations, 7 of them:
U+D: USB download, see below.
R+S: DOC flash from SD/MMC card, by filename DOCSPL.NB0, flashes the second bootloader. hard coded to flash to doc block 0.
R+B: DOC flash from SD/MMC card, by filename BOOT.BIN, flashes SABOOT. hard coded to flash to doc block 1. it is SABOOT packaged as a MS BIN.
R+O: DOC flash from SD/MMC card, by filename NK.BIN or NK.GZ
(first it looks for NK.GZ, if not found it tries to find NK.BIN
). NK.BIN flashes a BIN image, NK.GZ flashes a compressed image.
it turns out the BIN is flashed as is, no extra header or formatting is needed. the GZ however needs a header, but it is the exact same as seen in the rom dump. you keep the first 17 bytes, the rest is the raw compressed data of the BIN file, then the last 8 bytes are those crc32 and filesize data mentioned above at the OS booting info.
G+K: this takes the bootloader image
(SABOOT
) from doc at 0x40000 and writes it to block 1
(0x8000
). does not need any SD card, so if you press G+K during boot it will perform this action without any extra checks! and if you happen to have erased your flash at 0x40000, this G+K option will result in a neat brick...
(unless DOCSPL loads SABOOT from 8th block instead of 1st, but I doubt that!
)
B+C: you know what this is... hard reset/cold boot.
D+C (or maybe U+C?): you won't see this one in action without sending something over serial
(see below
). this is why it wasn't discovered before
- extrahidden options:
no idea how you'd set those, I haven't found a reference in the disassembly. maybe over the serial port
(see below
) but I doubt it.
- flash BOOTFL.BIN - bootloader image to flash directly to flash addresses specified in the BIN header. so either DOC has a fake address mapping to be able to specifiy addresses in the BIN header, or this FL is only for NOR flash. I would think DOC does have the fake mapping
(RAM to DOC mapping to be more specific, this is the most likely
), as it is required for BIN download from platform builder anyway.
another thing why this might only be for NOR is if this bootloader is SABOOT - should be stored as a BIN file instead of raw, and BOOTFL makes it get stored as raw, but maybe DOCSPL is flexible enough and willing to load raw SABOOT image too.
also, it is possible that this just intended to flash DOCSPL, and not SABOOT. DOCSPL *is* stored raw.
- flash NKFL.BIN - not implemented, but similar to BOOTFL flash, except it would only be the OS.
- load RAM OS NK.BIN - what it says.. copies NK.BIN BIN image from SD card and copies it to RAM... without any error checking.
(invalid BIN will just crash it i guess
)
this option is inaccessible right now, but I have ideas to get to it
I really want to get this one working!!
(RAM OS like on 900c
)
three ideas so far:
1
) patch the SABOOT loaded in ram then reboot to it, but I think DOCSPL reloads it from flash
2
) load patched SABOOT in ram and jump to it manually
(without true soft reset
), this probably needs lots of low level patching to get working
(same for 900c
)
3
) write the patch to the DOC directly
(I think this is viable
) one thing must be checked before doing so: does DOCSPL check the checksum of BIN file before loading SABOOT to ram on boot, if not then just write patch to doc, if yes, write changed checksum to doc aswell.
4
) or just flash patched SABOOT as BOOT.BIN
actually 3rd and 4th options are best because that will make the patch permanent and will work even after hard reset
- download and flash over USB
U+D key combination;
L,U option from terminal;
BIN image download from platform builder... but my PB 4.2 doesn't have USB option, only ethernet and serial, so will need to see what to do, maybe it needs a usb to serial driver to communicate with PB. and I hear PB 5.0 supposedly has direct USB download... anyone got PB 5.0 installed ? the evaluation version from microsoft is fine...
- download and flash over standard ethernet:
L,E option from terminal;
bog standard BIN image download from platform builder. now if I had that debug ethernet card...
it is a very straightforward method of flashing images, and you don't really have to install platform builder either, you can just use a tftp client on the PC with the right settings
(trick is to set the port to 980 instead of default 69
).
- download and flash over serial:
L,S option from terminal;
now I still have no idea where the serial port is, and no idea how to send the image
(might be download from platform builder but I've seen no evidence of that
), but the image is standard MS BIN.
I guess there is a way to get to the serial port, might involve hacking the docking station, anyone feels up to the task?
you can also start an automatic download over serial before entering serial menu
(this one depends on the same special thing sent over debug port. nec 900c has the exact same check!! NOTE, 900c shares some of the code and hardware with bsquare phh, bsquare made the 900c too.
)
- terminal over debug port:
there is a debug port that seems to be serial. but not the standard xscale serial port! the bootloader sends messages over it and if that port is activated, then you can also use some SMC ethernet debug card
(there is reference to product ethernet card too, can that be bought anywhere?
), which I have no idea where you'd obtain. anyone have an idea?
ok, even if only you have the serial port, you already have a very cool menu of options, copypasted from bootloader help menu with my comments in italic:
- menu options:
L - Run the S-Record Loader
s-record refers to MS BIN...options within this are E, S, U - download over Ethernet, Serial or USB
E - Completely erases all of system Flash, returns to prompt when complete
(now that's dangerous, I don't know yet if it erases bootloader too, need to check before trying )
C <source><destination><length>- Copy memory
(RAM or Flash
)
D <address>[B, W, D, default D] - Display data from starting address
(B = byte, W = word, D = dword)
S[B, W, D, default D] <address><value> [length] - Sets data at starting address>
G <address> - Starts execution from the address
M[M, U, R, W] <ramaddr><sector><count> - Mount/Unmount or Read/Write Disk data to/from RAM
T - Run the self-test
(sort of some POST)
I - Identify. Prints the device identification information
(it even shows you the website link to bsquare.com!)
V <start><length> - Verify checksum of specified memory region.
Z <start><length> - Zero memory region.
+ <16bit><16bit><16bit> - program debug ethernet card MAC address
= <16bit><16bit><16bit> - program product ethernet card MAC address
(now what is this product ethernet card? I want one!)
PD - Dumps PCO EEPROM contents
(PCO is what handles keyboard, touchscreen, backlight, etc. has its own firmware. 900c also has the same PCO = PIC.)
PW <address><value> - Writes value to PCO EEPROM address
PF <address><length><value>- Fills PCO EEPROM address range with a value
PP - Prepares PCO EEPROM with default build configuration
PS <platform setting><value> - sets platform boot configuration
-display <vga|qvga> - sets LCD panel size configuration
(wonder what happens if you set qvga!)
-cpuspeed [100|200|300|400] - sets PXA250 cpu speed configuration
you have more menu options though that I've seen in the disasm, and some of them are not implemented:
F - erase or write flash, it seems you can give it address and length and E is erase, W is write. when you write the data is maybe from RAM.. not sure yet
not supported/not implemented ones from the help menu are: E, M, and "-"
(program product eth card
).
you can get to this menu
(if we get access to serial port!
) by using U+D and then just fail usb download. and it goes straight there.
(or you can get to this menu right away using that tentative key combo mentioned above but only if it detects something special over serial or from whatever debug port there is
)
well I have written enough already,
as summary I'd emphasize the best options to get working would be:
- NK.GZ flash
(or NK.BIN flash but that's a waste of space unless you do want a small OS image
).
- NK.BIN RAM OS load.
- if flash from SD for some reason won't go, then USB download of NK.BIN.
the rest is just interesting and would be fun to get going.
what I'd like to hear if someone can try:
- find serial port, by disassembling docking station maybe
- try to do USB download from platform builder 5.0 if you have that installed
(eval version is just fine!
). do not attempt to download a valid BIN though, just try some junk file, so the download will fail, we just want to check if PB can see the bsquare. ... or with PB 4.2, see if there is a usb to serial driver.
- if you have a bsquare with some HW fault or otherwise not sorry for risking it, take the romdump, get the part from 0x80000, until FF FF FF FF FF FF FF FF FF FF FF empty part starts in the dump, name it NK.GZ and try to flash it in using R+O option
- any idea on this SMC ethernet card?
maybe it is a SD lan card?!
Edited by cmonex 2008-05-17 3:42 AM
). it assumes there are 1000 blocks to dump- but I remember there was a bsquare version that was 32MB rom total (and 64MB ram) though I've never seen one of those.
