RE: [lwip-users] lwip + sam7x = udef exception

[Goldschmidt Simon]

Hi Kieran,


> This suggests that p->payload is also not 4-byte aligned (as "+ IPH_HL
> (iphdr) * 4" should not change the bottom 2 bits), which in 
> turn suggests that when the data was put into the pbuf, it 
> wasn't done in a way that guarantees the headers and payloads 
> will fall on the required alignment.  For example, with 
> ethernet which has 14 byte headers, a driver will normally 
> arrange to put the ethernet header on at a 2 byte offset, so 
> that the IP header, TCP header and packet data all align on 4 
> byte boundaries.

Are you suggesting on a 32-bit-platform, ethernet packets should always
be received in a buffer which is 2 byte aligned, not 4 byte aligned??
This is be a real problem since
a) some MACs with DMA support are only able to store to 4 byte aligned
addresses and
b) in my case I have to share frames with another stack which expects
them to be 4 byte aligned.

Also, the ethernetif.c shipped with lwIP 1.2.0 does this alignment only
if ETH_PAD_SIZE is defined as 2. Since (except data alignment, but the
"application" has to deal with that) this seems to apply only to IP
addresses (only in IP header, not in ARP header) and TCP sequence
numbers, I think there should be an option for this alignment!

This could be done by changing IP addresses in the IP header to struct
ip_addr2 and a get-/set-seqno macro for TCP which handles the
(mis-)alignment of the 32-bit values in the TCP header.

I know this is a speed issue, also. But copying the received data from a
4 byte aligned buffer to a 2 byte aligned buffer is much more expensive.


Simon