On Mon, May 27, 2024 at 09:34:34AM -0600, Tom Rini wrote:
> On Fri, May 24, 2024 at 06:19:55PM +0200, Jerome Forissier wrote:
>
> > Prepare the introduction of the lwIP (lightweight IP) TCP/IP stack by
> > adding a new net-lwip/ directory and the NET_LWIP symbol. At this
> > point, enabling NET_LWIP simply disables NET. Subsequent commits will
> > introduce the lwIP code, re-work the NETDEVICE integration and port
> > some of the NET commands and features to lwIP.
> >
> > SPL_NET cannot be enabled when NET_LWIP=y. SPL_NET pulls some symbols
> > that are part of NET (such as arp_init(), arp_timeout_check(),
> > arp_receive(), net_arp_wait_packet_ip()). lwIP support in SPL may be
> > added later.
> >
> > Similarly, DFU_TFTP is not compatible with NET_LWIP because it depends
> > on net_loop(), tftp_timeout_ms, tftp_timeout_count_max. Let's add a
> > dependency on !NET_LWIP for now.
> >
> > Signed-off-by: Jerome Forissier <jerome.foriss...@linaro.org>
> [snip]
> > diff --git a/Kconfig b/Kconfig
> > index 82df59f176e..758256ab121 100644
> > --- a/Kconfig
> > +++ b/Kconfig
> > @@ -747,6 +747,8 @@ source "env/Kconfig"
> >
> >  source "net/Kconfig"
> >
> > +source "net-lwip/Kconfig"
> > +
> >  source "drivers/Kconfig"
> >
> >  source "fs/Kconfig"
>
> I think we need to instead rework this to a choice statement instead so
> that in the end we have something like:

+ 1

> choice "Networking stack"
> config NO_NET
>   bool "No networking support"
> config NET
>   bool "Legacy U-Boot networking stack"
> config NET_LWIP
>   bool "Use lwIP for networking stack"
>
> if NET_LEGACY
> source "net/Kconfig"
> endif
>
> if NET_LWIP
> source "net-lwip/Kconfig"
> endif
>
> And then SPL_NET still depends on !NET_LWIP for now and we sort out the
> problems with different networking stacks in SPL vs full U-Boot later
> on.

That's an excellent idea tbh. We can now decouple SPL and u-boot proper
using different stacks and fix the more difficult to debug SPL issues in
time. Once we feel happy we can switch over to LWIP completely

Thanks
/Ilias
>
> --
> Tom


Reply via email to