On Sun, Feb 16, 2025 at 10:15:16AM -0600, Tom Rini wrote: > On Sun, Feb 16, 2025 at 07:09:57AM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Sat, 15 Feb 2025 at 11:21, Tom Rini <tr...@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 <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. > > > > Yes I can do that - so are you OK to apply this first? > > No, I am not. It (a) doesn't apply to master (or more appropriately now, > next) and (b) breaks my lab. I'm actually now a little confused about > why qemu_arm64_lwip doesn't break in CI too. I bet it's because while we > do: > - ln -s conf.qemu_arm64_na > /tmp/uboot-test-hooks/bin/travis-ci/conf.qemu_arm64_lwip_na > we don't have a similar link for the boardenv problem (so yes, your > patch to make it say something would be good, but also, ugh, that > https://source.denx.de/u-boot/u-boot/-/jobs/1025936 shows 6 skipped, > nothing passed means we didn't *look* for anything more than green light > / red light). > > So I'm going to go and fix things so qemu_arm64_lwip runs tests for > real, and CI would fail on this series. And Michal, is there a reason we > don't enable network tests in the boardenv files for xilinx? That's > using lwIP now too, but since most of the tests don't run, it would also > not fail there due to being skipped. You can use the qemu boardenv > files as examples of how to automatically get something available for > tftp.
And it looks like Azure would like fail as only gitlab was missing the symlink for the boardenv file. Azure logs get dropped much quicker and I can't see if I have that failure anymore, but I can see most tests run on qemu_arm64_lwip. -- Tom
signature.asc
Description: PGP signature
