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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Goeffringmann Sent: Tuesday, February 06, 2007 12:45 PM To: [email protected] 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 [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
