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 <[EMAIL PROTECTED]>: >> 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. > ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users