[U-Boot-Users] No ethernet link on Lubbock board.

[Ben Warren]

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