| Message ID | 20241206023626.2456858-1-sjg@chromium.org |
|---|---|
| Headers | show |
| Series | pxe: Support read_all() for extlinux and PXE | expand |
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. To sync up with what I said on IRC, this breaks test/py/tests/test_net_boot.py likely due to changes in the output.
Hi Tom, On Thu, 16 Jan 2025 at 16:28, Tom Rini <trini@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. > > To sync up with what I said on IRC, this breaks > test/py/tests/test_net_boot.py likely due to changes in the output. I am taking a look at this, but I'm really not sure how to set up test_net_pxe_boot_config test I have this in my py/ellesmere/u_boot_boardenv_rpi_3_32b.py file: env__pxe_boot_test_skip = False env__net_pxe_bootable_file = { 'fn': 'default.boot', 'addr': 0x10000000, # 'size': 74, 'timeout': 50000, 'pattern': 'Linux', 'valid_label': '1', 'invalid_label': '2', 'exp_str_invalid': 'Skipping install for failure retrieving', 'local_label': '3', 'exp_str_local': 'missing environment variable: localcmd', 'empty_label': '4', 'exp_str_empty': 'No kernel given, skipping boot', 'check_type': 'boot_error', 'check_pattern': 'ERROR', } This is what I see when running test_net_pxe_boot_config : test/py/tests/test_net_boot.py +u-boot-test-reset rpi_3_32b rpi3 {lab mode} Building U-Boot in pytest-source dir for rpi_3_32b Bootstrapping U-Boot from dir /tmp/b/rpi_3_32b Writing U-Boot using method rpi3 cat: /sys/class/block/sdz1/size: No such file or directory cat: /sys/class/block/sdz1/size: No such file or directory {lab ready in 10.4s: U-Boot 2025.01-rc6-00508-gd6da3dbaef57-dirty (Jan 20 2025 - 12:11:05 -0700)} skip False U-Boot> setenv autoload no U-Boot> U-Boot> dhcp Waiting for Ethernet connection... done. BOOTP broadcast 1 DHCP client bound to address 192.168.4.50 (4 ms) U-Boot> U-Boot> echo $bootfile U-Boot> U-Boot> setenv pxefile_addr_r 10000000 U-Boot> U-Boot> pxe get missing environment variable: pxeuuid Retrieving file: pxelinux.cfg/01-b8-27-eb-b4-f9-f2 Waiting for Ethernet connection... done. Using smsc95xx_eth device TFTP from server 192.168.4.1; our IP address is 192.168.4.50 Filename 'pxelinux.cfg/01-b8-27-eb-b4-f9-f2'. Load address: 0x10000000 Loading: * TFTP error: 'File not found' (1) Not retrying... Retrieving file: pxelinux.cfg/C0A80432 Waiting for Ethernet connection... done. Using smsc95xx_eth device TFTP from server 192.168.4.1; our IP address is 192.168.4.50 Filename 'pxelinux.cfg/C0A80432'. Load address: 0x10000000 Loading: * TFTP error: 'File not found' (1) Not retrying... Retrieving file: pxelinux.cfg/C0A8043 Waiting for Ethernet connection... done. Using smsc95xx_eth device TFTP from server 192.168.4.1; our IP address is 192.168.4.50 Filename 'pxelinux.cfg/C0A8043'. Load address: 0x10000000 Loading: * TFTP error: 'File not found' (1) Not retrying... Retrieving file: pxelinux.cfg/C0A804 Waiting for Ethernet connection... done. Using smsc95xx_eth device TFTP from server 192.168.4.1; our IP address is 192.168.4.50 Filename 'pxelinux.cfg/C0A804'. Load address: 0x10000000 Loading: * TFTP error: 'File not found' (1) Not retrying... Retrieving file: pxelinux.cfg/C0A80 Waiting for Ethernet connection... done. Using smsc95xx_eth device TFTP from server 192.168.4.1; our IP address is 192.168.4.50 Filename 'pxelinux.cfg/C0A80'. Load address: 0x10000000 Loading: * TFTP error: 'File not found' (1) Not retrying... Retrieving file: pxelinux.cfg/C0A8 Waiting for Ethernet connection... done. Using smsc95xx_eth device TFTP from server 192.168.4.1; our IP address is 192.168.4.50 Filename 'pxelinux.cfg/C0A8'. Load address: 0x10000000 Loading: * TFTP error: 'File not found' (1) Not retrying... Retrieving file: pxelinux.cfg/C0A Waiting for Ethernet connection... done. Using smsc95xx_eth device TFTP from server 192.168.4.1; our IP address is 192.168.4.50 Filename 'pxelinux.cfg/C0A'. Load address: 0x10000000 Loading: * TFTP error: 'File not found' (1) Not retrying... Retrieving file: pxelinux.cfg/C0 Waiting for Ethernet connection... done. Using smsc95xx_eth device TFTP from server 192.168.4.1; our IP address is 192.168.4.50 Filename 'pxelinux.cfg/C0'. Load address: 0x10000000 Loading: * TFTP error: 'File not found' (1) Not retrying... Retrieving file: pxelinux.cfg/C Waiting for Ethernet connection... done. Using smsc95xx_eth device TFTP from server 192.168.4.1; our IP address is 192.168.4.50 Filename 'pxelinux.cfg/C'. Load address: 0x10000000 Loading: * TFTP error: 'File not found' (1) Not retrying... Retrieving file: pxelinux.cfg/default-arm-bcm283x-rpi Waiting for Ethernet connection... done. Using smsc95xx_eth device TFTP from server 192.168.4.1; our IP address is 192.168.4.50 Filename 'pxelinux.cfg/default-arm-bcm283x-rpi'. Load address: 0x10000000 Loading: * TFTP error: 'File not found' (1) Not retrying... Retrieving file: pxelinux.cfg/default-arm-bcm283x Waiting for Ethernet connection... done. Using smsc95xx_eth device TFTP from server 192.168.4.1; our IP address is 192.168.4.50 Filename 'pxelinux.cfg/default-arm-bcm283x'. Load address: 0x10000000 Loading: ################################################## 64 Bytes 4.9 KiB/s done Bytes transferred = 64 (40 hex) Config file '<NULL>' found U-Boot> U-Boot> pxe boot 10000000 Retrieving file: pxelinux.cfg/default-arm Waiting for Ethernet connection... done. Using smsc95xx_eth device TFTP from server 192.168.4.1; our IP address is 192.168.4.50 Filename 'pxelinux.cfg/default-arm'. Load address: 0x10000044 Loading: ################################################## 349 Bytes 30.3 KiB/s done Bytes transferred = 349 (15d hex) Retrieving file: pxelinux.cfg/default Waiting for Ethernet connection... done. Using smsc95xx_eth device TFTP from server 192.168.4.1; our IP address is 192.168.4.50 Filename 'pxelinux.cfg/default'. Load address: 0x100001a4 Loading: ################################################## 108 Bytes 9.8 KiB/s done Bytes transferred = 108 (6c hex) Linux boot selections 1: Boot kernel 2: Invalid boot 3: Local boot 4: Empty boot Enter choice: 3 3: Local boot missing environment variable: localcmd U-Boot> pxe boot 10000000 Retrieving file: pxelinux.cfg/default-arm Waiting for Ethernet connection... done. Using smsc95xx_eth device TFTP from server 192.168.4.1; our IP address is 192.168.4.50 Filename 'pxelinux.cfg/default-arm'. Load address: 0x10000044 Loading: ################################################## 349 Bytes 19.5 KiB/s done Bytes transferred = 349 (15d hex) Retrieving file: pxelinux.cfg/default Waiting for Ethernet connection... done. Using smsc95xx_eth device TFTP from server 192.168.4.1; our IP address is 192.168.4.50 Filename 'pxelinux.cfg/default'. Load address: 0x100001a4 Loading: ################################################## 108 Bytes 9.8 KiB/s done Bytes transferred = 108 (6c hex) Linux boot selections 1: Boot kernel 2: Invalid boot 3: Local boot 4: Empty boot Enter choice: 4 4: Empty boot No kernel given, skipping boot 1: Boot kernel Retrieving file: Image Waiting for Ethernet connection... done. Using smsc95xx_eth device TFTP from server 192.168.4.1; our IP address is 192.168.4.50 Filename 'Image'. Load address: 0x80000 Loading: ################################################## 6 Bytes 0 Bytes/s done Bytes transferred = 6 (6 hex) Retrieving file: rootfs.cpio.gz.u-boot Waiting for Ethernet connection... done. Using smsc95xx_eth device TFTP from server 192.168.4.1; our IP address is 192.168.4.50 Filename 'rootfs.cpio.gz.u-boot'. Load address: 0x2700000 Loading: ################################################## 30.6 MiB 995.1 KiB/s done Bytes transferred = 32123014 (1ea2886 hex) Retrieving file: system.dtb Waiting for Ethernet connection... done. Using smsc95xx_eth device TFTP from server 192.168.4.1; our IP address is 192.168.4.50 Filename 'system.dtb'. Load address: 0x2600000 Loading: ################################################## 11 Bytes 1000 Bytes/s done Bytes transferred = 11 (b hex) zimage: Bad magic! 2: Invalid boot Retrieving file: kernels/install.bin Waiting for Ethernet connection... done. Using smsc95xx_eth device TFTP from server 192.168.4.1; our IP address is 192.168.4.50 Filename 'kernels/install.bin'. Load address: 0x80000 Loading: * TFTP error: 'File not found' (1) Not retrying... Skipping install for failure retrieving kernel 3: Local boot missing environment variable: localcmd U-Boot> F Do you have a passing run I could compare against, and/or a boardenv file that works? Thanks, Simon
On Mon, Jan 20, 2025 at 12:20:06PM -0700, Simon Glass wrote: > Hi Tom, > > On Thu, 16 Jan 2025 at 16:28, Tom Rini <trini@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. > > > > To sync up with what I said on IRC, this breaks > > test/py/tests/test_net_boot.py likely due to changes in the output. > > I am taking a look at this, but I'm really not sure how to set up > test_net_pxe_boot_config test > > I have this in my py/ellesmere/u_boot_boardenv_rpi_3_32b.py file: > > env__pxe_boot_test_skip = False > env__net_pxe_bootable_file = { > 'fn': 'default.boot', > 'addr': 0x10000000, > # 'size': 74, > 'timeout': 50000, > 'pattern': 'Linux', > 'valid_label': '1', > 'invalid_label': '2', > 'exp_str_invalid': 'Skipping install for failure retrieving', > 'local_label': '3', > 'exp_str_local': 'missing environment variable: localcmd', > 'empty_label': '4', > 'exp_str_empty': 'No kernel given, skipping boot', > 'check_type': 'boot_error', > 'check_pattern': 'ERROR', > } > > This is what I see when running test_net_pxe_boot_config : > > test/py/tests/test_net_boot.py +u-boot-test-reset rpi_3_32b rpi3 > {lab mode} > Building U-Boot in pytest-source dir for rpi_3_32b > Bootstrapping U-Boot from dir /tmp/b/rpi_3_32b > Writing U-Boot using method rpi3 > cat: /sys/class/block/sdz1/size: No such file or directory > cat: /sys/class/block/sdz1/size: No such file or directory > > {lab ready in 10.4s: U-Boot 2025.01-rc6-00508-gd6da3dbaef57-dirty (Jan > 20 2025 - 12:11:05 -0700)} > skip False > U-Boot> setenv autoload no > U-Boot> U-Boot> dhcp > Waiting for Ethernet connection... done. > BOOTP broadcast 1 > DHCP client bound to address 192.168.4.50 (4 ms) > U-Boot> U-Boot> echo $bootfile > > U-Boot> U-Boot> setenv pxefile_addr_r 10000000 > U-Boot> U-Boot> pxe get > missing environment variable: pxeuuid > Retrieving file: pxelinux.cfg/01-b8-27-eb-b4-f9-f2 > Waiting for Ethernet connection... done. > Using smsc95xx_eth device > TFTP from server 192.168.4.1; our IP address is 192.168.4.50 > Filename 'pxelinux.cfg/01-b8-27-eb-b4-f9-f2'. > Load address: 0x10000000 > Loading: * > TFTP error: 'File not found' (1) > Not retrying... > Retrieving file: pxelinux.cfg/C0A80432 > Waiting for Ethernet connection... done. > Using smsc95xx_eth device > TFTP from server 192.168.4.1; our IP address is 192.168.4.50 > Filename 'pxelinux.cfg/C0A80432'. > Load address: 0x10000000 > Loading: * > TFTP error: 'File not found' (1) > Not retrying... > Retrieving file: pxelinux.cfg/C0A8043 > Waiting for Ethernet connection... done. > Using smsc95xx_eth device > TFTP from server 192.168.4.1; our IP address is 192.168.4.50 > Filename 'pxelinux.cfg/C0A8043'. > Load address: 0x10000000 > Loading: * > TFTP error: 'File not found' (1) > Not retrying... > Retrieving file: pxelinux.cfg/C0A804 > Waiting for Ethernet connection... done. > Using smsc95xx_eth device > TFTP from server 192.168.4.1; our IP address is 192.168.4.50 > Filename 'pxelinux.cfg/C0A804'. > Load address: 0x10000000 > Loading: * > TFTP error: 'File not found' (1) > Not retrying... > Retrieving file: pxelinux.cfg/C0A80 > Waiting for Ethernet connection... done. > Using smsc95xx_eth device > TFTP from server 192.168.4.1; our IP address is 192.168.4.50 > Filename 'pxelinux.cfg/C0A80'. > Load address: 0x10000000 > Loading: * > TFTP error: 'File not found' (1) > Not retrying... > Retrieving file: pxelinux.cfg/C0A8 > Waiting for Ethernet connection... done. > Using smsc95xx_eth device > TFTP from server 192.168.4.1; our IP address is 192.168.4.50 > Filename 'pxelinux.cfg/C0A8'. > Load address: 0x10000000 > Loading: * > TFTP error: 'File not found' (1) > Not retrying... > Retrieving file: pxelinux.cfg/C0A > Waiting for Ethernet connection... done. > Using smsc95xx_eth device > TFTP from server 192.168.4.1; our IP address is 192.168.4.50 > Filename 'pxelinux.cfg/C0A'. > Load address: 0x10000000 > Loading: * > TFTP error: 'File not found' (1) > Not retrying... > Retrieving file: pxelinux.cfg/C0 > Waiting for Ethernet connection... done. > Using smsc95xx_eth device > TFTP from server 192.168.4.1; our IP address is 192.168.4.50 > Filename 'pxelinux.cfg/C0'. > Load address: 0x10000000 > Loading: * > TFTP error: 'File not found' (1) > Not retrying... > Retrieving file: pxelinux.cfg/C > Waiting for Ethernet connection... done. > Using smsc95xx_eth device > TFTP from server 192.168.4.1; our IP address is 192.168.4.50 > Filename 'pxelinux.cfg/C'. > Load address: 0x10000000 > Loading: * > TFTP error: 'File not found' (1) > Not retrying... > Retrieving file: pxelinux.cfg/default-arm-bcm283x-rpi > Waiting for Ethernet connection... done. > Using smsc95xx_eth device > TFTP from server 192.168.4.1; our IP address is 192.168.4.50 > Filename 'pxelinux.cfg/default-arm-bcm283x-rpi'. > Load address: 0x10000000 > Loading: * > TFTP error: 'File not found' (1) > Not retrying... > Retrieving file: pxelinux.cfg/default-arm-bcm283x > Waiting for Ethernet connection... done. > Using smsc95xx_eth device > TFTP from server 192.168.4.1; our IP address is 192.168.4.50 > Filename 'pxelinux.cfg/default-arm-bcm283x'. > Load address: 0x10000000 > Loading: ################################################## 64 Bytes > 4.9 KiB/s > done > Bytes transferred = 64 (40 hex) > Config file '<NULL>' found > U-Boot> U-Boot> pxe boot 10000000 > Retrieving file: pxelinux.cfg/default-arm > Waiting for Ethernet connection... done. > Using smsc95xx_eth device > TFTP from server 192.168.4.1; our IP address is 192.168.4.50 > Filename 'pxelinux.cfg/default-arm'. > Load address: 0x10000044 > Loading: ################################################## 349 Bytes > 30.3 KiB/s > done > Bytes transferred = 349 (15d hex) > Retrieving file: pxelinux.cfg/default > Waiting for Ethernet connection... done. > Using smsc95xx_eth device > TFTP from server 192.168.4.1; our IP address is 192.168.4.50 > Filename 'pxelinux.cfg/default'. > Load address: 0x100001a4 > Loading: ################################################## 108 Bytes > 9.8 KiB/s > done > Bytes transferred = 108 (6c hex) > Linux boot selections > 1: Boot kernel > 2: Invalid boot > 3: Local boot > 4: Empty boot > Enter choice: 3 > 3: Local boot > missing environment variable: localcmd > U-Boot> pxe boot 10000000 > Retrieving file: pxelinux.cfg/default-arm > Waiting for Ethernet connection... done. > Using smsc95xx_eth device > TFTP from server 192.168.4.1; our IP address is 192.168.4.50 > Filename 'pxelinux.cfg/default-arm'. > Load address: 0x10000044 > Loading: ################################################## 349 Bytes > 19.5 KiB/s > done > Bytes transferred = 349 (15d hex) > Retrieving file: pxelinux.cfg/default > Waiting for Ethernet connection... done. > Using smsc95xx_eth device > TFTP from server 192.168.4.1; our IP address is 192.168.4.50 > Filename 'pxelinux.cfg/default'. > Load address: 0x100001a4 > Loading: ################################################## 108 Bytes > 9.8 KiB/s > done > Bytes transferred = 108 (6c hex) > Linux boot selections > 1: Boot kernel > 2: Invalid boot > 3: Local boot > 4: Empty boot > Enter choice: 4 > 4: Empty boot > No kernel given, skipping boot > 1: Boot kernel > Retrieving file: Image > Waiting for Ethernet connection... done. > Using smsc95xx_eth device > TFTP from server 192.168.4.1; our IP address is 192.168.4.50 > Filename 'Image'. > Load address: 0x80000 > Loading: ################################################## 6 Bytes > 0 Bytes/s > done > Bytes transferred = 6 (6 hex) > Retrieving file: rootfs.cpio.gz.u-boot > Waiting for Ethernet connection... done. > Using smsc95xx_eth device > TFTP from server 192.168.4.1; our IP address is 192.168.4.50 > Filename 'rootfs.cpio.gz.u-boot'. > Load address: 0x2700000 > Loading: ################################################## 30.6 MiB > 995.1 KiB/s > done > Bytes transferred = 32123014 (1ea2886 hex) > Retrieving file: system.dtb > Waiting for Ethernet connection... done. > Using smsc95xx_eth device > TFTP from server 192.168.4.1; our IP address is 192.168.4.50 > Filename 'system.dtb'. > Load address: 0x2600000 > Loading: ################################################## 11 Bytes > 1000 Bytes/s > done > Bytes transferred = 11 (b hex) > zimage: Bad magic! > 2: Invalid boot > Retrieving file: kernels/install.bin > Waiting for Ethernet connection... done. > Using smsc95xx_eth device > TFTP from server 192.168.4.1; our IP address is 192.168.4.50 > Filename 'kernels/install.bin'. > Load address: 0x80000 > Loading: * > TFTP error: 'File not found' (1) > Not retrying... > Skipping install for failure retrieving kernel > 3: Local boot > missing environment variable: localcmd > U-Boot> F > > Do you have a passing run I could compare against, and/or a boardenv > file that works? I didn't test this on 32bit ARM, only 64bit. For Pi 3: env__net_uses_usb = True env__net_dhcp_server = True env__tftp_boot_test_skip = False env__net_tftp_bootable_file = { 'fn': 'v6.6/image.fit.nocomp', 'addr': 0x00200000, 'size': 85984256, 'crc32': '754c839a', 'pattern': 'Linux', 'config': 'conf-852', } # Details regarding a file that may be read from a TFTP server. This variable # may be omitted or set to None if PXE testing is not possible or desired. env__net_pxe_bootable_file = { 'fn': 'default', 'addr': 0x00200000, 'size': 64, 'timeout': 50000, 'pattern': 'Linux', 'valid_label': '1', 'invalid_label': '2', 'exp_str_invalid': 'Skipping install for failure retrieving', 'local_label': '3', 'exp_str_local': 'missing environment variable: localcmd', 'empty_label': '4', 'exp_str_empty': 'No kernel given, skipping boot', } # False or omitted if a PXE boot test should be tested. # If PXE boot testing is not possible or desired, set this variable to True. # For example: If pxe configuration file is not proper to boot env__pxe_boot_test_skip = False And: $ cat /srv/tftp/pxelinux.cfg/default label Linux menu label Boot kernel kernel Image fdt system.dtb initrd rootfs.cpio.gz.u-boot $ cat /srv/tftp/pxelinux.cfg/default-arm menu title Linux boot selections menu include pxelinux.cfg/default label install menu label Invalid boot kernel kernels/install.bin append console=ttyAMA0,38400 debug earlyprintk initrd initrds/uzInitrdDebInstall label local menu label Local boot append root=/dev/sdb1 localboot 1 label boot menu label Empty boot $ cat /srv/tftp/pxelinux.cfg/01-b8-27-eb-fc-64-a6 menu include pxelinux.cfg/default-arm timeout 50 default Linux And kernels/install.bin, etc, do not exist. Only v6.6/image.fit.nocomp exists.
-Bin Hi Tom, On Mon, 20 Jan 2025 at 16:45, Tom Rini <trini@konsulko.com> wrote: > > On Mon, Jan 20, 2025 at 12:20:06PM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 16 Jan 2025 at 16:28, Tom Rini <trini@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. > > > > > > To sync up with what I said on IRC, this breaks > > > test/py/tests/test_net_boot.py likely due to changes in the output. > > > > I am taking a look at this, but I'm really not sure how to set up > > test_net_pxe_boot_config test > > > > I have this in my py/ellesmere/u_boot_boardenv_rpi_3_32b.py file: > > > > env__pxe_boot_test_skip = False > > env__net_pxe_bootable_file = { > > 'fn': 'default.boot', > > 'addr': 0x10000000, > > # 'size': 74, > > 'timeout': 50000, > > 'pattern': 'Linux', > > 'valid_label': '1', > > 'invalid_label': '2', > > 'exp_str_invalid': 'Skipping install for failure retrieving', > > 'local_label': '3', > > 'exp_str_local': 'missing environment variable: localcmd', > > 'empty_label': '4', > > 'exp_str_empty': 'No kernel given, skipping boot', > > 'check_type': 'boot_error', > > 'check_pattern': 'ERROR', > > } > > > > This is what I see when running test_net_pxe_boot_config : > > > > test/py/tests/test_net_boot.py +u-boot-test-reset rpi_3_32b rpi3 > > {lab mode} > > Building U-Boot in pytest-source dir for rpi_3_32b > > Bootstrapping U-Boot from dir /tmp/b/rpi_3_32b > > Writing U-Boot using method rpi3 > > cat: /sys/class/block/sdz1/size: No such file or directory > > cat: /sys/class/block/sdz1/size: No such file or directory > > > > {lab ready in 10.4s: U-Boot 2025.01-rc6-00508-gd6da3dbaef57-dirty (Jan > > 20 2025 - 12:11:05 -0700)} > > skip False > > U-Boot> setenv autoload no > > U-Boot> U-Boot> dhcp > > Waiting for Ethernet connection... done. > > BOOTP broadcast 1 > > DHCP client bound to address 192.168.4.50 (4 ms) > > U-Boot> U-Boot> echo $bootfile > > > > U-Boot> U-Boot> setenv pxefile_addr_r 10000000 > > U-Boot> U-Boot> pxe get > > missing environment variable: pxeuuid > > Retrieving file: pxelinux.cfg/01-b8-27-eb-b4-f9-f2 > > Waiting for Ethernet connection... done. > > Using smsc95xx_eth device > > TFTP from server 192.168.4.1; our IP address is 192.168.4.50 > > Filename 'pxelinux.cfg/01-b8-27-eb-b4-f9-f2'. > > Load address: 0x10000000 > > Loading: * > > TFTP error: 'File not found' (1) > > Not retrying... > > Retrieving file: pxelinux.cfg/C0A80432 > > Waiting for Ethernet connection... done. > > Using smsc95xx_eth device > > TFTP from server 192.168.4.1; our IP address is 192.168.4.50 > > Filename 'pxelinux.cfg/C0A80432'. > > Load address: 0x10000000 > > Loading: * > > TFTP error: 'File not found' (1) > > Not retrying... > > Retrieving file: pxelinux.cfg/C0A8043 > > Waiting for Ethernet connection... done. > > Using smsc95xx_eth device > > TFTP from server 192.168.4.1; our IP address is 192.168.4.50 > > Filename 'pxelinux.cfg/C0A8043'. > > Load address: 0x10000000 > > Loading: * > > TFTP error: 'File not found' (1) > > Not retrying... > > Retrieving file: pxelinux.cfg/C0A804 > > Waiting for Ethernet connection... done. > > Using smsc95xx_eth device > > TFTP from server 192.168.4.1; our IP address is 192.168.4.50 > > Filename 'pxelinux.cfg/C0A804'. > > Load address: 0x10000000 > > Loading: * > > TFTP error: 'File not found' (1) > > Not retrying... > > Retrieving file: pxelinux.cfg/C0A80 > > Waiting for Ethernet connection... done. > > Using smsc95xx_eth device > > TFTP from server 192.168.4.1; our IP address is 192.168.4.50 > > Filename 'pxelinux.cfg/C0A80'. > > Load address: 0x10000000 > > Loading: * > > TFTP error: 'File not found' (1) > > Not retrying... > > Retrieving file: pxelinux.cfg/C0A8 > > Waiting for Ethernet connection... done. > > Using smsc95xx_eth device > > TFTP from server 192.168.4.1; our IP address is 192.168.4.50 > > Filename 'pxelinux.cfg/C0A8'. > > Load address: 0x10000000 > > Loading: * > > TFTP error: 'File not found' (1) > > Not retrying... > > Retrieving file: pxelinux.cfg/C0A > > Waiting for Ethernet connection... done. > > Using smsc95xx_eth device > > TFTP from server 192.168.4.1; our IP address is 192.168.4.50 > > Filename 'pxelinux.cfg/C0A'. > > Load address: 0x10000000 > > Loading: * > > TFTP error: 'File not found' (1) > > Not retrying... > > Retrieving file: pxelinux.cfg/C0 > > Waiting for Ethernet connection... done. > > Using smsc95xx_eth device > > TFTP from server 192.168.4.1; our IP address is 192.168.4.50 > > Filename 'pxelinux.cfg/C0'. > > Load address: 0x10000000 > > Loading: * > > TFTP error: 'File not found' (1) > > Not retrying... > > Retrieving file: pxelinux.cfg/C > > Waiting for Ethernet connection... done. > > Using smsc95xx_eth device > > TFTP from server 192.168.4.1; our IP address is 192.168.4.50 > > Filename 'pxelinux.cfg/C'. > > Load address: 0x10000000 > > Loading: * > > TFTP error: 'File not found' (1) > > Not retrying... > > Retrieving file: pxelinux.cfg/default-arm-bcm283x-rpi > > Waiting for Ethernet connection... done. > > Using smsc95xx_eth device > > TFTP from server 192.168.4.1; our IP address is 192.168.4.50 > > Filename 'pxelinux.cfg/default-arm-bcm283x-rpi'. > > Load address: 0x10000000 > > Loading: * > > TFTP error: 'File not found' (1) > > Not retrying... > > Retrieving file: pxelinux.cfg/default-arm-bcm283x > > Waiting for Ethernet connection... done. > > Using smsc95xx_eth device > > TFTP from server 192.168.4.1; our IP address is 192.168.4.50 > > Filename 'pxelinux.cfg/default-arm-bcm283x'. > > Load address: 0x10000000 > > Loading: ################################################## 64 Bytes > > 4.9 KiB/s > > done > > Bytes transferred = 64 (40 hex) > > Config file '<NULL>' found > > U-Boot> U-Boot> pxe boot 10000000 > > Retrieving file: pxelinux.cfg/default-arm > > Waiting for Ethernet connection... done. > > Using smsc95xx_eth device > > TFTP from server 192.168.4.1; our IP address is 192.168.4.50 > > Filename 'pxelinux.cfg/default-arm'. > > Load address: 0x10000044 > > Loading: ################################################## 349 Bytes > > 30.3 KiB/s > > done > > Bytes transferred = 349 (15d hex) > > Retrieving file: pxelinux.cfg/default > > Waiting for Ethernet connection... done. > > Using smsc95xx_eth device > > TFTP from server 192.168.4.1; our IP address is 192.168.4.50 > > Filename 'pxelinux.cfg/default'. > > Load address: 0x100001a4 > > Loading: ################################################## 108 Bytes > > 9.8 KiB/s > > done > > Bytes transferred = 108 (6c hex) > > Linux boot selections > > 1: Boot kernel > > 2: Invalid boot > > 3: Local boot > > 4: Empty boot > > Enter choice: 3 > > 3: Local boot > > missing environment variable: localcmd > > U-Boot> pxe boot 10000000 > > Retrieving file: pxelinux.cfg/default-arm > > Waiting for Ethernet connection... done. > > Using smsc95xx_eth device > > TFTP from server 192.168.4.1; our IP address is 192.168.4.50 > > Filename 'pxelinux.cfg/default-arm'. > > Load address: 0x10000044 > > Loading: ################################################## 349 Bytes > > 19.5 KiB/s > > done > > Bytes transferred = 349 (15d hex) > > Retrieving file: pxelinux.cfg/default > > Waiting for Ethernet connection... done. > > Using smsc95xx_eth device > > TFTP from server 192.168.4.1; our IP address is 192.168.4.50 > > Filename 'pxelinux.cfg/default'. > > Load address: 0x100001a4 > > Loading: ################################################## 108 Bytes > > 9.8 KiB/s > > done > > Bytes transferred = 108 (6c hex) > > Linux boot selections > > 1: Boot kernel > > 2: Invalid boot > > 3: Local boot > > 4: Empty boot > > Enter choice: 4 > > 4: Empty boot > > No kernel given, skipping boot > > 1: Boot kernel > > Retrieving file: Image > > Waiting for Ethernet connection... done. > > Using smsc95xx_eth device > > TFTP from server 192.168.4.1; our IP address is 192.168.4.50 > > Filename 'Image'. > > Load address: 0x80000 > > Loading: ################################################## 6 Bytes > > 0 Bytes/s > > done > > Bytes transferred = 6 (6 hex) > > Retrieving file: rootfs.cpio.gz.u-boot > > Waiting for Ethernet connection... done. > > Using smsc95xx_eth device > > TFTP from server 192.168.4.1; our IP address is 192.168.4.50 > > Filename 'rootfs.cpio.gz.u-boot'. > > Load address: 0x2700000 > > Loading: ################################################## 30.6 MiB > > 995.1 KiB/s > > done > > Bytes transferred = 32123014 (1ea2886 hex) > > Retrieving file: system.dtb > > Waiting for Ethernet connection... done. > > Using smsc95xx_eth device > > TFTP from server 192.168.4.1; our IP address is 192.168.4.50 > > Filename 'system.dtb'. > > Load address: 0x2600000 > > Loading: ################################################## 11 Bytes > > 1000 Bytes/s > > done > > Bytes transferred = 11 (b hex) > > zimage: Bad magic! > > 2: Invalid boot > > Retrieving file: kernels/install.bin > > Waiting for Ethernet connection... done. > > Using smsc95xx_eth device > > TFTP from server 192.168.4.1; our IP address is 192.168.4.50 > > Filename 'kernels/install.bin'. > > Load address: 0x80000 > > Loading: * > > TFTP error: 'File not found' (1) > > Not retrying... > > Skipping install for failure retrieving kernel > > 3: Local boot > > missing environment variable: localcmd > > U-Boot> F > > > > Do you have a passing run I could compare against, and/or a boardenv > > file that works? > > I didn't test this on 32bit ARM, only 64bit. For Pi 3: > > env__net_uses_usb = True > > env__net_dhcp_server = True > > env__tftp_boot_test_skip = False > > env__net_tftp_bootable_file = { > 'fn': 'v6.6/image.fit.nocomp', > 'addr': 0x00200000, > 'size': 85984256, > 'crc32': '754c839a', > 'pattern': 'Linux', > 'config': 'conf-852', > } > > # Details regarding a file that may be read from a TFTP server. This variable > # may be omitted or set to None if PXE testing is not possible or desired. > env__net_pxe_bootable_file = { > 'fn': 'default', > 'addr': 0x00200000, > 'size': 64, > 'timeout': 50000, > 'pattern': 'Linux', > 'valid_label': '1', > 'invalid_label': '2', > 'exp_str_invalid': 'Skipping install for failure retrieving', > 'local_label': '3', > 'exp_str_local': 'missing environment variable: localcmd', > 'empty_label': '4', > 'exp_str_empty': 'No kernel given, skipping boot', > } > > # False or omitted if a PXE boot test should be tested. > # If PXE boot testing is not possible or desired, set this variable to True. > # For example: If pxe configuration file is not proper to boot > env__pxe_boot_test_skip = False > > And: > $ cat /srv/tftp/pxelinux.cfg/default > label Linux > menu label Boot kernel > kernel Image > fdt system.dtb > initrd rootfs.cpio.gz.u-boot > $ cat /srv/tftp/pxelinux.cfg/default-arm > menu title Linux boot selections > menu include pxelinux.cfg/default > > label install > menu label Invalid boot > kernel kernels/install.bin > append console=ttyAMA0,38400 debug earlyprintk > initrd initrds/uzInitrdDebInstall > > label local > menu label Local boot > append root=/dev/sdb1 > localboot 1 > > label boot > menu label Empty boot > $ cat /srv/tftp/pxelinux.cfg/01-b8-27-eb-fc-64-a6 > menu include pxelinux.cfg/default-arm > timeout 50 > > default Linux > > And kernels/install.bin, etc, do not exist. Only v6.6/image.fit.nocomp > exists. Thanks very much for that. I have got it running and bisected the problem to the penultimate patch, so will figure it out and send v4. Regards, Simon
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.
Hi Tom, On Fri, 24 Jan 2025 at 12:18, Tom Rini <trini@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. > > -- > Tom 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. Regards, Simon
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@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.
Hi Tom, On Sat, 15 Feb 2025 at 07:46, Tom Rini <trini@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@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/
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@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@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.
Hi Tom, On Sat, 15 Feb 2025 at 11:21, Tom Rini <trini@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@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@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
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 <trini@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@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@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.
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 <trini@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@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@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.
Hi Tom, On Sun, 16 Feb 2025 at 09:21, Tom Rini <trini@konsulko.com> wrote: > > 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 <trini@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@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@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. OK, that's fine. I'll pick up your patch and see what needs doing. Regards, Simon