Re: [lwip-users] porting lwip to a mips system

[Robert Goeffringmann]

Sorry if I'm being stupid, but isn't the link header size always
2 x 6 bytes mac + 2 bytes ethertype?

In any case, changing it to 16 doesn't have any influence on this at all. 
The code in pbuf.c behaves exactly the same as with PBUF_LINK_HLEN=14, due 
to that alignment code and the size of the ethernet header is hardcoded in 
etharp.c.

Regards,
Robert.

----- Original Message ----- 
From: "Taranowski, Thomas (SWCOE)" <address@hidden>
To: "Mailing list for lwIP users" <address@hidden>
Sent: Wednesday, February 07, 2007 12:14 AM
Subject: RE: [lwip-users] porting lwip to a mips system


Out of curiosity, why did you define the PBUF_LINK_HLEN to be 14?  If
you are using 802.3, it should typically be 16.

-----Original Message-----
From: address@hidden
[mailto:address@hidden
On Behalf Of Robert Goeffringmann
Sent: Tuesday, February 06, 2007 12:45 PM
To: address@hidden
Subject: [lwip-users] porting lwip to a mips system

Hello!

I am currently trying to get lwip to work on a PlayStation 2.
In this process, I've been facing some rather strange effects and I am
wondering if things are actually meant to work this way...

The first issue I ran into was the sys_arch_protect function.
My system works with multiple threads and implements the semaphore
functions
as well.
First I tried to implement sys_arch_protect by disabling interrupts.
This doesn't work because certain functions (e.g. pbuf_free in pbuf.c)
will
use sys_arch_protect (thereby disabling interrupts) and will then (while

interrupts are still disabled) call functions which use semaphores for
inter-thread protection (in this case, pbuf_free may call mem_free).
And well... obviously you can't wait for a semaphore if you've disabled
interrupts in order to prevent thread switching.
The way I understand it, pbuf_free could even be changed so that it
doesn't
need to disable interrupts if the pbuf it's being called on is a memory
buffer.
Or did I overlook a good reason why it works like this?
At some point I had the feeling that this situation occurs with other
functions as well, but so far I couldn't find any.
Anyways, if this can't be changed, I suppose it would be better to
mention
this behaviour in the sys_arch.txt. :)
Now as I implemented sys_arch_protect using a recursive mutex, it works.


The problem I am facing right now is the alignment of packets.
I've set MEM_ALIGNMENT to 4 in my lwipopts.h.
Now, if my netif driver receives a packet, it invokes pbuf_alloc,
receives a correctly aligned buffer, fills it with data and passes it to

lwip.
Works smoothly.

However, if an application sends tcp data (using the socket api, I
didn't
try anything else), all the packets that lwip sends to my netif driver
for
outputting are misaligned by 2 bytes. And looking at pbuf.c, this
actually
seems to be the intention...
I defined PBUF_LINK_HLEN as 14 bytes.
Now, when tcp_enqueue calls pbuf_alloc, pbuf_alloc first computes the
size
it needs for headers. In this case, that's:
20 (PBUF_TRANSPORT_HLEN) + 20 (PBUF_IP_HLEN) + 14 (PBUF_LINK_HLEN) = 54
bytes.
This is then rounded up to 56 bytes in order to match my MEM_ALIGNMENT
of 4
and pbuf->payload is set to that offset, so payload is correctly
aligned.
However, later these header sizes get substracted again and so the
pbuf's
payload
points to an address which is 2 bytes off from the necessary alignment
when
it's passed to netif->linkoutput.
This is especially annoying as I have to pass the data as doublewords of
4
bytes to the hardware's I/O port.
So basically, I have to read it from memory in units of 2 bytes, put it
together to make dwords and pass it to the HW port.
Even worse, though, if the pbuf is splitted, the splits occur in the
middle
of a dword, which makes it even more difficult.

Is this really the intention?

Thanks in advance :)
Robert.




_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users


_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users