Initrd and PPCbug, can it work?

Initrd and PPCbug, can it work?

[okorpil]

Hello!

Target hardware: MVME2100, MPC8240 microcontroller - PowerPC 603e CPU

I've successfully booted the Linux kernel via the netboot (NBO in PPCbug),
with a NFS root filesystem. I successfully booted the kernel from memory
(after NIOP) and from flash (RB, after I flashed it in the 4MB flash
bank with PFLASH).

All this was relying on NFS to give me the root filesystem, which worked
fine, but will not suffice in the long run, because the goal is to have it
boot as a standalone without a NFS root filesystem.

Yet I do not know how to accomplish that. I created both ext2 and cramfs
initial ramdisks (that mounted fine on the host), copied them into
arch/ppc/boot/images/ramdisk.image.gz, made make zImage.initrd and used
the images created by that.

Kernel bootup tells me, that it loaded the kernel and ramdisk and
relocated both, yet after the kernel boot finishes it fails (I guess when
it tries to mount a root filesystem). Bootlog is attached.

I've tried several variations of the kernel command line, but I am
stumped.

I thought I could use that zImage.initrd and keep the initial ram disk as
root filesystem, yet I do not know what the error in my config is.

Is this even possible with the PPCbug, or do I need a Linux-friendly
bootloader? I initially guessed, that if at bootup everything is
relocated, that would actually suffice, and no additional information from
the bootloader is required??

Thanks in advance,
Oliver Korpilla

My bootup output:

Network Boot File load in progress... To abort hit <BREAK>

Bytes Received =&1436351, Bytes Loaded =&1436351
Bytes/Second   =&718175, Elapsed Time =2 Second(s)

Residual-Data Located at: $01F5511C
loaded at:     00005400 001655BC
relocated to:  00800000 009601BC
zimage at:     008058B0 008C16FA
initrd at:     008C2000 0095D000
avail ram:     00400000 00800000

Linux/PPC load: console=ttyS0,9600 init=/linuxrc
Uncompressing Linux...done.
Now booting the kernel
Memory BAT mapping: BAT2=32Mb, BAT3=0Mb, residual: 0Mb
Linux version 2.4.25 (korpo@ppcproject1) (gcc version 2.95.3 20010315
(release)) #6 Wed Apr 21 14:44:36 CEST 2004
Platform: Motorola MVME2100
On node 0 totalpages: 8192
zone(0): 8192 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=ttyS0,9600 root=/dev/ram0 init=/linuxrc rw
OpenPIC Version 1.2 (1 CPUs and 16 IRQ sources) at f7fd0000
OpenPIC timer frequency is 8.333344 MHz
time_init: decrementer frequency = 16.666748 MHz
Calibrating delay loop... 133.12 BogoMIPS
Memory: 30392k available (1256k kernel code, 472k data, 252k init, 0k
highmem)
Dentry cache hash table entries: 4096 (order: 3, 32768 bytes)
Inode cache hash table entries: 2048 (order: 2, 16384 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
POSIX conformance testing by UNIFIX
PCI: Probing PCI hardware
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
JFFS2 version 2.1. (C) 2001 Red Hat, Inc., designed by Axis Communications
AB.
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ
SERIAL_PCI enabled
ttyS00 at 0xffe10000 (irq = 25) is a 16550A
Generic RTC Driver v1.07
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
Linux Tulip driver version 0.9.15-pre12 (Aug 9, 2002)
tulip0:  EEPROM default media type Autosense.
tulip0:  Index #0 - Media MII (#11) described by a 21142 MII PHY (3)
block.
tulip0:  MII transceiver #8 config 1000 status 7809 advertising 01e1.
eth0: Digital DS21143 Tulip rev 65 at 0xbfffec00, 00:01:AF:02:93:8C, IRQ
16.
pcnet32.c:v1.27a 10.02.2002 tsbogend@alpha.franken.de
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 2048 bind 2048)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
cramfs: wrong magic
Kernel panic: VFS: Unable to mount root fs on 01:00

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

Re: Initrd and PPCbug, can it work?

[Tom Rini]

On Wed, Apr 21, 2004 at 03:16:09PM +0200, okorpil@fh-landshut.de wrote:

> Hello!
>
> Target hardware: MVME2100, MPC8240 microcontroller - PowerPC 603e CPU
[snip]
> Is this even possible with the PPCbug, or do I need a Linux-friendly
> bootloader? I initially guessed, that if at bootup everything is
> relocated, that would actually suffice, and no additional information from
> the bootloader is required??

It works from PPCBug.  At least with cramfs, I _believe_ there is, or
has been a problem with creating an image on an LE machine for a BE
machine, and vice versa.  What happens when you try and use an ext2
ramdisk?

