Notice: We have migrated to GitLab launching 2024-05-01 see here: https://gitlab.rtems.org/

#1712 closed enhancement (fixed)

Add LWIP Support to RTEMS

Reported by: Joel Sherrill Owned by: Joel Sherrill
Priority: normal Milestone: 6.1
Component: network/legacy Version: 4.11
Severity: minor Keywords:
Cc: ralf.corsepius@…, thomas.doerfler@…, chrisj@…, sebastian.huber@… Blocked By:
Blocking:

Description (last modified by Joel Sherrill)

This port was done by Marcello Presulli <m.presulli@…> and has been in my inbox for a while. I think I have merged most of their BSP specific work but the lwip has been pending. They managed to run LWIP+SNMP and an application in something like 128K RAM

Here are some email fragments about it.

For now we have just finished to port the latest lwip-1.3.2 based on the latest rtems 4.9.4 version successfully including
a test_app for pings.

We have stressed the stack with ping floods (packetsize 1400 Bytes interval ~150ms) about 250.000 sequences or more without
packet losses and an average latency of 2ms.

Additional we have adopted a new bsp target for the mcf5225x platform.

To lwip now:

we integrated it directly via the autoconfigure/automake process under the
rtems cpukit/liblwip subtree and therefore it gets built with rtems
when u configure it with --enable-networking=lwip appropriately.
The driver on the other side we put it in libcpu/m68k/mcf5225x and it got
built in the library context of the librtemsbsp.a.
The driver has only 2 references on lwip headers ...

To the bsp:

The bsp we have adopted from mcf52223 and have created it as a own
bsp-target=mcf5225x also via the autoconfig/automake mechanism.
In the bsp itself i have modified the bsp_get_CPU_clock_speed() and some
improvements in the console driver and PIT2 timer interrupt.
The bsp_start() we have defined as weak symbol so we don't have to touch
the "empty" bsp_start() of rtems coz it's platform-circuit
specific you know.

Attachments (1)

mcf5225x+lwip.zip (470.1 KB) - added by Joel Sherrill on 10/28/10 at 15:14:22.
LWIP + BSP modifications as received

Download all attachments as: .zip

Change History (12)

Changed on 10/28/10 at 15:14:22 by Joel Sherrill

Attachment: mcf5225x+lwip.zip added

LWIP + BSP modifications as received

comment:1 Changed on 10/28/10 at 15:14:37 by Joel Sherrill

Cc: Sebastian Huber added

comment:2 Changed on 10/28/10 at 15:14:49 by Joel Sherrill

Cc: Chris Johns added

comment:3 Changed on 10/28/10 at 15:15:22 by Joel Sherrill

Cc: thomas.doerfler added

comment:4 Changed on 10/28/10 at 15:15:37 by Joel Sherrill

Cc: Ralf Corsepius added

comment:5 Changed on 11/02/10 at 23:41:51 by Ralf Corsepius

Replying to comment:8:

Sebastian, others,

I have had second thoughts about putting this in RTEMS. I agree that it would
be better to submit the port to LWIP and let it live there.

IMO, this proposal is non-applicable, because a network stack's interactions are deeply woven with the OS.

Considering this, using an external networking stack introduces bootstrapping problems (== problems building rtems).

That said, to me, LWIP is a binary decision: Switch from BSD or LWIP rsp. to forget about it - I am very strongly leaning towards the latter and consider all proposal so far to be beyond reason.

comment:6 Changed on 11/22/14 at 14:28:21 by Gedare Bloom

Description: modified (diff)
Owner: changed from Eric Norum to Joel Sherrill
Status: newassigned
Version: HEAD4.11

comment:7 Changed on 11/22/14 at 14:28:41 by Gedare Bloom

Resolution: wontfix
Status: assignedclosed

comment:8 Changed on 11/22/14 at 14:29:10 by Gedare Bloom

Milestone: 4.115.0
Resolution: wontfix
Status: closedreopened

comment:9 Changed on 03/20/16 at 01:17:10 by Pavel Pisa

Some more LwIP pointers and ideas are expressed at next Wiki page

https://devel.rtems.org/wiki/Packages/LWIP

comment:10 Changed on 11/09/17 at 06:26:42 by Sebastian Huber

Milestone: 5.06.1

Milestone renamed

comment:11 Changed on 12/16/21 at 15:53:06 by Joel Sherrill

Description: modified (diff)
Resolution: fixed
Status: reopenedclosed

lwip is currently in its own repo and has better support. Closing.

Note: See TracTickets for help on using tickets.