Hi Tom, On Mon, Oct 13, 2025 at 7:40 AM Tom Rini <[email protected]> wrote: > > 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 <[email protected]> wrote: > > > > > > Hi Tony, > > > > > > On Sat, 11 Oct 2025 at 20:41, Tony Dinh <[email protected]> wrote: > > > > > > > > On Sat, Oct 11, 2025 at 7:37 AM Tom Rini <[email protected]> wrote: > > > > > > > > > > On Sat, Oct 11, 2025 at 01:03:39PM +0100, Peter Robinson wrote: > > > > > > On Fri, 10 Oct 2025 at 15:28, Tom Rini <[email protected]> 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 <[email protected]> > > > > > > > > --- > > > > > > > > > > > > > > > > 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
Of course you're right! "make menuconfig" works as described above. Thanks, Tony > > 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
