How to load initramfs only on-demand?

[Woody Wu]

On Sunday, March 13, 2016, Greg KH <greg at kroah.com> wrote:

> On Sat, Mar 12, 2016 at 04:29:08PM +0800, Woody Wu wrote:
> > My question is, is there such a kernel parameter to do the job? Probably
> there
> > is a non-parameter solution like passing the initramfs address in a
> register
> > when a boot loader transfer control to the kernel, but this is not an
> option to
> > me since my boot loader (u-boot) does not support doing this. Thanks.
>
> You have the source to your bootloader, I suggest you fix that up to
> support this if you want it, not much the kernel can do on it's own
> here, sorry.
>
>
But the kernel document says,

External initramfs images:
--------------------------

If the kernel has initrd support enabled, an external cpio.gz archive can
also
be passed into a 2.6 kernel in place of an initrd.  In this case, the kernel
will autodetect the type (initramfs, not initrd) and extract the external
cpio
archive into rootfs before trying to run /init.

This has the memory efficiency advantages of initramfs (no ramdisk block
device) but the separate packaging of initrd (which is nice if you have
non-GPL code you'd like to run from initramfs, without conflating it with
the GPL licensed Linux kernel binary).

It can also be used to supplement the kernel's built-in initramfs image.
The
files in the external archive will overwrite any conflicting files in
the built-in initramfs archive.  Some distributors also prefer to customize
a single kernel image with task-specific initramfs images, without
recompiling.

So I am thinking, can I from my bootloader load a cpio.gz into ram and
start kernel with a command line "initrd=0x30000000"? Wii this work? And,
in this case should I also pass kernel with someilike "roo=/dev/ram"?
Thanks.

-woody


-- 
Life is the only flaw in an otherwise perfect nonexistence
    -- Schopenhauer

woody
public key at http://subkeys.pgp.net:11371 (narkewoody at gmail.com)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160313/cd9a0c64/attachment.html