Bizarre initrd problem on CLLF860T

Bizarre initrd problem on CLLF860T

[Graham Stoney]

Hi there,

I'm wondering if anyone could please give me a pointer on the following
problem I'm having: A couple of months ago when I last tried booting one of
our CLLF860T boards with an initrd, it all worked fine -- no drama. Figuring
that this hurdle was conquered, I haven't tried again until today, as we're
happily NFS mounting the root filesystem for development.

Today though, I can't for the life of me work out why the initrd stuff isn't
working. The log messages tell me that it's trying to mount the root filesystem
*twice*, and the second attempt fails with a panic. I've been banging my head
against this all afternoon to no avail; any suggestions?

I'm using Dan's 2.2.13-derived kernel; here are the boot messages:

loaded at:     00200000 0020C580
relocated to:  00100000 0010C580
board data at: 001001C4 001001E0
relocated to:  00200100 0020011C
zimage at:     00207000 00266B05
initrd at:     00266B05 00332154
avail ram:     00333000 01000000

Linux/PPC load:
Uncompressing Linux...done.
Now booting the kernel
Linux version 2.2.13 (greyham@brixi) (gcc version 2.95.2 19991024 (release)) #55
 Mon Apr 17 16:53:24T 2000
Boot arguments: root=/dev/ram
time_init: decrementer frequency = 180000000/60
Calibrating delay loop... 47.82 BogoMIPS
Memory: 14352k available (728k kernel code, 452k data, 32k init) [c0000000,c1000
000]
DENTRY hash tas: 262144 (order: 9, 2097152 bytes)
Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.2
Based upon Swansea University Computer Society NET3.039
NET4: Unix domain sockets 1.0 for Linux NET4.0.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
TCP: Hash tables configured (ehash 16384 bhash 16384)
Starting kswapd v 1.1.1.1
CPM UART driver version 0.03
ttyS00 at 0x0280 is a SMC
ttyS01 at 0x0380 is a SMC
ttyS02 at 0x0100 is a SCC
ttyS03 at 0x0200 is a SCC
pty: 256 Unix98 ptys configured
RAM disk driver initialized:  16 RAM disks of 4096K size
loop: registered device at major 7
eth0: FEC ENET Version 0.1, 00:10:ec:00:0d:3b
PPP: version 2.3.7 (demand dialling)
TCP compression code copyright 1989 Regents of the University of California
PPP line discipline regid.
fec: Phy @ 0x17, type 0x01814401
fec: link down
fec: 100 Mbps, Half-Duplex
Sending BOOTP requests..... OK
IP-Config: Got BOOTP answer from 10.2.2.90, my address is 10.2.0.21
IP-Config: Guessing netmask 255.0.0.0
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem)
VFS: Cannot open root device 00:00
Kernel panic: VFS: Unable to mount root fs on 00:00
Rebooting in 180 seconds..<0>Kernel panic: Kernel Mode Software FPU Emulation
Rebooting in 180 seconds..

Any help greatly appreciated,
Graham
--
Graham Stoney
Principal Hardware/Software Engineer
Canon Information Systems Research Australia
Ph: +61 2 9805 2909  Fax: +61 2 9805 2929

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

Re: Bizarre initrd problem on CLLF860T

[Marcus Sundberg]

greyham@research.canon.com.au (Graham Stoney) writes:

> Hi there,
>
> I'm wondering if anyone could please give me a pointer on the following
> problem I'm having: A couple of months ago when I last tried booting one of
> our CLLF860T boards with an initrd, it all worked fine -- no drama. Figuring
> that this hurdle was conquered, I haven't tried again until today, as we're
> happily NFS mounting the root filesystem for development.
>
> Today though, I can't for the life of me work out why the initrd stuff isn't
> working. The log messages tell me that it's trying to mount the root filesystem
> *twice*, and the second attempt fails with a panic. I've been banging my head
> against this all afternoon to no avail; any suggestions?
>
> I'm using Dan's 2.2.13-derived kernel; here are the boot messages:

[snip]

> RAMDISK: Compressed image found at block 0
> VFS: Mounted root (ext2 filesystem)
> VFS: Cannot open root device 00:00
> Kernel panic: VFS: Unable to mount root fs on 00:00

Looks like the initrd is sucessfully mounted, then /linuxrc is either
executed quietly or fails to be executed. In either case the bootup
continues, and fails to mount the real root device because it is not
set to anything useful.

How is your bootup supposed to work? If you want to use the initrd
as the real root file system you should pass root=/dev/ram to
the kernel.

