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

[Victor]

Something more I have found out:

I've looking at drivers/net/lan91c96.c:

I have enabled Debug, and hardcoded my Mac address on get_rom_mac().

I loaded u-boot on my board, and when I run a tftp command I get this:

$ tftp
LAN91C96:smc_close
LAN91C96:smc_shutdown
LAN91C96:smc_open
LAN91C96:smc_reset
LAN91C96:smc_enable
Using MAC Address 00:02:B3:00:8F:3B
*** Warning: no boot file name; using 'C0A80102.img'
TFTP from server 192.168.1.1; our IP address is 192.168.1.2
Filename 'C0A80102.img'.
Load address: 0xa0008000
Loading: LAN91C96: memory allocation, try 1 failed ...
LAN91C96: memory allocation, try 2 failed ...
LAN91C96: memory allocation, try 3 failed ...
LAN91C96: memory allocation, try 4 failed ...
LAN91C96: memory allocation, try 5 failed ...
RCV: STATUS e000 LENGTH    0
RCV: STATUS e000 LENGTH    0
RCV: STATUS e000 LENGTH    0
RCV: STATUS e000 LENGTH    0
RCV: STATUS e000 LENGTH    0
RCV: STATUS e000 LENGTH    0
RCV: STATUS e000 LENGTH    0
RCV: STATUS e000 LENGTH    0
RCV: STATUS e000 LENGTH    0
RCV: STATUS e000 LENGTH    0
RCV: STATUS e000 LENGTH    0
RCV: STATUS e000 LENGTH    0
RCV: STATUS e000 LENGTH    0
RCV: STATUS e000 LENGTH    0
RCV: STATUS e000 LENGTH    0
LAN91C96:smc_close
LAN91C96:smc_shutdown

Abort


2008/7/9 Victor wrote:
> 2008/7/9 Ben Warren <biggerbadderben at gmail.com>:
>> 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.
>
> (I should have written the real ending... :) ). No, it doesn't work.
> I'm constantly looking at my laptop LNK led, and it doesn't get enable
> even a second.
>
>
>>>
>>> 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.
>
> No, it's not confusing at all. I wish I had time too, but my project
> already ended, so I'm using the extra time with the hardware at trying
> to fix some things. And one of them was this one. I will try today
> modifying the function and see what happens.
>
>>
>> regards,
>> Ben
>>
>
> Thanks.
>