Problems NFS booting current git kernel from arago on TI8168

B.J. Buchalter

As I posted in a different thread, I am having problems booting with an NFS root using the current git kernel from arago. The kernel boots fine, but cannot mount the NFS root. Here is the boot log:

TI8168_EVM#boot

Using DaVinci EMAC device
TFTP from server 10.0.1.199; our IP address is 10.0.1.198
Filename 'uImage'.
Load address: 0x81000000
Loading: *#################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 #################################################################
	 ###############################
done
Bytes transferred = 2486316 (25f02c hex)
## Booting kernel from Legacy Image at 81000000 ...
   Image Name:   Linux-2.6.37-14267-gbe5d2aa-dirt
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2486252 Bytes = 2.4 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[    0.000000] Linux version 2.6.37-14267-gbe5d2aa-dirty (bj@ti-dev-bj) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203) ) #2 PREEMPT Thu Apr 28 04:52:43 EDT 2011
[    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7f
[    0.000000] CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine: ti8168evm
[    0.000000] reserved size = 0 at 0
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] OMAP chip is TI8168 1.0
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 42164
[    0.000000] Kernel command line: console=ttyO2,115200n8 root=/dev/nfs nfsroot=/targetfs,nolock rw mem=166M ip=10.0.1.198:10.0.1.199:10.0.1.1:255.255.255.0:evm:eth0:off
....
[    1.030000] davinci_mdio davinci_mdio.0: davinci mdio revision 1.6
[    1.030000] davinci_mdio davinci_mdio.0: detected phy mask fffffffd
[    1.040000] davinci_mdio.0: probed
[    1.040000] davinci_mdio davinci_mdio.0: phy[1]: device 0:01, driver unknown
[    1.050000] PCI: enabling device 0000:02:00.0 (0140 -> 0142)
[    1.120000] firewire_ohci: isochronous cycle inconsistent
[    1.120000] firewire_ohci: Added fw-ohci device 0000:02:00.0, OHCI v1.10, 8 IR + 8 IT contexts, quirks 0x2
[    1.130000] Initializing USB Mass Storage driver...
[    1.140000] usbcore: registered new interface driver usb-storage
[    1.140000] USB Mass Storage support registered.
[    1.150000] mice: PS/2 mouse device common for all mice
[    1.150000] i2c /dev entries driver
[    1.160000] PSTATE 1ff0000
[    1.160000] usbcore: registered new interface driver usbhid
[    1.170000] usbhid: USB HID core driver
[    1.170000] ALSA device list:
[    1.170000]   No soundcards found.
[    1.180000] oprofile: using arm/armv7
[    1.180000] TCP cubic registered
[    1.190000] ata1: SATA link down (SStatus 0 SControl 300)
[    1.190000] ata2: SATA link down (SStatus 0 SControl 300)
[    1.200000] NET: Registered protocol family 17
[    1.200000] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3
[    1.210000] omap_voltage_late_init: Voltage driver support not added
[    1.300000] mmc0: new SDHC card at address e624
[    1.300000] mmcblk0: mmc0:e624 SD08G 7.40 GiB 
[    1.310000]  mmcblk0: p1 p2 p3
[    1.620000] firewire_core: created device fw0: GUID 7856341278563412, S800
[    1.630000] firewire_net: firewire0: IPv4 over FireWire on device 7856341278563412
[    1.630000] firewire_core: created device fw2: GUID 70cd60fffeb8cc8c, S800
[    1.640000] firewire_core: created device fw1: GUID 0007590200001f95, S400
[    1.650000] firewire_core: phy config: card 0, new root=ffc2, gap_count=63
[    1.660000] firewire_core: refreshed device fw0
[    1.740000] davinci_mdio davinci_mdio.0: resetting idled controller
[    1.740000] net eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=0:01, id=282f014)
[    2.760000] IP-Config: Complete:
[    2.760000]      device=eth0, addr=10.0.1.198, mask=255.255.255.0, gw=10.0.1.1,
[    2.770000]      host=evm, domain=, nis-domain=(none),
[    2.770000]      bootserver=10.0.1.199, rootserver=10.0.1.199, rootpath=
[    5.790000] VFS: Unable to mount root fs via NFS, trying floppy.
[    5.790000] VFS: Cannot open root device "nfs" or unknown-block(2,0)
[    5.800000] Please append a correct "root=" boot option; here are the available partitions:
[    5.810000] 1f00            2432 mtdblock0  (driver?)
[    5.810000] 1f01             128 mtdblock1  (driver?)
[    5.820000] 1f02            4352 mtdblock2  (driver?)
[    5.820000] 1f03          204928 mtdblock3  (driver?)
[    5.830000] 1f04           50304 mtdblock4  (driver?)
[    5.830000] b300         7761920 mmcblk0  driver: mmcblk
[    5.840000]   b301           40131 mmcblk0p1 00000000-0000-0000-0000-000000000mmcblk0p1
[    5.850000]   b302          883575 mmcblk0p2 00000000-0000-0000-0000-000000000mmcblk0p2
[    5.860000]   b303         6835657 mmcblk0p3 00000000-0000-0000-0000-000000000mmcblk0p3
[    5.860000] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)
[    5.870000] Backtrace: 
[    5.880000] [] (dump_backtrace+0x0/0x110) from [] (dump_stack+0x18/0x1c)
[    5.880000]  r7:ca013000 r6:00000000 r5:c002c36c r4:c0517cb0
[    5.890000] [] (dump_stack+0x0/0x1c) from [] (panic+0x68/0x184)
[    5.900000] [] (panic+0x0/0x184) from [] (mount_block_root+0x1e0/0x220)
[    5.910000]  r3:00000000 r2:ca029e68 r1:ca029f58 r0:c046bb4c
[    5.910000] [] (mount_block_root+0x0/0x220) from [] (mount_root+0xac/0xcc)
[    5.920000] [] (mount_root+0x0/0xcc) from [] (prepare_namespace+0x170/0x1d4)
[    5.930000]  r4:c0517564
[    5.930000] [] (prepare_namespace+0x0/0x1d4) from [] (kernel_init+0x114/0x154)
[    5.940000]  r5:c0008670 r4:c0517500
[    5.950000] [] (kernel_init+0x0/0x154) from [] (do_exit+0x0/0x71c)
[    5.960000]  r5:c0008670 r4:00000000

