[U-Boot-Users] Help U-Boot NFS filesystem.

[U-Boot-Users] Help U-Boot NFS filesystem.

[muqiyong]

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 at 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

[U-Boot-Users] Help U-Boot NFS filesystem.

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If ignorance is bliss, why aren't there more happy people?

[U-Boot-Users] Help U-Boot NFS filesystem.

[Marco Cavallini]

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
-- 
Marco Cavallini
Koan s.a.s. - Bergamo - ITALIA
Embedded and Real-Time Software Engineering
www.KoanSoftware.com   |    www.KaeilOS.com

[U-Boot-Users] Help U-Boot NFS filesystem.

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"May your future be limited only by your dreams."
- Christa McAuliffe

[U-Boot-Users] Help U-Boot NFS filesystem.

[Marco Cavallini]

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.
-- 
Marco Cavallini
Koan s.a.s. - Bergamo - ITALIA
Embedded and Real-Time Software Engineering
www.KoanSoftware.com   |    www.KaeilOS.com

[U-Boot-Users] Help U-Boot NFS filesystem->bootloader MAC

[NZG]

>  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

[U-Boot-Users] Help U-Boot NFS filesystem.

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
But the only way of discovering the limits  of  the  possible  is  to
venture a little way past them into the impossible.
                         - _Profiles of the Future_ (1962; rev. 1973)
                  ``Hazards of Prophecy: The Failure of Imagination''

[U-Boot-Users] Help U-Boot NFS filesystem->bootloader MAC

[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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
What is tolerance? -- it is the consequence of humanity. We  are  all
formed  of frailty and error; let us pardon reciprocally each other's
folly -- that is the first law of nature.                  - Voltaire

[U-Boot-Users] bootloader MAC

[NZG]

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.html
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

[U-Boot-Users] bootloader MAC

[Rune Torgersen]

> -----Original Message-----
> From: u-boot-users-bounces at lists.sourceforge.net 
> [mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf Of NZG
> Sent: Thursday, June 08, 2006 17:32
> To: u-boot-users at 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.

[U-Boot-Users] bootloader MAC

[NZG]

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

[U-Boot-Users] bootloader MAC

[Rune Torgersen]

> -----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.

[U-Boot-Users] bootloader MAC

[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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It is wrong always, everywhere and for everyone to  believe  anything
upon  insufficient  evidence.  - W. K. Clifford, British philosopher,
circa 1876

[U-Boot-Users] bootloader MAC

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Mr. Cole's Axiom:
        The sum of the intelligence on the planet is a constant;
        the population is growing.

[U-Boot-Users] bootloader MAC

[NZG]

> 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 

[U-Boot-Users] bootloader MAC

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The day-to-day travails of the IBM programmer are so amusing to  most
of us who are fortunate enough never to have been one - like watching
Charlie Chaplin trying to cook a shoe.

[U-Boot-Users] Help U-Boot NFS filesystem.

[Alex Zeffertt]

> Uncompressing
> Linux.............................................................
> ............. done, booting the kernel.
> Linux version 2.6.16 (root at 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

[U-Boot-Users] Help U-Boot NFS filesystem.

[muqiyong]

> 
> > Uncompressing
> > Linux.............................................................
> > ............. done, booting the kernel.
> > Linux version 2.6.16 (root at 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 at 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)

[U-Boot-Users] Help U-Boot NFS filesystem.

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
You're dead, Jim.
	-- McCoy, "Amok Time", stardate 3372.7

[U-Boot-Users] bootloader MAC

[NZG]

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

[U-Boot-Users] bootloader MAC

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If there was anything that depressed him more than his own  cynicism,
it was that quite often it still wasn't as cynical as real life.
                                 - Terry Pratchett, _Guards! Guards!_

[U-Boot-Users] bootloader MAC

[NZG]

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.

[U-Boot-Users] bootloader MAC

[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

[U-Boot-Users] Help U-Boot NFS filesystem. (Flash error! maybe I need wait my next board)

[muqiyong]

> > 	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.. at 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    ... at ...A........
103fc060: 71ae44f2 42022020 30004000 90000b8d    .D.q  .B. at .0....
103fc070: 00212701 0a004226 9380810c 04989110    .'!.&B..........
103fc080: 00408101 49220133 a0000105 13408910    .. at .3."I...... at .
103fc090: 062ec000 00624006 80214828 10000018    ..... at b.(H!.....
103fc0a0: 2000a042 8020cc80 48188391 840d5018    B.. .. ....H.P..
103fc0b0: 40001018 dc220202 5010901b 01960552    ... at .."....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#. at ..!M....A...
U-Boot> md 21000000

21000000: a502430e 640a022e 0410000b 81188192    .C.....d........
21000010: 04024822 24624240 0810a000 28801080    "H.. at 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    ... at ...A........
21000060: 71ae44f2 42022020 30004000 90000b8d    .D.q  .B. at .0....
21000070: 00212701 0a004226 9380810c 04989110    .'!.&B..........
21000080: 00408101 49220133 a0000105 13408910    .. at .3."I...... at .
21000090: 062ec000 00624006 80214828 10000018    ..... at b.(H!.....
210000a0: 2000a042 8020cc80 48188391 840d5018    B.. .. ....H.P..
210000b0: 40001018 dc220202 5010901b 01960552    ... at .."....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#. at ..!M....A...