--
Tom Rini
http://gate.crashing.org/~trini/

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

Re: Initrd and PPCbug, can it work?

[Oliver Korpilla]

Tom Rini wrote:

>>Is this even possible with the PPCbug, or do I need a Linux-friendly
>>bootloader? I initially guessed, that if at bootup everything is
>>relocated, that would actually suffice, and no additional information from
>>the bootloader is required??
>>
>>
>
>It works from PPCBug.  At least with cramfs, I _believe_ there is, or
>has been a problem with creating an image on an LE machine for a BE
>machine, and vice versa.  What happens when you try and use an ext2
>ramdisk?
>
>
>
Tried this initially, and it didn't work - will try again, to supply you
with the exact messages later today (I'm not in work yet - lazy, lazy! :) )

The steps for my initrd image - AFAI can remember:

I made a file with

dd if=/dev/zero of=initrd.img bs=1k count=8192

(Made an ext2 on it, don't quite remember the command, but mounted ok!)

(as root)

mount --t ext2 -o loop initrd.img tmp/
cp -ar rootfs/ tmp
umount tmp/

(as me)
gzip -9 -c initrd.img > initrd.bin

(and copied it into the kernel dir)
cp initrd.bin <kernel_dir>/arch/ppc/boot/simple/images/ramdisk.image.gz
cd <kernel_dir>

make zImage.initrd


Is this correct, or is there anywhere a wrong assumption in between?

(Actually getting this ramdisk to boot seems to be getting more
important all the time, because the flash chip support in Memory
Technology Devices seems to be broken for good and so I cannot make a
flash fs like jffs2 over it, or a FTL-ext2... looks more and more I'm
running out of options :) )

Thanks and with kind regards,
Oliver Korpilla


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

Re: Initrd and PPCbug, can it work?

[Marius Groeger]

On Tue, 27 Apr 2004, Oliver Korpilla wrote:

> >>Is this even possible with the PPCbug, or do I need a Linux-friendly
> >>bootloader? I initially guessed, that if at bootup everything is
...
> >It works from PPCBug.  At least with cramfs, I _believe_ there is, or
> >has been a problem with creating an image on an LE machine for a BE
...
> Tried this initially, and it didn't work - will try again, to supply you
> with the exact messages later today (I'm not in work yet - lazy, lazy! :) )

Please do so. We're booting initrd images from PPC-Bug fine over here
(MVME2700), so I'd be interested in potential catches.

Regards,
Marius

--
Marius Groeger <mgroeger@sysgo.com>           Project Manager
SYSGO AG                      Embedded and Real-Time Software
Voice: +49 6136 9948 0                  FAX: +49 6136 9948 10
www.sysgo.com | www.elinos.com | www.osek.de | www.imerva.com


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

Re: Initrd and PPCbug, can it work?

[Oliver Korpilla]

Marius Groeger wrote:
>
> Please do so. We're booting initrd images from PPC-Bug fine over here
> (MVME2700), so I'd be interested in potential catches.
>
> Regards,
> Marius
>

Marius, would you be so kind to share with me, how you configured your
board, so that it boots from initrd? My problem seems to be a
configuration error, at least until proven otherwise...

My bootup with PPCbug is given below (look at the kernel commandline,
perhaps this is wrong, but I do not know how to set it reasonably).

The initrd image was made with ext2, copied over to
arch/ppc/boot/images/ramdisk.image.gz, and I made make zImage.initrd


With kind regards,
Oliver Korpilla

After entering NBO, it looks like this (NBO is set to load the
zImage.initrd):

Network Boot File load in progress... To abort hit <BREAK>

Bytes Received =&1276607, Bytes Loaded =&1276607
Bytes/Second   =&638303, Elapsed Time =2 Second(s)

Residual-Data Located at: $01F5511C
loaded at:     00005400 0013E5BC
relocated to:  00800000 009391BC
zimage at:     008058A0 008B7749
initrd at:     008B8000 009356B8
avail ram:     00400000 00800000

Linux/PPC load: console=ttyS0,9600 root=/dev/ram0
Uncompressing Linux...done.
Now booting the kernel
Memory BAT mapping: BAT2=32Mb, BAT3=0Mb, residual: 0Mb
Linux version 2.4.25 (korpo@ppcproject1) (gcc version 2.95.3 20010315
(release)) #18 Tue Apr 27 10:38:09 CEST 2004
Platform: Motorola MVME2100

On node 0 totalpages: 8192
zone(0): 8192 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=ttyS0,9600 root=/dev/ram0
OpenPIC Version 1.2 (1 CPUs and 16 IRQ sources) at f7fd0000
OpenPIC timer frequency is 8.333344 MHz
time_init: decrementer frequency = 16.666754 MHz
Calibrating delay loop... 133.12 BogoMIPS
Memory: 30488k available (1180k kernel code, 452k data, 252k init, 0k
highmem)
Dentry cache hash table entries: 4096 (order: 3, 32768 bytes)

Inode cache hash table entries: 2048 (order: 2, 16384 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
POSIX conformance testing by UNIFIX
PCI: Probing PCI hardware
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ
SERIAL_PCI enabled
ttyS00 at 0xffe10000 (irq = 25) is a 16550A

Generic RTC Driver v1.07
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
Linux Tulip driver version 0.9.15-pre12 (Aug 9, 2002)
tulip0:  EEPROM default media type Autosense.
tulip0:  Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block.
tulip0:  MII transceiver #8 config 1000 status 7809 advertising 01e1.
eth0: Digital DS21143 Tulip rev 65 at 0xbfffec00, 00:01:AF:02:93:8C, IRQ 16.
pcnet32.c:v1.27a 10.02.2002 tsbogend@alpha.franken.de
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 2048 bind 2048)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
cramfs: wrong magic
Kernel panic: VFS: Unable to mount root fs on 01:00
  <0>Rebooting in 180 seconds..

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

Re: Initrd and PPCbug, can it work?

[Marius Groeger]

On Tue, 27 Apr 2004, Oliver Korpilla wrote:

> The initrd image was made with ext2, copied over to
> arch/ppc/boot/images/ramdisk.image.gz, and I made make zImage.initrd
...
> TCP: Hash tables configured (established 2048 bind 2048)
> NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
> cramfs: wrong magic
> Kernel panic: VFS: Unable to mount root fs on 01:00
>   <0>Rebooting in 180 seconds..

Now -- is it cramfs or ext2 that you want to boot? It looks like you haven't
configured ext2 in your kernel!?

Regards,
Marius

--
Marius Groeger <mgroeger@sysgo.com>           Project Manager
SYSGO AG                      Embedded and Real-Time Software
Voice: +49 6136 9948 0                  FAX: +49 6136 9948 10
www.sysgo.com | www.elinos.com | www.osek.de | www.imerva.com


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

Re: Initrd and PPCbug, can it work?

[Oliver Korpilla]

Marius Groeger wrote:
> On Tue, 27 Apr 2004, Oliver Korpilla wrote:
>
>
>>TCP: Hash tables configured (established 2048 bind 2048)
>>NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
>>cramfs: wrong magic
>>Kernel panic: VFS: Unable to mount root fs on 01:00
>>  <0>Rebooting in 180 seconds..
>
>
> Now -- is it cramfs or ext2 that you want to boot? It looks like you haven't
> configured ext2 in your kernel!?
>

This was the first I checked - CONFIG_EXT2_FS is set to y. Besides, I
tried doing the same with a cramfs initrd - won't work either. Cannot
say whether I configured that right.

Maybe this is an endianess problem in my initrds?

I don't know. :(

With kind regards,
Oliver Korpilla

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

Re: Initrd and PPCbug, can it work?

[Magnus Damm]

On Tue, 27 Apr 2004 11:42:12 +0200
Oliver Korpilla <okorpil@fh-landshut.de> wrote:

> This was the first I checked - CONFIG_EXT2_FS is set to y. Besides, I
> tried doing the same with a cramfs initrd - won't work either. Cannot
> say whether I configured that right.
>
> Maybe this is an endianess problem in my initrds?

As long as you use ext2 you should not have any endian problems.

It might be tempting to use other fancy filesystems, but I don't
like endian problems so I usually stick to ext2. I create my
ext2 initrds on x86 systems and use them on ppc without problems.

/ magnus

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

Re: Initrd and PPCbug, can it work?

[Oliver Korpilla]

Magnus Damm wrote:
>>Maybe this is an endianess problem in my initrds?
>
>
> As long as you use ext2 you should not have any endian problems.
>
> It might be tempting to use other fancy filesystems, but I don't
> like endian problems so I usually stick to ext2. I create my
> ext2 initrds on x86 systems and use them on ppc without problems.
>

Yeah, I see. But this may be the problem that I had the cramfs error
messages even with a cramfs initrd - this is endian sensitive and only
makes little-endian - won't work without a patch, so I really better
stick with ext2,hm?

Thanks,
Oliver Korpilla

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

Re: Initrd and PPCbug, can it work?

[Marius Groeger]

On Tue, 27 Apr 2004, Oliver Korpilla wrote:

> Maybe this is an endianess problem in my initrds?

Have you tried setting "rootfstype=ext2"?

Marius

--
Marius Groeger <mgroeger@sysgo.com>           Project Manager
SYSGO AG                      Embedded and Real-Time Software
Voice: +49 6136 9948 0                  FAX: +49 6136 9948 10
www.sysgo.com | www.elinos.com | www.osek.de | www.imerva.com


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

Re: Initrd and PPCbug, can it work?

[Oliver Korpilla]

Marius Groeger wrote:
>
> Have you tried setting "rootfstype=ext2"?
>

I have, and do not any longer get the error message, but still the
kernel panic.

What I am trying to do:

Use the initrd loaded with the kernel as a root filesystem in memory
after bootup.

Exactly what commandline parameters for the kernel would I need to make
that?

With kind regards,
Oliver Korpilla

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

Re: Initrd and PPCbug, can it work?

[Magnus Damm]

On Tue, 27 Apr 2004 14:45:17 +0200
Oliver Korpilla <okorpil@fh-landshut.de> wrote:

> Use the initrd loaded with the kernel as a root filesystem in memory
> after bootup.
>
> Exactly what commandline parameters for the kernel would I need to make
> that?

I don't know what magic patches that are applied to the mvl-3.1 kernel
that a customer of mine use, but we use one kernel with initrd (ext2fs)
and nfs root + ip pnp support. Then we select at boot-time how we want
to boot the system:

Development: "noinitrd ip=on nfsroot=192.168.1.1:/home/nfs/foobar"
Standalone: "ip=off"

We boot a "Gzipped Multi-File Image" from u-boot, but I guess that booting
a standard zImage from anywhere would do too.

/ magnus

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

Different solution

[Oliver Korpilla]

Magnus Damm wrote:
>
> I don't know what magic patches that are applied to the mvl-3.1 kernel
> that a customer of mine use, but we use one kernel with initrd (ext2fs)
> and nfs root + ip pnp support. Then we select at boot-time how we want
> to boot the system:
>
> Development: "noinitrd ip=on nfsroot=192.168.1.1:/home/nfs/foobar"
> Standalone: "ip=off"
>
> We boot a "Gzipped Multi-File Image" from u-boot, but I guess that booting
> a standard zImage from anywhere would do too.
>

A quicker solution was to use my flash as a JFFS2 root filesystem (it
was actually quite complicated, because write support in the kernel
(MTD) is broken for the onboard flash chip - well, read it on the
linux-mtd ;) ). I now mount this readonly, and I have a filesystem
without needing to reserve RAM for it - where the initrd resides. So
this is actually a better solution, that utilizes my ressources better. :)

