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 <tr...@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 <tr...@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. -- Tom
signature.asc
Description: PGP signature
