[RFC PATCH 0/5] LWIP stack integration

Maxim Uvarov maxim.uvarov at linaro.org
Mon May 22 11:01:12 CEST 2023


My measurements for binary after LTO looks like:

U-boot WGET |  LWIP WGET + ping |  LWIP WGET| diff bytes| diff %
870728            |  915000                    | 912560          | 41832
| 4.8

BR,
Maxim.

On Fri, 19 May 2023 at 09:52, Tom Rini <trini at konsulko.com> wrote:

> On Fri, May 19, 2023 at 04:17:06PM +0300, Ilias Apalodimas wrote:
> > Hi Tom,
> >
> > Apologies for being late to the party
> >
> > > On Thu, May 11, 2023 at 09:52:04AM -0400, Tom Rini wrote:
> > > On Fri, May 05, 2023 at 10:25:24AM +0000, Maxim Uvarov wrote:
> > >
> > > > Greetings,
> > > >
> > > > This RFC patchset is an attempt to try to use an already existing IP
> network stack inside U-boot.
> > > > U-Boot recently got basic TCP/IP support, implementing wget, but in
> order to get a full IP stack
> > > > with new features (e.g ipv6), it would be preferable to use an
> established embedded ip library,
> > > > instead of rewriting the code from scratch.
> > > >
> > > > For this experiment LWIP network stack was selected:
> > > > https://savannah.nongnu.org/git/?group=lwip
> > > >
> > > > LWIP main features include:
> > > > - Protocols: IP, IPv6, ICMP, ND, MLD, UDP, TCP, IGMP, ARP, PPPoS,
> PPPoE
> > > > - DHCP client, DNS client (incl. mDNS hostname resolver),
> AutoIP/APIPA (Zeroconf),
> > > >   SNMP agent (v1, v2c, v3, private MIB support & MIB compiler)
> > > > - APIs: specialized APIs for enhanced performance, optional
> Berkeley-alike socket API
> > > > - Extended features: IP forwarding over multiple network interfaces,
> TCP congestion control,
> > > >   RTT estimation and fast recovery/fast retransmit
> > > > - Addon applications: HTTP(S) server, SNTP client, SMTP(S) client,
> ping, NetBIOS nameserver,
> > > >   mDNS responder, MQTT client, TFTP server.
> > > >
> > > > This RFC work is a demo to enable lwIP (lightweight IP) which is a
> widely used open-source
> > > > TCP/IP stack designed for embedded systems for U-boot. That will
> allow using already
> > > > written network applications for microcontrollers.
> > > >
> > > > lwIP is licensed under a BSD-style license:
> http://lwip.wikia.com/wiki/License.
> > > > Which should be compatible with u-boot.
> > > >
> > > > In the current RFC I tried to use minimal changes to better see how
> LWIP code can be embedded into
> > > > U-boot. Patches implement ping and wget commands work. Both commands
> are currently copy pasting and
> > > > reusing lwIP examples.  Whether we want to add the final application
> in U-Boot or lwIP is up to
> > > > discussion, but the current approach was the easiest one for an RFC.
> > >
> > > I'm honestly not sure this is the most useful way of doing an RFC.  The
> > > long term goal would be that we replace our existing net/ with lwIP,
> > > yes? So what I'd see as more valuable is what it looks like to limit
> > > yourself to either sandbox or some QEMU target, disable the current
> > > network stack, and instead use lwIP to support just cmd/net.c so that
> > > the scope of the conversion is visible.  Then the size comparison you
> do
> > > should be between platform + net + cmd/net.c (and the rest of
> networking
> > > turned off) and platform + lwip + cmd/net.c converted.
> >
> > This might be a bit too much imho.  How about replacing the TCP stack
> which
> > is new an under heavy devel as well.  If we do that we could replace lwip
> > with the version Maxim proposes and check the difference between
> > U-boot + homegrown TCP + wget
> > U-Boot + LWIP (for tcp only) + new wget
> >
> > That would give us an idea before trying to replace the UDP portion which
> > is way bigger
>
> I guess we can try that as a starting point and see what things look
> like.  My gut feeling however is that's not going to look like a win.
>
> --
> Tom
>


More information about the U-Boot mailing list