[PATCH] bootstd: Allow PXE boot to be disabled

[Tom Rini]

On Sun, Oct 12, 2025 at 08:12:59PM -0700, Tony Dinh wrote:
> Hi Simon,
> 
> On Sat, Oct 11, 2025 at 11:52 PM Simon Glass <sjg at chromium.org> wrote:
> >
> > Hi Tony,
> >
> > On Sat, 11 Oct 2025 at 20:41, Tony Dinh <mibodhi at gmail.com> wrote:
> > >
> > > On Sat, Oct 11, 2025 at 7:37 AM Tom Rini <trini at konsulko.com> wrote:
> > > >
> > > > On Sat, Oct 11, 2025 at 01:03:39PM +0100, Peter Robinson wrote:
> > > > > On Fri, 10 Oct 2025 at 15:28, Tom Rini <trini at konsulko.com> wrote:
> > > > > >
> > > > > > On Thu, Oct 09, 2025 at 10:29:17PM -0700, Tony Dinh wrote:
> > > > > >
> > > > > > > Make it possible to disable CMD_PXE.
> > > > > > > Remove unnecessary PXE_UTILS selection in BOOTMETH_EXTLINUX config.
> > > > > > > In extlinux_boot(), invoke pxe utils only when
> > > > > > > CONFIG_BOOTMETH_EXTLINUX_PXE is enabled.
> > > > > > >
> > > > > > > This patch results in about 9K reduction in image size when
> > > > > > > PXE boot is disabled.
> > > > > > >
> > > > > > > Signed-off-by: Tony Dinh <mibodhi at gmail.com>
> > > > > > > ---
> > > > > > >
> > > > > > >  boot/Kconfig             |  3 +--
> > > > > > >  boot/bootmeth_extlinux.c | 18 ++++++++++--------
> > > > > > >  2 files changed, 11 insertions(+), 10 deletions(-)
> > > > > >
> > > > > > Is some part of the symbol logic here wrong? A challenge is that "PXE"
> > > > > > is also where the logic to parse extlinux.conf style files came from,
> > > > > > and I thought we had split those two out. And then there's this:
> > > > > >
> > > > > > >
> > > > > > > diff --git a/boot/Kconfig b/boot/Kconfig
> > > > > > > index 2993cd7f9ba..403ce4c3d46 100644
> > > > > > > --- a/boot/Kconfig
> > > > > > > +++ b/boot/Kconfig
> > > > > > > @@ -421,10 +421,10 @@ config BOOT_DEFAULTS_CMDS
> > > > > > >       select CMD_PART if PARTITIONS
> > > > > > >       select CMD_DHCP if CMD_NET
> > > > > > >       select CMD_PING if CMD_NET
> > > > > > > -     select CMD_PXE if CMD_NET
> > > > > > >       select CMD_BOOTI if ARM64
> > > > > > >       select CMD_BOOTZ if ARM && !ARM64
> > > > > > >       imply CMD_MII if NET
> > > > > > > +     imply CMD_PXE if CMD_NET
> >
> > If you only want scripts, then perhaps you can enable just what you
> > need, e.g. BOOTMETH_SCRIPT? You may need to disable BOOT_DEFAULTS and
> > choose your own options.
> 
> Indeed, that was a missing config when I tried with BOOTSTD_FULL
> disabled. But there is more, please see below.
> 
> >
> > > > > >
> > > > > > This is one of the things where defaults isn't supposed to be so easy to
> > > > > > get out of. How many platforms are you wanting to then disable CMD_PXE
> > > > > > on to save space?
> > > > >
> > > > > PXE is generally being removed in a lot of cases as it's not
> > > > > considered secure and now we have HTTP Boot there are other means of
> > > > > doing network booting so I think we'll see more and more situations
> > > > > where we want to disable PXE.
> > > > >
> > > > > This is actually something I've been meaning to look at so it's
> > > > > something I would love to see :)
> > >
> > > Glad to hear :)
> > >
> > > >
> > > > And in the world where we also can't just remove ATAGS support because
> > > > distros (Debian at least) still boots some modern platforms via ATAGS +
> > > > appended device tree, the high level options for "boot this anywhere"
> > > > need to perhaps be different from "very modern requirements only
> > > > distro". I'm not objecting to be clear.
> > >
> > > As Tom suggested previously, perhaps looking from a different angle.
> > > We can disable BOOTSTD_FULL and then try adding only options that are
> > > needed for a board. Unfortunately this approach did not work when I
> > > tried it in the past. It seems for bootstd to work well, we need to
> > > take the whole thing by enabling BOOTSTD_FULL.
> >
> > If you end up trying it again, please give a few details here as we
> > might be able to improve this. When bootstd was first introduced we
> > had very tight code-size constraints, so quite a few features are only
> > provided if BOOTSTD_FULL is enabled. Tom has suggested enabling more
> > features in the base implementation but we haven't really figured out
> > which.
> 
> The problem is when a board already has enabled BOOTSTD_FULL or has
> been updated with Distro Boot (CONFIG_DISTRO_DEFAULTS), all the
> necessary configurations such as ext2, ext4, efi partition,... are
> implied, therefore were removed from board defconfig. They must be
> added back.
> 
> I actually tried this just now and it does work booting a script from
> USB drive with this combination:
> 
> CONFIG_BOOTMETH_SCRIPT=y
> CONFIG_DISTRO_DEFAULTS=y    (this also selects CMD_PXE, but it's OK
> for this test)
> # CONFIG_BOOTSTD_FULL is not set
> 
> I think it's quite cumbersome to add each of the necessary configs
> back to the board defconfig. Not as easy as removing CMD_PXE, or other
> CMD_x to remove a capability.

There's two parts to this. In turns of changing the defconfig to start
with, you shouldn't need to "add back", if you do:
$ make foo_defconfig
$ make menuconfig # Disable full, etc
$ make savedefconfig
$ cp defconfig configs/foo_defconfig

But the second part is that yes, it's at least currently intentional to
be cumbersome to break the "all stock distributions work in all expected
use cases" option. If you have networking, networking works in U-Boot,
but you're not allowing users to install distros over the network like
they should be able to expect to, it shouldn't be easy.

I am open to splitting the current option up in to multiple parts, along
the lines of legacy options, modern options, disk options, network
options since as Peter noted earlier in this thread, PXE is going away
in favour of HTTP(s) boot. But we still have lots of legacy boards and
distros to support.

-- 
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/20251013/b4db9afb/attachment.sig>