[U-Boot-Users] Help U-Boot NFS filesystem.
Hi all, I try to mount NFS filesystem onto my AT91RM9200DK board, But the eth0 device failed, from the boot message it looks that I didn't set the MAC addr: at91_ether: Your bootloader did not configure a MAC address. eth0: Link now 100-FullDuplex eth0: AT91 ethernet at 0xfefbc000 int=24 100-FullDuplex (00:00:00:00:00:00) ---------------------------------------------------------------------------- But I've set it in the U-Boot env: ---------------------------------------------------------------------------- U-Boot> printenv bootdelay=3 baudrate=115200 serverip=192.168.0.182 ipaddr=192.168.0.66 netmask=255.255.255.0 ethaddr=00:10:ec:00:87:73 bootargs=root=/dev/nfs rw nfsroot=${serverip}:${rootpath} ip=${ipaddr}:${serveri p}:${gatewayip}:${netmask}:${hostname}::off rootpath=/opt/eldk_arm/arm hostname=mqy gatewayip=192.168.0.182 bootfile=/tftpboot/uImage bootcmd=bootm 10080000 ok=ok stdin=serial stdout=serial stderr=serial
Environment size: 403/65532 bytes U-Boot> --------------------------------------------------------------------------- And this is full boot message ---------------------------------------------------------------------------- -
U-Boot 1.1.4 (May 29 2006 - 18:53:58)
DRAM: 32 MB Atmel: ATM_ID_BV322DT (32Mbit) Flash: 4 MB In: serial Out: serial Err: serial U-Boot 1.1.4 (May 29 2006 - 18:53:58)
DRAM: 32 MB Atmel: ATM_ID_BV322DT (32Mbit) Flash: 4 MB In: serial Out: serial Err: serial Hit any key to stop autoboot: 0 ## Booting image at 10080000 ... Image Name: Linux-2.6.16 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1103380 Bytes = 1.1 MB Load Address: 20008000 Entry Point: 20008000 Verifying Checksum ... OK OK
Starting kernel ...
Uncompressing Linux............................................................. ............. done, booting the kernel. Linux version 2.6.16 (root@second) (gcc version 4.0.0 (DENX ELDK 4.0 4.0.0)) #16 Thu Jun 8 03:40:10 AQTT 2006 CPU: ARM920Tid(wb) [41129200] revision 0 (ARMv4T) Machine: Atmel AT91RM9200-DK Memory policy: ECC disabled, Data cache writeback Clocks: CPU 179 MHz, master 59 MHz, main 18.432 MHz CPU0: D VIVT write-back cache CPU0: I cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets CPU0: D cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets Built 1 zonelists Kernel command line: root=/dev/nfs rw nfsroot=${serverip}:${rootpath} ip=${ipadd r}:${serverip}:${gatewayip}:${netmask}:${hostname}::off AT91: 128 gpio irqs in 4 banks PID hash table entries: 256 (order: 8, 4096 bytes) Console: colour dummy device 80x30 Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 32MB = 32MB total Memory: 30044KB available (1844K code, 402K data, 92K init) Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok NET: Registered protocol family 16 usbcore: registered new driver usbfs usbcore: registered new driver hub NetWinder Floating Point Emulator V0.97 (double precision) Initializing Cryptographic API io scheduler noop registered io scheduler anticipatory registered (default) AT91 Real Time Clock driver. AT91 SPI driver loaded AT91 Watchdog Timer enabled (5 seconds, nowayout=1) at91_usart.0: ttyS0 at MMIO 0xfefff200 (irq = 1) is a AT91_SERIAL at91_usart.1: ttyS1 at MMIO 0xfffc4000 (irq = 7) is a AT91_SERIAL RAMDISK driver initialized: 16 RAM disks of 32768K size 1024 blocksize at91_ether: Your bootloader did not configure a MAC address. eth0: Link now 100-FullDuplex eth0: AT91 ethernet at 0xfefbc000 int=24 100-FullDuplex (00:00:00:00:00:00) eth0: Davicom 9196 PHY (Copper) physmap flash device: 200000 at 10000000 phys_mapped_flash: Found 1 x16 devices at 0x0 in 16-bit bank Amd/Fujitsu Extended Query Table at 0x0041 phys_mapped_flash: CFI does not contain boot bank location. Assuming top. number of CFI chips: 1 cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness. RedBoot partition parsing not available at91_cf: irqs det #64, io #0 at91_ohci at91_ohci: AT91 OHCI at91_ohci at91_ohci: new USB bus registered, assigned bus number 1 at91_ohci at91_ohci: irq 23, io mem 0x00300000 usb usb1: Product: AT91 OHCI usb usb1: Manufacturer: Linux 2.6.16 ohci_hcd usb usb1: SerialNumber: at91 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected udc: at91_udc version 8 March 2005 mice: PS/2 mouse device common for all mice i2c /dev entries driver at91_i2c at91_i2c: AT91 i2c bus driver. NET: Registered protocol family 2 IP route cache hash table entries: 512 (order: -1, 2048 bytes) TCP established hash table entries: 2048 (order: 1, 8192 bytes) TCP bind hash table entries: 2048 (order: 1, 8192 bytes) TCP: Hash tables configured (established 2048 bind 2048) TCP reno registered TCP bic registered NET: Registered protocol family 1 NET: Registered protocol family 17 IP-Config: Failed to open eth0 IP-Config: No network devices available. Root-NFS: No NFS server available, giving up. 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)
Thanks a lot! KylongMu
In message BAY107-DAV10BFF455E74EC007966499C58B0@phx.gbl 008501c68b19$639091e0$8ed3fea9@first you wrote:
I try to mount NFS filesystem onto my AT91RM9200DK board, But the eth0 device failed, from the boot message it looks that I didn't set the MAC addr: at91_ether: Your bootloader did not configure a MAC address. eth0: Link now 100-FullDuplex eth0: AT91 ethernet at 0xfefbc000 int=24 100-FullDuplex (00:00:00:00:00:00)
You are right. You did not set your MAC address in Linux.
But this is a Linux problem and actually off topic here.
But I've set it in the U-Boot env:
So what? Please see the FAQ: http://www.denx.de/wiki/view/DULG/EthernetDoesNotWorkInLinux
Best regards,
Wolfgang Denk
Wolfgang Denk ha scritto:
I try to mount NFS filesystem onto my AT91RM9200DK board, But the eth0 device failed, from the boot message it looks that I didn't set the MAC addr: at91_ether: Your bootloader did not configure a MAC address. eth0: Link now 100-FullDuplex eth0: AT91 ethernet at 0xfefbc000 int=24 100-FullDuplex (00:00:00:00:00:00)
You are right. You did not set your MAC address in Linux.
But this is a Linux problem and actually off topic here.
But I've set it in the U-Boot env:
So what? Please see the FAQ: http://www.denx.de/wiki/view/DULG/EthernetDoesNotWorkInLinux
Best regards,
Wolfgang Denk
Wolfgang is right. BTW if you really want a quick and dirty solution you can use this little patch. http://www.koansoftware.com/it/art.php?art=86
Just a little hack ;-)
Ciao
Dear Marco,
in message 448864F6.8060106@koansoftware.com you wrote:
BTW if you really want a quick and dirty solution you can use this little patch. http://www.koansoftware.com/it/art.php?art=86
May I please ask you to pay a little more respect to Copyright? This article was stolen^H^H^H^H^H^Hcopied from our DULG without permission, without including a copyright notice and a pointer to the license used, and without any credit to previous authors.
You cannot do that.
Wolfgang Denk
Wolfgang Denk ha scritto:
Dear Marco,
BTW if you really want a quick and dirty solution you can use this little patch. http://www.koansoftware.com/it/art.php?art=86
May I please ask you to pay a little more respect to Copyright? This article was stolen^H^H^H^H^H^Hcopied from our DULG without permission, without including a copyright notice and a pointer to the license used, and without any credit to previous authors.
You cannot do that.
Wolfgang, my apologies. I included a link to the original source (your website) if this is not enough for you, I'm going to promptly remove it. Sorry again.
Dear Marco,
in message 44888704.5090909@koansoftware.com you wrote:
my apologies. I included a link to the original source (your website) if this is not enough for you, I'm going to promptly remove it.
Please don't misunderstand me. You are welcome to use and copy the stuff, it's intentionally under a free license. All I ask you is to include a copyright notice and a pointer to the license used, and credit to previous authors.
Sorry again.
Thanks.
Best regards,
Wolfgang Denk
In general, a Linux driver shall not make any assumptions about any initialization being done (or not done) by a boot loader; instead, that driver is responsible for performing all of the necessary initialization itself.
IMHO the MAC is an exception to this. Since it's supposed to be hardcoded to the board it's inappropriate for the OS to be dynamically assigning it. Currently we set the MAC from the protected flash of U-Boot into our Coldfire's fec before starting the OS(which is not necessarily Linux). The boards can then be appropriatly shipped to customers with pre-programmed MAC addresses identifying the module, independent of the OS.
I realize this discussion centers around an ARM, however, so there may be hardware weirdness I don't know about that prevents this type of approach.
NZG
On Thursday 08 June 2006 2:49 pm, Wolfgang Denk wrote:
Dear Marco,
in message 448864F6.8060106@koansoftware.com you wrote:
BTW if you really want a quick and dirty solution you can use this little patch. http://www.koansoftware.com/it/art.php?art=86
May I please ask you to pay a little more respect to Copyright? This article was stolen^H^H^H^H^H^Hcopied from our DULG without permission, without including a copyright notice and a pointer to the license used, and without any credit to previous authors.
You cannot do that.
Wolfgang Denk
In message 200606081540.31714.ngustavson@emacinc.com you wrote:
In general, a Linux driver shall not make any assumptions about any initialization being done (or not done) by a boot loader; instead, that driver is responsible for performing all of the necessary initialization itself.
IMHO the MAC is an exception to this. Since it's supposed to be hardcoded to the board it's inappropriate for the OS to be dynamically assigning it.
Nobody is talking about about dynamical assignemnt.
It's just that the *Linux* *driver* is responsible to initialize it, no matter which boot loader you use and what the boot loader is doing or not doing.
See the FAQ, and follow the links. If you still doubt this, seacht the ARM Linux mailing list archive. This has been discussed many times before.
Best regards,
Wolfgang Denk
On Thursday 08 June 2006 4:40 pm, Wolfgang Denk wrote:
Nobody is talking about about dynamical assignemnt.
It's just that the *Linux* *driver* is responsible to initialize it, no matter which boot loader you use and what the boot loader is doing or not doing.
In some cases that would amount to dynamic reassignment, such as in the Coldfire fec, which does not provide the typical load from eeprom functionality for it's MAC. It must be assigned by software somewhere, I am of the opinion that the bootloader should do it. Why? Because when we ship a board, we have to program the bootloader into it so customers can load an OS, the MAC goes into a protected region of flash, which it's not likely to be accidentally removed. We buy chunks of MAC addresses and assign them to boards we ship in quantity. I look at the bootloader like the BIOS of a PC without the system calls. It initializes the hardware to a minimal point (you've at least got to turn on the DRAM, an IMHO make sure the MAC is valid) and loads the OS. The OS will probably change with time, but the BIOS/bootloader is less likely too.
This has been discussed many times before.
I know, I lurk, but I have yet to see any real discussion other than quick fixes. I've pulled out the most relevant ones I can find below, if you know of a better one please send a link.
I see: http://lists.arm.linux.org.uk/pipermail/linux-arm/2005-July/010246.html Which discusses using gen_eth_addrl for generating MAC address, but of course this is only useful for testing http://www.denx.de/wiki/bin/view/DULG/EthernetDoesNotWork
I see: http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2004-July/023572.ht... Which was never resolved on list
I see: http://lists.arm.linux.org.uk/pipermail/linux-arm/2004-December/008936.html In which using ifconfig to set the MAC is recommended in conjunction with purchasing a block of MAC addresses for at least $550. This is pretty non-standard. We manufacture boards here and all of them are shipped with a pre-programmed valid address, Advantech and Aeon and every other major board manufacturer I know of, do the same. I also have never seen a Linux distribution that set's it's MAC on bootup through ifconfig, usually it's set on bootup by reading an EEPROM.
And finally: http://lists.arm.linux.org.uk/pipermail/linux-arm/2002-October/004300.html In which the solution was to contact the board manufacturer (rightfully so as they should be providing the MAC)
NZG
-----Original Message----- From: u-boot-users-bounces@lists.sourceforge.net [mailto:u-boot-users-bounces@lists.sourceforge.net] On Behalf Of NZG Sent: Thursday, June 08, 2006 17:32 To: u-boot-users@lists.sourceforge.net Subject: [U-Boot-Users] bootloader MAC
On Thursday 08 June 2006 4:40 pm, Wolfgang Denk wrote:
Nobody is talking about about dynamical assignemnt.
It's just that the *Linux* *driver* is responsible to
initialize it,
no matter which boot loader you use and what the boot
loader is doing
or not doing.
In some cases that would amount to dynamic reassignment, such as in the Coldfire fec, which does not provide the typical load from eeprom functionality for it's MAC. It must be assigned by software somewhere, I am of the opinion that the bootloader should do it. Why? Because when we ship a board, we have to program the bootloader into it so customers can load an OS, the MAC goes into a protected region of flash, which it's not likely to be accidentally removed. We buy chunks of MAC addresses and assign them to boards we ship in quantity. I look at the bootloader like the BIOS of a PC without the system calls. It initializes the hardware to a minimal point (you've at least got to turn on the DRAM, an IMHO make sure the MAC is valid) and loads the OS. The OS will probably change with time, but the BIOS/bootloader is less likely too.
On PPC we have the MAC proframmed in FLASH as a u-boot evironment variable. THis is in turn passed to the kernel on th ebd_T struct, and the *Linux* driver initializes the MAC on the ethernety interface when the ethernet driver is initialized.
Do the same. Pass the MAC to the kernel and let the driver init set the MAC to the hardware.
On Thursday 08 June 2006 5:58 pm, Rune Torgersen wrote:
On PPC we have the MAC proframmed in FLASH as a u-boot evironment variable. THis is in turn passed to the kernel on th ebd_T struct, and the *Linux* driver initializes the MAC on the ethernety interface when the ethernet driver is initialized.
Do the same. Pass the MAC to the kernel and let the driver init set the MAC to the hardware
Why is this a superior approach?
The method you've outlined assumes that the OS will make a special provision to grab the MAC from the bootloader, you can modify Linux for this certainly, but what if the board isn't running Linux? Also note, that it's still the bootloader that's setting the flash, just in a much more complex way.
Since typically it's loaded directly by the hardware, most OS's expect it to be there. Why not just have the bootloader put it there directly?
thx, NZG
-----Original Message----- From: NZG Sent: Thursday, June 08, 2006 18:16 On Thursday 08 June 2006 5:58 pm, Rune Torgersen wrote:
Do the same. Pass the MAC to the kernel and let the driver
init set the MAC
to the hardware
Why is this a superior approach?
It is not necessarily superior, but works. One situation it is better (not that I have seen this used) is if the ethernet driver needs to reset the hardware ethernet. If it doesn't know the MAC, you are now without a MAC address.
It also means you depend on the state of the hardware. You cannot jut issue a full reset to the etherner chip, and set it up fully from there.
In message DCEAAC0833DD314AB0B58112AD99B93B0189DE21@ismail.innsys.innovsys.com you wrote:
One situation it is better (not that I have seen this used) is if the ethernet driver needs to reset the hardware ethernet. If it doesn't know the MAC, you are now without a MAC address.
It also means you depend on the state of the hardware. You cannot jut issue a full reset to the etherner chip, and set it up fully from there.
Right. And one important area where this plays a role in real life is when you have to optimize power consumption on your system (like when runningfrom batteries), and you power on the ethernet port only when you want to use it. Now don't tell me that you want to reaboot your system in such a situation.
It does not matter where the Linux driver is grabbing the MAC address from - from a EEPROM, or from the U-Boto environment, from the bd_info struct or from some OF tree - fact is, that it's the Linux driver's responsibility to program the MAC.
'nuff said.
Best regards,
Wolfgang Denk
In message 200606081731.49365.ngustavson@emacinc.com you wrote:
It's just that the *Linux* *driver* is responsible to initialize =A0it, no matter which boot loader you use and what the boot loader is doing or not doing.
In some cases that would amount to dynamic reassignment, such as in the Coldfire fec, which does not provide the typical load from eeprom
So what? Is there any reason why the Linux ethernet driver could not perform the same actions that U-Boot can perform?
functionality for it's MAC. It must be assigned by software somewhere, I am of the opinion that the bootloader should do it.
You are wrong. It is teh responsibility of the Linux driver to adjust the settings it needs for correct operation.
I look at the bootloader like the BIOS of a PC without the system calls. It initializes the hardware to a minimal point (you've at least got to turn on the DRAM, an IMHO make sure the MAC is valid) and loads the OS.
I agree with the RAM, but the MAC has nothing to do here. The BIOS on a PC does not care about any MAC addresses either.
Best regards,
Wolfgang Denk
So what? Is there any reason why the Linux ethernet driver could not perform the same actions that U-Boot can perform?
Yes, the board won't necessarily be booting a version Linux we specify, or Linux at all for that matter. As an OEM we can't modify every OS in the world to check these things, but we can ensure that the MAC address is correctly installed in the bootloader when we ship it out. If we do not put the MAC address in, there are Linux versions out there(all of them to my knowledge) that won't do it either. Somebody has to take responsibility for it.
It does not matter where the Linux driver is grabbing the MAC address from - from a EEPROM, or from the U-Boto environment, from the bd_info struct or from some OF tree - fact is, that it's the Linux driver's responsibility to program the MAC.
It's a common practice among ethernet controllers, such as the Realtek 8139 and the Intel 82559 to have the MAC address automatically load from the EEPROM upon reset with no intervention from any sort of driver. There isn't really anything incorrect about expecting the MAC to be valid upon loading the OS,It's typical of the industry. I agree you will have a more robust OS if your driver's do not assume things to be initialized, but I would not go so far as to call it the OS's "responsibility". Even if it is, it's not typically being furfilled, so how about some redundancy?
Did your copy of Windows come with a MAC address? Did you buy one for you Linux distro? Of course not, it came with the hardware. It isn't set specifically by the BIOS but it's part of the core package, it has nothing to do with the OS. By putting it in the bootloader I'm attempting to maintain this typical arrangement by delivering a piece of hardware that can use any OS, but comes with a working bootloader and a pre-installed MAC.
Right. And one important area where this plays a role in real life is when you have to optimize power consumption on your system (like when runningfrom batteries), and you power on the ethernet port only when you want to use it. Now don't tell me that you want to reaboot your system in such a situation.
In the systems mentioned above, it's automatically loaded from the EEPROM without intervention from a driver. In the case of the MCF5282, the MAC address is stored in the FEC which is a part of the processor and cannot be effectively powered down without powering down the processor. The PHY can be, but this won't unset the MAC. This solution may or may not be as effective for the ARM. I'd have to do more research to know, but it is certainly effective for the Coldfire.
You are wrong. It is teh responsibility of the Linux driver to adjust the settings it needs for correct operation.
Please offer some justification, or at least evidence of collective agreement for your opinions. To requote your own email: It is wrong always, everywhere and for everyone to believe anything upon insufficient evidence. - W. K. Clifford, British philosopher,
NZG
In message 200606082306.33226.ngustavson@emacinc.com you wrote:
In the systems mentioned above, it's automatically loaded from the EEPROM without intervention from a driver. In the case of the MCF5282, the MAC
You obviously know these things better than me, so I better shut up.
Best regards,
Wolfgang Denk
On Friday 09 June 2006 2:44 am, Wolfgang Denk wrote:
You obviously know these things better than me, so I better shut up.
I've got some hardware experience but you certainly are far more experienced with bootloaders than me. I do value your input and thank you for taking the time to get engaged in this debate.
Nathan Z. Gustavson Engineer & Perpetual student EMAC.Inc - www.emacinc.com
In message 200606090923.18523.ngustavson@emacinc.com you wrote:
On Friday 09 June 2006 2:44 am, Wolfgang Denk wrote:
You obviously know these things better than me, so I better shut up.
I've got some hardware experience but you certainly are far more experienced with bootloaders than me.
Maybe not only bootloaders.
You claim things which you obviously never checked.
For example, you wrote:
It's a common practice among ethernet controllers, such as the Realtek 8139 and the Intel 82559 to have the MAC address automatically load from the EEPROM upon reset with no intervention from any sort of driver.
You obviouly never bothered to spend a thought on *who* reads the MAC address from EEPROM on such systems? These cards don't have any on-board BIOS or so which would do this.
You never bothered to check for example "drivers/rtl8139.c" in the U-Boot sources or "drivers/net/8139*.c" in the Linux kernel tree.
You never bothered to check for example "drivers/eepro100.c" in the U-Boot sources or "drivers/net/e100.c" in the Linux kernel tree.
Otherwise you should have discovered the e100_eeprom_read() resp. read_eeprom() functions in these drivers which do - guess what? - read the MAC address from EEPROM.
The cards you used as example actually *do* have code in their drivers to read the MAC address from the EEPROM and program it into the controller. You see?
But you write:
There isn't really anything incorrect about expecting the MAC to be valid upon loading the OS,It's typical of the industry.
Maybe you should go and read a bit of driver code from some operating systems, before claiming to know what these do or don't do.
Best regards,
Wolfgang Denk
On Friday 09 June 2006 11:56 am, you wrote:
You never bothered to check for example "drivers/rtl8139.c" in the U-Boot sources or "drivers/net/8139*.c" in the Linux kernel tree.
You never bothered to check for example "drivers/eepro100.c" in the U-Boot sources or "drivers/net/e100.c" in the Linux kernel tree.
Your right I didn't check the driver, but I checked the data sheets which states that the MAC is loaded upon any reset. If the driver does it it's purely redundancy
You claim things which you obviously never checked. It's a common practice among ethernet controllers, such as the Realtek 8139 and the Intel 82559 to have the MAC address automatically load from the EEPROM upon reset with no intervention from any sort of driver.
There is nothing about my statement that is not true.
But you write: There isn't really anything incorrect about expecting the MAC to be valid upon loading the OS,It's typical of the industry. Maybe you should go and read a bit of driver code from some operating systems, before claiming to know what these do or don't do.
I stand by my statement. The core system put's it there, regardless of whether the OS reloads it or not. I believe we should do the same.
It is an interesting point however, I was unaware that the drivers are loading the MAC, thank you for pointing it out. Nevertheless, the MAC was already there, this loading is redundant.
NZG.
On Friday 09 June 2006 11:56 am, Wolfgang Denk wrote:
Otherwise you should have discovered the e100_eeprom_read() resp. read_eeprom() functions in these drivers which do - guess what? - read the MAC address from EEPROM.
The cards you used as example actually *do* have code in their drivers to read the MAC address from the EEPROM and program it into the controller. You see?
I'm going through the e100.c code now. The drivers do have code to read and write the MAC address, but I don't see any reference to them actually doing this during normal operation. This sort of thing may give you the capability to write the MAC into the device if ifconfig, but that would be something the OEM would do once and then leave alone.
During diagnostics,
There is a section fo code in e100 that reads out the MAC:
memcpy(netdev->dev_addr, nic->eeprom, ETH_ALEN); if(!is_valid_ether_addr(netdev->dev_addr)) { DPRINTK(PROBE, ERR, "Invalid MAC address from " "EEPROM, aborting.\n"); err = -EAGAIN; goto err_out_free; }
But this reads out the MAC into a net device, registering it's MAC with the OS, not loading into the physical device.
(on page 35 of the 82559ER Fast Ethernet PCI Controller data sheet) The 82559ER performs an automatic read of seven words (0H, 1H, 2H, AH, Bh, Ch and DH) of the EEPROM after the de-assertion of Reset.
(0H, 1H, 2H is the MAC)
Haven't been through the Realtek code yet. But I suspect it's something similar.
NZG
Uncompressing Linux............................................................. ............. done, booting the kernel. Linux version 2.6.16 (root@second) (gcc version 4.0.0 (DENX ELDK 4.0 4.0.0)) #16 Thu Jun 8 03:40:10 AQTT 2006 CPU: ARM920Tid(wb) [41129200] revision 0 (ARMv4T) Machine: Atmel AT91RM9200-DK Memory policy: ECC disabled, Data cache writeback Clocks: CPU 179 MHz, master 59 MHz, main 18.432 MHz CPU0: D VIVT write-back cache CPU0: I cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets CPU0: D cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets Built 1 zonelists Kernel command line: root=/dev/nfs rw nfsroot=${serverip}:${rootpath} ip=${ipadd r}:${serverip}:${gatewayip}:${netmask}:${hostname}::off
Quite apart from the MAC address issue, you need to fix your kernel command line. The variables in the last line above do not make sense to the kernel, it needs to be passed actual IP addresses.
Note: if you don't know what the IP addresses will be (because they are delivered by a DHCP server, for example) you can do this:
setenv bootcmd setenv bootargs root=/dev/nfs rw nfsroot=${serverip}:${rootpath} ... ; bootm ...
Alex
Uncompressing Linux............................................................. ............. done, booting the kernel. Linux version 2.6.16 (root@second) (gcc version 4.0.0 (DENX ELDK 4.0
4.0.0))
#16 Thu Jun 8 03:40:10 AQTT 2006 CPU: ARM920Tid(wb) [41129200] revision 0 (ARMv4T) Machine: Atmel AT91RM9200-DK Memory policy: ECC disabled, Data cache writeback Clocks: CPU 179 MHz, master 59 MHz, main 18.432 MHz CPU0: D VIVT write-back cache CPU0: I cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets CPU0: D cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets Built 1 zonelists Kernel command line: root=/dev/nfs rw nfsroot=${serverip}:${rootpath} ip=${ipadd r}:${serverip}:${gatewayip}:${netmask}:${hostname}::off
Quite apart from the MAC address issue, you need to fix your kernel command line. The variables in the last line above do not make sense to the kernel, it needs to be passed actual IP addresses.
Note: if you don't know what the IP addresses will be (because they are delivered by a DHCP server, for example) you can do this:
setenv bootcmd setenv bootargs root=/dev/nfs rw nfsroot=${serverip}:${rootpath} ... ; bootm ...
Alex
Hi Alex, I tried with your way, it's not work.> U-Boot> printenv
bootdelay=3 baudrate=115200 serverip=192.168.0.182 ipaddr=192.168.0.66 netmask=255.255.255.0 ethaddr=00:10:ec:00:87:73 rootpath=/opt/eldk_arm/arm hostname=mqy gatewayip=192.168.0.182 bootfile=/tftpboot/uImage bootcmd=bootm 10080000 ok=ok macaddr=0010ec008773 stdin=serial stdout=serial stderr=serial bootargs=root=/dev/nfs rw nfsroot=192.168.0.182:/opt/eldk_arm/arm ip=192.168.0.66:192.168.0.182:192.168.0.182:255.255.255.0:mqy::off
Environment size: 433/65532 bytes U-Boot> bootm
## Booting image at 21000000 ... Image Name: Linux-2.6.16 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1103380 Bytes = 1.1 MB Load Address: 20008000 Entry Point: 20008000 Verifying Checksum ... OK OK
Starting kernel ...
Uncompressing Linux....................................................................... . done, booting the kernel.
Linux version 2.6.16 (root@second) (gcc version 4.0.0 (DENX ELDK 4.0 4.0.0)) #16 Thu Jun 8 03:40:10 AQTT 2006
CPU: ARM920Tid(wb) [41129200] revision 0 (ARMv4T)
Machine: Atmel AT91RM9200-DK
Memory policy: ECC disabled, Data cache writeback
Clocks: CPU 179 MHz, master 59 MHz, main 18.432 MHz
CPU0: D VIVT write-back cache
CPU0: I cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets
CPU0: D cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets
Built 1 zonelists
Kernel command line: root=/dev/nfs rw nfsroot=192.168.0.182:/opt/eldk_arm/arm ip=192.168.0.66:192.168.0.182:192.168.0.182:255.255.255.0:mqy::off
AT91: 128 gpio irqs in 4 banks
PID hash table entries: 256 (order: 8, 4096 bytes)
Console: colour dummy device 80x30
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 32MB = 32MB total
Memory: 30044KB available (1844K code, 402K data, 92K init)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
NET: Registered protocol family 16
usbcore: registered new driver usbfs
usbcore: registered new driver hub
NetWinder Floating Point Emulator V0.97 (double precision)
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered (default)
AT91 Real Time Clock driver.
AT91 SPI driver loaded
AT91 Watchdog Timer enabled (5 seconds, nowayout=1)
at91_usart.0: ttyS0 at MMIO 0xfefff200 (irq = 1) is a AT91_SERIAL
at91_usart.1: ttyS1 at MMIO 0xfffc4000 (irq = 7) is a AT91_SERIAL
RAMDISK driver initialized: 16 RAM disks of 32768K size 1024 blocksize
at91_ether: Your bootloader did not configure a MAC address.
eth0: Link down.
eth0: AT91 ethernet at 0xfefbc000 int=24 10-HalfDuplex (00:00:00:00:00:00)
eth0: Davicom 9196 PHY (Copper)
physmap flash device: 200000 at 10000000
phys_mapped_flash: Found 1 x16 devices at 0x0 in 16-bit bank
Amd/Fujitsu Extended Query Table at 0x0041
phys_mapped_flash: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
RedBoot partition parsing not available
at91_cf: irqs det #64, io #0
at91_ohci at91_ohci: AT91 OHCI
at91_ohci at91_ohci: new USB bus registered, assigned bus number 1
at91_ohci at91_ohci: irq 23, io mem 0x00300000
usb usb1: Product: AT91 OHCI
usb usb1: Manufacturer: Linux 2.6.16 ohci_hcd
usb usb1: SerialNumber: at91
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
udc: at91_udc version 8 March 2005
mice: PS/2 mouse device common for all mice
i2c /dev entries driver
at91_i2c at91_i2c: AT91 i2c bus driver.
NET: Registered protocol family 2
IP route cache hash table entries: 512 (order: -1, 2048 bytes)
TCP established hash table entries: 2048 (order: 1, 8192 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
IP-Config: Failed to open eth0
IP-Config: No network devices available.
Looking up port of RPC 100003/2 on 192.168.0.182
portmap: RPC call returned error 101
Root-NFS: Unable to get nfsd port number from server, using default
Looking up port of RPC 100005/1 on 192.168.0.182
portmap: RPC call returned error 101
Root-NFS: Unable to get mountd port number from server, using default
mount: RPC call returned error 101
Root-NFS: Server returned error -101 while mounting /opt/eldk_arm/arm
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)
In message BAY107-DAV17B470DE33C807F80BA54CC5880@phx.gbl 002401c68bbf$6f7dfd20$8ed3fea9@first you wrote:
I tried with your way, it's not work.>
Of course not. The boot arguments is only ONE of things you have to fix. The uninitialized MAC address is still unfixed:
...
at91_ether: Your bootloader did not configure a MAC address. eth0: Link down. eth0: AT91 ethernet at 0xfefbc000 int=24 10-HalfDuplex (00:00:00:00:00:00)
You won't make any progress until you fix this, too.
Best regards,
Wolfgang Denk
I tried with your way, it's not work.>
Of course not. The boot arguments is only ONE of things you have to fix. The uninitialized MAC address is still unfixed:
...
at91_ether: Your bootloader did not configure a MAC address. eth0: Link down. eth0: AT91 ethernet at 0xfefbc000 int=24 10-HalfDuplex
(00:00:00:00:00:00)
You won't make any progress until you fix this, too.
Best regards,
Wolfgang Denk
--
Dear Denk, Thanks for your help, and I do not make any progress till now. Because during my test, my flash error! Because Atmel suggest with AT49BV322 or AT49BV642 to replace AT49BV6416, I modified the "flash.c" "flash.h" to support it. And my board with AT49BV322DT, This is top boot flash, and it work after modify the flash driver of uboot. But it failed today, it looks like the Sector failed, but the second Sector Can work still. Or should I use Bottom boot FLASH? ------------------------------------------------------------------------- U-Boot> protect off 10040000 1006ffff
Un-Protected 3 sectors U-Boot> fli
Bank # 1: Atmel: AT49BV322DT (32Mbit) Size: 4 MB in 71 Sectors Sector Start Addresses: 10000000 (RO) 10010000 (RO) 10020000 10030000 10040000 10050000 10060000 10070000 10080000 10090000 100A0000 100B0000 100C0000 100D0000 100E0000 100F0000 10100000 10110000 10120000 10130000 10140000 10150000 10160000 10170000 10180000 10190000 101A0000 101B0000 101C0000 101D0000 101E0000 101F0000 10200000 10210000 10220000 10230000 10240000 10250000 10260000 10270000 10280000 10290000 102A0000 102B0000 102C0000 102D0000 102E0000 102F0000 10300000 10310000 10320000 10330000 10340000 10350000 10360000 10370000 10380000 10390000 103A0000 103B0000 103C0000 103D0000 103E0000 103F0000 103F2000 103F4000 103F6000 103F8000 103FA000 103FC000 103FE000 U-Boot> erase 10040000 1006ffff
Erasing sector 4 ... ok. Erasing sector 5 ... ok. Erasing sector 6 ... ok. Erased 3 sectors U-Boot> cp.b 21000000 10040000 ffff
Copy to Flash... Flash not Erased U-Boot>
U-Boot> cp.b 21000000 10050000 ffff
Copy to Flash... Flash not Erased U-Boot> U-Boot> cp.b 21000000 103fc000 fff
Copy to Flash... done U-Boot> md 103fc000
103fc000: a502430e 640a022e 0410000b 81188192 .C.....d........ 103fc010: 04024822 24624240 0810a000 28801080 "H..@Bb$.......( 103fc020: f8502400 04a00446 1c140808 88000100 .$P.F........... 103fc030: 13200004 00640611 00c49000 00191182 .. ...d......... 103fc040: 00800022 44460520 00844292 a0998480 "... .FD.B...... 103fc050: 4008a080 41040401 c800100c 01808000 ...@...A........ 103fc060: 71ae44f2 42022020 30004000 90000b8d .D.q .B.@.0.... 103fc070: 00212701 0a004226 9380810c 04989110 .'!.&B.......... 103fc080: 00408101 49220133 a0000105 13408910 ..@.3."I......@. 103fc090: 062ec000 00624006 80214828 10000018 .....@b.(H!..... 103fc0a0: 2000a042 8020cc80 48188391 840d5018 B.. .. ....H.P.. 103fc0b0: 40001018 dc220202 5010901b 01960552 ...@.."....PR... 103fc0c0: 14800143 06030600 98140919 00000c10 C............... 103fc0d0: 002e0010 00607420 80108929 98102800 .... t`.)....(.. 103fc0e0: 6480e681 00082c24 08200881 100c9800 ...d$,.... ..... 103fc0f0: 40842341 4d2185c7 09058988 80000941 A#.@..!M....A... U-Boot> md 21000000
21000000: a502430e 640a022e 0410000b 81188192 .C.....d........ 21000010: 04024822 24624240 0810a000 28801080 "H..@Bb$.......( 21000020: f8502400 04a00446 1c140808 88000100 .$P.F........... 21000030: 13200004 00640611 00c49000 00191182 .. ...d......... 21000040: 00800022 44460520 00844292 a0998480 "... .FD.B...... 21000050: 4008a080 41040401 c800100c 01808000 ...@...A........ 21000060: 71ae44f2 42022020 30004000 90000b8d .D.q .B.@.0.... 21000070: 00212701 0a004226 9380810c 04989110 .'!.&B.......... 21000080: 00408101 49220133 a0000105 13408910 ..@.3."I......@. 21000090: 062ec000 00624006 80214828 10000018 .....@b.(H!..... 210000a0: 2000a042 8020cc80 48188391 840d5018 B.. .. ....H.P.. 210000b0: 40001018 dc220202 5010901b 01960552 ...@.."....PR... 210000c0: 14800143 06030600 98140919 00000c10 C............... 210000d0: 002e0010 00607420 80108929 98102800 .... t`.)....(.. 210000e0: 6480e681 00082c24 08200881 100c9800 ...d$,.... ..... 210000f0: 40842341 4d2185c7 09058988 80000941 A#.@..!M....A...
participants (6)
-
Alex Zeffertt -
Marco Cavallini -
muqiyong -
NZG -
Rune Torgersen -
Wolfgang Denk