I would like to still found a solution incorporating an initrd, but in
this case only for completeness' sake.


Anybody ideas about how of if to set the following parameters:

root, rootfstype, keepinitrd

and any others needed to use the initrd?

Residual-Data Located at: $01F5511C
loaded at: 00005400 001655BC
relocated to: 00800000 009601BC
zimage at: 008058B0 008C16FA
initrd at: 008C2000 0095D000
avail ram: 00400000 00800000

I'm a bit unsure whether these are good values, or if the place the
initrd is relocated to at loading is actually problematic - e.g.
problematic with regards to HIGHMEM, or end of memory. I have 32MB of
physical mem.

Hope I didn't demotivate anyone to find a solution, though! ;)

With kind regards,
Oliver Korpilla

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

Different solution

[Oliver Korpilla]

Magnus Damm wrote:
>
> I don't know what magic patches that are applied to the mvl-3.1 kernel
> that a customer of mine use, but we use one kernel with initrd (ext2fs)
> and nfs root + ip pnp support. Then we select at boot-time how we want
> to boot the system:
>
> Development: "noinitrd ip=on nfsroot=192.168.1.1:/home/nfs/foobar"
> Standalone: "ip=off"
>
> We boot a "Gzipped Multi-File Image" from u-boot, but I guess that booting
> a standard zImage from anywhere would do too.
>

A quicker solution was to use my flash as a JFFS2 root filesystem (it
was actually quite complicated, because write support in the kernel
(MTD) is broken for the onboard flash chip - well, read it on the
linux-mtd ;) ). I now mount this readonly, and I have a filesystem
without needing to reserve RAM for it - where the initrd resides. So
this is actually a better solution, that utilizes my ressources better. :)

I would like to still found a solution incorporating an initrd, but in
this case only for completeness' sake.


Anybody ideas about how of if to set the following parameters:

root, rootfstype, keepinitrd

and any others needed to use the initrd?

Residual-Data Located at: $01F5511C
loaded at: 00005400 001655BC
relocated to: 00800000 009601BC
zimage at: 008058B0 008C16FA
initrd at: 008C2000 0095D000
avail ram: 00400000 00800000

I'm a bit unsure whether these are good values, or if the place the
initrd is relocated to at loading is actually problematic - e.g.
problematic with regards to HIGHMEM, or end of memory. I have 32MB of
physical mem.

Hope I didn't demotivate anyone to find a solution, though! ;)

With kind regards,
Oliver Korpilla


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