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