[PATCH v3 00/46] pxe: Support read_all() for extlinux and PXE

[Simon Glass]

Hi Tom,

On Sat, 15 Feb 2025 at 07:46, Tom Rini <trini at konsulko.com> wrote:
>
> On Sat, Feb 15, 2025 at 05:06:42AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Fri, 24 Jan 2025 at 12:18, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Thu, Dec 05, 2024 at 07:35:39PM -0700, Simon Glass wrote:
> > >
> > > > This series implements read_all() so that it is possible to read all the
> > > > files relating to a bootflow, make adjustments and then boot.
> > > >
> > > > Unfortunately quite a few things stand in the way, so this series
> > > > finishes off several pending items: zboot without CONFIG_CMDLINE,
> > > > required support in pxe_utils and the differing code in the extlinux and
> > > > PXE bootmeths. There is very little new code, but quite a lot of
> > > > refactoring.
> > > >
> > > > The bootm, booti and bootz commands have all been refactored previously,
> > > > so that they can operate without needing CONFIG_CMDLINE to be enabled.
> > > > At the, time, zboot was left alone, since it is x86-specific and a bit
> > > > more trouble.
> > > >
> > > > However it turns out that the booti support doesn't work with compressed
> > > > booti images, so this series resolved that problem too.
> > > >
> > > > This series adds a programatic API for zboot and uses the forthcoming
> > > > bootstd 'image list' to collect information from an extlinux file. It is
> > > > therefore possible to parse the file, load the resulting images and then
> > > > examine/adjust the resulting bootflow, before booting.
> > > >
> > > > The addition of options to extlinux resulted in the PXE and extlinux
> > > > bootmeth having slightly different features. This is tidied up in this
> > > > series, with common functions for both. This allows the same features
> > > > (loading images as a separate step) to be provided for PXE.
> > >
> > > With v4 of 45/46, this fails with lwIP on Pi in the PXE tests now. You
> > > likely don't need more than CONFIG_NET_LWIP=y being added but for
> > > completeness here's everything:
> > > CONFIG_UNIT_TEST=y
> > > # CONFIG_CMD_EFIDEBUG is not set
> > > CONFIG_CMD_BOOTMENU=y
> > > CONFIG_CMD_LOG=y
> > > # CONFIG_CMD_BOOTEFI_SELFTEST is not set
> > > CONFIG_IPV6=y
> > > CONFIG_IPV6_ROUTER_DISCOVERY=y
> > > CONFIG_CMD_TFTPPUT=y
> > > CONFIG_CMD_WGET=y
> > > CONFIG_FIT=y
> > > CONFIG_FIT_SIGNATURE=y
> > > CONFIG_FIT_BEST_MATCH=y
> > > CONFIG_SYS_BOOTM_LEN=0x4000000
> > > CONFIG_NET_LWIP=y
> > > CONFIG_BOOTSTAGE_STASH_ADDR=0x02400000
> > > CONFIG_BOOTSTAGE=y
> > > CONFIG_BOOTSTAGE_STASH=y
> > > CONFIG_CMD_BOOTSTAGE=y
> > > on top of rpi_3_defconfig.
> >
> > I just noticed this response (a bit behind on email), but I don't
> > think it is reasonable to require out-of-tree changes. We just need CI
> > to pass, along with any labs. This whole series seems to have been
> > blocked?
> >
> > If you like, I would be willing to debug it if this series is applied,
> > and send a follow-on patch. I have a second rpi3 in my lab which I
> > could add to gitlab, along with the changes above, so we can catch
> > this sort of thing in future. It would have to be added with some
> > documentation, so others can figure out what is going on. Just to be
> > clear, I have no issue with LWIP, just with this series being blocked
> > due to out-of-tree changes.
>
> I don't know what "out of tree" changes you're referring to. I guess you
> mean the test I noted above? It's only out of tree because you didn't
> follow up with Heinrich's buildman patch to allow using fragments. If
> that was applied then it would be worthwhile to have the Pi targets in
> your lab do more tests, including the above. And please note this is my
> lab that fails.

I suggested a file format to specify combinations that we test. You
wanted them to be created as separate boards. If you don't want to
reconsider my proposal[1] you could create a separate in-tree rpi3
board with these options. That would actually be easier for my lab,
although with Heinrich's patch it wouldn't matter much, as you say.

Heinrich's patch[2] is fine but needs a test. Are you asking me to write it?

Once we figure this out, I will add it to my lab.

Regards,
Simon

[1] https://patchwork.ozlabs.org/project/uboot/patch/20241108152350.3686274-9-sjg@chromium.org/
[2] https://patchwork.ozlabs.org/project/uboot/patch/20241220002156.87780-1-heinrich.schuchardt@canonical.com/