initrd problems

initrd problems

[Anders Blomdell]

I have created a compressed ramdisk of the root I'm currently using as NFS
root for my embedded system. When I try to boot it with the following boot
arguments:

   Linux/PPC load: console=ttyS0,9600 root=/dev/ram rw

it fails with:

   RAMDISK: Compressed image found at block 0
   Freeing initrd memory: 361k freed
   Kernel panic: VFS: Unable to mount root fs on 01:00

Anything very obvious that is wrong?

Regards

Anders Blomdell

------------------------------------------------------------------------------
  Anders Blomdell
  Department of Automatic Control        Email: anders.blomdell@control.lth.
se
  Lund Institute of Technology           Phone: +46 46 222 4625
  Box 118, S-221 00 Lund, Sweden         Fax:   +46 46 138118


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

Re: initrd problems

[Wolfgang Denk]

In message <ACFC1B4A-EC24-11D6-8213-0003931C2BFA@control.lth.se> you wrote:
>
>    RAMDISK: Compressed image found at block 0
>    Freeing initrd memory: 361k freed
>    Kernel panic: VFS: Unable to mount root fs on 01:00
>
> Anything very obvious that is wrong?

Are you sure you have support for initial ramdisk (CONFIG_BLK_DEV_RAM
+ CONFIG_BLK_DEV_INITRD) aneabled in your kernel  configuration?  And
support for the filesystem type used in your ramdisk image?

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Nothing is easier than to denounce  the  evildoer;  nothing  is  more
difficult than to understand him.                 - Fyodor Dostoevski

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

initrd problems

[Sriram Narasimhan]

Hello,

I am unable to boot up my linux with my ramdisk image.
Board: MPC8260 ADS
Kernel: 2.4.1
PPC Boot: 2.0.0

When I boot up the kernel without ramdisk, the same kernel image is
booting up fine.
But when I use a ramdisk

## Booting image at 00100000 ...
   Image Name:   Embedix for MPC8260ADS
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    531861 Bytes = 519.4 kB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at 00200000 ...
   Image Name:   Simple ramdisk Image
   Image Type:   PowerPC Linux RAMDisk Image (uncompressed)
   Data Size:    4194304 Bytes =  4 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Loading Ramdisk to 00b5e000, end 00f5e000 ... OK

I dont get any console output after this. I am not sure that it hangs,
because I see the ethernet link led's getting reset (same behaviour in
normal bootup) and the SCC controller leds getting enabled. (same
behaviour in normal boot up).

The command line passing into the kernel is:
" root=/dev/ram0 init=/linuxrc rw "
I believe PPC boot will pass the ramdisk start and end address along
with the above command line.
I have verified this also by checking the log_buff after I had reset the
board.

00145664: 3c343e72 343a2030 30623565 3030300a    <4>r4: 00b5e000.
00145674: 3c343e54 6f74616c 206d656d 6f727920    <4>Total memory
00145684: 3d203136 4d423b20 7573696e 67203634    = 16MB; using 64
00145694: 6b422066 6f722068 61736820 7461626c    kB for hash tabl
001456a4: 65202861 74206330 31383030 3030290a    e (at c0180000).
001456b4: 3c343e4c 696e7578 20766572 73696f6e    <4>Linux version
001456c4: 20322e34 2e312028 726f6f74 40656d62     2.4.1 (root@emb
001456d4: 65646978 29202867 63632076 65727369    edix) (gcc versi
001456e4: 6f6e2032 2e39352e 33203230 30313033    on 2.95.3 200103
001456f4: 31352028 72656c65 61736529 29202338    15 (release)) #8
00145704: 30205765 64204170 72203233 2031353a    0 Wed Apr 23 15:
00145714: 35393a32 37205554 43203230 30330a3c    59:27 UTC 2003.<
00145724: 343e4f6e 206e6f64 65203020 746f7461    4>On node 0 tota
00145734: 6c706167 65733a20 34303936 0a3c343e    lpages: 4096.<4>
00145744: 7a6f6e65 2830293a 20343039 36207061    zone(0): 4096 pa
00145754: 6765732e 0a3c343e 7a6f6e65 2831293a    ges..<4>zone(1):
00145764: 20302070 61676573 2e0a3c34 3e7a6f6e     0 pages..<4>zon
00145774: 65283229 3a203020 70616765 732e0a3c    e(2): 0 pages..<
00145784: 343e4b65 726e656c 20636f6d 6d616e64    4>Kernel command
00145794: 206c696e 653a202f 6465762f 00000000     line: /dev/....
001457a4: 00000000 00000000 00000000 00000000    ................
001457b4: 00000000 00000000 00000000 00000000    ................
001457c4: 00000000 00000000 00000000 00000000    ................
001457d4: 00000000 00000000 00000000 00000000    ................

