2008/8/12 Richard Danter radanter@googlemail.com:
2008/8/8 Richard Danter radanter@googlemail.com:
I now have a driver that initialises the 64120 and U-Boot sees the bridge and Ethernet card. So far so good! But the Ethernet card can not ping anything on my network.
This is what I see...
--8<-- U-Boot 1.3.3-svn19 (Aug 8 2008 - 15:32:31)
Board: PPMC MIPS DRAM: 64 MB Flash: 4 MB In: serial Out: serial Err: serial Net: i82559#0 => pci Scanning PCI devices on bus 0 BusDevFun VendorId DeviceId Device Class Sub-Class _____________________________________________________________ 00.00.00 0x11ab 0x4620 Bridge device 0x00 00.07.00 0x8086 0x1030 Network controller 0x00 00.08.00 0x1011 0x0026 Bridge device 0x04 => printenv baudrate=9600 ethact=i82559#0 ipaddr=192.168.1.84 netmask=255.255.255.0 stdin=serial stdout=serial stderr=serial
Environment size: 113/32764 bytes => ping 192.168.1.1 i82559#0: Tx error buffer not ready ping failed; host 192.168.1.1 is not alive --8<--
My guess is that there is probably still something I did not do in the PCI init code, but I have looked at as many examples as I can find and I can't see anything amiss. Any thoughts on what would case the buffer not to work even though the Ethernet card itself is seen and appears to be detected correctly?
OK, I think I figured this out but still not sure what the correct solution is...
The tx_ring and rx_ring buffers are being placed in SDRAM accessed via kseg0 (cached) at 0x8nnnnnnn. After trying to ping and getting the timeout I see the following at this location...
83ff8d30: 00000240 308dff03 16080001 00002203 ...@0.........". 83ff8d40: 01002e00 60088868 0040f284 31050000 ....`..h.@..1...
But if I look at the same physical address via kseg1 (uncached) at 0xAnnnnnnn then I see...
a3ff8d30: 00a00240 308dff03 16080001 00002203 ...@0.........". a3ff8d40: 01002e00 60088868 0040f284 31050000 ....`..h.@..1...
I think the 00a0 at the start is the correct value (Tx done). Can anyone confirm this?
Confirmed myself.
Solution so far is either to run U-Boot from KSeg1 or to pepper the eepro100 driver with flush_cache() calls. Both seem to work though running in kseg1 is slower.
Has anyone else used an eepro100 on a MIPS target? Did you hit the same problem?
I can see that some drivers (e.g. rtl8139.c) already have the flush_cache() calls.
Rich
If so then the problem seems to be that I need to read/write the Tx/Rx buffers via kseg1 and not kseg0. But in general I want as much data and code in kseg0 as possible to get the best performance.
What is the correct way to do this?
Thanks Rich