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

[Tom Rini]

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.

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