[U-Boot-Users] No ethernet link on Lubbock board.
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.
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
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? :-Dstdin=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
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
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.
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.
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
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
participants (3)
-
Ben Warren -
Jerry Van Baren -
Victor