Re: apex-1.3.31 and sercomm flash header
Martin Michlmayr wrote:
> * Rod Whitby <firstname.lastname@example.org> [2006-08-05 11:26]:
>> We also have the source code for the Linksys modifications to
>> RedBoot, so we can look at that to see if there is another way to
>> fool the Linksys RedBoot 'boot' command.
> If you can take a look and let me know how to fool it, I'll be glad to
> test it.
Here's the code from the Linksys RedBoot which is in the NSLU2:
void do_move(int argc, char *argv)
unsigned long fileSize = *(unsigned long
diag_printf("copy kernel code from flash to RAM\n");
memcpy((unsigned char *)KERNEL_RAM_ADDRESS,(unsigned char *)
load_address = KERNEL_RAM_ADDRESS;
load_address_end = KERNEL_RAM_ADDRESS + fileSize;
entry_address = KERNEL_RAM_ADDRESS;
fileSize = *(unsigned long *)(FLASH_ADDR_BASE+RAMDISK_OFFSET);
diag_printf("copy ramdisk file from flash to RAM\n");
memcpy((unsigned char *)RAMDISK_RAM_ADDRESS,(unsigned char *)
So there is an unconditional copy of the kernel and ramdisk, from fixed
locations in the flash (KERNEL_CODE_OFFSET+0x10 and
RAMDISK_OFFSET+0x10), with lengths given by the words at
KERNEL_CODE_OFFSET and RAMDISK_OFFSET respectively.
See http://www.nslu2-linux.org/wiki/Info/RedBootSequence for more details.
So as long as the size word at 0x50160000 is small enough, you can get
away with it (for the nslu2-linux custom firmware where we use jffs2
instead of a ramdisk, we just set the size to a single erase block
(128K) and redboot copies that empty block). If, however, you happen to
have all zeros in that location, or a very large number, it is usually