Re: Ramdisk image on flash.

[Dan Malek <dan@embeddededge.com>]

Tibor Polgar wrote:

> The original poster wanted a setup where the initrd was NOT part of the
> kernel, which begs the question of how/where it would be put into flash so
> something could load/uncompress it. 

I regularly do this with compressed kernels (zImage) on PowerPC, ARM, and
Alchemy MIPS processors.  I attach the compressed ramdisk to the zImage,
usually with "cat" and some shell scripts.  The zImage uncompressor code
will relocate the ramdisk (and potentially ask for additional kernel
command line parameters) and will tell the kernel where the ramdisk is
located.  I don't have to recompile the kernel to do this, and best of
all it doesn't require any special boot rom knowledge of the image.  It
works with all boot roms that can load a binary image into a memory location
(not everyone uses RedBoot) :-)  Another advantage is exactly the same
image that you repeatedly test by loading over tftp or with a debugger
can be written into flash memory without modification.  It removes the
need to actually have to write to flash to test the image that will be
eventually written to flash.  You just jump to the start of the image to
uncompress/relocate/initialize/jump to kernel regardless of where it
is located.

When using ramdisks from flash, you must relocate them to RAM because the
kernel thinks it can add the pages used by the compressed ramdisk into the
free pool once the ramdisk is uncompressed into the file system cache.  The
uncompressor code I mentioned above will test the start address of the
image and copy it to ram if necessary.

There are a couple of things keeping me from making a patch for the MIPS
kernel.  This method is in conflict with the "compiled in" ramdisk method,
and reserving the "bootmem" pages to ensure the kernel doesn't allocate the
compressed ramdisk pages before they are freed doesn't work well compared
to other architectures.  I'm still running on luck with this latter problem,
but I think I can fix it.  I don't know yet what to do about the conflicts
and assumptions made about the compiled-in ramdisk.

Thanks.


	-- Dan