The r4 register which points to the ramdisk start is also correct. So
PPC boot is passing the ramdisk parameter properly.
I unable to get any more output from the log_buff.

Also when I tried using a compressed image of the ramdisk, PPC boot
failed to uncompress it.
Can I provide a compressed image of the ramdisk to PPCBoot.?

Is there anything wrong that I am doing in setting up the ramdisk
environment ?

Any pointers or suggestions would be very useful.
Thank you.
Regards,
Sriram N


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

Re: initrd problems

[Wolfgang Denk]

In message <3EA776EC.3090805@tataelxsi.co.in> you wrote:
>
> ## Booting image at 00100000 ...
>    Image Name:   Embedix for MPC8260ADS
>    Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>    Data Size:    531861 Bytes = 519.4 kB
>    Load Address: 00000000
>    Entry Point:  00000000
>    Verifying Checksum ... OK
>    Uncompressing Kernel Image ... OK
> ## Loading RAMDisk Image at 00200000 ...
>    Image Name:   Simple ramdisk Image
>    Image Type:   PowerPC Linux RAMDisk Image (uncompressed)
>    Data Size:    4194304 Bytes =  4 MB
>    Load Address: 00000000
>    Entry Point:  00000000
>    Verifying Checksum ... OK
>    Loading Ramdisk to 00b5e000, end 00f5e000 ... OK

Try using higher load addresses, i.e. load the kernel  at  0x00200000
and the ramdisk at 0x00400000.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
A mouse is an elephant built by the Japanese.

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

initrd problems

[Sébastien Côté]

Hi,

I'm trying to boot Sandpoint linux on my board but I can't get initrd
to load.  I'm not using any special bootloader.

I compiled the kernel using make zImage.initrd (my initrd ramdisk is
smaller than 4 MB) and I added root=/dev/ram to the cmd_line in the
function sandpoint_setup_arch() from sandpoint_setup.c.  I know I
shouldn't have to do this (acording to the HOWTO), but I am so
clueless about the cause of the problem that I'm ready to try anything.

The kernel loads until the function mount_root() (in fs/super.c).
This is where it stops:

        retval = blkdev_get(bdev, mode, 0, BDEV_FS);
        if (retval == -EROFS) {
                root_mountflags |= MS_RDONLY;
                retval = blkdev_get(bdev, FMODE_READ, 0, BDEV_FS);
        }
        if (retval) {
                /*
                 * Allow the user to distinguish between failed open
                 * and bad superblock on root device.
                 */
                printk ("VFS: Cannot open root device \"%s\" or %s\n",
                        root_device_name, kdevname (ROOT_DEV));
                printk ("Please append a correct \"root=\" boot
option\n");
                panic("VFS: Unable to mount root fs on %s",
                        kdevname(ROOT_DEV));
        }

With the help of a debugger, I found out that:
root_device_name = ram
ROOT_DEV = 0x0100  /* which is ram according to init/main.c */

So if the root_device points to ram like it should, does anybody know
why it can't open the root device?

The kernel has been copied at address 0 of the RAM on the board along
with initrd (there's no hard-drive or flash, just ram).  Do I need to
set something before I launch the kernel?  I tought everything was setup
up correctly when I did make zImage.initrd ! (INITRD_OFFSET and
INITRD_SIZE should be set by make zImage.initrd, right?)

Any help would be appreciated !


Sébastien Côté

(Sorry if you received this e-mail twice but it didn't seem to go
through the first time)

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

Re: initrd problems

[Sébastien Côté]

I finally figured out a small part of the problem...  My initrd_start
was overwritten (to 0) by the function start_kernel in init/main.c :

#ifdef CONFIG_BLK_DEV_INITRD
	if (initrd_start && !initrd_below_start_ok &&
			initrd_start < min_low_pfn << PAGE_SHIFT) {
		printk(KERN_CRIT "initrd overwritten (0x%08lx < 0x%08lx) - "
		    "disabling it.\n",initrd_start,min_low_pfn << PAGE_SHIFT);
		initrd_start = 0;
	}
#endif

I don't really understand this function... Why would my initrd be
overwritten?!?  Anyways, I commented it out to see what would happen.
This time, it opened the root device (in function mount_root()) but
didn't go very far:

	sb = get_super(ROOT_DEV);
	if (sb) {
		fs_type = sb->s_type;
		goto mount_it;
	}
	...
	panic("VFS: Unable to mount root fs on %s", kdevname(ROOT_DEV));


sb is NULL.  Damn..  What now?  Is it possible that my initrd has been
erased like the kernel told me?  What else could it be?

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!

By the way, I forgot to mention it in the first email but I'm using
linux-2.4.0-test2.


Sébastien Côté

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

Re: initrd problems

[Matt Porter]

On Thu, Jan 18, 2001 at 05:27:18PM -0500, Sébastien Côté wrote:
>
> I finally figured out a small part of the problem...  My initrd_start
> was overwritten (to 0) by the function start_kernel in init/main.c :

<snip>

> I don't really understand this function... Why would my initrd be
> overwritten?!?  Anyways, I commented it out to see what would happen.

Because it's in the wrong place and the kernel is walking all over
it.  Usually because a bootloader couldn't handle relocating the
image to a safe place.

<snip>

> sb is NULL.  Damn..  What now?  Is it possible that my initrd has been
> erased like the kernel told me?  What else could it be?

Yes.

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

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

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

Re: initrd problems

[Sébastien Côté]

Matt Porter wrote:
> > 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.

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.

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)

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)

