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

[Cord S. <cs...@em...>]

Hi Stuart,

On Thu, 22 Nov 2001, Stuart Menefy wrote:

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

Yes, works. I just need to manipulate S0 and S7 records.

> > >    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

That makes things more clear, thanks. But there're still problems (s. below).

> 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.

Ah, I had a closer look and found the autodetection routine.

> 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.

That option is *not* parsed in arch/sh/kernle/setup.c.

> 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.

Yes, I've found that, but was wondering how to set things up without the help
of a LILO.

> > >  - 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 ;-)

Besides all the great tips, initrd doesn't work for me....
Here's my empty_zero_page setup (arch/sh/kernel/head.S):

       .section		  .empty_zero_page, "aw"
ENTRY(empty_zero_page)
	.long	1		/* MOUNT_ROOT_RDONLY */
	.long	0		   /* RAMDISK_FLAGS */
	.long	0x0100		      /* ORIG_ROOT_DEV */
	.long	1			 /* LOADER_TYPE */
	.long	0x00300000		 /* INITRD_START */
	.long	0x00100000		 /* INITRD_SIZE */
	.long	0
	
#ifdef CONFIG_CMDLINE_BOOL
       .balign 0x100,0,0x100	/* COMMAND_LINE */
       .string "mem=16m console=ttyS0,115200n8 init=/bin/sh"
!      .string CONFIG_CMDLINE
#endif /* CONFIG_CMDLINE_BOOL */
       
       .balign 4096,0,4096

My problem is, that the ezp somehow is not filled correctly after
decompressing the kernel. I put a hexdump right at the top of
arch/sh/kernel/setup_arch() and there's still some text strings from the
bootloader... (no commandline either). Anyone an idea, why?

Therefore all initrd setup with INITRD_START, etc. goes wrong. But even if I
hardcode the above values to INITRD_START and INITRD_SIZE, which leads to
correct values in the calls to reserve_bootmem_node(), the loading fails. 

What I found ist that in initrd_load() the offset for rd_load_image() is taken
from rd_image_start, which in turn of the broken ezp is also broken. Why is
rd_image_start relevant for an initrd?

Any ideas? Thanks.

	Cord