Victor wrote: > This is a problem I've been fighting to for a long time. I'm sure it > would be something stupid I haven't noticed, but I don't know what > else to try. My Linux OS is working flawlessly with a correct eth0 > device, so at least I know it's not (or should not) a hardware > problem. > > No, it looks like the driver has some badly circular logic > Everything else works as expected, but the LAN91C96 driver does not > enable the board network interface. > > So even after the message "Using MAC Address 00:02:b3:00:8f:xx" (assuming "xx" is really "01" or something real) it doesn't work? I think it should. > Environment: > Hardware: Lubbock Board from Intel, wired to an IBM Laptop. > U-boot version: 1.3.3 (tried with 1.3.1, 1.20, same results) > mac address: tried with the one generated by the eth_gen_tool, and the > original hardware one. > Default 'lubbock.h' file, heavy edited one, etc... No luck. > > $ printenv: > U-Boot 1.3.3 (Jul 8 2008 - 19:07:01) > > DRAM: 64 MB > Flash: 64 MB > Hit any key to stop autoboot: 0 > $ printenv > baudrate=115200 > netmask=255.255.0.0 > bootdelay=5 > serverip=192.168.1.1 > ipaddr=192.168.1.2 > bootcmd=bootm 200000 > bootargs=ip=192.168.1.2:192.168.1.1:192.168.1.1:255.255.255.0:pxa:eth0:off > mem=64M root=/dev/nfs nfsroot=192.168.1.1:/rootfs/nfs init=/sbin/init > console=ttyS0,115200 > ethaddr=00:02:b3:00:8f:xx > stdin=serial > stdout=serial > stderr=serial > > Something odd I noticed: > > $ tftpboot > > Warning: MAC addresses don't match: > HW MAC address: 01:00:01:00:01:00 > "ethaddr" value: 00:02:B3:00:8F:xx > Using MAC Address 00:02:B3:00:8F:xx > > Linux detects the correct Mac Address without any configuration, why > u-boot reads 01:00:01:00:01:00? > > Probably the number that's initialized in the device. It's a bogus MAC address, but you're really reading uninitialized data. The problem is this:
tftpboot calls smc_open(), which calls smc_get_ethaddr(), which in turn reads the environment and reads the MAC address registers in the device, comparing them. It then writes the appropriate MAC address to the device's address registers... See the problem? the device's registers aren't non-volatile. What you really want to do is read only from the environment and program the device with that value. The problem really stems from the fact that get_rom_mac() always returns 1. If I had time and hardware I'd help fix this. I would think that things should work as-is, though, and that you should be able to just ignore the warning. Sorry if this is confusing. regards, Ben ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users