Thanks for your help,

Sébastien Côté

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

Re: initrd problems

[Matt Porter]

On Fri, Jan 19, 2001 at 12:22:43PM -0500, S?bastien C?t? wrote:
> Matt Porter wrote:
> > > 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/

Re: initrd problems

[Sébastien Côté]

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/

Re: initrd problems

[Kyle Harris]

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/

Re: initrd problems

[Sébastien Côté]

Kyle Harris wrote:
>
> 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.

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/

Re: initrd problems

[Mark A. Greer]

Where did you get this version of that kernel?  From the MontaVista CDK or from
the website?  If from the website, when did you get it?

Try this (if its not already done).  Go into arch/ppc/boot/head.S and add the
following lines after the set up of r6 to hold the cmd_line.

        /* r4,r5 have initrd_start, size */
        lis     r2,initrd_start@h
        ori     r2,r2,initrd_start@l
        lwz     r4,0(r2)
        lis     r2,initrd_end@h
        ori     r2,r2,initrd_end@l
        lwz     r5,0(r2)

Go into arch/ppc/kernel/sandpoint_setup.c.  Find sandpoint_setup_arch() and add
something like (again, if its not already there).

     #ifdef CONFIG_BLK_DEV_INITRD
             if (initrd_start)
                     ROOT_DEV = MKDEV(RAMDISK_MAJOR, 0);

       #endif

Try it now and see if that helps...

Mark
--


Sébastien Côté wrote:

> I finally figured out a small part of the problem...  My initrd_start
> was overwritten (to 0) by the function start_kernel in init/main.c :
>
> #ifdef CONFIG_BLK_DEV_INITRD
>         if (initrd_start && !initrd_below_start_ok &&
>                         initrd_start < min_low_pfn << PAGE_SHIFT) {
>                 printk(KERN_CRIT "initrd overwritten (0x%08lx < 0x%08lx) - "
>                     "disabling it.\n",initrd_start,min_low_pfn << PAGE_SHIFT);
>                 initrd_start = 0;
>         }
> #endif
>
> I don't really understand this function... Why would my initrd be
> overwritten?!?  Anyways, I commented it out to see what would happen.
> This time, it opened the root device (in function mount_root()) but
> didn't go very far:
>
>         sb = get_super(ROOT_DEV);
>         if (sb) {
>                 fs_type = sb->s_type;
>                 goto mount_it;
>         }
>         ...
>         panic("VFS: Unable to mount root fs on %s", kdevname(ROOT_DEV));
>
> sb is NULL.  Damn..  What now?  Is it possible that my initrd has been
> erased like the kernel told me?  What else could it be?
>
> 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!
>
> By the way, I forgot to mention it in the first email but I'm using
> linux-2.4.0-test2.
>
> Sébastien Côté
>