//Marcus
--
Signature under construction, please come back later.

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

Re: Bizarre initrd problem on CLLF860T

[Graham Stoney]

Marcus Sundberg writes:
> > RAMDISK: Compressed image found at block 0
> > VFS: Mounted root (ext2 filesystem)
> > VFS: Cannot open root device 00:00
> > Kernel panic: VFS: Unable to mount root fs on 00:00
>
> Looks like the initrd is sucessfully mounted, then /linuxrc is either
> executed quietly or fails to be executed. In either case the bootup
> continues, and fails to mount the real root device because it is not
> set to anything useful.

Yes, but I'm confused as to why...

> How is your bootup supposed to work? If you want to use the initrd
> as the real root file system you should pass root=/dev/ram to
> the kernel.

I'm just trying to boot to a standalone shell; I have no /linuxrc in my initrd,
and I do want to use the initrd as the real root file system. Also, I have:

    Boot arguments: root=/dev/ram

So it looks to me as though it _should_ work; but why is it trying to remount
device 00:00?  The ramdisk is supposed to be 01:00.

Mucho confusedo,
Graham

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

RE: Bizarre initrd problem on CLLF860T

[Jason Wohlgemuth]

Graham,

Hmmm... Here are some things I would try... it may be helpful to put a debug
line in fs/namei.c, the open_namei call,  and simply print the pathname,
maybe this will show you the file which is causing the problem.  When I get
to work, I look at the the root device 00:00 and see what is different on my
builds and get back to you with more information.

Jason

-----Original Message-----
From: owner-linuxppc-embedded@lists.linuxppc.org
[mailto:owner-linuxppc-embedded@lists.linuxppc.org]On Behalf Of Graham
Stoney
Sent: Monday, April 17, 2000 4:42 AM
To: Marcus Sundberg
Cc: Graham Stoney; LinuxPPC Embedded Mailing List
Subject: Re: Bizarre initrd problem on CLLF860T



Marcus Sundberg writes:
> > RAMDISK: Compressed image found at block 0
> > VFS: Mounted root (ext2 filesystem)
> > VFS: Cannot open root device 00:00
> > Kernel panic: VFS: Unable to mount root fs on 00:00
>
> Looks like the initrd is sucessfully mounted, then /linuxrc is either
> executed quietly or fails to be executed. In either case the bootup
> continues, and fails to mount the real root device because it is not
> set to anything useful.

Yes, but I'm confused as to why...

> How is your bootup supposed to work? If you want to use the initrd
> as the real root file system you should pass root=/dev/ram to
> the kernel.

I'm just trying to boot to a standalone shell; I have no /linuxrc in my
initrd,
and I do want to use the initrd as the real root file system. Also, I have:

    Boot arguments: root=/dev/ram

So it looks to me as though it _should_ work; but why is it trying to
remount
device 00:00?  The ramdisk is supposed to be 01:00.

Mucho confusedo,
Graham


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

Re: Bizarre initrd problem on CLLF860T

[Dan Malek]

Graham Stoney wrote:

> Today though, I can't for the life of me work out why the initrd stuff isn't
> working.

So, what's different in your configuration?  Is this the same kernel
and ramdisk?  Like I requested in a previous message, the the sources
from MontaVista.  They are the most recent.


> Sending BOOTP requests..... OK
> IP-Config: Got BOOTP answer from 10.2.2.90, my address is 10.2.0.21
> IP-Config: Guessing netmask 255.0.0.0
> RAMDISK: Compressed image found at block 0

IP-Config with Ramdisk is a pretty weird configuration.  At the
'Linux/PPC Load:' enter 'root=/dev/ram ip=off'.


	-- Dan

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

Re: Bizarre initrd problem on CLLF860T

[Wolfgang Denk]

In message <38FB0DA0.DDE9098C@embeddededge.com> Dan Malek wrote:
>
> > Sending BOOTP requests..... OK
> > IP-Config: Got BOOTP answer from 10.2.2.90, my address is 10.2.0.21
> > IP-Config: Guessing netmask 255.0.0.0
> > RAMDISK: Compressed image found at block 0
>
> IP-Config with Ramdisk is a pretty weird configuration.  At the
> 'Linux/PPC Load:' enter 'root=/dev/ram ip=off'.

Why do you call this weird? Is it not possible to use BOOTP  to  just
get an IP address assigned?

What method for network configuration do you suggest for a  minimized
embedded  system? Including tools like ifconfig and set-up scripts to
call them?

