[tulip] Tulip and PowerPC endian issue?
Jim Rowe
rowejames@acmsystems.com
Thu Jan 30 16:49:01 2003
On Thu, 2003-01-30 at 13:15, Donald Becker wrote:
> On 30 Jan 2003, Jim Rowe wrote:
>
> > > There is a bug in the kernel's tulip driver that byte-swaps the
> > > station address when used with the Comet chip.
> >
> > Yes, the tulip driver in kernel 2.4.19 will byte swap the hardware
> > address when running on a CardBus interface on the PPC. It may swap
> > other data, but for sure it swaps the MAC.
> ..
> > Note I still haven't had any success pinging or communicating with the
> > cardbus interface, however the information that is reported by
> > /var/log/messages and ifconfig now looks correct.
> >
> > Has this driver been known to work correctly with a CardBus interface on
> > the PPC? I'm working with some custom hardware and it would be helpful
> > to know if the driver has been tested on such a setup.
>
> Hmmm, not a CardBus interface. There are additional opportunities for
> screwing up with CardBus -- usually broken address space configuration.
I'm not having any luck. I have my network setup properly and I'm not
able to communicate with any devices on the same subnet. The transmit
and receive statistics given by ifconfig show that nothing is going in
or out of the interface.
What type of things should I look for to check for broken address space
configuration?
Here is my /proc/iomem:
80000000-bfffffff : PCI Memory
80000000-803fffff : PCI CardBus #01
80400000-807fffff : PCI CardBus #02
80400000-804003ff : PCI device 1317:1985
bf7f5000-bfbf4fff : PCI CardBus #02
bf800000-bf81ffff : PCI device 1317:1985
bfbf5000-bfbf5fff : Ricoh Co Ltd RL5c476 II (#2)
bfbf6000-bfff5fff : PCI CardBus #01
bfff6000-bfff6fff : Ricoh Co Ltd RL5c476 II
bfff7f00-bfff7fff : CMD Technology Inc PCI0680
bfff8000-bfffbfff : Texas Instruments TSB12LV26 IEEE-1394 Controller
(Link)
bffff800-bfffffff : Texas Instruments TSB12LV26 IEEE-1394 Controller
(Link)
And lspci -v:
root@eth0:~# lspci -v
00:05.0 FireWire (IEEE 1394): Texas Instruments: Unknown device 8020
(prog-if 10 [OHCI])
Flags: bus master, medium devsel, latency 128, IRQ 27
Memory at bffff800 (32-bit, non-prefetchable) [size=2K]
Memory at bfff8000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [44] Power Management version 1
00:06.0 IDE interface: CMD Technology Inc: Unknown device 0680 (rev 01)
(prog-if 85 [Master SecO PriO])
Subsystem: CMD Technology Inc: Unknown device 0680
Flags: bus master, medium devsel, latency 128, IRQ 28
I/O ports at fff8 [size=8]
I/O ports at fff4 [size=4]
I/O ports at ffe8 [size=8]
I/O ports at ffe4 [size=4]
I/O ports at ffd0 [size=16]
Memory at bfff7f00 (32-bit, non-prefetchable) [size=256]
Expansion ROM at <unassigned> [disabled] [size=512K]
Capabilities: [60] Power Management version 2
00:07.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 80)
Flags: bus master, medium devsel, latency 168, IRQ 30
Memory at bfff6000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=00, secondary=01, subordinate=01, sec-latency=176
Memory window 0: bfbf6000-bfff5000 (prefetchable)
Memory window 1: 80000000-803ff000
I/O window 0: 0000bfd0-0000ffcf
I/O window 1: 00004000-000040ff
16-bit legacy interface ports at 0001
00:07.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 80)
Flags: bus master, medium devsel, latency 168, IRQ 30
Memory at bfbf5000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=00, secondary=02, subordinate=02, sec-latency=176
Memory window 0: bf7f5000-bfbf4000 (prefetchable)
Memory window 1: 80400000-807ff000
I/O window 0: 00007fd0-0000bfcf
I/O window 1: 00004400-000044ff
16-bit legacy interface ports at 0001
02:00.0 Ethernet controller: Bridgecom, Inc: Unknown device 1985 (rev
11)
Subsystem: Netgear: Unknown device 511a
Flags: bus master, medium devsel, latency 32, IRQ 30
I/O ports at 8000 [size=256]
Memory at 80400000 (32-bit, non-prefetchable) [size=1K]
Expansion ROM at bf800000 [size=128K]
Capabilities: [c0] Power Management version 2
I'm not required to use a tulip-based card for my project. I'm
considering using a 3c59x-based CardBus PC Card to see if I have any
better luck. Any suggesstions?
--
Jim Rowe
Advanced CounterMeasure Systems
Email: jrowe@acmsystems.com