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

[Simon Glass]

Hi Tom,

On Sat, 15 Feb 2025 at 11:21, Tom Rini <trini at konsulko.com> wrote:
>
> On Sat, Feb 15, 2025 at 10:24:08AM -0700, Simon Glass wrote:
> > 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?
>
> Yes, I much prefer what Heinrich did. As he's apparently been too busy
> to address your feedback, it would be helpful if you finished it.

Yes I can do that - so are you OK to apply this first?

Regards,
SImon

>
> --
> Tom