RE: A BUG and ieee1394_transactions.c: FIXME: Lengths not multiple of 4 are not implemented.
Brought to you by:
aeb,
bencollins
From: Rodney R. <re...@de...> - 2000-04-04 22:24:15
|
What Manfred asserts stands to reason, in order for hardware to handle headers, and for future extensibility, the hardware has to be able to parse the header. Thus the big/little endian issue doesn't stand into it: the type of the header is known, it is a bit vector, of fixed variable lengths, whose image, however, requires transposition on the quadlet boundry in little endian RAM but not in big endian RAM. The data field however is a different story its type is not known to the hardware and in little endian the DMA R/W order is reversed over big endian. In my previous discourse, I was not talking about making the ordinal value of a quadlet in memory the same in both boxes, that's an assumption of the type of data contained in the field. I was talking about the definition of binary compatibility here: the order of the bytes are addressed be the same in any box. I will expand further on the example. In order to preserve binary compatibility hardware little endian must(optimally) transpose the byte stream in situ because the DMA R/W order is different during each of these instances depending on DMA transfer size: quadlet, or doublet, or singlet. Examine the following given the message is "12345": LilI BigI Address(8)-> 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 case byte(8:8) RAM-PORT r/w 1 2 3 4 5 x x x 1 2 3 4 5 x x x STREAM(X = swap) 1 2 3 4 5 x x x 1 2 3 4 5 x x x case quadlet(32:8) RAM-PORT r/w 4321 xxx5 1234 5xxx STREAM(no swap) 4 3 2 1 x x x 5 1 2 3 4 5 x x x STREAM(swap) 1 2 3 4 5 x x x 4 3 2 1 x x x 5 From this is should be apparent that, unless hardware swaps, in order for binary compatability to occur, a little endian box must swap the bytes in RAM if DMA is set to do quadlet(32:8) transfers but it does not matter if DMA is set to do byte(8:8) transfers. It also should be noted this has no consequence under some circumstances. A hard drive for instance would save and return the data in the same order regardless if bytes are swapped or not(if the parameters don't change). But, box-to-box communication requires a definition of binary compatability. A few advisories exists here once the swaping issue is resolved. First, when transfering quadlets covered in the case of the OHCI spec. Here the type of the data field is known(a possible assumption, if it be agree that) and the ordinal value is preserved when swap is set and the software does a second swap. Second, when writing data that came in from the data field bound for the header field of another packet, such as the address. Further, this brings up a new issue, if true hardware independence is to be achieved in the interface, some read-only properties of the device(low-level) layer must be known to the service(high-level) layer. Data polarity (big/little endian) is one, another is the GUID of the card. The case of the polarity property is that hardware may implement swapping but some cards may not(see the previous advisory). The case for the GUID is that the ordinal value must be preserved if not it looses its uniqueness and the method of aquisition of this value is hardware dependent. Rodney Rhoton Manfred Weihs wrote: >That is not completely true. Since the header of iso packets is stored >in the first quadlet of the buffer which is handed over to >iso_handler_t, it is not an internal issue of the driver, because also >user space applications get access to it. >BTW: It took me quite a while to find out, that the first quadlet of >this buffer is the 1394-header (stored little endian), then the >header-crc is missing, and then the rest (the data) of the packet >follows (stored big endian). Of course it makes sense that this header >is handed over to the iso handler (because it provides a means to find >out, if the packet has a CIP header), but it could be considered if it >makes more sense to change its byte order (so that _everything_ is big >endian) or to introduce new arguments for the handler (expecially Tag >and perhaps Sy) and remove the header from the buffer. Andreas Bombe wrote: > ... the byte order policy changed, now bytes appear on the bus as > they are ordered in RAM (i.e. no hardware byte swapping is done > anymore on little endian -- except for the header, but this is an > internal issue). |