Re: initrd problems

On Fri, Jan 19, 2001 at 12:22:43PM -0500, S?bastien C?t? wrote:

Matt Porter wrote:

quoted

quoted

I was also wondering if I loaded the kernel correctly.  I put my
zImage+initrd (zvmlinux.initrd) at address 0 of ram.  Since I compiled
the kernel with debug symbols, it takes a few Megs... Could it be too
large for it's own good?  Maybe somebody knows about the answer to that
one!

What does the bootloader show when it relocates the zImage and initrd?
How about a progress dump so we have something to help you with?  You
make some comments about not using a special bootloader then say
you are loading a zImage (from the Sandpoint port) which does have
a relocating bootloader.  This smells like a custom board port where
you've gutted or dropped a bootloader and don't have the r3-r6 set
up correctly for entry into arch/ppc/kernel/head.S.  Are you really
just dropping vmlinux at address 0?  Details details...

I'll try to see what happens when the image is moved now that I know
this might be the problem, but my stupid debugger isn't friendly at all
and it's very difficult to do so.

Get a BDI2000, http://www.abatron.ch

I tought the image wouldn't be moved if I placed it a address 0.  I copy
my zvmlinux.initrd at this address so I tought it wouldn't be used.
This is indeed a custom board and I'm really just dropping vmlinux at
address 0.

This doesn't make a bit of sense.  Either you are placing a
zvmlinux.initrd image which contains a relocating bootloader at 0 or
you are placing the uncompressed vmlinux kernel at 0.  Which is it?

I also found out that the values of initrd_start and initrd_end aren't
valid when assigned from r4 and r5, so something must be overwriting
these values (intrd_end is smaller than initrd_start)

The initrd will be overwritten by kernel data structures if you don't
relocate it to a safe place.  If your r4/initrd_start and r5/initrd_end
reflect that place then (with Mark's patch to the stock Sandpoint
code) the kernel ramdisk/initrd driver will be able to find the image.

What's the use for r3?  I read it's board identification but I don't
really care if my board isn't identified correctly (for now at least).
A looked for documentation about this but couldn't find any (the booting
process of linux on a PowerPc seems to be terribly undocumented)

The kernel entry state for various platforms is fully documented in
arch/ppc/kernel/head.S.  It's of no use to your custom board port.

I've done this many times for custom board ports.  Have your JTAG
probe configure the memory controller.  You then simply drop
your vmlinux at physical 0.  Take your separate initrd image and
drop it at a safe place like 0x800000.  Use the JTAG probe to set
r4 to 0x800000 and r5 to 0x800000 + (<initrd_size> - 1).  Go at
0 and you'll boot then root from your initrd.

Put it all in a script for your JTAG probe or do it right and modify
the spruceboot or pmonboot bootloaders from linuxppc_2_5 and do it
right the first time.

--
Matt Porter
MontaVista Software, Inc.
mporter@mvista.com

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Matt Porter wrote:

I've done this many times for custom board ports.  Have your JTAG
probe configure the memory controller.  You then simply drop
your vmlinux at physical 0.  Take your separate initrd image and
drop it at a safe place like 0x800000.  Use the JTAG probe to set
r4 to 0x800000 and r5 to 0x800000 + (<initrd_size> - 1).  Go at
0 and you'll boot then root from your initrd.

Ok, now this is exactly what I do.  The initrd doesn't get overwritten
anymore.  The function mount_root is called, the root device is opened
but I get a panic at:

	sb = get_super(ROOT_DEV);
	if (sb) { goto mount_it}
	...

	read_unlock(&file_systems_lock);
	panic("VFS: Unable to mount root fs on %s", kdevname(ROOT_DEV));

ROOT_DEV = 0x100 (RAM)

However, when I get to this point initrd_start is equal to 0.  I'm not
sure if this is ok, it could have been set to 0 by initrd_release but
I'm not sure.  I'm still fighting with the debugger to step into that
part of the code.

Still, this is better than what I had last week.  Thanks for your help!

Sébastien Côté

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Sébastien Côté wrote:

Ok, now this is exactly what I do.  The initrd doesn't get overwritten
anymore.  The function mount_root is called, the root device is opened
but I get a panic at:

        sb = get_super(ROOT_DEV);
        if (sb) { goto mount_it}
        ...

        read_unlock(&file_systems_lock);
        panic("VFS: Unable to mount root fs on %s", kdevname(ROOT_DEV));

You'll also get this error if your kernel has not been built with
support for the filesystem (e.g. ext2) contained on your initrd.

Good luck, Kyle.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Kyle Harris wrote:

Sébastien Côté wrote:

quoted

Ok, now this is exactly what I do.  The initrd doesn't get overwritten
anymore.  The function mount_root is called, the root device is opened
but I get a panic at:

        sb = get_super(ROOT_DEV);
        if (sb) { goto mount_it}
        ...

        read_unlock(&file_systems_lock);
        panic("VFS: Unable to mount root fs on %s", kdevname(ROOT_DEV));

You'll also get this error if your kernel has not been built with
support for the filesystem (e.g. ext2) contained on your initrd.

Unfortunately, that's not the problem.  I get the same error if I point
r4 (initrd_start) to an invalid value so I guess the problem must be
with initrd.  Maybe initrd_start shouldn't be 0 when I get to that
point, now I just need to find why it changed!


Thanks anyway,

Sébastien Côté

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/