I've been using similar combinations (RARP + initrd)  for  some  time
without problems; would this fail using BOOTP?

Ummm... let's see:

Using RARP:

	...
	ttyS00 at 0x0380 is a SMC
	ttyS01 at 0x0280 is a SMC
	pty: 256 Unix98 ptys configured
	Found 2x16bit 4Mbyte CFI flash device of type AMD/Fujitsu standard at 40000000
	registered flash device /dev/flash0
	Found 2x16bit 4Mbyte CFI flash device of type AMD/Fujitsu standard at 40400000
	registered flash device /dev/flash1
	RAM disk driver initialized:  16 RAM disks of 4096K size
	eth0: CPM ENET Version 0.2, 00:d0:93:00:02:6c
	PPP: version 2.3.7 (demand dialling)
	TCP compression code copyright 1989 Regents of the University of California
	PPP line discipline registered.
	Sending RARP requests.... OK
	IP-Config: Got RARP answer from 10.0.0.1, my address is 10.0.0.99
	IP-Config: Guessing netmask 255.0.0.0
	RAMDISK: Compressed image found at block 0
	EXT2-fs warning: checktime reached, running e2fsck is recommended
	VFS: Mounted root (ext2 filesystem).
	Freeing unused kernel memory: 32k init
	Stand-alone shell (version 2.1)
	>

Using BOOTP:

	...
	ttyS00 at 0x0380 is a SMC
	ttyS01 at 0x0280 is a SMC
	pty: 256 Unix98 ptys configured
	Found 2x16bit 4Mbyte CFI flash device of type AMD/Fujitsu standard at 40000000
	registered flash device /dev/flash0
	Found 2x16bit 4Mbyte CFI flash device of type AMD/Fujitsu standard at 40400000
	registered flash device /dev/flash1
	RAM disk driver initialized:  16 RAM disks of 4096K size
	eth0: CPM ENET Version 0.2, 00:d0:93:00:02:6c
	PPP: version 2.3.7 (demand dialling)
	TCP compression code copyright 1989 Regents of the University of California
	PPP line discipline registered.
	Sending BOOTP requests.... OK
	IP-Config: Got BOOTP answer from 10.0.0.1, my address is 10.0.0.99
	RAMDISK: Compressed image found at block 0
	EXT2-fs warning: checktime reached, running e2fsck is recommended
	VFS: Mounted root (ext2 filesystem).
	Freeing unused kernel memory: 36k init
	Stand-alone shell (version 2.1)
	>

This works for me, too.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Man is the best computer we can put aboard a spacecraft ...  and  the
only one that can be mass produced with unskilled labor.
                                                  - Wernher von Braun

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

Re: Bizarre initrd problem on CLLF860T

[Graham Stoney]

Hi everyone,

Thanks to all your suggestions, I have found the culprit...

Dan Malek writes:
> So, what's different in your configuration?  Is this the same kernel
> and ramdisk?  Like I requested in a previous message, the the sources
> from MontaVista.  They are the most recent.

I am using the MontaVista kernel, with a few trivial local tweaks; namely the
patches I've posted here over the last few weeks. My initrd problem lies in
the CPU6 workaround in set_dec in arch/ppc/kernel/head.S, which does, err,
interesting things to the command line!:

        .globl  set_dec
set_dec:
        mfmsr   r5              /* Disable interrupts */
        li      r4,0
        ori     r4,r4,MSR_EE
        andc    r6,r5,r4
        SYNC                    /* Some chip revs need this... */
        mtmsr   r6
        SYNC
        lis     r7, cmd_line@h			###
        ori     r7, r7, cmd_line@l		###
        li      r4, 0x2c00			###
        stw     r4, 12(r7)			###
        lwz     r4, 12(r7)			###
        mtspr   22, r3          /* Update Decrementer */
        SYNC
        mtmsr   r5
        SYNC
        blr

The lines marked ### look like debug code that shouldn't have made it out to
the world. It's causing my boot command line "root=/dev/ram" to turn into
"root=/dev/ra", and triggering the initrd code that tries to remount the real
root filesystem. If you're using the CPU6 workarounds, I suggest you nuke
those lines.

Turns out I'm not going crazy after all.

Thanks again for all your suggestions,
Graham
--
Graham Stoney
Principal Hardware/Software Engineer
Canon Information Systems Research Australia
Ph: +61 2 9805 2909  Fax: +61 2 9805 2929

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

Re: Bizarre initrd problem on CLLF860T

[Marcus Sundberg]

