2009-05-28 18:27:08 +00:00
|
|
|
/* Generated by bin2c */
|
|
|
|
|
|
2010-02-13 18:53:29 +00:00
|
|
|
#include "dualboot.h"
|
|
|
|
|
|
2009-05-28 18:27:08 +00:00
|
|
|
unsigned char nrv2e_d8[168] = {
|
|
|
|
|
0x0f, 0x18, 0x01, 0x24, 0x65, 0x42, 0xe4, 0x07, 0x05, 0x26, 0x36, 0x02, 0x0a, 0xe0, 0x00, 0x20,
|
|
|
|
|
0x00, 0x47, 0x04, 0x78, 0x64, 0x41, 0x01, 0x30, 0x24, 0x06, 0xf7, 0x46, 0x03, 0x78, 0x01, 0x30,
|
|
|
|
|
0x13, 0x70, 0x01, 0x32, 0x24, 0x19, 0xfe, 0x46, 0xf3, 0xd0, 0xf7, 0xd2, 0x01, 0x21, 0x04, 0xe0,
|
|
|
|
|
0x01, 0x39, 0x24, 0x19, 0xfe, 0x46, 0xec, 0xd0, 0x49, 0x41, 0x24, 0x19, 0xfe, 0x46, 0xe8, 0xd0,
|
|
|
|
|
0x49, 0x41, 0x24, 0x19, 0xfe, 0x46, 0xe4, 0xd0, 0xf2, 0xd3, 0xcb, 0x1e, 0x00, 0x21, 0x08, 0xd3,
|
|
|
|
|
0x1b, 0x02, 0x05, 0x78, 0x01, 0x30, 0x1d, 0x43, 0xed, 0x43, 0xd8, 0xd0, 0x6d, 0x10, 0x13, 0xd2,
|
|
|
|
|
0x03, 0xe0, 0x24, 0x19, 0xfe, 0x46, 0xd4, 0xd0, 0x0e, 0xd2, 0x01, 0x21, 0x24, 0x19, 0xfe, 0x46,
|
|
|
|
|
0xcf, 0xd0, 0x09, 0xd2, 0x24, 0x19, 0xfe, 0x46, 0xcb, 0xd0, 0x49, 0x41, 0x24, 0x19, 0xfe, 0x46,
|
|
|
|
|
0xc7, 0xd0, 0xf7, 0xd3, 0x04, 0x31, 0x04, 0xe0, 0x24, 0x19, 0xfe, 0x46, 0xc1, 0xd0, 0x49, 0x41,
|
|
|
|
|
0x02, 0x31, 0xee, 0x42, 0x00, 0xd2, 0x01, 0x31, 0x13, 0x78, 0x53, 0x5d, 0x13, 0x70, 0x01, 0x32,
|
|
|
|
|
0x01, 0x39, 0xfa, 0xd1, 0xbe, 0xe7, 0x00, 0x00
|
|
|
|
|
};
|
mkamsboot: prevents 2 potential problems
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
2010-02-19 14:10:26 +00:00
|
|
|
unsigned char dualboot_clip[256] = {
|
2010-03-04 00:08:53 +00:00
|
|
|
0xe4, 0xf0, 0x9f, 0xe5, 0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea,
|
|
|
|
|
0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea,
|
2009-05-28 18:27:08 +00:00
|
|
|
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
|
mkamsboot: prevents 2 potential problems
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
2010-02-19 14:10:26 +00:00
|
|
|
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x24, 0x00, 0x1f, 0xe5,
|
|
|
|
|
0x24, 0x10, 0x1f, 0xe5, 0x01, 0x20, 0x40, 0xe0, 0x18, 0x30, 0x1f, 0xe5, 0x01, 0x40, 0x50, 0xe4,
|
|
|
|
|
0x01, 0x40, 0x43, 0xe4, 0x00, 0x00, 0x52, 0xe1, 0xfb, 0xff, 0xff, 0x1a, 0x2c, 0x30, 0x0f, 0xe5,
|
|
|
|
|
0x88, 0x00, 0x9f, 0xe5, 0x00, 0x10, 0x90, 0xe5, 0x01, 0x18, 0x81, 0xe3, 0x00, 0x10, 0x80, 0xe5,
|
|
|
|
|
0x7c, 0x00, 0x9f, 0xe5, 0x00, 0x10, 0xa0, 0xe3, 0x00, 0x14, 0x80, 0xe5, 0x00, 0x11, 0x90, 0xe5,
|
|
|
|
|
0x00, 0x00, 0x51, 0xe3, 0x0c, 0x00, 0x00, 0x1a, 0x68, 0x00, 0x9f, 0xe5, 0x20, 0x10, 0xa0, 0xe3,
|
|
|
|
|
0x00, 0x14, 0x80, 0xe5, 0x80, 0x10, 0x80, 0xe5, 0x5c, 0x00, 0x9f, 0xe5, 0x00, 0x10, 0xa0, 0xe3,
|
|
|
|
|
0x00, 0x14, 0x80, 0xe5, 0x04, 0x10, 0x90, 0xe5, 0x00, 0x00, 0x51, 0xe3, 0x02, 0x00, 0x00, 0x1a,
|
|
|
|
|
0x88, 0x00, 0x1f, 0xe5, 0x88, 0x10, 0x1f, 0xe5, 0x01, 0x00, 0x00, 0xea, 0x9c, 0x00, 0x1f, 0xe5,
|
|
|
|
|
0x9c, 0x10, 0x1f, 0xe5, 0x94, 0x30, 0x1f, 0xe5, 0x02, 0x50, 0x83, 0xe2, 0x01, 0x40, 0x43, 0xe0,
|
|
|
|
|
0x01, 0x20, 0x50, 0xe4, 0x01, 0x20, 0x43, 0xe4, 0x04, 0x00, 0x53, 0xe1, 0xfb, 0xff, 0xff, 0x1a,
|
|
|
|
|
0x01, 0x00, 0x83, 0xe2, 0x00, 0x20, 0xa0, 0xe3, 0x15, 0xff, 0x2f, 0xe1, 0x3c, 0x00, 0x00, 0x00,
|
|
|
|
|
0x14, 0x00, 0x0f, 0xc8, 0x00, 0x00, 0x0b, 0xc8, 0x00, 0x00, 0x0d, 0xc8, 0x00, 0x00, 0x0c, 0xc8
|
2009-05-28 18:27:08 +00:00
|
|
|
};
|
mkamsboot: prevents 2 potential problems
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
2010-02-19 14:10:26 +00:00
|
|
|
unsigned char dualboot_e200v2[236] = {
|
2010-03-04 00:08:53 +00:00
|
|
|
0xd4, 0xf0, 0x9f, 0xe5, 0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea,
|
|
|
|
|
0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea,
|
2009-05-28 18:27:08 +00:00
|
|
|
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
|
mkamsboot: prevents 2 potential problems
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
2010-02-19 14:10:26 +00:00
|
|
|
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x24, 0x00, 0x1f, 0xe5,
|
|
|
|
|
0x24, 0x10, 0x1f, 0xe5, 0x01, 0x20, 0x40, 0xe0, 0x18, 0x30, 0x1f, 0xe5, 0x01, 0x40, 0x50, 0xe4,
|
|
|
|
|
0x01, 0x40, 0x43, 0xe4, 0x00, 0x00, 0x52, 0xe1, 0xfb, 0xff, 0xff, 0x1a, 0x2c, 0x30, 0x0f, 0xe5,
|
|
|
|
|
0x78, 0x00, 0x9f, 0xe5, 0x00, 0x10, 0x90, 0xe5, 0x01, 0x18, 0x81, 0xe3, 0x00, 0x10, 0x80, 0xe5,
|
|
|
|
|
0x6c, 0x00, 0x9f, 0xe5, 0x00, 0x10, 0xa0, 0xe3, 0x00, 0x14, 0x80, 0xe5, 0x20, 0x10, 0x90, 0xe5,
|
|
|
|
|
0x00, 0x00, 0x51, 0xe3, 0x08, 0x00, 0x00, 0x1a, 0x58, 0x00, 0x9f, 0xe5, 0x00, 0x10, 0xa0, 0xe3,
|
|
|
|
|
0x00, 0x14, 0x80, 0xe5, 0x20, 0x10, 0x90, 0xe5, 0x00, 0x00, 0x51, 0xe3, 0x02, 0x00, 0x00, 0x0a,
|
|
|
|
|
0x78, 0x00, 0x1f, 0xe5, 0x78, 0x10, 0x1f, 0xe5, 0x01, 0x00, 0x00, 0xea, 0x8c, 0x00, 0x1f, 0xe5,
|
|
|
|
|
0x8c, 0x10, 0x1f, 0xe5, 0x84, 0x30, 0x1f, 0xe5, 0x02, 0x50, 0x83, 0xe2, 0x01, 0x40, 0x43, 0xe0,
|
|
|
|
|
0x01, 0x20, 0x50, 0xe4, 0x01, 0x20, 0x43, 0xe4, 0x04, 0x00, 0x53, 0xe1, 0xfb, 0xff, 0xff, 0x1a,
|
|
|
|
|
0x01, 0x00, 0x83, 0xe2, 0x00, 0x20, 0xa0, 0xe3, 0x15, 0xff, 0x2f, 0xe1, 0x3c, 0x00, 0x00, 0x00,
|
|
|
|
|
0x14, 0x00, 0x0f, 0xc8, 0x00, 0x00, 0x0b, 0xc8, 0x00, 0x00, 0x0d, 0xc8
|
2009-05-28 18:27:08 +00:00
|
|
|
};
|
2010-03-09 16:29:38 +00:00
|
|
|
unsigned char dualboot_c200v2[336] = {
|
|
|
|
|
0x38, 0xf1, 0x9f, 0xe5, 0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea,
|
2010-03-04 00:08:53 +00:00
|
|
|
0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea,
|
2009-05-28 18:27:08 +00:00
|
|
|
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
|
mkamsboot: prevents 2 potential problems
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
2010-02-19 14:10:26 +00:00
|
|
|
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x24, 0x00, 0x1f, 0xe5,
|
|
|
|
|
0x24, 0x10, 0x1f, 0xe5, 0x01, 0x20, 0x40, 0xe0, 0x18, 0x30, 0x1f, 0xe5, 0x01, 0x40, 0x50, 0xe4,
|
|
|
|
|
0x01, 0x40, 0x43, 0xe4, 0x00, 0x00, 0x52, 0xe1, 0xfb, 0xff, 0xff, 0x1a, 0x2c, 0x30, 0x0f, 0xe5,
|
2010-03-09 16:29:38 +00:00
|
|
|
0xdc, 0x00, 0x9f, 0xe5, 0x00, 0x10, 0x90, 0xe5, 0x01, 0x18, 0x81, 0xe3, 0x00, 0x10, 0x80, 0xe5,
|
|
|
|
|
0xcc, 0x00, 0x9f, 0xe5, 0x00, 0x10, 0x90, 0xe5, 0x02, 0x18, 0x81, 0xe3, 0x7f, 0x10, 0xc1, 0xe3,
|
|
|
|
|
0x00, 0x10, 0x80, 0xe5, 0xbc, 0x00, 0x9f, 0xe5, 0x00, 0x10, 0xa0, 0xe3, 0x24, 0x10, 0x80, 0xe5,
|
|
|
|
|
0x3c, 0x10, 0xa0, 0xe3, 0x1c, 0x10, 0x80, 0xe5, 0x00, 0x10, 0xa0, 0xe3, 0x20, 0x10, 0x80, 0xe5,
|
|
|
|
|
0x8c, 0x10, 0xa0, 0xe3, 0x04, 0x10, 0x80, 0xe5, 0x51, 0x20, 0xa0, 0xe3, 0x0c, 0x20, 0x80, 0xe5,
|
|
|
|
|
0x30, 0x10, 0x90, 0xe5, 0x01, 0x00, 0x11, 0xe3, 0xfc, 0xff, 0xff, 0x1a, 0x25, 0x10, 0xa0, 0xe3,
|
|
|
|
|
0x44, 0x10, 0x80, 0xe5, 0x02, 0x20, 0x82, 0xe3, 0x0c, 0x20, 0x80, 0xe5, 0x01, 0x10, 0xa0, 0xe3,
|
|
|
|
|
0x10, 0x10, 0x80, 0xe5, 0x10, 0x10, 0x90, 0xe5, 0x00, 0x00, 0x51, 0xe3, 0xfc, 0xff, 0xff, 0x1a,
|
|
|
|
|
0x00, 0x10, 0x90, 0xe5, 0x08, 0x00, 0x11, 0xe3, 0x08, 0x00, 0x00, 0x1a, 0x58, 0x00, 0x9f, 0xe5,
|
|
|
|
|
0x00, 0x10, 0xa0, 0xe3, 0x00, 0x14, 0x80, 0xe5, 0x00, 0x11, 0x90, 0xe5, 0x00, 0x00, 0x51, 0xe3,
|
|
|
|
|
0x02, 0x00, 0x00, 0x0a, 0xdc, 0x00, 0x1f, 0xe5, 0xdc, 0x10, 0x1f, 0xe5, 0x01, 0x00, 0x00, 0xea,
|
|
|
|
|
0xf0, 0x00, 0x1f, 0xe5, 0xf0, 0x10, 0x1f, 0xe5, 0xe8, 0x30, 0x1f, 0xe5, 0x02, 0x50, 0x83, 0xe2,
|
|
|
|
|
0x01, 0x40, 0x43, 0xe0, 0x01, 0x20, 0x50, 0xe4, 0x01, 0x20, 0x43, 0xe4, 0x04, 0x00, 0x53, 0xe1,
|
|
|
|
|
0xfb, 0xff, 0xff, 0x1a, 0x01, 0x00, 0x83, 0xe2, 0x00, 0x20, 0xa0, 0xe3, 0x15, 0xff, 0x2f, 0xe1,
|
|
|
|
|
0x3c, 0x00, 0x00, 0x00, 0x14, 0x00, 0x0f, 0xc8, 0x00, 0x00, 0x07, 0xc8, 0x00, 0x00, 0x0d, 0xc8
|
2009-05-28 18:27:08 +00:00
|
|
|
};
|
mkamsboot: prevents 2 potential problems
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
2010-02-19 14:10:26 +00:00
|
|
|
unsigned char dualboot_m200v4[212] = {
|
2010-03-04 00:08:53 +00:00
|
|
|
0xc0, 0xf0, 0x9f, 0xe5, 0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea,
|
|
|
|
|
0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea,
|
2009-05-28 18:27:08 +00:00
|
|
|
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
|
mkamsboot: prevents 2 potential problems
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
2010-02-19 14:10:26 +00:00
|
|
|
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x24, 0x00, 0x1f, 0xe5,
|
|
|
|
|
0x24, 0x10, 0x1f, 0xe5, 0x01, 0x20, 0x40, 0xe0, 0x18, 0x30, 0x1f, 0xe5, 0x01, 0x40, 0x50, 0xe4,
|
|
|
|
|
0x01, 0x40, 0x43, 0xe4, 0x00, 0x00, 0x52, 0xe1, 0xfb, 0xff, 0xff, 0x1a, 0x2c, 0x30, 0x0f, 0xe5,
|
|
|
|
|
0x64, 0x00, 0x9f, 0xe5, 0x00, 0x10, 0x90, 0xe5, 0x01, 0x18, 0x81, 0xe3, 0x00, 0x10, 0x80, 0xe5,
|
|
|
|
|
0x58, 0x00, 0x9f, 0xe5, 0x20, 0x10, 0xa0, 0xe3, 0x00, 0x14, 0x80, 0xe5, 0x80, 0x10, 0x80, 0xe5,
|
|
|
|
|
0x04, 0x20, 0x90, 0xe5, 0x00, 0x00, 0x52, 0xe3, 0x02, 0x00, 0x00, 0x1a, 0x64, 0x00, 0x1f, 0xe5,
|
|
|
|
|
0x64, 0x10, 0x1f, 0xe5, 0x01, 0x00, 0x00, 0xea, 0x78, 0x00, 0x1f, 0xe5, 0x78, 0x10, 0x1f, 0xe5,
|
|
|
|
|
0x70, 0x30, 0x1f, 0xe5, 0x02, 0x50, 0x83, 0xe2, 0x01, 0x40, 0x43, 0xe0, 0x01, 0x20, 0x50, 0xe4,
|
|
|
|
|
0x01, 0x20, 0x43, 0xe4, 0x04, 0x00, 0x53, 0xe1, 0xfb, 0xff, 0xff, 0x1a, 0x01, 0x00, 0x83, 0xe2,
|
|
|
|
|
0x00, 0x20, 0xa0, 0xe3, 0x15, 0xff, 0x2f, 0xe1, 0x3c, 0x00, 0x00, 0x00, 0x14, 0x00, 0x0f, 0xc8,
|
|
|
|
|
0x00, 0x00, 0x0b, 0xc8
|
2009-05-28 18:27:08 +00:00
|
|
|
};
|
mkamsboot: prevents 2 potential problems
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
2010-02-19 14:10:26 +00:00
|
|
|
unsigned char dualboot_fuze[236] = {
|
2010-03-04 00:08:53 +00:00
|
|
|
0xd4, 0xf0, 0x9f, 0xe5, 0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea,
|
|
|
|
|
0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea,
|
2009-05-28 18:27:08 +00:00
|
|
|
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
|
mkamsboot: prevents 2 potential problems
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
2010-02-19 14:10:26 +00:00
|
|
|
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x24, 0x00, 0x1f, 0xe5,
|
|
|
|
|
0x24, 0x10, 0x1f, 0xe5, 0x01, 0x20, 0x40, 0xe0, 0x18, 0x30, 0x1f, 0xe5, 0x01, 0x40, 0x50, 0xe4,
|
|
|
|
|
0x01, 0x40, 0x43, 0xe4, 0x00, 0x00, 0x52, 0xe1, 0xfb, 0xff, 0xff, 0x1a, 0x2c, 0x30, 0x0f, 0xe5,
|
|
|
|
|
0x78, 0x00, 0x9f, 0xe5, 0x00, 0x10, 0x90, 0xe5, 0x01, 0x18, 0x81, 0xe3, 0x00, 0x10, 0x80, 0xe5,
|
|
|
|
|
0x6c, 0x00, 0x9f, 0xe5, 0x00, 0x10, 0xa0, 0xe3, 0x00, 0x14, 0x80, 0xe5, 0x20, 0x10, 0x90, 0xe5,
|
|
|
|
|
0x00, 0x00, 0x51, 0xe3, 0x08, 0x00, 0x00, 0x1a, 0x58, 0x00, 0x9f, 0xe5, 0x00, 0x10, 0xa0, 0xe3,
|
|
|
|
|
0x00, 0x14, 0x80, 0xe5, 0x20, 0x10, 0x90, 0xe5, 0x00, 0x00, 0x51, 0xe3, 0x02, 0x00, 0x00, 0x0a,
|
|
|
|
|
0x78, 0x00, 0x1f, 0xe5, 0x78, 0x10, 0x1f, 0xe5, 0x01, 0x00, 0x00, 0xea, 0x8c, 0x00, 0x1f, 0xe5,
|
|
|
|
|
0x8c, 0x10, 0x1f, 0xe5, 0x84, 0x30, 0x1f, 0xe5, 0x02, 0x50, 0x83, 0xe2, 0x01, 0x40, 0x43, 0xe0,
|
|
|
|
|
0x01, 0x20, 0x50, 0xe4, 0x01, 0x20, 0x43, 0xe4, 0x04, 0x00, 0x53, 0xe1, 0xfb, 0xff, 0xff, 0x1a,
|
|
|
|
|
0x01, 0x00, 0x83, 0xe2, 0x00, 0x20, 0xa0, 0xe3, 0x15, 0xff, 0x2f, 0xe1, 0x3c, 0x00, 0x00, 0x00,
|
|
|
|
|
0x14, 0x00, 0x0f, 0xc8, 0x00, 0x00, 0x0b, 0xc8, 0x00, 0x00, 0x0d, 0xc8
|
2009-05-28 18:27:08 +00:00
|
|
|
};
|
mkamsboot: prevents 2 potential problems
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
2010-02-19 14:10:26 +00:00
|
|
|
unsigned char dualboot_clipv2[280] = {
|
2010-03-04 00:08:53 +00:00
|
|
|
0x00, 0xf1, 0x9f, 0xe5, 0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea,
|
|
|
|
|
0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea,
|
2009-05-28 18:27:08 +00:00
|
|
|
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
|
mkamsboot: prevents 2 potential problems
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
2010-02-19 14:10:26 +00:00
|
|
|
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x24, 0x00, 0x1f, 0xe5,
|
|
|
|
|
0x24, 0x10, 0x1f, 0xe5, 0x01, 0x20, 0x40, 0xe0, 0x18, 0x30, 0x1f, 0xe5, 0x01, 0x40, 0x50, 0xe4,
|
|
|
|
|
0x01, 0x40, 0x43, 0xe4, 0x00, 0x00, 0x52, 0xe1, 0xfb, 0xff, 0xff, 0x1a, 0x2c, 0x30, 0x0f, 0xe5,
|
|
|
|
|
0xa4, 0x00, 0x9f, 0xe5, 0x00, 0x10, 0x90, 0xe5, 0x01, 0x18, 0x81, 0xe3, 0x00, 0x10, 0x80, 0xe5,
|
|
|
|
|
0x98, 0x00, 0x9f, 0xe5, 0x00, 0x10, 0xa0, 0xe3, 0x00, 0x14, 0x80, 0xe5, 0x00, 0x11, 0x90, 0xe5,
|
|
|
|
|
0x00, 0x00, 0x51, 0xe3, 0x13, 0x00, 0x00, 0x1a, 0x84, 0x00, 0x9f, 0xe5, 0x38, 0x10, 0xa0, 0xe3,
|
|
|
|
|
0x00, 0x14, 0x80, 0xe5, 0x08, 0x10, 0xa0, 0xe3, 0x20, 0x10, 0x80, 0xe5, 0x10, 0x10, 0xa0, 0xe3,
|
|
|
|
|
0x40, 0x10, 0x80, 0xe5, 0x20, 0x10, 0xa0, 0xe3, 0x80, 0x10, 0x80, 0xe5, 0x00, 0x10, 0xa0, 0xe3,
|
|
|
|
|
0x40, 0x10, 0x80, 0xe5, 0x05, 0x10, 0xa0, 0xe3, 0x01, 0x10, 0x51, 0xe2, 0xfd, 0xff, 0xff, 0x1a,
|
|
|
|
|
0x04, 0x10, 0x90, 0xe5, 0x00, 0x00, 0x51, 0xe3, 0x02, 0x00, 0x00, 0x0a, 0xa4, 0x00, 0x1f, 0xe5,
|
|
|
|
|
0xa4, 0x10, 0x1f, 0xe5, 0x01, 0x00, 0x00, 0xea, 0xb8, 0x00, 0x1f, 0xe5, 0xb8, 0x10, 0x1f, 0xe5,
|
|
|
|
|
0xb0, 0x30, 0x1f, 0xe5, 0x02, 0x50, 0x83, 0xe2, 0x01, 0x40, 0x43, 0xe0, 0x01, 0x20, 0x50, 0xe4,
|
|
|
|
|
0x01, 0x20, 0x43, 0xe4, 0x04, 0x00, 0x53, 0xe1, 0xfb, 0xff, 0xff, 0x1a, 0x01, 0x00, 0x83, 0xe2,
|
|
|
|
|
0x00, 0x20, 0xa0, 0xe3, 0x15, 0xff, 0x2f, 0xe1, 0x3c, 0x00, 0x00, 0x00, 0x14, 0x00, 0x0f, 0xc8,
|
|
|
|
|
0x00, 0x00, 0x0b, 0xc8, 0x00, 0x00, 0x0e, 0xc8
|
2009-05-28 18:27:08 +00:00
|
|
|
};
|
mkamsboot: prevents 2 potential problems
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
2010-02-19 14:10:26 +00:00
|
|
|
unsigned char dualboot_clipplus[216] = {
|
2010-03-04 00:08:53 +00:00
|
|
|
0xc0, 0xf0, 0x9f, 0xe5, 0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea,
|
|
|
|
|
0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea,
|
2010-01-13 03:05:29 +00:00
|
|
|
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
|
mkamsboot: prevents 2 potential problems
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
2010-02-19 14:10:26 +00:00
|
|
|
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x24, 0x00, 0x1f, 0xe5,
|
|
|
|
|
0x24, 0x10, 0x1f, 0xe5, 0x01, 0x20, 0x40, 0xe0, 0x18, 0x30, 0x1f, 0xe5, 0x01, 0x40, 0x50, 0xe4,
|
|
|
|
|
0x01, 0x40, 0x43, 0xe4, 0x00, 0x00, 0x52, 0xe1, 0xfb, 0xff, 0xff, 0x1a, 0x2c, 0x30, 0x0f, 0xe5,
|
|
|
|
|
0x64, 0x00, 0x9f, 0xe5, 0x00, 0x10, 0x90, 0xe5, 0x01, 0x18, 0x81, 0xe3, 0x00, 0x10, 0x80, 0xe5,
|
|
|
|
|
0x58, 0x00, 0x9f, 0xe5, 0x20, 0x10, 0x90, 0xe5, 0x54, 0x00, 0x9f, 0xe5, 0x08, 0x20, 0x90, 0xe5,
|
|
|
|
|
0x01, 0x20, 0x82, 0xe1, 0x00, 0x00, 0x52, 0xe3, 0x02, 0x00, 0x00, 0x1a, 0x64, 0x00, 0x1f, 0xe5,
|
|
|
|
|
0x64, 0x10, 0x1f, 0xe5, 0x01, 0x00, 0x00, 0xea, 0x78, 0x00, 0x1f, 0xe5, 0x78, 0x10, 0x1f, 0xe5,
|
|
|
|
|
0x70, 0x30, 0x1f, 0xe5, 0x02, 0x50, 0x83, 0xe2, 0x01, 0x40, 0x43, 0xe0, 0x01, 0x20, 0x50, 0xe4,
|
|
|
|
|
0x01, 0x20, 0x43, 0xe4, 0x04, 0x00, 0x53, 0xe1, 0xfb, 0xff, 0xff, 0x1a, 0x01, 0x00, 0x83, 0xe2,
|
|
|
|
|
0x00, 0x20, 0xa0, 0xe3, 0x15, 0xff, 0x2f, 0xe1, 0x3c, 0x00, 0x00, 0x00, 0x14, 0x00, 0x0f, 0xc8,
|
|
|
|
|
0x00, 0x00, 0x0d, 0xc8, 0x00, 0x00, 0x0b, 0xc8
|
2010-01-13 03:05:29 +00:00
|
|
|
};
|
2010-02-26 13:55:17 +00:00
|
|
|
unsigned char dualboot_fuzev2[236] = {
|
2010-03-04 00:08:53 +00:00
|
|
|
0xd4, 0xf0, 0x9f, 0xe5, 0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea,
|
|
|
|
|
0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea, 0xfe, 0xff, 0xff, 0xea,
|
2010-02-26 13:55:17 +00:00
|
|
|
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
|
|
|
|
|
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x24, 0x00, 0x1f, 0xe5,
|
|
|
|
|
0x24, 0x10, 0x1f, 0xe5, 0x01, 0x20, 0x40, 0xe0, 0x18, 0x30, 0x1f, 0xe5, 0x01, 0x40, 0x50, 0xe4,
|
|
|
|
|
0x01, 0x40, 0x43, 0xe4, 0x00, 0x00, 0x52, 0xe1, 0xfb, 0xff, 0xff, 0x1a, 0x2c, 0x30, 0x0f, 0xe5,
|
|
|
|
|
0x78, 0x00, 0x9f, 0xe5, 0x00, 0x10, 0x90, 0xe5, 0x01, 0x18, 0x81, 0xe3, 0x00, 0x10, 0x80, 0xe5,
|
|
|
|
|
0x6c, 0x00, 0x9f, 0xe5, 0x00, 0x10, 0xa0, 0xe3, 0x00, 0x14, 0x80, 0xe5, 0x20, 0x10, 0x90, 0xe5,
|
|
|
|
|
0x00, 0x00, 0x51, 0xe3, 0x08, 0x00, 0x00, 0x1a, 0x58, 0x00, 0x9f, 0xe5, 0x00, 0x10, 0xa0, 0xe3,
|
|
|
|
|
0x00, 0x14, 0x80, 0xe5, 0x20, 0x10, 0x90, 0xe5, 0x00, 0x00, 0x51, 0xe3, 0x02, 0x00, 0x00, 0x1a,
|
|
|
|
|
0x78, 0x00, 0x1f, 0xe5, 0x78, 0x10, 0x1f, 0xe5, 0x01, 0x00, 0x00, 0xea, 0x8c, 0x00, 0x1f, 0xe5,
|
|
|
|
|
0x8c, 0x10, 0x1f, 0xe5, 0x84, 0x30, 0x1f, 0xe5, 0x02, 0x50, 0x83, 0xe2, 0x01, 0x40, 0x43, 0xe0,
|
|
|
|
|
0x01, 0x20, 0x50, 0xe4, 0x01, 0x20, 0x43, 0xe4, 0x04, 0x00, 0x53, 0xe1, 0xfb, 0xff, 0xff, 0x1a,
|
|
|
|
|
0x01, 0x00, 0x83, 0xe2, 0x00, 0x20, 0xa0, 0xe3, 0x15, 0xff, 0x2f, 0xe1, 0x3c, 0x00, 0x00, 0x00,
|
|
|
|
|
0x14, 0x00, 0x0f, 0xc8, 0x00, 0x00, 0x0b, 0xc8, 0x00, 0x00, 0x0d, 0xc8
|
|
|
|
|
};
|