Hi All,
Sorry for disturbing the list again.
I am using RTL8139C in our target board which is based on MIPS
IDT32334 processor.
The version of 8139too.c that i am using is 1.0.1 where as I am
using a embedded linux which is based on Linux Kernel
2.4.5-pre1.
When the packet is transmitted out, it is coming out as all
0's(captured using sniffer). I dumped the whole packet in
rtl8139_start_xmit (). The packet is a valid ARP packet.
My doubt is whether this 8139too.c is tested with MIPS processors?
Because in one of the article i found that the supported
processors are ARM, i386 etc.
Can any body throw some light on this?
with best regards,
Nanda
On Tue, Aug 13, 2002 at 10:09:56AM -0000, Nandakumar NarayanaSwamy wrote:
> Hi All,
>
> Sorry for disturbing the list again.
>
> I am using RTL8139C in our target board which is based on MIPS
> IDT32334 processor.
...
> My doubt is whether this 8139too.c is tested with MIPS processors?
> Because in one of the article i found that the supported
> processors are ARM, i386 etc.
( Are you sure you don't want to use 8139cp.c driver ? )
It might. The issue is most likely the ENDIANITY of command
registers, and how they are supported.
The i386 is little-endian machine, and most hardware is made for that.
However in case of embedded systems, there are very system dependent
details no how the host processor accesses PCI-bus, and what happens
then...
Talk with your harware maker. At least the 8139*.c drivers use
cpu_to_le32() and friends for these byte-order mapping issues, but
if there happens some gratuitious byte-order wrap-around when posting
IO from the CPU to the PCI bus, then you have major problems, and
will need experienced kernel hacker to get you thru...
That is, if the CPU does post a big-endian (data byte order) operation
into the bus, and the cpu<->bus host-bridge will not do any magic byte-
order wrap-around, then the driver should just simply work.
Of course with MIPS processors you can have two different byte-orders
active in the system (one at the time, of course). You need to know
which you are using.
> Can any body throw some light on this?
> with best regards,
> Nanda
Hi Matti Aarnio,
Thanks for your response.
Our target board is little endian and some initial code is working
which is compiled in little endian mode. Also the PCI bus will
also work in little endian mode.
Thanks again for your response.
With best regards,
Nanda
On Tue, 13 Aug 2002 Matti Aarnio wrote :
>On Tue, Aug 13, 2002 at 10:09:56AM -0000, Nandakumar
>NarayanaSwamy wrote:
> > Hi All,
> >
> > Sorry for disturbing the list again.
> >
> > I am using RTL8139C in our target board which is based on
>MIPS
> > IDT32334 processor.
>...
> > My doubt is whether this 8139too.c is tested with MIPS
>processors?
> > Because in one of the article i found that the supported
> > processors are ARM, i386 etc.
>
> ( Are you sure you don't want to use 8139cp.c driver ? )
>
> It might. The issue is most likely the ENDIANITY of command
> registers, and how they are supported.
>
> The i386 is little-endian machine, and most hardware is made
>for that.
> However in case of embedded systems, there are very system
>dependent
> details no how the host processor accesses PCI-bus, and what
>happens
> then...
>
> Talk with your harware maker. At least the 8139*.c drivers
>use
> cpu_to_le32() and friends for these byte-order mapping issues,
>but
> if there happens some gratuitious byte-order wrap-around when
>posting
> IO from the CPU to the PCI bus, then you have major problems,
>and
> will need experienced kernel hacker to get you thru...
>
> That is, if the CPU does post a big-endian (data byte order)
>operation
> into the bus, and the cpu<->bus host-bridge will not do any
>magic byte-
> order wrap-around, then the driver should just simply work.
>
>
> Of course with MIPS processors you can have two different
>byte-orders
> active in the system (one at the time, of course). You need
>to know
> which you are using.
>
>
> > Can any body throw some light on this?
> > with best regards,
> > Nanda