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.