[PATCH] EFI Loader: Correct dependencies for EFI_HTTP_BOOT

[Tom Rini]

On Wed, Mar 18, 2026 at 06:18:26PM -0700, E Shattow wrote:
> 
> On 3/18/26 07:57, Tom Rini wrote:
> > On Wed, Mar 18, 2026 at 11:00:14AM +0000, Peter Robinson wrote:
> >> On Wed, 18 Mar 2026 at 01:47, Tom Rini <trini at konsulko.com> wrote:
> >>>
> >>> On Tue, Mar 17, 2026 at 04:08:22PM +0000, Peter Robinson wrote:
> >>>> On Tue, 17 Mar 2026 at 13:51, Tom Rini <trini at konsulko.com> wrote:
> >>>>>
> >>>>> On Tue, Mar 17, 2026 at 08:42:39AM +0100, Heinrich Schuchardt wrote:
> >>>>>> Am 17. März 2026 08:03:47 MEZ schrieb Ilias Apalodimas <ilias.apalodimas at linaro.org>:
> >>>>>>> Hi Tom,
> >>>>>>>
> >>>>>>> On Tue, 17 Mar 2026 at 03:24, Tom Rini <trini at konsulko.com> wrote:
> >>>>>>>>
> >>>>>>>> As exposed by "make randconfig", we have an issue with the dependencies
> >>>>>>>> for EFI_HTTP_BOOT. As this is implemeneted by running commands (as seen
> >>>>>>>> by what it selects) it must depend on CMDLINE as well.
> >>>>>>>>
> >>>>>>>> Signed-off-by: Tom Rini <trini at konsulko.com>
> >>>>>>>
> >>>>>>> In theory, you can configure UEFI with a set of prebuilt boot options.
> >>>>>>> If one of them is http(s) the device will boot even if CMDLINE is not
> >>>>>>> selected. I am not against this patch, but we will remove the
> >>>>>>> possibility to build a firmware without cmdline that just boots to
> >>>>>>> whatever is was preconfigured
> >>>>>>>
> >>>>>>> Cheers
> >>>>>>> /Ilias
> >>>>>>>> ---
> >>>>>>>> Cc: Heinrich Schuchardt <xypron.glpk at gmx.de>
> >>>>>>>> Cc: Ilias Apalodimas <ilias.apalodimas at linaro.org>
> >>>>>>>> ---
> >>>>>>>>  lib/efi_loader/Kconfig | 1 +
> >>>>>>>>  1 file changed, 1 insertion(+)
> >>>>>>>>
> >>>>>>>> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> >>>>>>>> index b5f81e0ff530..a9b2f813e1d5 100644
> >>>>>>>> --- a/lib/efi_loader/Kconfig
> >>>>>>>> +++ b/lib/efi_loader/Kconfig
> >>>>>>>> @@ -600,6 +600,7 @@ config EFI_BOOTMGR
> >>>>>>>>  config EFI_HTTP_BOOT
> >>>>>>>>         bool "EFI HTTP Boot support"
> >>>>>>>>         depends on NET || NET_LWIP
> >>>>>>>> +       depends on CMDLINE
> >>>>>>>>         select CMD_NET
> >>>>>>>>         select CMD_DHCP
> >>>>>>>>         select CMD_DNS
> >>>>>>
> >>>>>> Having to select commands here to get network is what needs to change. The network commands and EFI_HTTP_BOOT both should depend on configuration symbols for the protocol implementations.
> >>>>>
> >>>>> Yes. And this is about fixing missing dependencies, today.
> >>>>>
> >>>>>> @Tom: Do we have a target release when to finish the move to the LWIP stack?
> >>>>>
> >>>>> We do not. I'm not yet sure if all the various use cases of the legacy
> >>>>> stack are fully supported now (I don't recall off-hand the NFS series
> >>>>> state right now for example).
> >>>>
> >>>> I did see NFS patches go through the list.
> >>>
> >>> I saw the NFS support as well shortly after hitting send, as part of a
> >>> randconfig build.
> >>>
> >>>> I think there's also likely some legacy usecases where non parity is
> >>>> likely fine too.
> >>>
> >>> Perhaps the question really is, for the distribution folks, what are the
> >>> use cases you know of where lwIP doesn't have support yet? That's the
> >>> first big hurdle towards, likely, saying EFI_LOADER implies NET_LWIP
> >>> maybe, since I know there's cases there lwIP is better for.
> >>
> >> I don't know of any problems or missing features, I turned in on by
> >> default in Fedora across all devices for Fedora 43 (The 2025.07
> >> builds) because I wanted UEFI HTTP boot and haven't had any bug
> >> reports, and I suspect the features like UEFI HTTP is more useful for
> >> most distros than loss of other features because a lot of vendors are
> >> moving away from legacy tech like BOOTP/TFTP because of lack of
> >> security and the fact most of those technologies are not usable on the
> >> Edge/outside of the data centre.
> >>
> >> I know of one device which has tight SPI flash space (Jetson p3450)
> >> which I need to look at closer to see what I can trim, but that's a
> >> side point on that device.
> > 
> > OK. I know the NFS for lwIP request came from somewhere and wasn't just
> > a fun side project. Pretty sure anyhow. So I wonder if there's other
> > things like that that someone knows of.
> > 
> 
> The ability to push data from memory to a remote file is missing from
> LwIP (no tftpput). I have suggested previously that an simple U-Boot
> HTTP server configured to respond with data from a memory address and
> range, and/or to serve files from a filesystem, would be interesting
> although not exactly replacing the functionality missing from the lack
> of tftpput.

Oh yeah. And since lwIP already has tftpget, I would hope adding "put"
isn't too much work.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260318/a3dbd226/attachment.sig>