20 byte header on SD8686 rx packets

[Erwin Authried]

Hi Bob,

it looks like you have to use the "packed" attribute for the union as
well as each struct inside the union, otherwise the compiler for the ARM
will align the size to next 32-bit boundary.

-Erwin

Am Samstag, den 11.07.2009, 09:27 +0100 schrieb Bob Dunlop:
> Hi,
> 
> On Fri, Jul 10 at 11:00, Bing Zhao wrote:
> > > 
> > > The problem was a change to the packing of struct rxpd caused when the
> > > new status union was added.  Try as I might I couldn't get it to pack
> > > right.  So since only one field was being used in just one place I
> > > hacked it out.  I know this isn't a good solution, but as I said above
> > > it works for me.
> > 
> > I added the new status/bss union to support different firmware versions.
> ...
> Yes I saw that and I liked the clarification it produced.  Unfortunatly I
> just couldn't get it to pack straight with my compiler.
> 
> > I'm more interested in fixing any issue of RxPD structure packing in rx.c.
> > Could you please enable LIBERTAS_DEBUG and hexdump some data before and after the RxPD is stripped?
> 
> I can do that when I get into the office on Monday but I don't think it will
> help.  The problem is not in the data but in the way the compiler interprets
> the structure.
> 
> We're using a rather old cross compiler for ARM based on gcc 3.4.5
> 
> During my dig I added a printk to display the values of various pointers
> and the offset between p_rx_pd and &p_rx_pd->pkt_ptr was 10 bytes rather
> than the 8 you would expect from a packed structure.
> 
> Try as I might with the packed attribute and various pragmas I couldn't
> get the offset down to 8 bytes until I ripped out the union :(
> 
> 
> The offset of +2 changes the value read for p_rx_pd->pkt_ptr from the
> expected 0x14 to 0x0 and hence the code doesn't skip over the 20 byte
> header.  The 0x14 is still in the correct place in the data stream as
> you can see in the original tcpdumps, it's just the compiler is looking
> in the wrong place.