Re: apex-1.3.31 and sercomm flash header

[Marc Singer <elf@buici.com>]

On Sat, Aug 05, 2006 at 09:54:49PM +0930, Rod Whitby wrote:
> Martin Michlmayr wrote:
> > * Rod Whitby <rod@whitby.id.au> [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
> *)(FLASH_ADDR_BASE+KERNEL_CODE_OFFSET);
> 
>   diag_printf("copy kernel code from flash to RAM\n");
>   memcpy((unsigned char *)KERNEL_RAM_ADDRESS,(unsigned char *)
>         (FLASH_ADDR_BASE+KERNEL_CODE_OFFSET+0x10),fileSize);
> 
>   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);

So then this is the evil line.  If means that this particular memory
location must return something that doesn't crash redboot.

>   diag_printf("copy ramdisk file from flash to RAM\n");
>   memcpy((unsigned char *)RAMDISK_RAM_ADDRESS,(unsigned char *)
>         (FLASH_ADDR_BASE+RAMDISK_OFFSET+0x10),fileSize);
> }
> 
> 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
> fatal.

Seems like we can still make the apex partition be a single block.  We
just need to make sure that the block from where the ramdisk is copied
(FLASH_ADDR_BASE) contains a reasonable length word.

There doesn't seem to be any reason not to put the kernel at this
offset.  We can leave the other space free and, perhaps, allocate it
for something else in the future.

I'm also inclined to leave the APEX environment in the final flash
block.  That way, we can repurpose this 1M-(64K|128K) of space at some
time in the future without impacting the rest of the system.

Cheers.