b6c20c17e4
We checked if the new firmware block (bootloader+ucl function+packed bootloader & OF) fit in the OF file, but not if it would run properly. For example the Clipv2 OF is bigger than 0x50000 bytes uncompressed, but it fitted in this space when packed and concatenated to a packed bootloader + ucl function and dualboot code (but we use 1MB of RAM and not 0x50000 anyway). Now we check that both bootloader and OF are small enough to be unpacked at runtime: the unpacked data must be smaller than available memory and not overlap with ucl function and packed data (although the unpacked and packed data could probably overlap a bit, I don't know how to calculate this and this could be quite complex). total_size() is replaced by check_sizes() which will perform all the checks and set an error string if the firmware can't be patched. (both mkamsboot and rbutilqt modified accordingly) The second problem is that dualboot.S assumed r3 and r5 were left untouched in the device specific checks. This was undocumented and very error prone when modifying these checks. r3 is the last byte of packed copy (bootloader or OF) r5 is the entry point of uclunpack function derived from r3, so move r5 calculation after the device specific code. Even if r3 is currently unused in the device specific code, we store it in memory after copying the ucl function, when it points to the last byte of packed data (not yet copied at this point since we didn't chose if we boot the OF or the bootloader), and restore it just before using it so no restriction is placed on registers usage in device specific code. Add a new variable ucl_dest in dualboot.S set by mkamsboot.c, which represents the last bound of buffer where we copy the ucl function, and then the packed data (bootloader or OF). RAM_SIZE definition is moved from dualboot.S to mkamsboot.c new model_memory_size(), where it is a bit better documented. Tested on e200v2 and Clip+ git-svn-id: svn://svn.rockbox.org/rockbox/trunk@24772 a1c6a512-1295-4272-9138-f99709370657 |
||
|---|---|---|
| .. | ||
| dualboot | ||
| dualboot.c | ||
| dualboot.h | ||
| main.c | ||
| Makefile | ||
| md5.c | ||
| md5.h | ||
| mkamsboot.c | ||
| mkamsboot.h | ||
| README | ||
mkamsboot
---------
A tool to inject a bootloader into a Sansa V2 (AMS) firmware file.
Usage
-----
mkamsboot <firmware file> <boot file> <output file>
<firmware file> is an original Sansa firmware file obtained from the Sansa
forums for example : http://forums.sandisk.com/sansa/?category.id=devices
<boot file> is the code you want to execute (a rockbox bootloader), previously
scrambled with tools/scramble utility.
<output file> is the resulting firmware file which you'll have to copy on your
Sansa player. See "Firmware filenames".
Supported models
----------------
Sansa Clip : firmware version starting with "01."
Sansa Clip+ : firmware version starting with "01."
Sansa Clipv2: firmware version starting with "02."
Sansa Fuze : firmware version starting with "01."
Sansa E200v2: firmware version starting with "03."
Sansa C200v2: firmware version starting with "03."
Sansa M200v4: firmware version starting with "4."
Firmware filenames
------------------
For the firmware upgrade to happen, the firmware has to be named specially:
clip v2 : m30pa.bin
clip : m300a.bin
clip+ : clppa.bin
fuze : fuzea.bin
e200v2 : e200pa.bin
c200v2 : c200pa.bin
m200v4 : m200a.bin
Dual-Boot
---------
The purpose of this program is to provide dual-boot between the original
firmware and the new (rockbox) firmware.
By default the player will boot into the new firmware.
To boot into the Original Firmware, you need to press the Left key.
***Note : on the c200v2 you need to press the Right key.
The player will boot into the Original Firmware as well if it is powered up by
inserting an usb cable.
***Note : on the m200v4 powering up by usb will cause booting into the new
firmware
Hacking
-------
See comments in mkamsboot.c and dualboot/dualboot.S for more information.