greyham@research.canon.com.au (Graham Stoney) writes:

> I am using the MontaVista kernel, with a few trivial local tweaks; namely the
> patches I've posted here over the last few weeks. My initrd problem lies in
> the CPU6 workaround in set_dec in arch/ppc/kernel/head.S, which does, err,
> interesting things to the command line!:
>
>         .globl  set_dec
> set_dec:
>         mfmsr   r5              /* Disable interrupts */
>         li      r4,0
>         ori     r4,r4,MSR_EE
>         andc    r6,r5,r4
>         SYNC                    /* Some chip revs need this... */
>         mtmsr   r6
>         SYNC
>         lis     r7, cmd_line@h			###
>         ori     r7, r7, cmd_line@l		###
>         li      r4, 0x2c00			###
>         stw     r4, 12(r7)			###
>         lwz     r4, 12(r7)			###
>         mtspr   22, r3          /* Update Decrementer */
>         SYNC
>         mtmsr   r5
>         SYNC
>         blr
>
> The lines marked ### look like debug code that shouldn't have made it out to
> the world. It's causing my boot command line "root=/dev/ram" to turn into
> "root=/dev/ra", and triggering the initrd code that tries to remount the real
> root filesystem. If you're using the CPU6 workarounds, I suggest you nuke
> those lines.

Actually they are part of the CPU6 workaround. set_dec() apparently
was overlooked in our version of it, but MontaVista have that fixed.
Unfortunately they fixed it wrong - set_dec() is called before the
command line is processed, unlike _switch() which also use cmd_line
to store the value.

I'd suggest keeping the C-version of set_dec() in ppc/kernel/time.h
where it used to be and change it to the followingcode :

static __inline__ void set_dec(unsigned int val)
{
        unsigned long flags;
	unsigned long dummy_var;
	register unsigned long reg5 __asm__ ("r5") = DEC_ADDR;
	register unsigned long reg4 __asm__ ("r4") = (unsigned long) &dummy_var;

        save_flags(flags);
        cli();
	asm volatile (
		"stw   %3,0(%2) \n\t"
		"lwz   %3,0(%2) \n\t"
		"mtspr %0,%1 \n\t"
		: : "i"(DEC), "r"((val)), "r"(reg4), "r"(reg5)
		: "r4", "r5", "memory");
        restore_flags(flags);
}

//Marcus
--
Signature under construction, please come back later.

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

Re: Bizarre initrd problem on CLLF860T

[Marcus Sundberg]

Marcus Sundberg <erammsu@kieraypc01.p.y.ki.era.ericsson.se> writes:

> I'd suggest keeping the C-version of set_dec() in ppc/kernel/time.h
> where it used to be and change it to the following code :

[snip]

Or not. ;-)
That didn't come out of the compiler as something useful, this version
works though:

static __inline__ void set_dec(unsigned int val)
{
	unsigned long dummy_var;
	register unsigned long reg5 __asm__ ("r5");
	register unsigned long reg4 __asm__ ("r4");
	unsigned long flags;

	save_flags(flags);
	cli();
	reg4 = (unsigned long) &dummy_var;
	reg5 = DEC_ADDR;
	asm volatile (
		"stw   %3,0(%2) \n\t"
		"lwz   %3,0(%2) \n\t"
		"mtspr %0,%1 \n\t"
		: : "i"(DEC), "r"((val)), "r"(reg4), "r"(reg5)
		: "r4", "r5", "memory");
	restore_flags(flags);
}

//Marcus
--
Signature under construction, please come back later.

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

Re: Bizarre initrd problem on CLLF860T

[Dan Malek]

Graham Stoney wrote:

> ..... My initrd problem lies in
> the CPU6 workaround in set_dec in arch/ppc/kernel/head.S, which does, err,
> interesting things to the command line!:

Sorry about that.  It was a test hack I forgot about.  I just needed
something aligned and mapped to read/write that was _supposed_ to not
affect anything.  It popped to mind and I never went back to do something
proper......I don't know why it ever worked for me.

Just create some 32-bit aligned variable and use that.


	-- Dan

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

Re: Bizarre initrd problem on CLLF860T

[Dan Malek]

Marcus Sundberg wrote:

> I'd suggest keeping the C-version of set_dec() in ppc/kernel/time.h
> where it used to be and change it to the followingcode :

I just use whatever comes from the Linux/PPC development tree.  It
seems to move around depending upon what compiler bugs exist at the time.
It may also be necessary to make this a real function for RT/Linux support.


	-- Dan

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