Does anyone have any suggestions as to how to make this work?

BR,

B.J.

over 14 years ago

0 Norman Wong over 14 years ago

Guru 26430 points

Your bootargs looks like it missing the NFS server IP address. Change "nfsroot=/targetfs" to something like "nfsroot=10.0.1.199:/targetfs".

0 B.J. Buchalter over 14 years ago in reply to Norman Wong

Intellectual 875 points

Hi Norman,

Thanks, that was a good idea, but unfortunately does not change the issue. I will point out that the same boot-args work with the 2.6.34 kernel from the ezsdk.

Any other ideas?

The functional boot via 2.6.34 looks like this:

[    0.000000] TCP cubic registered
[    0.000000] NET: Registered protocol family 17
[    0.000000] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3
[    0.000000] emac-mii: probed
[    0.000000] mdio_bus 1:01: DaVinci EMAC: mii bus found 31
[    0.000000] net eth1: DaVinci EMAC eth1 PHY not found
[    0.000000] mmc0: new SDHC card at address e624
[    0.000000] mmcblk0: mmc0:e624 SD08G 7.40 GiB 
[    0.000000]  mmcblk0: p1 p2 p3
[    0.000000] ata1: SATA link down (SStatus 0 SControl 300)
[    0.000000] ata2: SATA link down (SStatus 0 SControl 300)
[    0.000000] davinci_emac: probe of davinci_emac.1 failed with error -1
[    0.000000] firewire_net: firewire0: IPv4 over FireWire on device 7856341278563412
[    0.000000] firewire_core: created device fw0: GUID 7856341278563412, S800
[    0.000000] firewire_core: created device fw1: GUID 0007590200001f95, S400
[    0.000000] firewire_core: created device fw2: GUID 70cd60fffeb8cc8c, S800
[    0.000000] eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=1:01, id=282f014)
[    0.000000] IP-Config: Complete:
[    0.000000]      device=eth0, addr=10.0.1.198, mask=255.255.255.0, gw=10.0.1.1,
[    0.000000]      host=evm, domain=, nis-domain=(none),
[    0.000000]      bootserver=10.0.1.199, rootserver=10.0.1.199, rootpath=
[    0.000000] Looking up port of RPC 100003/2 on 10.0.1.199
[    0.000000] PHY: 1:01 - Link is Up - 1000/Full
[    0.000000] Looking up port of RPC 100005/1 on 10.0.1.199
[    0.000000] VFS: Mounted root (nfs filesystem) on device 0:12.

