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

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

On Nov 22,  7:55pm, cs/internet////////RFC-822/cs#a#emlix#f#com@hemloc wrote:
> Subject: Re: [linuxsh-dev] How to use an initrd?
> Hi Stuart,
> 
> On Thu, 22 Nov 2001, Stuart Menefy wrote:
> 
> [..]
> > 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.

It is however parsed in drivers/block/rd.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.

Sorry, my mistake. I should have said Documentation/ramdisk.txt. What
I was referring to was simply the bit at the end which describes how
to create the ramdisk image.

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

If you are using the compressed kernel, then one of the things which
happens while compressing the kernel code, is that the ezp gets stripped
off. Have a look for the objcopy in arch/sh/boot/compressed/Makefile.

Either:
 - boot the uncompressed kernel
 - modify the Makefile to not strip ezp (and remember to change the 
   initial value of output_ptr to reflect the fact that the kernel should
   be decompressed lower into memory)
 - hack misc.c to init the ezp
 - or get your loader to initialise ezp.

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

This code was origionally written to support loading of a ramdisk from
a floppy disk. So rd_image_start is the offset (in blocks) into the device
which holds the ramdisk image. For an initrd image this must be 0.

This is initialised in arch/sh/kernel/setup.c from RAMDISK_FLAGS, which
is read from ezp + 0x04.

So if your ezp is not being set up, I suspect this value is ending up
as non-zero, and when trying to decompress the ramdisk image the kernel
is not looking at the beginning of the image but at some offset into it.

Stuart