It faults, I guess, because of bootd behavior. Explanation:

(I've set bootcmd with my bootm command, and everything that's fine in my environnement (serverip, ethaddr, ..) and had a saveenv. )

* When I've finished updating my rootfs via tftpboot, I do a boot which does what bootcmd variable stores, that's to say, a bootm on a flash adr.

Kernel is runing all right, see : . . eth0: Link now 100-FullDuplex eth0: AT91 ethernet at 0xfefbc000 int=24 100-FullDuplex (12:34:56:78:99:AA) eth0: Davicom 9196 PHY (Copper) .

Then I can execute this command, all right : # ifconfig eth0 192.168.0.5 up && echo Ok || echo Ko Ok #

* After this, on rebooting my board via a reboot command (or even with a pushbutton reset) to test autoboot functionnality on reboot, kernel starts but it seems it can't retrieve my mac addr. : . . 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) .

So naturally I can't execute my ifconfig : # ifconfig eth0 192.168.0.5 up && echo Ok || echo Ko SIOCSIFFLAGS: Cannot assign requested address SIOCSIFFLAGS: Cannot assign requested address Ko #

This is always reproductible, but never happens after my rootfs update.

I've found a temp. solution : run a ping command on serverip or simply adding it to bootcmd like this : bootcmd=ping $(serverip);bootm 0x10020000

It seems "net commands" update environnement or something like that. If no net commands is executed before the boot/bootd command, then it could be a reason why kernel is fed with a left blank, wrong mac addr. value.

Any ideas on more reliable way-to or better way to make it work ?

Thanks in advance

Mathieu Deschamps.