Re: [linuxsh-dev] How to use an initrd?

[Stuart M. <Stu...@st...>]

On Nov 21,  9:42pm, cs/internet////////RFC-822/cs#a#emlix#f#com@hemloc wrote:
> Subject: Re: [linuxsh-dev] How to use an initrd?
> Hi Stuart,
> 
> many thanks for the detailed help. Still some questions, s. below:
> 
> On Wed, 21 Nov 2001, Stuart Menefy wrote:
> 
> > Cord
> > 
> > Its pretty simple. Assuming you have a ramdisk image, you simply need
> > to load it into memory, and tell the kernel where it is:
> > 
> >  - loading will depend on what tools you are using to download your kernel.
> >    If you have a loader which supports the downloading of binary files,
> >    that it simple. If you are using a tool like gdb, which only supports
> >    the downloading of elf files, or a loader which can only use S-records
> >    or similar, ld or objcopy can be used to convert to the appropriate
> >    format.
> 
> I've to use S-records, which I generate with objcopy. But the loader only
> permits one upload with one start address. Guess, I've to combine two
> S-records into one file. That should work, shouldn't it?

Yep, S-records have the address for each line, so simply concatinating
them should work fine.

> >    The image needs to be loaded into memory which the kernel knows about,
> >    so don't try and load the image into what, for the kernel's point of
> >    view, is unused memory.
> 
> The address is not important? I.e. right after the compressed image or near
> the upper limit of RAM? How does the kernel know where to move the
> uncompressed data to? Can it be compressed at all? At offset 0x14 below, the
> initrd size corresponds to the image in RAM after uploading, doesn't it?

Correct, the address is not important. However it does need to be above
the kernel text and data, plus the kernel's page map, so near the top of
memory is good.

The way this works:
 - kernel sets up free page list for the whole of memory. Initially all
   pages are free, so the next thing it does is mark the kernel code and
   data pages, plus the pages the page list itself occupies, as in use.
 - the kernel then marks the initrd memory as in use (which is why it needs
   to be part of the known memory map).
 - the image is then decompressed, pages for the decompressed image just
   being allocated as normal from the free page list.
 - finally the initrd memory is marked as free

So the decompressed image can be anywhere in memory, you don't need to
known or care.

Yes, it can be compressed, just use gzip.

The initrd size at offset 0x14 corrisponds to the compressed size (it
is this which is used to mark the initrd pages as occupied in the second
step above).

One thing I did forget to mention, which may be causing some confusion.
The final ram disk size is fixed (ie it does not expand to accomodate
whatever data you put in it), although the memory it occupies is only
allocated as required.

The default size is chosen when you configure the kernel
(CONFIG_BLK_DEV_RAM_SIZE) and is usually 4M. However it can also be
overridden from the kernel command line with the "ramdisk_size=xxx" option,
where xxx is the size in K.

One other thing I should have mentioned. There is a good description
of how to create the initrd image in Documentation/initrd.txt in the
kernel source tree.


> >  - telling the kernel where the image is simply involves modifying
> >    a few workds of memory near the start of the kernel image. These
> >    corrispond to the C symbol empty_zero_page, which is 4K from the
> >    start of kernel memory:
> > 
> >       empty_zero_page + 0x00: mount root read only
> >                       + 0x04: ramdisk flags
> >                       + 0x08: root device
> >                       + 0x0c: loader type
> >                       + 0x10: initrd start
> >                       + 0x14: initrd size
> >                       + 0x100: kernel command line
> > 
> >    The only words you should need to modify are:
> >      + 0x0c: loader type - set to 1
> >      + 0x10: initrd start - set to the offset of the image from the start
> >              of kernel memory (CONFIG_MEMORY_START)
> >      + 0x14: initrd size - size of the initrd image
> 
> Yes, I've found the ezp, but I thought it would be more difficult ;-)
> 
> >    Again, how you do this depends of what tools you are using. You might
> >    want to have a look at the gdb start up scripts which are part of the
> >    CVS kernel sources, in the root of the kernel sources - .gdbinit-dmida
> >    is a well commented example.
> 
> I'll look at it.
> 
> > Hope this helps
> 
> Definitely. Thanks again!
> 	Cord
> 
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsh-dev
> 
> 
>-- End of excerpt from cs/internet////////RFC-822/cs#a#emlix#f#com@hemloc