[Top] [All Lists]

Re: Ramdisk image on flash.

To: Dan Malek <>
Subject: Re: Ramdisk image on flash.
From: Jun Sun <>
Date: Thu, 20 Feb 2003 12:44:56 -0800
Cc: Tibor Polgar <>, Mark Salter <>,,,
In-reply-to: <>; from on Thu, Feb 20, 2003 at 03:35:15PM -0500
Original-recipient: rfc822;
References: <> <> <> <20030220194115.2A21378A6D@deneb.localdomain> <> <>
User-agent: Mutt/1.2.5i
On Thu, Feb 20, 2003 at 03:35:15PM -0500, Dan Malek wrote:
> 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.

Looks like you have the solution that I called for. :-)
> 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.

The compiled-in one uses a configure option.  Perhaps you can rely on that
to differentiate?  Once the new method get stable, I am in favor to 
covert all embedded ramdisk to the new one.


<Prev in Thread] Current Thread [Next in Thread>