• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 102 subscribers
  • Views 816 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

NFS root does not work with DVSDK 2.0 / DM6467

Danny H
Prodigy 40 points

Hello,

 

I have an  EVMDM6467 board. It is set up for TFTP kernel load and NFS root. If I put a DVSDK1.4 kernel on my TFTP server, it boots fine and loads the NFS root file system with no problems. However, if I change the uImage file on the TFTP server to a DVSDK 2.0 kernel, for example 'PSP_02_00_00_140/bin/dm6467/uImage-dm6467', I get this:

TFTP from server 10.10.10.240; our IP address is 10.10.10.241
Filename 'uImage'.
Load address: 0x80700000
Loading: #################################################################
  #################################################################
  #################################################################
  #################################################################
  #################################################################
  ################################################################
done
Bytes transferred = 1988588 (1e57ec hex)
## Booting image at 80700000 ...
  Image Name: Linux-2.6.18_pro500-davinci_evm-
  Image Type: ARM Linux Kernel Image (uncompressed)
  Data Size: 1988524 Bytes = 1.9 MB
  Load Address: 80008000
  Entry Point: 80008000
  Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux................................................................................................................................... done, booting the kernel.
Linux version 2.6.18_pro500-davinci_evm-arm_v5t_le (x0029463@aspbuild11) (gcc version 4.2.0 20070126 (prerelease) (MontaVista 4.2.0-3.0.0.0702771 2007-03-10)) #1 PREEMPT Wed May 20 01:14:17 IST 209CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177

....

 

Switched to high resolution mode on CPU 0
IP-Config: Complete:
  device=eth0, addr=10.10.10.241, mask=255.255.254.0, gw=10.10.10.1,
  host=off, domain=, nis-domain=(none),
  bootserver=255.255.255.255, rootserver=10.10.10.240, rootpath=
Looking up port of RPC 100003/2 on 10.10.10.240
Root-NFS: Unable to get nfsd port number from server, using default
Looking up port of RPC 100005/1 on 10.10.10.240
Root-NFS: Unable to get mountd port number from server, using default
Root-NFS: Server returned error -5 while mounting /home/dny/work/filesys
VFS: Unable to mount root fs via NFS, trying floppy.
VFS: Cannot open root device "nfs" or unknown-block(2,0)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)

I tried the following:

Disabling firewall, using DHCP, changing /etc/exports - in all cases the 1.4 kernel boots while the 2.0 kernel does not.

 

U-boot settings:

baudrate=115200
bootfile="uImage"
bootcmd=tftp;bootm
ethaddr=00:0e:99:02:b3:02
serverip=10.10.10.240
ipaddr=10.10.10.241
bootdelay=1
bootargs=console=ttyS0,115200n8 noinitrd rw ip=10.10.10.241 root=/dev/nfs nfsroot=10.10.10.240:/home/dny/work/filesys,nolock,tcp,rsize=1024,wsize=1024 mem=120M
stdin=serial
stdout=serial
stderr=serial

 

Any help would be appreciated!

  • 0
    TI__Mastermind 37340 points

    This sounds very similar to a problem reported recently; it was claimed that breaking into u-boot and issuing poing command (e.g. ping <host-ip-address>) gets TFTP and NFS working on DVSDK 2.0.  If you can confirm this it would be another data point for us to investigate.

  • 0 in reply to Juan Gonzales
    Prodigy 40 points

     

    OK, I tried pinging - the pings work fine to several local hosts, also the kernel load via TFTP works fine, however the mount stage fails as before:

    IP-Config: Guessing netmask 255.0.0.0
    IP-Config: Complete:
    device=eth0, addr=10.10.10.241, mask=255.0.0.0, gw=255.255.255.255,
    host=10.10.10.241, domain=, nis-domain=(none),
    bootserver=255.255.255.255, rootserver=10.10.10.240, rootpath=
    Looking up port of RPC 100003/2 on 10.10.10.240
    Root-NFS: Unable to get nfsd port number from server, using default
    Looking up port of RPC 100005/1 on 10.10.10.240
    Root-NFS: Unable to get mountd port number from server, using default
    Root-NFS: Server returned error -5 while mounting /home/dny/work/filesys
    VFS: Unable to mount root fs via NFS, trying floppy.
    VFS: Cannot open root device "nfs" or unknown-block(2,0)
    Please append a correct "root=" boot option
    Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)

    Please note: I have added the following switch - "nfsroot=10.10.10.240:/home/dny/work/filesys,nolock,tcp" - without the ",tcp" option I get, in addition to the current failures, also a time out on both "looking up port of rpc..." requests.

    Thanks,

     

  • 0 in reply to Danny H
    Intellectual 410 points

    I got the exactly same problem with 2.6.18 kernel. If I boot back the 2.6.10, with the exactly same hardware and cables setup, I could mount the root nfs. So definitely something changed in the 2.6.18. I got the same problem with both DM6446 and DM6467 EVMs.

    Also, wireshark shows that there was only ARP traffic between the NFS server and DM6467 board when this situation happened. EVM keeps asking "who has xx.xx.xx.xx?", NFS server keeps replying.

    Any ideas pls?

  • 0 in reply to S.C
    Intellectual 270 points

    Has anyone found an answer to this problem yet?

    Thanks

  • 0 in reply to newb
    TI__Mastermind 37340 points

    as suggested above, using ping command from u-boot prompt should allow you to work-around this problem until our next software release fixes this issue.

    you can try something similar to the command below if you want to automate the this work-around. 

    bootcmd=ping 192.168.0.25;nboot 80700000 0 a0000;bootm

  • 0 in reply to Juan Gonzales
    Intellectual 590 points

    HI Juan,

    I got the same problem.

    your workaround only makes "ping" at boot.

    Buf after compressing kernel, no ping would happen by "bootcmd=ping 192.168.0.25".

    Is this related to nfs kernel config?

    attached is my kernel config file.

    Please have a look.

    Thanks.

  • 0 in reply to Juan Gonzales
    Intellectual 590 points

    does your workaround solution require uimage burn to flash first?