Note that the following:

[    0.000000] emac-mii: probed
[    0.000000] mdio_bus 1:01: DaVinci EMAC: mii bus found 31

is not in the 2.6.37 boot log and that

2.6.34:   [    0.000000] eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=1:01, id=282f014)

v.s.

2.6.37:   [    1.740000] net eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=0:01, id=282f014)

The MII bus number has changed from 1 to 0. In any case, the next step in the successful boot is:

[    0.000000] Looking up port of RPC 100003/2 on 10.0.1.199

and that does not occur on the unsuccessful boot.

0 Norman Wong over 14 years ago in reply to B.J. Buchalter

Guru 26430 points

Oops. I didn't notice that rootserver IP addr was set. The bootarg is the first thing on the debug list. You are way beyond the elementary stuff. The question can be narrowed down to "Why doesn eth0 link come up?". I don't think the MII PHY address should change. I vaguely remember the code scans MII bus for PHYs until somebody answers. It then polls that PHY for link status. Maybe a kernel config option needs changing? That's all I got.

0 Norman Wong over 14 years ago in reply to B.J. Buchalter

Guru 26430 points

A shot in the dark. On the odd chance that the network driver is slower than the root file system. You could try delaying the file system. The bootarg "rootwait" is usually used for SD Cards. I doubt it would work for NFS. The bootarg "rootdelay=2" should delay for 2 seconds.

0 Srirama Govindarajan over 14 years ago in reply to Norman Wong

TI__Expert 8250 points

we have verified inter-op with gigabit switch and here are our observations

1) when using dhcp at kernel boot, the startup sequence gives enough time for the link to re-established and hence it always boots up consistently

2) when using static IP or IP being passed through bootargs, the bootup sequence doesnt provide enough time for the link negotiation, hence it helps to add "rootdelay=3" to the bootargs. After adding this delay it boots up consistently

Regards

Sriram

0 B.J. Buchalter over 14 years ago in reply to Srirama Govindarajan

Intellectual 875 points

Hi Folks,

Adding the rootdelay=3 to the boot args did indeed do the trick. Thank you very much for the suggestion!

Actually, I would recommend rootdelay=4 as I have still seen it fail occasionally.

This seems like a bug in the kernel to me; if the boot-args say that the kernel should use an nfs rootfs, shouldn't the system wait until the interface comes up before trying to mount the filesystem? That way you would not have to wait an arbitrary amount of time -- just as long as required for the interface to be accessible...

In any case, thanks for the help; I really appreciate it!

Best regards,

B.J.

0 Norman Wong over 14 years ago in reply to B.J. Buchalter

Guru 26430 points

That's not a bug! It's a Linux feature....almost all the device drivers are unsynchronized. The "rootwait" boot parameter will cause the root file system to wait forever for the root device to come up. It is somewhat annoying that it is not default. I was guessing that "rootwait" would not work with the pseudo-device "/dev/nfs". But I did little googling and found that there are some examples of "rootwait" with NFS. Now whether it works or not is unknown. People that have used "rootwait" with NFS may have just lucked out and the network came up first. Linux will just silently ignore the "rootwait" if it doesn't apply.

0 B.J. Buchalter over 14 years ago in reply to Norman Wong

Intellectual 875 points

Norman,

Thanks for the info. Indeed, rootwait does not work for NFS on this board.

It still feels like a bug to me, especially in the case of NFS boot; a box that is being NFS booted is unlikely to have any local boot resources available; kernel panicing instead of waiting for the boot device to become available is not a good outcome.

In anycase, the bootwait argument gets me past the problem, so thanks for your help! Best regards, B.J.

Processors

Processors forum

Problems NFS booting current git kernel from arago on TI8168