I have this problem with AT91SAM9-L9260 on Olimex kit. I have tried to run it from the NFS disk but the kernel (my own) have a problem with ethernet.
My kernel is working properly when I use the rootfs on NAND Flash prepared by Olimex. I send the kernel to the RAM from U-Boot with tftp. When I try to change rootfs to NFS, I get the log: IP-Config: Failed to open eth0.
When I boot my kernel with NAND flash rootfs the network is working, but the MAC address is preconfigured by network starting script. In U-Boot the network is also working but I have to set the ethaddr env-variable. My kernel is also properly configured to boot from NFS (I have checked this many times, besides the kernel message says that it is eth0 fault).
I have found some information on google that probably it doesn’t work because the network device do not have MAC address (or it cannot be read from the device). So the network cannot be set up in kernel booting time. If it is true, how can I set this MAC address to make it work??
Maybe some of you are working with this board and already have solved this problem?
I have no experience with the Olimex Board, but I do have experience booting from the network.
Have you tried:
Use a packet sniffer like wireshark on the host PC to see what kind of things are taking place. Is the Mac address changing from one value to another at bootup?
Are you using an initial ramdisk? If not you should modify one that works for NAND and make it give you access at an early stage in boot-up so you can debug. This is how I’ve solved many problems like this.
Some useful initrd commands:
Make a new ramdisk based on current working directory:
mpi have you managed to solve this issue? i’m having the same problem and it’s quite frustrating. i think i managed to nfs mount the board once but couldn’t repeat the steps to do it again. mounting root fs on usb pen drive works like a charm. not sure whether people from olimex have any tech support available?
The message is emitted by the following portion of ipconfig.c
if (dev_change_flags(dev, oflags | IFF_UP) < 0) {
printk(KERN_ERR "IP-Config: Failed to open %s\n", dev->name);
continue;
}
I would suspect something wrong with PHY connection. Micrel is the one of my most favourite Ethernet product company (stay away from CS8900A. SMsC91C111 or DM9000 as they don’t work) and I’m confident of there should be little issue of Micrel PHY beside physical design or MII operational error.
I strolled around Atmel AT91RM9200 PDF. OK, it’s a pleasant surprise to me of its particular descriptor design (How wise they are) My concern is how PHY pin connection is wired and operated. I’m yet to dig deep down Olimex Linux code, though, according to EMAC troubles I’ve seen in this list my theory this moment is the PHY reset operation often fails. Amusing, this is the place where designer/programmer would make failure to do the right. Here is proposed check list;
the correctness of every PHY wire in electronics perspective.
the correctness of PIO register designations by PIO “B” control block.
If I was a person good to use high precision probe, I would make full investigation about how RESET line behaves on particular moments and whether PHY is really configured as demands.
Not sure about the PHY, but that problem than should occur even rootfs is mounted on usb pen drive or nand flash, which is not the case for me (unless early stage networking is somehow different once nfsroot is passed as a kernel command line arg?). In both cases eth0 is opened successfully and networking is fine. I compiled my linux kernel 2.6.24.5 with 2.6.24-at91.patch. Once kernel boots and rootfs is mounted (from nand flash or usb drive) nfs mount works quite fine.
Olimex board ships with linux 2.6.23. I don’t think they enabled CONFIG_NFS_FS, CONFIG_ROOT_NFS, CONFIG_IP_PNP as the error I received while trying to mount nfs rootfs was somewhat different than with my manually compiled kernel (not 100% sure, need to test again though …)
One of my theory is that waiting AN completion is somehow frakely, sometimes works othertimes does not. The original poster mentioned myterious “Fault” condition about that.
My developemnt approcach is to do rootfs-on-NFS very first than any other rootfs layout. During the work phase the knowledge of target HW is accumlated step-by-step. Here is cmdline designation I use;```
console=XXX root=/dev/nfs rw ip=dhcp
OK- if you set the ethernet mac address in the u-boot setting up and save this to flash there is at last acknowledgement of nfs:
setenv ethaddr 00ad:d0:05:00
saveenv
Be very careful with saveenv- if you have incorrect enviornoment variables many of them will require a complete reinstallation of u-boot to remove them.
You will probably get errors trying to open console- this has to do with permissions in the nfs directory on the host PC. Quick workaround is to cp the /dev/console device from your host PC linux system into the nfs directory i.e if the nfs directory is /media/nfs then
Now I get the same error I had previously where the ethernet device is not recognised in Linux- this is directly because of saving the U-boot ethaddr environment variable- will have to either fix it in linux or resort back to the original u-boot configuration which will require reinstalling u-boot.
ad:d0:05:00