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

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

[Victor]

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.

Everything else works as expected, but the LAN91C96 driver does not
enable the board network interface.

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?

Any idea?

I will thank a lubbock.h file in case you got one with ethernet
working, just to try it out.


Thanks a lot.

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

[Jerry Van Baren]

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.
> 
> Everything else works as expected, but the LAN91C96 driver does not
> enable the board network interface.
> 
> 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
                          ^^
                          Hmmm, what base are we using here?  Base 26?
                          :-D
> 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

I'm assuming you didn't hand edit in the "xx" out of paranoia.

> Linux detects the correct Mac Address without any configuration, why
> u-boot reads 01:00:01:00:01:00?

Beats me.

> Any idea?

Try a valid MAC address?

Good luck,
gvb

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

[Victor]

2008/7/8 Jerry Van Baren <gerald.vanbaren@ge.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.
>>
>> Everything else works as expected, but the LAN91C96 driver does not
>> enable the board network interface.
>>
>> 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
>
>                         ^^
>                         Hmmm, what base are we using here?  Base 26?
>                         :-D
>>
>> 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
>
> I'm assuming you didn't hand edit in the "xx" out of paranoia.

Yeah, I did hand edit it. Paranoia? Just a habit, don't know why...

>
>> Linux detects the correct Mac Address without any configuration, why
>> u-boot reads 01:00:01:00:01:00?
>
> Beats me.
>
>> Any idea?
>
> Try a valid MAC address?

As I said, i tried the ones generated by gen_eth_addr with no luck.

>
> Good luck,
> gvb
>

[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

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

[Victor]

2008/7/9 Ben Warren <biggerbadderben@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.

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

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

[Jerry Van Baren]

Victor wrote:
> 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 ...

Ahhh, that and grep ought to narrow down the error domain hugely.  Bingo:
<http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=drivers/net/lan91c96.c;h=c23a4000a2860cfa596fd864c11da8ff4b22c4b6;hb=c956717ab25c962ef49d49064dfc73f4edcba1fb#l449>

Now you just have to figure out why the chip doesn't want to allocate 
memory or perhaps you have a problem with the MEMORY_WAIT_TIME 
definition?  Maybe your CPU is too fast, maybe you need a delay in the 
loop or need to make the loop (MEMORY_WAIT_TIME) longer?

Best regards,
gvb

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

[Victor]

I tried making the loop slower, but no luck.

Just another thing I found today. If you reboot from a working Linux
(ctr-alt-del), ethernet works flawlessly on u-boot !!!!!!!

2008/7/9 Jerry Van Baren <gerald.vanbaren@ge.com>:
> Victor wrote:
>>
>> 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 ...
>
> Ahhh, that and grep ought to narrow down the error domain hugely.  Bingo:
> <http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=drivers/net/lan91c96.c;h=c23a4000a2860cfa596fd864c11da8ff4b22c4b6;hb=c956717ab25c962ef49d49064dfc73f4edcba1fb#l449>
>
> Now you just have to figure out why the chip doesn't want to allocate memory
> or perhaps you have a problem with the MEMORY_WAIT_TIME definition?  Maybe
> your CPU is too fast, maybe you need a delay in the loop or need to make the
> loop (MEMORY_WAIT_TIME) longer?
>
> Best regards,
> gvb
>