--
Mark A. Greer (mgreer@mvista.com; 480-517-0287)
MontaVista Software, Inc.
2141 E. Broadway Road, Suite 108
Tempe, AZ  85282


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

Re: initrd problems

[Sébastien Côté]

"Mark A. Greer" wrote:
>
> Where did you get this version of that kernel?  From the MontaVista CDK or from
> the website?  If from the website, when did you get it?

I'm pretty sure it came from the web..  I think it was downloaded at the
end of November but I can't be sure...  I could probably answer this
next week.

> Try this (if its not already done).  Go into arch/ppc/boot/head.S and add the
> following lines after the set up of r6 to hold the cmd_line.
>
>         /* r4,r5 have initrd_start, size */
>         lis     r2,initrd_start@h
>         ori     r2,r2,initrd_start@l
>         lwz     r4,0(r2)
>         lis     r2,initrd_end@h
>         ori     r2,r2,initrd_end@l
>         lwz     r5,0(r2)
>
> Go into arch/ppc/kernel/sandpoint_setup.c.  Find sandpoint_setup_arch() and add
> something like (again, if its not already there).
>
>      #ifdef CONFIG_BLK_DEV_INITRD
>              if (initrd_start)
>                      ROOT_DEV = MKDEV(RAMDISK_MAJOR, 0);
>
>        #endif
>

I tried that patch that I found in the list archives but it didn't make
any difference.


Sébastien Côté

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

Re: initrd problems

[Michael Pruznick]

I'd had a similar problem with a 2.5 kernel from late nov
or early dec.  I had to comment out the follow code from
init/main.c::do_basic_setup() to get it working.  I also
had to apply the head.S and <board>_setup.c file as
already mentioned in this thread.  I also played with devfs
support but don't remember if either enabled or disabled was
required.  I never followed up on this, but I suspect this
is a bad kludge and that there is a better way to solve this
problem.  Let me know if this works for you.

    718 #if 0
    719 #ifdef CONFIG_BLK_DEV_INITRD
    720         root_mountflags = real_root_mountflags;
    721         if (mount_initrd && ROOT_DEV != real_root_dev
    722             && MAJOR(ROOT_DEV) == RAMDISK_MAJOR && MINOR(ROOT_DEV) == 0) {
    723                 int error;
    724                 int i, pid;
    725
    726                 pid = kernel_thread(do_linuxrc, "/linuxrc", SIGCHLD);
    727                 if (pid>0)
    728                         while (pid != wait(&i));
    729                 if (MAJOR(real_root_dev) != RAMDISK_MAJOR
    730                      || MINOR(real_root_dev) != 0) {
    731                         error = change_root(real_root_dev,"/initrd");
    732                         if (error)
    733                                 printk(KERN_ERR "Change root to /initrd: "
    734                                     "error %d\n",error);
    735                 }
    736         }
    737 #endif
    738 #endif



Sébastien Côté wrote:
>
> "Mark A. Greer" wrote:
> >
> > Where did you get this version of that kernel?  From the MontaVista CDK or from
> > the website?  If from the website, when did you get it?
>
> I'm pretty sure it came from the web..  I think it was downloaded at the
> end of November but I can't be sure...  I could probably answer this
> next week.
>
> > Try this (if its not already done).  Go into arch/ppc/boot/head.S and add the
> > following lines after the set up of r6 to hold the cmd_line.
> >
> >         /* r4,r5 have initrd_start, size */
> >         lis     r2,initrd_start@h
> >         ori     r2,r2,initrd_start@l
> >         lwz     r4,0(r2)
> >         lis     r2,initrd_end@h
> >         ori     r2,r2,initrd_end@l
> >         lwz     r5,0(r2)
> >
> > Go into arch/ppc/kernel/sandpoint_setup.c.  Find sandpoint_setup_arch() and add
> > something like (again, if its not already there).
> >
> >      #ifdef CONFIG_BLK_DEV_INITRD
> >              if (initrd_start)
> >                      ROOT_DEV = MKDEV(RAMDISK_MAJOR, 0);
> >
> >        #endif
> >
>
> I tried that patch that I found in the list archives but it didn't make
> any difference.
>
> Sébastien Côté
>

--
Michael Pruznick, michael_pruznick@mvista.com, www.mvista.com
MontaVista Software, 1237 East Arques Ave, Sunnyvale, CA 94085

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