[PATCH] EFI Loader: Correct dependencies for EFI_HTTP_BOOT

[E Shattow]

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.

-E