Re: Bug fix in cl_8900a ethernet driver

[Bob Koninckx <bob dot koninckx at mech dot kuleuven dot ac dot be>]

On Sat, 2003-04-12 at 05:50, Jonathan Larmour wrote:
> Laurent Gonzalez wrote:
> > 
> > It is a good thing to optimise the aligned case, but I don't thing that
> > the performance increase will be significative. The real bottle neck
> > here, is the memory access to the cs8900 that requires more than 100ns
> > for a single 16-bit io write. Even flash devices are faster !
> 
> Ugh. I didn't realise that. Still for the sake of argument I've merged Bob 
> K's patch which he mentioned elsewhere with this and applied it.
> 
> Bob, one of the reasons I decided to take something more like my version 
> of cs8900a_send (so shoot me, I'm biased ;-))


Jifl,

Bang, you're dead ..


> , was because I believe yours 
> wouldn't be right for len==1 in the last iteration of the for loop (it 
> will HAL_WRITE saved_data which would contain the real data in the MSB, 


Which is exactly where you want to have it! From (the very difficult to
interprete correctly, took me some time :) ) AN205 from Cirrus

"20. I'm connecting the SC8900A to a big endian processor and have
switched the high and low order byte connections (D8:15 -> D0:7 and D0:7
-> D8:15). I want to sure that I maintain byte order when doing a memory
space transfer of packets, but require byteswapping when writing to the
control registers on the ethernet controller?

The CS8900 assumes a "little endian" ISA-type system. However, network
byte order is always big-endian. Therefore to minimize software
manipulation of frame data in ISA systems, the CS8900 byte-swaps frame
data internally. The control and status registers are not byte swapped.
In a big-endian system (e.g. Motorola) you can either byte-swap the
network data (to reverse the byte swapping done internally to the
CS8900) in software or you can do it in hardware (byte swap the data
lines to the chip). Byte swapping the data lines is much more efficient;
you will only need to byte swap the control/status/counter values in
software and not the frame data. (Most of the read/writes to the chip
are frame data.) Since network byte order is always big endian this
scheme works without special support on the other end of the network."

Thus, in order to avoid immense overhead you make the host processor
appear to the CS8900 as if it where a little endian machine! This also
implies that the meaning of MSB and LSB on the host processor gets
reversed! Hence, you have to byte swap control registers etc ... and
also, the _MSB_ gets on the bus before the _LSB_. If there's only one
byte to send, it therefore must be in the MSB.

The same thing is also visible here


            if (odd_byte) {
                // Add data to the most significant byte
#if(CYG_BYTEORDER == CYG_LSBFIRST)
                saved_data |= ((cyg_uint16)*data++) << 8;
#elif(CYG_BYTEORDER == CYG_MSBFIRST)
                saved_data = ((cyg_uint16)*data++) | (saved_data << 8);
#endif
                HAL_WRITE_UINT16(cpd->base+CS8900A_RTDATA, saved_data);
                len--;
                odd_byte = false;
            }

The new byte gets into the MSB on a little endian target (meaning that
the old one in the LSB gets on the bus first)
On a big endian target, the new byte gets into the LSB, which implies
that the old one in the MSB gets on the bus first.


pfeeew ... I hope all this makes any sense to you... if not, it's your
time to shoot :-)

In order to be absolutely sure, I applied your patch and indeed, every
frame with an odd number of bytes gets ignored by the other side because
of checksum errors...


> not the LSB), as well as just allowing me to merge it more easily :). So 
> have a look at what I've done to check you're happy.


So sorry, no, not really happy with this as it breaks my application.
This MSB/LSB hocus pocus is the reason why I think this needs to be
retested on little endian targets as well. A small mistake is easily
made and looked over. I can't do it as I appear to be the weirdo who
wants to use it on big endian, platform for which I evidently volunteer
to do the testing.


Bob



> 
> Jifl
-- 
----------------------------------------------------------------------
ir. Bob Koninckx
Katholieke Universiteit Leuven
Division Production Engineering,                   tel.  +32 16 322535
Machine Design and Automation                      fax.  +32 16 322987
Celestijnenlaan 300B                  bob dot koninckx at mech dot kuleuven dot ac dot be
B-3001 Leuven Belgium               http://www.mech.kuleuven.ac.be/pma
----------------------------------------------------------------------