lwip 1.4.0

[liamstask]

Looks like it was recently released: http://download.savannah.gnu.org/releases/lwip

I seem to remember somebody mentioning they had already started to go through the process of upgrading the ChibiOS port layer to 1.4.0, but I couldn't find it after a quick search. If anybody has this lying around (even an in-progress version) I'd be happy to take a look and help get it updated. Otherwise, I shall forge ahead and post when I've made some progress. Thanks.

[brian360]

I used one of the release candidates for 1.4.0 for the STM32 Ethernet demo. Check out the "stm32_ethernet_wrapper" branch in SVN and look under demos/ARMCM3-STM32F107-LWIP. I plan on upgrading my project to 1.4.0 soon, but likely won't get to it for another couple of weeks.

Also check out the last few posts of this thread: viewtopic.php?f=3&t=23&start=20

[Giovanni]

Hi Liam and Brian,

I hope to put lwIP 1.4.0 as default after finishing the work on the SDC driver. Until then if there are updates about lwIP please post in this thread, I remember there was an issue in the arch layer related to time constants.

Giovanni

[liamstask]

Sounds great - thanks for the info Brian.

[Giovanni]

Hi,

I fixed the lwIP 1.3.0 interface layer in the repository. Does it require changes in order to switch to lwIP 1.4.0?

Giovanni

[liamstask]

There definitely are some other changes, but it doesn't look like anything *too* major has changed in the port layer. I haven't done any full testing, but it looks like Brian's changes capture all the important stuff.

A couple interesting notes:
- sys_arch_timeouts() is not needed any more, so we don't need to keep the per-thread pointer like we used to
- the following info was added to docs/rawapi.txt:

--- Zero-copy MACs

To achieve zero-copy on transmit, the data passed to the raw API must
remain unchanged until sent. Because the send- (or write-)functions return
when the packets have been enqueued for sending, data must be kept stable
after that, too.

This implies that PBUF_RAM/PBUF_POOL pbufs passed to raw-API send functions
must *not* be reused by the application unless their ref-count is 1.

For no-copy pbufs (PBUF_ROM/PBUF_REF), data must be kept unchanged, too,
but the stack/driver will/must copy PBUF_REF'ed data when enqueueing, while
PBUF_ROM-pbufs are just enqueued (as ROM-data is expected to never change).

Also, data passed to tcp_write without the copy-flag must not be changed!

Therefore, be careful which type of PBUF you use and if you copy TCP data
or not!

I haven't fully investigated the implications of this, but seemed like it might be worth tracking down

edit: if the STM32 and SAM7X256 are both going to use lwIP, it might also be nice to move the lwip support code somewhere more general - into either the HAL or the 'various' folder within the ChibiOS source tree, as opposed to the demo folder that it is currently located in.

[Giovanni]

Hi Liam,

You are right, probably the best place is ./os/various. No having to hold that extra data per-thread is a huge improvement too.

Giovanni

[liamstask]

I've done some more testing, and things seem to be working fine based off the stable 2.2.x branch in SVN. I have attached a .zip of the 'arch' folder that provides the lwip support. The main changes:
* all lwIP interface routines updated for new signatures
* sys_arch_timeouts() is removed - can also remove corresponding section in chconf.h
* remove function declarations from sys_arch.h - these are included within lwip in sys.h
* note - a couple new files are used within lwIP, but it seems to be mainly organizational as opposed to adding new functionality: ${LWIP}/src/core/def.c and ${LWIP}/src/core/timers.c should be added to the Makefile, and ${LWIP}/src/netif/loopif.c can be removed.

I would prefer not to commit these on trunk, as I don't have a SAM7X256 demo board to test with at the moment, only a SAM7X256-based Make Controller. Hopefully it's simple to apply these changes and add support for 1.4.0. It might also be worth announcing on the lwIP mailing list once it's included...would be nice for some more people to see the excellent support for lwIP in ChibiOS.

[Giovanni]

Thanks Liam,

I have that board and will do the testing.

Giovanni

[Giovanni]

Hi,

I retested the lwIP demo using the newest code and it seems everything is OK. I just had to make a couple of trivial changes into the webthread code.

I went through the lwIP code, in my opinion the option for recursive locks is not really required, at least I haven't found any code where the no-reentrant locks rule is violated. I would suggest disabling this option, the OS would become much more efficient.

Would be possible to re-test the STM32 demo using the newly integrated code?

Giovanni