[PATCH v2 0/6] efi_loader: run bootdev_hunt() to find ESP
Some hard devices need specific routines to scan for block devices, e.g. NVMe (nvme scan), SCSI (scsi start).
Invoke bootdev_hunt() to find all block devices.
Reviewers complained that PXE boot was executed unexpectedly. eth_bootdev_hunt() should not execute dhcp_run() as this itself would load a file and boot it if autostart=yes. Instead just check that there is a network device.
To fix Gitlab CI issues the following changes were necessary:
In test_extension.py do not assume that extensions have not been loaded by bootdev hunter in a previous test.
Remove CONFIG_AMIGA_PARTITION from sandbox_deconfig to avoid a timeout.
Remove CONFIG_USB_DWC3 from xilinx_versal_virt_defconfig to avoid a boot failure.
Add a parameter '-e' to select if UEFI boot options shall be shown by the bootmenu command.
v2: Do not run dhcp_run() in eth_bootdev_hunt(). In test_extension.py do not assume initial state. Remove CONFIG_AMIGA_PARTITION from sandbox_deconfig. Remove CONFIG_USB_DWC3 from xilinx_versal_virt_defconfig. Add a parameter '-e' to bootmenu command.
Heinrich Schuchardt (6): test: fix test_extension.py configs: sandbox_deconfig: remove CONFIG_AMIGA_PARTITION configs: xilinx_versal_virt: disable USB_DWC3 net: eth_bootdev_hunt() must not try to boot cmd: bootmenu: add parameter -e for UEFI boot options efi_loader: run bootdev_hunt() to find ESP
cmd/bootmenu.c | 39 +++++++++++++++++++++------- configs/sandbox_defconfig | 1 - configs/xilinx_versal_virt_defconfig | 2 -- doc/usage/cmd/bootmenu.rst | 13 +++++++--- lib/efi_loader/efi_setup.c | 8 ++++++ net/eth_bootdev.c | 30 ++++++++++++--------- test/py/tests/test_extension.py | 4 ++- 7 files changed, 69 insertions(+), 28 deletions(-)
test_extension.py assumes that no extension is known at test start. This assumption is wrong because we do not come out of reboot. A prior test may have already hunted for the extension bootdev.
Remove the invalid assert.
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com --- v2: new patch --- test/py/tests/test_extension.py | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/test/py/tests/test_extension.py b/test/py/tests/test_extension.py index 267cf2ff27c..2a3c5116171 100644 --- a/test/py/tests/test_extension.py +++ b/test/py/tests/test_extension.py @@ -26,7 +26,9 @@ def test_extension(u_boot_console): load_dtb(u_boot_console)
output = u_boot_console.run_command('extension list') - assert('No extension' in output) + # extension_bootdev_hunt may have already run. + # Without reboot we cannot make any assumption here. + # assert('No extension' in output)
output = u_boot_console.run_command('extension scan') assert output == 'Found 2 extension board(s).'
We do not actually test the code. Scanning for Amiga partitions of the sandbox is extremely slow, especially on the partially implemented USB device.
For build testing the other sandbox defconfigs are good enough.
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com --- v2: new patch --- configs/sandbox_defconfig | 1 - 1 file changed, 1 deletion(-)
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig index 718e4a8283c..683888f238f 100644 --- a/configs/sandbox_defconfig +++ b/configs/sandbox_defconfig @@ -142,7 +142,6 @@ CONFIG_CMD_SQUASHFS=y CONFIG_CMD_MTDPARTS=y CONFIG_CMD_STACKPROTECTOR_TEST=y CONFIG_MAC_PARTITION=y -CONFIG_AMIGA_PARTITION=y CONFIG_OF_CONTROL=y CONFIG_OF_LIVE=y CONFIG_ENV_IS_NOWHERE=y
On Sat, Nov 23, 2024 at 10:45:50PM +0100, Heinrich Schuchardt wrote:
We do not actually test the code. Scanning for Amiga partitions of the sandbox is extremely slow, especially on the partially implemented USB device.
For build testing the other sandbox defconfigs are good enough.
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com
v2: new patch
configs/sandbox_defconfig | 1 - 1 file changed, 1 deletion(-)
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig index 718e4a8283c..683888f238f 100644 --- a/configs/sandbox_defconfig +++ b/configs/sandbox_defconfig @@ -142,7 +142,6 @@ CONFIG_CMD_SQUASHFS=y CONFIG_CMD_MTDPARTS=y CONFIG_CMD_STACKPROTECTOR_TEST=y CONFIG_MAC_PARTITION=y -CONFIG_AMIGA_PARTITION=y CONFIG_OF_CONTROL=y CONFIG_OF_LIVE=y CONFIG_ENV_IS_NOWHERE=y
This means we don't do static analysis on the code anymore either, which isn't good, in theory. In specifics, this is fine since the code rarely changes. But I wonder instead if we're timing out too quickly now? Or if we should have but weren't timing out before, but that's now been fixed?
Tom Rini trini@konsulko.com schrieb am So., 24. Nov. 2024, 17:17:
On Sat, Nov 23, 2024 at 10:45:50PM +0100, Heinrich Schuchardt wrote:
We do not actually test the code. Scanning for Amiga partitions of the sandbox is extremely slow, especially on the partially implemented USB device.
For build testing the other sandbox defconfigs are good enough.
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com
v2: new patch
configs/sandbox_defconfig | 1 - 1 file changed, 1 deletion(-)
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig index 718e4a8283c..683888f238f 100644 --- a/configs/sandbox_defconfig +++ b/configs/sandbox_defconfig @@ -142,7 +142,6 @@ CONFIG_CMD_SQUASHFS=y CONFIG_CMD_MTDPARTS=y CONFIG_CMD_STACKPROTECTOR_TEST=y CONFIG_MAC_PARTITION=y -CONFIG_AMIGA_PARTITION=y CONFIG_OF_CONTROL=y CONFIG_OF_LIVE=y CONFIG_ENV_IS_NOWHERE=y
This means we don't do static analysis on the code anymore either, which isn't good, in theory. In specifics, this is fine since the code rarely changes. But I wonder instead if we're timing out too quickly now? Or if we should have but weren't timing out before, but that's now been fixed?
There are still enough other sandbox defconfigs which build with AMIGA_PRTITION.
As we don't have any real boards using it, should the Amiga partition support be removed?
Best regards
Heinrich
-- Tom
On Sun, Nov 24, 2024 at 05:35:31PM +0100, Heinrich Schuchardt wrote:
Tom Rini trini@konsulko.com schrieb am So., 24. Nov. 2024, 17:17:
On Sat, Nov 23, 2024 at 10:45:50PM +0100, Heinrich Schuchardt wrote:
We do not actually test the code. Scanning for Amiga partitions of the sandbox is extremely slow, especially on the partially implemented USB device.
For build testing the other sandbox defconfigs are good enough.
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com
v2: new patch
configs/sandbox_defconfig | 1 - 1 file changed, 1 deletion(-)
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig index 718e4a8283c..683888f238f 100644 --- a/configs/sandbox_defconfig +++ b/configs/sandbox_defconfig @@ -142,7 +142,6 @@ CONFIG_CMD_SQUASHFS=y CONFIG_CMD_MTDPARTS=y CONFIG_CMD_STACKPROTECTOR_TEST=y CONFIG_MAC_PARTITION=y -CONFIG_AMIGA_PARTITION=y CONFIG_OF_CONTROL=y CONFIG_OF_LIVE=y CONFIG_ENV_IS_NOWHERE=y
This means we don't do static analysis on the code anymore either, which isn't good, in theory. In specifics, this is fine since the code rarely changes. But I wonder instead if we're timing out too quickly now? Or if we should have but weren't timing out before, but that's now been fixed?
There are still enough other sandbox defconfigs which build with AMIGA_PRTITION.
Yes, but only "sandbox_defconfig" gets Coverity scan.
As we don't have any real boards using it, should the Amiga partition support be removed?
There's two real platforms enabling it, but that could be by mistake. So no, I don't object to getting those platforms to ack removal and then removing it.
The CI uses the following command to launch xilinx_versal_virt_defconfig:
qemu-system-aarch64 -M xlnx-versal-virt \ -display none -m 4G -serial mon:stdio \ -device loader,file=u-boot,cpu-num=0
'usb start' or invoking eth_bootdev_hunt leads to a crash when function dwc3_core_init() tries to access a register at offset 0xc704 (DWC3_DCTL) relative to the register start address 0xfe20c100.
Disable CONFIG_USB_DWC3 until the driver problem is fixed.
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com --- v2: new patch --- configs/xilinx_versal_virt_defconfig | 2 -- 1 file changed, 2 deletions(-)
diff --git a/configs/xilinx_versal_virt_defconfig b/configs/xilinx_versal_virt_defconfig index c8f166c1221..06a240173ba 100644 --- a/configs/xilinx_versal_virt_defconfig +++ b/configs/xilinx_versal_virt_defconfig @@ -153,8 +153,6 @@ CONFIG_USB=y CONFIG_DM_USB_GADGET=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_USB_DWC3=y -CONFIG_USB_DWC3_GENERIC=y CONFIG_USB_ULPI_VIEWPORT=y CONFIG_USB_ULPI=y CONFIG_USB_GADGET=y
On 11/23/24 22:45, Heinrich Schuchardt wrote:
The CI uses the following command to launch xilinx_versal_virt_defconfig:
qemu-system-aarch64 -M xlnx-versal-virt \ -display none -m 4G -serial mon:stdio \ -device loader,file=u-boot,cpu-num=0'usb start' or invoking eth_bootdev_hunt leads to a crash when function dwc3_core_init() tries to access a register at offset 0xc704 (DWC3_DCTL) relative to the register start address 0xfe20c100.
Disable CONFIG_USB_DWC3 until the driver problem is fixed.
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com
v2: new patch
configs/xilinx_versal_virt_defconfig | 2 -- 1 file changed, 2 deletions(-)
diff --git a/configs/xilinx_versal_virt_defconfig b/configs/xilinx_versal_virt_defconfig index c8f166c1221..06a240173ba 100644 --- a/configs/xilinx_versal_virt_defconfig +++ b/configs/xilinx_versal_virt_defconfig @@ -153,8 +153,6 @@ CONFIG_USB=y CONFIG_DM_USB_GADGET=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_USB_DWC3=y -CONFIG_USB_DWC3_GENERIC=y CONFIG_USB_ULPI_VIEWPORT=y CONFIG_USB_ULPI=y CONFIG_USB_GADGET=y
NACK. That's not the way to go. If one test is failing in CI disable that test not really support which is for HW too.
Thanks, Michal
On 11/25/24 09:32, Michal Simek wrote:
On 11/23/24 22:45, Heinrich Schuchardt wrote:
The CI uses the following command to launch xilinx_versal_virt_defconfig:
qemu-system-aarch64 -M xlnx-versal-virt \ -display none -m 4G -serial mon:stdio \ -device loader,file=u-boot,cpu-num=0
'usb start' or invoking eth_bootdev_hunt leads to a crash when function dwc3_core_init() tries to access a register at offset 0xc704 (DWC3_DCTL) relative to the register start address 0xfe20c100.
Disable CONFIG_USB_DWC3 until the driver problem is fixed.
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com
v2: new patch
configs/xilinx_versal_virt_defconfig | 2 -- 1 file changed, 2 deletions(-)
diff --git a/configs/xilinx_versal_virt_defconfig b/configs/ xilinx_versal_virt_defconfig index c8f166c1221..06a240173ba 100644 --- a/configs/xilinx_versal_virt_defconfig +++ b/configs/xilinx_versal_virt_defconfig @@ -153,8 +153,6 @@ CONFIG_USB=y CONFIG_DM_USB_GADGET=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_USB_DWC3=y -CONFIG_USB_DWC3_GENERIC=y CONFIG_USB_ULPI_VIEWPORT=y CONFIG_USB_ULPI=y CONFIG_USB_GADGET=y
NACK. That's not the way to go. If one test is failing in CI disable that test not really support which is for HW too.
Thanks, Michal
Hello Michal,
It is not that a single test fails. USB is completely unusable on the board. 'usb start' leads to an immediate crash.
The problem already existed in v2021.01. Do you know of any QEMU/U-Boot combination where USB ever worked on the board?
Best regards
Heinrich
On 11/25/24 10:21, Heinrich Schuchardt wrote:
On 11/25/24 09:32, Michal Simek wrote:
On 11/23/24 22:45, Heinrich Schuchardt wrote:
The CI uses the following command to launch xilinx_versal_virt_defconfig:
qemu-system-aarch64 -M xlnx-versal-virt \ -display none -m 4G -serial mon:stdio \ -device loader,file=u-boot,cpu-num=0
'usb start' or invoking eth_bootdev_hunt leads to a crash when function dwc3_core_init() tries to access a register at offset 0xc704 (DWC3_DCTL) relative to the register start address 0xfe20c100.
Disable CONFIG_USB_DWC3 until the driver problem is fixed.
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com
v2: new patch
configs/xilinx_versal_virt_defconfig | 2 -- 1 file changed, 2 deletions(-)
diff --git a/configs/xilinx_versal_virt_defconfig b/configs/ xilinx_versal_virt_defconfig index c8f166c1221..06a240173ba 100644 --- a/configs/xilinx_versal_virt_defconfig +++ b/configs/xilinx_versal_virt_defconfig @@ -153,8 +153,6 @@ CONFIG_USB=y CONFIG_DM_USB_GADGET=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_USB_DWC3=y -CONFIG_USB_DWC3_GENERIC=y CONFIG_USB_ULPI_VIEWPORT=y CONFIG_USB_ULPI=y CONFIG_USB_GADGET=y
NACK. That's not the way to go. If one test is failing in CI disable that test not really support which is for HW too.
Thanks, Michal
Hello Michal,
It is not that a single test fails. USB is completely unusable on the board. 'usb start' leads to an immediate crash.
I am not applying any patches on SOM with HEAD and usb is partially working. I can agree that it is not super stable with upstream only patches but that's different story.
The problem already existed in v2021.01.
Any log?
Do you know of any QEMU/U-Boot combination where USB ever worked on the board?
Why was this visible in CI in past and why this pops up now? What has changed? I don't think there was any change in QEMu regarding USB but I can double check.
Thanks, Michal
On 25.11.24 11:02, Michal Simek wrote:
On 11/25/24 10:21, Heinrich Schuchardt wrote:
On 11/25/24 09:32, Michal Simek wrote:
On 11/23/24 22:45, Heinrich Schuchardt wrote:
The CI uses the following command to launch xilinx_versal_virt_defconfig:
qemu-system-aarch64 -M xlnx-versal-virt \ -display none -m 4G -serial mon:stdio \ -device loader,file=u-boot,cpu-num=0
'usb start' or invoking eth_bootdev_hunt leads to a crash when function dwc3_core_init() tries to access a register at offset 0xc704 (DWC3_DCTL) relative to the register start address 0xfe20c100.
Disable CONFIG_USB_DWC3 until the driver problem is fixed.
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com
v2: new patch
configs/xilinx_versal_virt_defconfig | 2 -- 1 file changed, 2 deletions(-)
diff --git a/configs/xilinx_versal_virt_defconfig b/configs/ xilinx_versal_virt_defconfig index c8f166c1221..06a240173ba 100644 --- a/configs/xilinx_versal_virt_defconfig +++ b/configs/xilinx_versal_virt_defconfig @@ -153,8 +153,6 @@ CONFIG_USB=y CONFIG_DM_USB_GADGET=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_USB_DWC3=y -CONFIG_USB_DWC3_GENERIC=y CONFIG_USB_ULPI_VIEWPORT=y CONFIG_USB_ULPI=y CONFIG_USB_GADGET=y
NACK. That's not the way to go. If one test is failing in CI disable that test not really support which is for HW too.
Thanks, Michal
Hello Michal,
It is not that a single test fails. USB is completely unusable on the board. 'usb start' leads to an immediate crash.
I am not applying any patches on SOM with HEAD and usb is partially working.
Don't you see a crash when executing 'usb start'? What QEMU are you using?
I can agree that it is not super stable with upstream only patches but that's different story.
The problem already existed in v2021.01.
Any log?
$ git reset --hard origin/master $ make xilinx_versal_virt_defconfig $ CROSS_COMPILE=aarch64-linux-gnu- make -j$(nproc) $ qemu-system-riscv64 --version QEMU emulator version 9.0.2 (Debian 1:9.0.2+ds-4ubuntu7) $ qemu-system-aarch64 -M xlnx-versal-virt \
-display none -m 4G -serial mon:stdio \ -device loader,file=u-boot,cpu-num=0
U-Boot 2025.01-rc2-00172-g880fcc49eb40 (Nov 25 2024 - 11:18:35 +0100)
CPU: UNKNOWN Model: Xilinx Versal Virtual development board DRAM: 2 GiB (effective 4 GiB) EL Level: EL3 Core: 32 devices, 13 uclasses, devicetree: board Warning: Device tree includes old 'u-boot,dm-' tags: please fix by 2023.07! MMC: sdhci@f1040000: 0, sdhci@f1050000: 1 Loading Environment from nowhere... OK In: uart@ff000000 Out: uart@ff000000 Err: uart@ff000000 Bootmode: JTAG_MODE Net: ZYNQ GEM: ff0c0000, mdio bus ff0c0000, phyaddr 0, interface rgmii-id
Warning: ethernet@ff0c0000 (eth0) using random MAC address - 5e:f6:37:a3:68:24 eth0: ethernet@ff0c0000 ZYNQ GEM: ff0d0000, mdio bus ff0d0000, phyaddr 0, interface rgmii-id
Warning: ethernet@ff0d0000 (eth1) using random MAC address - 5e:8a:ec:a9:d7:e8 , eth1: ethernet@ff0d0000 MMC: no card present MMC: no card present Cannot persist EFI variables without system partition Missing TPMv2 device for EFI_TCG_PROTOCOL Missing RNG device for EFI_RNG_PROTOCOL Hit any key to stop autoboot: 0 Versal> usb start starting USB... Bus dwc3@fe200000: "Synchronous Abort" handler, esr 0x96000050 elr: 0000000008068fd8 lr : 0000000008069940 (reloc) elr: 000000007ff17fd8 lr : 000000007ff18940 x0 : 00000000fe20c100 x1 : 0000000040000000 x2 : 0000000033310000 x3 : 000000000000003f x4 : 000000007ffa74b0 x5 : 000000007c112880 x6 : 000000007ffa74c0 x7 : 000000007c300000 x8 : 0000000000000684 x9 : 000000007bda668c x10: 0000000000000003 x11: 0000000000000188 x12: 0000000000000000 x13: 000000007bda6be0 x14: 0000000000000000 x15: 000000007bda6224 x16: 000000007fee9244 x17: 0000000000000000 x18: 000000007bea6be0 x19: 000000007c111b48 x20: 000000007c111240 x21: 0000000047822004 x22: 000000007ff998b2 x23: 000000007ff998e8 x24: 000000007ffd4514 x25: 0000000000000000 x26: 0000000000000000 x27: 000000007c111130 x28: 000000007c1110d0 x29: 000000007bda67b0
Code: b9030660 f9416e60 d5033fbf 52a80001 (b9060401) Resetting CPU ...
resetting ...
$ cat u-boot.map .text.dwc3_core_init 0x0000000008068f24 0x6a0 drivers/usb/dwc3/core.o .text.dwc3_of_parse 0x00000000080695c4 0x310 drivers/usb/dwc3/core.o 0x00000000080695c4 dwc3_of_parse
Do you know of any QEMU/U-Boot combination where USB ever worked on the board?
Why was this visible in CI in past and why this pops up now? What has changed? I don't think there was any change in QEMu regarding USB but I can double check.
We never started USB in the CI. With patch 6/6 of the series usb_bootdev_hunter() is invoked which starts USB.
Best regards
Heinrich
On 11/25/24 11:35, Heinrich Schuchardt wrote:
On 25.11.24 11:02, Michal Simek wrote:
On 11/25/24 10:21, Heinrich Schuchardt wrote:
On 11/25/24 09:32, Michal Simek wrote:
On 11/23/24 22:45, Heinrich Schuchardt wrote:
The CI uses the following command to launch xilinx_versal_virt_defconfig:
qemu-system-aarch64 -M xlnx-versal-virt \ -display none -m 4G -serial mon:stdio \ -device loader,file=u-boot,cpu-num=0
'usb start' or invoking eth_bootdev_hunt leads to a crash when function dwc3_core_init() tries to access a register at offset 0xc704 (DWC3_DCTL) relative to the register start address 0xfe20c100.
Disable CONFIG_USB_DWC3 until the driver problem is fixed.
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com
v2: new patch
configs/xilinx_versal_virt_defconfig | 2 -- 1 file changed, 2 deletions(-)
diff --git a/configs/xilinx_versal_virt_defconfig b/configs/ xilinx_versal_virt_defconfig index c8f166c1221..06a240173ba 100644 --- a/configs/xilinx_versal_virt_defconfig +++ b/configs/xilinx_versal_virt_defconfig @@ -153,8 +153,6 @@ CONFIG_USB=y CONFIG_DM_USB_GADGET=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_USB_DWC3=y -CONFIG_USB_DWC3_GENERIC=y CONFIG_USB_ULPI_VIEWPORT=y CONFIG_USB_ULPI=y CONFIG_USB_GADGET=y
NACK. That's not the way to go. If one test is failing in CI disable that test not really support which is for HW too.
Thanks, Michal
Hello Michal,
It is not that a single test fails. USB is completely unusable on the board. 'usb start' leads to an immediate crash.
I am not applying any patches on SOM with HEAD and usb is partially working.
Don't you see a crash when executing 'usb start'? What QEMU are you using?
I can agree that it is not super stable with upstream only patches but that's different story.
The problem already existed in v2021.01.
Any log?
$ git reset --hard origin/master $ make xilinx_versal_virt_defconfig $ CROSS_COMPILE=aarch64-linux-gnu- make -j$(nproc) $ qemu-system-riscv64 --version QEMU emulator version 9.0.2 (Debian 1:9.0.2+ds-4ubuntu7) $ qemu-system-aarch64 -M xlnx-versal-virt \
-display none -m 4G -serial mon:stdio \ -device loader,file=u-boot,cpu-num=0
U-Boot 2025.01-rc2-00172-g880fcc49eb40 (Nov 25 2024 - 11:18:35 +0100)
CPU: UNKNOWN Model: Xilinx Versal Virtual development board DRAM: 2 GiB (effective 4 GiB) EL Level: EL3 Core: 32 devices, 13 uclasses, devicetree: board Warning: Device tree includes old 'u-boot,dm-' tags: please fix by 2023.07! MMC: sdhci@f1040000: 0, sdhci@f1050000: 1 Loading Environment from nowhere... OK In: uart@ff000000 Out: uart@ff000000 Err: uart@ff000000 Bootmode: JTAG_MODE Net: ZYNQ GEM: ff0c0000, mdio bus ff0c0000, phyaddr 0, interface rgmii-id
Warning: ethernet@ff0c0000 (eth0) using random MAC address - 5e:f6:37:a3:68:24 eth0: ethernet@ff0c0000 ZYNQ GEM: ff0d0000, mdio bus ff0d0000, phyaddr 0, interface rgmii-id
Warning: ethernet@ff0d0000 (eth1) using random MAC address - 5e:8a:ec:a9:d7:e8 , eth1: ethernet@ff0d0000 MMC: no card present MMC: no card present Cannot persist EFI variables without system partition Missing TPMv2 device for EFI_TCG_PROTOCOL Missing RNG device for EFI_RNG_PROTOCOL Hit any key to stop autoboot: 0 Versal> usb start starting USB... Bus dwc3@fe200000: "Synchronous Abort" handler, esr 0x96000050 elr: 0000000008068fd8 lr : 0000000008069940 (reloc) elr: 000000007ff17fd8 lr : 000000007ff18940 x0 : 00000000fe20c100 x1 : 0000000040000000 x2 : 0000000033310000 x3 : 000000000000003f x4 : 000000007ffa74b0 x5 : 000000007c112880 x6 : 000000007ffa74c0 x7 : 000000007c300000 x8 : 0000000000000684 x9 : 000000007bda668c x10: 0000000000000003 x11: 0000000000000188 x12: 0000000000000000 x13: 000000007bda6be0 x14: 0000000000000000 x15: 000000007bda6224 x16: 000000007fee9244 x17: 0000000000000000 x18: 000000007bea6be0 x19: 000000007c111b48 x20: 000000007c111240 x21: 0000000047822004 x22: 000000007ff998b2 x23: 000000007ff998e8 x24: 000000007ffd4514 x25: 0000000000000000 x26: 0000000000000000 x27: 000000007c111130 x28: 000000007c1110d0 x29: 000000007bda67b0
Code: b9030660 f9416e60 d5033fbf 52a80001 (b9060401) Resetting CPU ...
resetting ...
$ cat u-boot.map .text.dwc3_core_init 0x0000000008068f24 0x6a0 drivers/usb/dwc3/core.o .text.dwc3_of_parse 0x00000000080695c4 0x310 drivers/usb/dwc3/core.o 0x00000000080695c4 dwc3_of_parse
Do you know of any QEMU/U-Boot combination where USB ever worked on the board?
Why was this visible in CI in past and why this pops up now? What has changed? I don't think there was any change in QEMu regarding USB but I can double check.
We never started USB in the CI. With patch 6/6 of the series usb_bootdev_hunter() is invoked which starts USB.
Did you push this to gitlab CI? Which test/py is failing there?
M
On Mon, Nov 25, 2024 at 07:03:41PM +0100, Michal Simek wrote:
On 11/25/24 11:35, Heinrich Schuchardt wrote:
On 25.11.24 11:02, Michal Simek wrote:
On 11/25/24 10:21, Heinrich Schuchardt wrote:
On 11/25/24 09:32, Michal Simek wrote:
On 11/23/24 22:45, Heinrich Schuchardt wrote:
The CI uses the following command to launch xilinx_versal_virt_defconfig:
qemu-system-aarch64 -M xlnx-versal-virt \ -display none -m 4G -serial mon:stdio \ -device loader,file=u-boot,cpu-num=0
'usb start' or invoking eth_bootdev_hunt leads to a crash when function dwc3_core_init() tries to access a register at offset 0xc704 (DWC3_DCTL) relative to the register start address 0xfe20c100.
Disable CONFIG_USB_DWC3 until the driver problem is fixed.
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com
v2: new patch
configs/xilinx_versal_virt_defconfig | 2 -- 1 file changed, 2 deletions(-)
diff --git a/configs/xilinx_versal_virt_defconfig b/configs/ xilinx_versal_virt_defconfig index c8f166c1221..06a240173ba 100644 --- a/configs/xilinx_versal_virt_defconfig +++ b/configs/xilinx_versal_virt_defconfig @@ -153,8 +153,6 @@ CONFIG_USB=y CONFIG_DM_USB_GADGET=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_USB_DWC3=y -CONFIG_USB_DWC3_GENERIC=y CONFIG_USB_ULPI_VIEWPORT=y CONFIG_USB_ULPI=y CONFIG_USB_GADGET=y
NACK. That's not the way to go. If one test is failing in CI disable that test not really support which is for HW too.
Thanks, Michal
Hello Michal,
It is not that a single test fails. USB is completely unusable on the board. 'usb start' leads to an immediate crash.
I am not applying any patches on SOM with HEAD and usb is partially working.
Don't you see a crash when executing 'usb start'? What QEMU are you using?
I can agree that it is not super stable with upstream only patches but that's different story.
The problem already existed in v2021.01.
Any log?
$ git reset --hard origin/master $ make xilinx_versal_virt_defconfig $ CROSS_COMPILE=aarch64-linux-gnu- make -j$(nproc) $ qemu-system-riscv64 --version QEMU emulator version 9.0.2 (Debian 1:9.0.2+ds-4ubuntu7) $ qemu-system-aarch64 -M xlnx-versal-virt \
-display none -m 4G -serial mon:stdio \ -device loader,file=u-boot,cpu-num=0
U-Boot 2025.01-rc2-00172-g880fcc49eb40 (Nov 25 2024 - 11:18:35 +0100)
CPU: UNKNOWN Model: Xilinx Versal Virtual development board DRAM: 2 GiB (effective 4 GiB) EL Level: EL3 Core: 32 devices, 13 uclasses, devicetree: board Warning: Device tree includes old 'u-boot,dm-' tags: please fix by 2023.07! MMC: sdhci@f1040000: 0, sdhci@f1050000: 1 Loading Environment from nowhere... OK In: uart@ff000000 Out: uart@ff000000 Err: uart@ff000000 Bootmode: JTAG_MODE Net: ZYNQ GEM: ff0c0000, mdio bus ff0c0000, phyaddr 0, interface rgmii-id
Warning: ethernet@ff0c0000 (eth0) using random MAC address - 5e:f6:37:a3:68:24 eth0: ethernet@ff0c0000 ZYNQ GEM: ff0d0000, mdio bus ff0d0000, phyaddr 0, interface rgmii-id
Warning: ethernet@ff0d0000 (eth1) using random MAC address - 5e:8a:ec:a9:d7:e8 , eth1: ethernet@ff0d0000 MMC: no card present MMC: no card present Cannot persist EFI variables without system partition Missing TPMv2 device for EFI_TCG_PROTOCOL Missing RNG device for EFI_RNG_PROTOCOL Hit any key to stop autoboot: 0 Versal> usb start starting USB... Bus dwc3@fe200000: "Synchronous Abort" handler, esr 0x96000050 elr: 0000000008068fd8 lr : 0000000008069940 (reloc) elr: 000000007ff17fd8 lr : 000000007ff18940 x0 : 00000000fe20c100 x1 : 0000000040000000 x2 : 0000000033310000 x3 : 000000000000003f x4 : 000000007ffa74b0 x5 : 000000007c112880 x6 : 000000007ffa74c0 x7 : 000000007c300000 x8 : 0000000000000684 x9 : 000000007bda668c x10: 0000000000000003 x11: 0000000000000188 x12: 0000000000000000 x13: 000000007bda6be0 x14: 0000000000000000 x15: 000000007bda6224 x16: 000000007fee9244 x17: 0000000000000000 x18: 000000007bea6be0 x19: 000000007c111b48 x20: 000000007c111240 x21: 0000000047822004 x22: 000000007ff998b2 x23: 000000007ff998e8 x24: 000000007ffd4514 x25: 0000000000000000 x26: 0000000000000000 x27: 000000007c111130 x28: 000000007c1110d0 x29: 000000007bda67b0
Code: b9030660 f9416e60 d5033fbf 52a80001 (b9060401) Resetting CPU ...
resetting ...
$ cat u-boot.map .text.dwc3_core_init 0x0000000008068f24 0x6a0 drivers/usb/dwc3/core.o .text.dwc3_of_parse 0x00000000080695c4 0x310 drivers/usb/dwc3/core.o 0x00000000080695c4 dwc3_of_parse
Do you know of any QEMU/U-Boot combination where USB ever worked on the board?
Why was this visible in CI in past and why this pops up now? What has changed? I don't think there was any change in QEMu regarding USB but I can double check.
We never started USB in the CI. With patch 6/6 of the series usb_bootdev_hunter() is invoked which starts USB.
Did you push this to gitlab CI? Which test/py is failing there?
Er, we don't do "usb start" in CI yet, is why it doesn't fail there. Or are you suggesting this is a QEMU problem ?
On 11/25/24 19:08, Tom Rini wrote:
On Mon, Nov 25, 2024 at 07:03:41PM +0100, Michal Simek wrote:
On 11/25/24 11:35, Heinrich Schuchardt wrote:
On 25.11.24 11:02, Michal Simek wrote:
On 11/25/24 10:21, Heinrich Schuchardt wrote:
On 11/25/24 09:32, Michal Simek wrote:
On 11/23/24 22:45, Heinrich Schuchardt wrote: > The CI uses the following command to launch xilinx_versal_virt_defconfig: > > qemu-system-aarch64 -M xlnx-versal-virt \ > -display none -m 4G -serial mon:stdio \ > -device loader,file=u-boot,cpu-num=0 > > 'usb start' or invoking eth_bootdev_hunt leads to a crash when function > dwc3_core_init() tries to access a register at offset 0xc704 (DWC3_DCTL) > relative to the register start address 0xfe20c100. > > Disable CONFIG_USB_DWC3 until the driver problem is fixed. > > Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com > --- > v2: > new patch > --- > configs/xilinx_versal_virt_defconfig | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/configs/xilinx_versal_virt_defconfig > b/configs/ xilinx_versal_virt_defconfig > index c8f166c1221..06a240173ba 100644 > --- a/configs/xilinx_versal_virt_defconfig > +++ b/configs/xilinx_versal_virt_defconfig > @@ -153,8 +153,6 @@ CONFIG_USB=y > CONFIG_DM_USB_GADGET=y > CONFIG_USB_XHCI_HCD=y > CONFIG_USB_XHCI_DWC3=y > -CONFIG_USB_DWC3=y > -CONFIG_USB_DWC3_GENERIC=y > CONFIG_USB_ULPI_VIEWPORT=y > CONFIG_USB_ULPI=y > CONFIG_USB_GADGET=y
NACK. That's not the way to go. If one test is failing in CI disable that test not really support which is for HW too.
Thanks, Michal
Hello Michal,
It is not that a single test fails. USB is completely unusable on the board. 'usb start' leads to an immediate crash.
I am not applying any patches on SOM with HEAD and usb is partially working.
Don't you see a crash when executing 'usb start'? What QEMU are you using?
I can agree that it is not super stable with upstream only patches but that's different story.
The problem already existed in v2021.01.
Any log?
$ git reset --hard origin/master $ make xilinx_versal_virt_defconfig $ CROSS_COMPILE=aarch64-linux-gnu- make -j$(nproc) $ qemu-system-riscv64 --version QEMU emulator version 9.0.2 (Debian 1:9.0.2+ds-4ubuntu7) $ qemu-system-aarch64 -M xlnx-versal-virt \
-display none -m 4G -serial mon:stdio \ -device loader,file=u-boot,cpu-num=0
U-Boot 2025.01-rc2-00172-g880fcc49eb40 (Nov 25 2024 - 11:18:35 +0100)
CPU: UNKNOWN Model: Xilinx Versal Virtual development board DRAM: 2 GiB (effective 4 GiB) EL Level: EL3 Core: 32 devices, 13 uclasses, devicetree: board Warning: Device tree includes old 'u-boot,dm-' tags: please fix by 2023.07! MMC: sdhci@f1040000: 0, sdhci@f1050000: 1 Loading Environment from nowhere... OK In: uart@ff000000 Out: uart@ff000000 Err: uart@ff000000 Bootmode: JTAG_MODE Net: ZYNQ GEM: ff0c0000, mdio bus ff0c0000, phyaddr 0, interface rgmii-id
Warning: ethernet@ff0c0000 (eth0) using random MAC address - 5e:f6:37:a3:68:24 eth0: ethernet@ff0c0000 ZYNQ GEM: ff0d0000, mdio bus ff0d0000, phyaddr 0, interface rgmii-id
Warning: ethernet@ff0d0000 (eth1) using random MAC address - 5e:8a:ec:a9:d7:e8 , eth1: ethernet@ff0d0000 MMC: no card present MMC: no card present Cannot persist EFI variables without system partition Missing TPMv2 device for EFI_TCG_PROTOCOL Missing RNG device for EFI_RNG_PROTOCOL Hit any key to stop autoboot: 0 Versal> usb start starting USB... Bus dwc3@fe200000: "Synchronous Abort" handler, esr 0x96000050 elr: 0000000008068fd8 lr : 0000000008069940 (reloc) elr: 000000007ff17fd8 lr : 000000007ff18940 x0 : 00000000fe20c100 x1 : 0000000040000000 x2 : 0000000033310000 x3 : 000000000000003f x4 : 000000007ffa74b0 x5 : 000000007c112880 x6 : 000000007ffa74c0 x7 : 000000007c300000 x8 : 0000000000000684 x9 : 000000007bda668c x10: 0000000000000003 x11: 0000000000000188 x12: 0000000000000000 x13: 000000007bda6be0 x14: 0000000000000000 x15: 000000007bda6224 x16: 000000007fee9244 x17: 0000000000000000 x18: 000000007bea6be0 x19: 000000007c111b48 x20: 000000007c111240 x21: 0000000047822004 x22: 000000007ff998b2 x23: 000000007ff998e8 x24: 000000007ffd4514 x25: 0000000000000000 x26: 0000000000000000 x27: 000000007c111130 x28: 000000007c1110d0 x29: 000000007bda67b0
Code: b9030660 f9416e60 d5033fbf 52a80001 (b9060401) Resetting CPU ...
resetting ...
$ cat u-boot.map .text.dwc3_core_init 0x0000000008068f24 0x6a0 drivers/usb/dwc3/core.o .text.dwc3_of_parse 0x00000000080695c4 0x310 drivers/usb/dwc3/core.o 0x00000000080695c4 dwc3_of_parse
Do you know of any QEMU/U-Boot combination where USB ever worked on the board?
Why was this visible in CI in past and why this pops up now? What has changed? I don't think there was any change in QEMu regarding USB but I can double check.
We never started USB in the CI. With patch 6/6 of the series usb_bootdev_hunter() is invoked which starts USB.
Did you push this to gitlab CI? Which test/py is failing there?
Er, we don't do "usb start" in CI yet, is why it doesn't fail there. Or are you suggesting this is a QEMU problem ?
This is where it is failing from dwc3_core_init(). dwc3_writel(dwc->regs, DWC3_DCTL, DWC3_DCTL_CSFTRST);
It means it is likely qemu model limitation.
Thanks, Michal
On Mon, Nov 25, 2024 at 07:44:15PM +0100, Michal Simek wrote:
On 11/25/24 19:08, Tom Rini wrote:
On Mon, Nov 25, 2024 at 07:03:41PM +0100, Michal Simek wrote:
On 11/25/24 11:35, Heinrich Schuchardt wrote:
On 25.11.24 11:02, Michal Simek wrote:
On 11/25/24 10:21, Heinrich Schuchardt wrote:
On 11/25/24 09:32, Michal Simek wrote: > > > On 11/23/24 22:45, Heinrich Schuchardt wrote: > > The CI uses the following command to launch xilinx_versal_virt_defconfig: > > > > qemu-system-aarch64 -M xlnx-versal-virt \ > > -display none -m 4G -serial mon:stdio \ > > -device loader,file=u-boot,cpu-num=0 > > > > 'usb start' or invoking eth_bootdev_hunt leads to a crash when function > > dwc3_core_init() tries to access a register at offset 0xc704 (DWC3_DCTL) > > relative to the register start address 0xfe20c100. > > > > Disable CONFIG_USB_DWC3 until the driver problem is fixed. > > > > Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com > > --- > > v2: > > new patch > > --- > > configs/xilinx_versal_virt_defconfig | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/configs/xilinx_versal_virt_defconfig > > b/configs/ xilinx_versal_virt_defconfig > > index c8f166c1221..06a240173ba 100644 > > --- a/configs/xilinx_versal_virt_defconfig > > +++ b/configs/xilinx_versal_virt_defconfig > > @@ -153,8 +153,6 @@ CONFIG_USB=y > > CONFIG_DM_USB_GADGET=y > > CONFIG_USB_XHCI_HCD=y > > CONFIG_USB_XHCI_DWC3=y > > -CONFIG_USB_DWC3=y > > -CONFIG_USB_DWC3_GENERIC=y > > CONFIG_USB_ULPI_VIEWPORT=y > > CONFIG_USB_ULPI=y > > CONFIG_USB_GADGET=y > > NACK. That's not the way to go. If one test is failing in CI > disable that test not really support which is for HW too. > > Thanks, > Michal
Hello Michal,
It is not that a single test fails. USB is completely unusable on the board. 'usb start' leads to an immediate crash.
I am not applying any patches on SOM with HEAD and usb is partially working.
Don't you see a crash when executing 'usb start'? What QEMU are you using?
I can agree that it is not super stable with upstream only patches but that's different story.
The problem already existed in v2021.01.
Any log?
$ git reset --hard origin/master $ make xilinx_versal_virt_defconfig $ CROSS_COMPILE=aarch64-linux-gnu- make -j$(nproc) $ qemu-system-riscv64 --version QEMU emulator version 9.0.2 (Debian 1:9.0.2+ds-4ubuntu7) $ qemu-system-aarch64 -M xlnx-versal-virt \
-display none -m 4G -serial mon:stdio \ -device loader,file=u-boot,cpu-num=0
U-Boot 2025.01-rc2-00172-g880fcc49eb40 (Nov 25 2024 - 11:18:35 +0100)
CPU: UNKNOWN Model: Xilinx Versal Virtual development board DRAM: 2 GiB (effective 4 GiB) EL Level: EL3 Core: 32 devices, 13 uclasses, devicetree: board Warning: Device tree includes old 'u-boot,dm-' tags: please fix by 2023.07! MMC: sdhci@f1040000: 0, sdhci@f1050000: 1 Loading Environment from nowhere... OK In: uart@ff000000 Out: uart@ff000000 Err: uart@ff000000 Bootmode: JTAG_MODE Net: ZYNQ GEM: ff0c0000, mdio bus ff0c0000, phyaddr 0, interface rgmii-id
Warning: ethernet@ff0c0000 (eth0) using random MAC address - 5e:f6:37:a3:68:24 eth0: ethernet@ff0c0000 ZYNQ GEM: ff0d0000, mdio bus ff0d0000, phyaddr 0, interface rgmii-id
Warning: ethernet@ff0d0000 (eth1) using random MAC address - 5e:8a:ec:a9:d7:e8 , eth1: ethernet@ff0d0000 MMC: no card present MMC: no card present Cannot persist EFI variables without system partition Missing TPMv2 device for EFI_TCG_PROTOCOL Missing RNG device for EFI_RNG_PROTOCOL Hit any key to stop autoboot: 0 Versal> usb start starting USB... Bus dwc3@fe200000: "Synchronous Abort" handler, esr 0x96000050 elr: 0000000008068fd8 lr : 0000000008069940 (reloc) elr: 000000007ff17fd8 lr : 000000007ff18940 x0 : 00000000fe20c100 x1 : 0000000040000000 x2 : 0000000033310000 x3 : 000000000000003f x4 : 000000007ffa74b0 x5 : 000000007c112880 x6 : 000000007ffa74c0 x7 : 000000007c300000 x8 : 0000000000000684 x9 : 000000007bda668c x10: 0000000000000003 x11: 0000000000000188 x12: 0000000000000000 x13: 000000007bda6be0 x14: 0000000000000000 x15: 000000007bda6224 x16: 000000007fee9244 x17: 0000000000000000 x18: 000000007bea6be0 x19: 000000007c111b48 x20: 000000007c111240 x21: 0000000047822004 x22: 000000007ff998b2 x23: 000000007ff998e8 x24: 000000007ffd4514 x25: 0000000000000000 x26: 0000000000000000 x27: 000000007c111130 x28: 000000007c1110d0 x29: 000000007bda67b0
Code: b9030660 f9416e60 d5033fbf 52a80001 (b9060401) Resetting CPU ...
resetting ...
$ cat u-boot.map .text.dwc3_core_init 0x0000000008068f24 0x6a0 drivers/usb/dwc3/core.o .text.dwc3_of_parse 0x00000000080695c4 0x310 drivers/usb/dwc3/core.o 0x00000000080695c4 dwc3_of_parse
Do you know of any QEMU/U-Boot combination where USB ever worked on the board?
Why was this visible in CI in past and why this pops up now? What has changed? I don't think there was any change in QEMu regarding USB but I can double check.
We never started USB in the CI. With patch 6/6 of the series usb_bootdev_hunter() is invoked which starts USB.
Did you push this to gitlab CI? Which test/py is failing there?
Er, we don't do "usb start" in CI yet, is why it doesn't fail there. Or are you suggesting this is a QEMU problem ?
This is where it is failing from dwc3_core_init(). dwc3_writel(dwc->regs, DWC3_DCTL, DWC3_DCTL_CSFTRST);
It means it is likely qemu model limitation.
And since this is for the virt platform, doesn't it make sense to disable it until the model is fixed?
On 11/25/24 19:48, Tom Rini wrote:
On Mon, Nov 25, 2024 at 07:44:15PM +0100, Michal Simek wrote:
On 11/25/24 19:08, Tom Rini wrote:
On Mon, Nov 25, 2024 at 07:03:41PM +0100, Michal Simek wrote:
On 11/25/24 11:35, Heinrich Schuchardt wrote:
On 25.11.24 11:02, Michal Simek wrote:
On 11/25/24 10:21, Heinrich Schuchardt wrote: > On 11/25/24 09:32, Michal Simek wrote: >> >> >> On 11/23/24 22:45, Heinrich Schuchardt wrote: >>> The CI uses the following command to launch xilinx_versal_virt_defconfig: >>> >>> qemu-system-aarch64 -M xlnx-versal-virt \ >>> -display none -m 4G -serial mon:stdio \ >>> -device loader,file=u-boot,cpu-num=0 >>> >>> 'usb start' or invoking eth_bootdev_hunt leads to a crash when function >>> dwc3_core_init() tries to access a register at offset 0xc704 (DWC3_DCTL) >>> relative to the register start address 0xfe20c100. >>> >>> Disable CONFIG_USB_DWC3 until the driver problem is fixed. >>> >>> Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com >>> --- >>> v2: >>> new patch >>> --- >>> configs/xilinx_versal_virt_defconfig | 2 -- >>> 1 file changed, 2 deletions(-) >>> >>> diff --git a/configs/xilinx_versal_virt_defconfig >>> b/configs/ xilinx_versal_virt_defconfig >>> index c8f166c1221..06a240173ba 100644 >>> --- a/configs/xilinx_versal_virt_defconfig >>> +++ b/configs/xilinx_versal_virt_defconfig >>> @@ -153,8 +153,6 @@ CONFIG_USB=y >>> CONFIG_DM_USB_GADGET=y >>> CONFIG_USB_XHCI_HCD=y >>> CONFIG_USB_XHCI_DWC3=y >>> -CONFIG_USB_DWC3=y >>> -CONFIG_USB_DWC3_GENERIC=y >>> CONFIG_USB_ULPI_VIEWPORT=y >>> CONFIG_USB_ULPI=y >>> CONFIG_USB_GADGET=y >> >> NACK. That's not the way to go. If one test is failing in CI >> disable that test not really support which is for HW too. >> >> Thanks, >> Michal > > Hello Michal, > > It is not that a single test fails. USB is completely unusable > on the board. 'usb start' leads to an immediate crash.
I am not applying any patches on SOM with HEAD and usb is partially working.
Don't you see a crash when executing 'usb start'? What QEMU are you using?
I can agree that it is not super stable with upstream only patches but that's different story.
> > The problem already existed in v2021.01.
Any log?
$ git reset --hard origin/master $ make xilinx_versal_virt_defconfig $ CROSS_COMPILE=aarch64-linux-gnu- make -j$(nproc) $ qemu-system-riscv64 --version QEMU emulator version 9.0.2 (Debian 1:9.0.2+ds-4ubuntu7) $ qemu-system-aarch64 -M xlnx-versal-virt \
-display none -m 4G -serial mon:stdio \ -device loader,file=u-boot,cpu-num=0
U-Boot 2025.01-rc2-00172-g880fcc49eb40 (Nov 25 2024 - 11:18:35 +0100)
CPU: UNKNOWN Model: Xilinx Versal Virtual development board DRAM: 2 GiB (effective 4 GiB) EL Level: EL3 Core: 32 devices, 13 uclasses, devicetree: board Warning: Device tree includes old 'u-boot,dm-' tags: please fix by 2023.07! MMC: sdhci@f1040000: 0, sdhci@f1050000: 1 Loading Environment from nowhere... OK In: uart@ff000000 Out: uart@ff000000 Err: uart@ff000000 Bootmode: JTAG_MODE Net: ZYNQ GEM: ff0c0000, mdio bus ff0c0000, phyaddr 0, interface rgmii-id
Warning: ethernet@ff0c0000 (eth0) using random MAC address - 5e:f6:37:a3:68:24 eth0: ethernet@ff0c0000 ZYNQ GEM: ff0d0000, mdio bus ff0d0000, phyaddr 0, interface rgmii-id
Warning: ethernet@ff0d0000 (eth1) using random MAC address - 5e:8a:ec:a9:d7:e8 , eth1: ethernet@ff0d0000 MMC: no card present MMC: no card present Cannot persist EFI variables without system partition Missing TPMv2 device for EFI_TCG_PROTOCOL Missing RNG device for EFI_RNG_PROTOCOL Hit any key to stop autoboot: 0 Versal> usb start starting USB... Bus dwc3@fe200000: "Synchronous Abort" handler, esr 0x96000050 elr: 0000000008068fd8 lr : 0000000008069940 (reloc) elr: 000000007ff17fd8 lr : 000000007ff18940 x0 : 00000000fe20c100 x1 : 0000000040000000 x2 : 0000000033310000 x3 : 000000000000003f x4 : 000000007ffa74b0 x5 : 000000007c112880 x6 : 000000007ffa74c0 x7 : 000000007c300000 x8 : 0000000000000684 x9 : 000000007bda668c x10: 0000000000000003 x11: 0000000000000188 x12: 0000000000000000 x13: 000000007bda6be0 x14: 0000000000000000 x15: 000000007bda6224 x16: 000000007fee9244 x17: 0000000000000000 x18: 000000007bea6be0 x19: 000000007c111b48 x20: 000000007c111240 x21: 0000000047822004 x22: 000000007ff998b2 x23: 000000007ff998e8 x24: 000000007ffd4514 x25: 0000000000000000 x26: 0000000000000000 x27: 000000007c111130 x28: 000000007c1110d0 x29: 000000007bda67b0
Code: b9030660 f9416e60 d5033fbf 52a80001 (b9060401) Resetting CPU ...
resetting ...
$ cat u-boot.map .text.dwc3_core_init 0x0000000008068f24 0x6a0 drivers/usb/dwc3/core.o .text.dwc3_of_parse 0x00000000080695c4 0x310 drivers/usb/dwc3/core.o 0x00000000080695c4 dwc3_of_parse
> Do you know of any QEMU/U-Boot combination where USB ever worked on the board?
Why was this visible in CI in past and why this pops up now? What has changed? I don't think there was any change in QEMu regarding USB but I can double check.
We never started USB in the CI. With patch 6/6 of the series usb_bootdev_hunter() is invoked which starts USB.
Did you push this to gitlab CI? Which test/py is failing there?
Er, we don't do "usb start" in CI yet, is why it doesn't fail there. Or are you suggesting this is a QEMU problem ?
This is where it is failing from dwc3_core_init(). dwc3_writel(dwc->regs, DWC3_DCTL, DWC3_DCTL_CSFTRST);
It means it is likely qemu model limitation.
And since this is for the virt platform, doesn't it make sense to disable it until the model is fixed?
If we are talking about CI it is about pytests. It means we can simply just disable that particular test which wants to call it.
And I can't see any issue in CI when this series is applied on the top of rc3. https://source.denx.de/u-boot/custodians/u-boot-microblaze/-/pipelines/23565
From my perspective make no sense to remove usb from defconfig because it is used on real HW (we are using this defconfig for real HW). If there is any issue with USB then we can just disable USB in CI only.
Thanks, Michal
On 11/26/24 08:57, Michal Simek wrote:
On 11/25/24 19:48, Tom Rini wrote:
On Mon, Nov 25, 2024 at 07:44:15PM +0100, Michal Simek wrote:
On 11/25/24 19:08, Tom Rini wrote:
On Mon, Nov 25, 2024 at 07:03:41PM +0100, Michal Simek wrote:
On 11/25/24 11:35, Heinrich Schuchardt wrote:
On 25.11.24 11:02, Michal Simek wrote: > > > On 11/25/24 10:21, Heinrich Schuchardt wrote: >> On 11/25/24 09:32, Michal Simek wrote: >>> >>> >>> On 11/23/24 22:45, Heinrich Schuchardt wrote: >>>> The CI uses the following command to launch >>>> xilinx_versal_virt_defconfig: >>>> >>>> qemu-system-aarch64 -M xlnx-versal-virt \ >>>> -display none -m 4G -serial mon:stdio \ >>>> -device loader,file=u-boot,cpu-num=0 >>>> >>>> 'usb start' or invoking eth_bootdev_hunt leads to a crash when >>>> function >>>> dwc3_core_init() tries to access a register at offset 0xc704 >>>> (DWC3_DCTL) >>>> relative to the register start address 0xfe20c100. >>>> >>>> Disable CONFIG_USB_DWC3 until the driver problem is fixed. >>>> >>>> Signed-off-by: Heinrich Schuchardt >>>> heinrich.schuchardt@canonical.com >>>> --- >>>> v2: >>>> new patch >>>> --- >>>> configs/xilinx_versal_virt_defconfig | 2 -- >>>> 1 file changed, 2 deletions(-) >>>> >>>> diff --git a/configs/xilinx_versal_virt_defconfig >>>> b/configs/ xilinx_versal_virt_defconfig >>>> index c8f166c1221..06a240173ba 100644 >>>> --- a/configs/xilinx_versal_virt_defconfig >>>> +++ b/configs/xilinx_versal_virt_defconfig >>>> @@ -153,8 +153,6 @@ CONFIG_USB=y >>>> CONFIG_DM_USB_GADGET=y >>>> CONFIG_USB_XHCI_HCD=y >>>> CONFIG_USB_XHCI_DWC3=y >>>> -CONFIG_USB_DWC3=y >>>> -CONFIG_USB_DWC3_GENERIC=y >>>> CONFIG_USB_ULPI_VIEWPORT=y >>>> CONFIG_USB_ULPI=y >>>> CONFIG_USB_GADGET=y >>> >>> NACK. That's not the way to go. If one test is failing in CI >>> disable that test not really support which is for HW too. >>> >>> Thanks, >>> Michal >> >> Hello Michal, >> >> It is not that a single test fails. USB is completely unusable >> on the board. 'usb start' leads to an immediate crash. > > I am not applying any patches on SOM with HEAD and usb is > partially working.
Don't you see a crash when executing 'usb start'? What QEMU are you using?
> I can agree that it is not super stable with upstream only patches > but that's different story. > >> >> The problem already existed in v2021.01. > > Any log?
$ git reset --hard origin/master $ make xilinx_versal_virt_defconfig $ CROSS_COMPILE=aarch64-linux-gnu- make -j$(nproc) $ qemu-system-riscv64 --version QEMU emulator version 9.0.2 (Debian 1:9.0.2+ds-4ubuntu7) $ qemu-system-aarch64 -M xlnx-versal-virt \ > -display none -m 4G -serial mon:stdio \ > -device loader,file=u-boot,cpu-num=0
U-Boot 2025.01-rc2-00172-g880fcc49eb40 (Nov 25 2024 - 11:18:35 +0100)
CPU: UNKNOWN Model: Xilinx Versal Virtual development board DRAM: 2 GiB (effective 4 GiB) EL Level: EL3 Core: 32 devices, 13 uclasses, devicetree: board Warning: Device tree includes old 'u-boot,dm-' tags: please fix by 2023.07! MMC: sdhci@f1040000: 0, sdhci@f1050000: 1 Loading Environment from nowhere... OK In: uart@ff000000 Out: uart@ff000000 Err: uart@ff000000 Bootmode: JTAG_MODE Net: ZYNQ GEM: ff0c0000, mdio bus ff0c0000, phyaddr 0, interface rgmii-id
Warning: ethernet@ff0c0000 (eth0) using random MAC address - 5e:f6:37:a3:68:24 eth0: ethernet@ff0c0000 ZYNQ GEM: ff0d0000, mdio bus ff0d0000, phyaddr 0, interface rgmii-id
Warning: ethernet@ff0d0000 (eth1) using random MAC address - 5e:8a:ec:a9:d7:e8 , eth1: ethernet@ff0d0000 MMC: no card present MMC: no card present Cannot persist EFI variables without system partition Missing TPMv2 device for EFI_TCG_PROTOCOL Missing RNG device for EFI_RNG_PROTOCOL Hit any key to stop autoboot: 0 Versal> usb start starting USB... Bus dwc3@fe200000: "Synchronous Abort" handler, esr 0x96000050 elr: 0000000008068fd8 lr : 0000000008069940 (reloc) elr: 000000007ff17fd8 lr : 000000007ff18940 x0 : 00000000fe20c100 x1 : 0000000040000000 x2 : 0000000033310000 x3 : 000000000000003f x4 : 000000007ffa74b0 x5 : 000000007c112880 x6 : 000000007ffa74c0 x7 : 000000007c300000 x8 : 0000000000000684 x9 : 000000007bda668c x10: 0000000000000003 x11: 0000000000000188 x12: 0000000000000000 x13: 000000007bda6be0 x14: 0000000000000000 x15: 000000007bda6224 x16: 000000007fee9244 x17: 0000000000000000 x18: 000000007bea6be0 x19: 000000007c111b48 x20: 000000007c111240 x21: 0000000047822004 x22: 000000007ff998b2 x23: 000000007ff998e8 x24: 000000007ffd4514 x25: 0000000000000000 x26: 0000000000000000 x27: 000000007c111130 x28: 000000007c1110d0 x29: 000000007bda67b0
Code: b9030660 f9416e60 d5033fbf 52a80001 (b9060401) Resetting CPU ...
resetting ...
$ cat u-boot.map .text.dwc3_core_init 0x0000000008068f24 0x6a0 drivers/usb/dwc3/ core.o .text.dwc3_of_parse 0x00000000080695c4 0x310 drivers/usb/dwc3/ core.o 0x00000000080695c4 dwc3_of_parse
> >> Do you know of any QEMU/U-Boot combination where USB ever worked >> on the board? > > Why was this visible in CI in past and why this pops up now? > What has changed? I don't think there was any change in QEMu > regarding USB but I can double check.
We never started USB in the CI. With patch 6/6 of the series usb_bootdev_hunter() is invoked which starts USB.
Did you push this to gitlab CI? Which test/py is failing there?
Er, we don't do "usb start" in CI yet, is why it doesn't fail there. Or are you suggesting this is a QEMU problem ?
This is where it is failing from dwc3_core_init(). dwc3_writel(dwc->regs, DWC3_DCTL, DWC3_DCTL_CSFTRST);
It means it is likely qemu model limitation.
And since this is for the virt platform, doesn't it make sense to disable it until the model is fixed?
If we are talking about CI it is about pytests. It means we can simply just disable that particular test which wants to call it.
And I can't see any issue in CI when this series is applied on the top of rc3. https://source.denx.de/u-boot/custodians/u-boot-microblaze/-/ pipelines/23565
From my perspective make no sense to remove usb from defconfig because it is used on real HW (we are using this defconfig for real HW). If there is any issue with USB then we can just disable USB in CI only.
Hello Michal,
Thank you for the suggestion.
Overriding defconfigs in the CI is possible. I am currently testing with this patch
https://source.denx.de/u-boot/custodians/u-boot-efi/-/commit/f1980dd387b7720...
diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml index 4ecf76eaa0b..bac577ec008 100644 --- a/.azure-pipelines.yml +++ b/.azure-pipelines.yml @@ -511,6 +511,7 @@ stages: TEST_PY_BD: "xilinx_versal_virt" TEST_PY_ID: "--id qemu" TEST_PY_TEST_SPEC: "not sleep" + OVERRIDE: "-a ~CONFIG_USB_DWC3" xtfpga: TEST_PY_BD: "xtfpga" TEST_PY_ID: "--id qemu" diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 2164ad79a72..714284a56df 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -508,6 +508,7 @@ xilinx_versal_virt test.py: TEST_PY_BD: "xilinx_versal_virt" TEST_PY_TEST_SPEC: "not sleep" TEST_PY_ID: "--id qemu" + OVERRIDE: "-a ~CONFIG_USB_DWC3" <<: *buildman_and_testpy_dfn
xtfpga test.py:
Best regards
Heinrich
On 11/26/24 09:34, Heinrich Schuchardt wrote:
On 11/26/24 08:57, Michal Simek wrote:
On 11/25/24 19:48, Tom Rini wrote:
On Mon, Nov 25, 2024 at 07:44:15PM +0100, Michal Simek wrote:
On 11/25/24 19:08, Tom Rini wrote:
On Mon, Nov 25, 2024 at 07:03:41PM +0100, Michal Simek wrote:
On 11/25/24 11:35, Heinrich Schuchardt wrote: > On 25.11.24 11:02, Michal Simek wrote: >> >> >> On 11/25/24 10:21, Heinrich Schuchardt wrote: >>> On 11/25/24 09:32, Michal Simek wrote: >>>> >>>> >>>> On 11/23/24 22:45, Heinrich Schuchardt wrote: >>>>> The CI uses the following command to launch >>>>> xilinx_versal_virt_defconfig: >>>>> >>>>> qemu-system-aarch64 -M xlnx-versal-virt \ >>>>> -display none -m 4G -serial mon:stdio \ >>>>> -device loader,file=u-boot,cpu-num=0 >>>>> >>>>> 'usb start' or invoking eth_bootdev_hunt leads to a crash when function >>>>> dwc3_core_init() tries to access a register at offset 0xc704 (DWC3_DCTL) >>>>> relative to the register start address 0xfe20c100. >>>>> >>>>> Disable CONFIG_USB_DWC3 until the driver problem is fixed. >>>>> >>>>> Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com >>>>> --- >>>>> v2: >>>>> new patch >>>>> --- >>>>> configs/xilinx_versal_virt_defconfig | 2 -- >>>>> 1 file changed, 2 deletions(-) >>>>> >>>>> diff --git a/configs/xilinx_versal_virt_defconfig >>>>> b/configs/ xilinx_versal_virt_defconfig >>>>> index c8f166c1221..06a240173ba 100644 >>>>> --- a/configs/xilinx_versal_virt_defconfig >>>>> +++ b/configs/xilinx_versal_virt_defconfig >>>>> @@ -153,8 +153,6 @@ CONFIG_USB=y >>>>> CONFIG_DM_USB_GADGET=y >>>>> CONFIG_USB_XHCI_HCD=y >>>>> CONFIG_USB_XHCI_DWC3=y >>>>> -CONFIG_USB_DWC3=y >>>>> -CONFIG_USB_DWC3_GENERIC=y >>>>> CONFIG_USB_ULPI_VIEWPORT=y >>>>> CONFIG_USB_ULPI=y >>>>> CONFIG_USB_GADGET=y >>>> >>>> NACK. That's not the way to go. If one test is failing in CI >>>> disable that test not really support which is for HW too. >>>> >>>> Thanks, >>>> Michal >>> >>> Hello Michal, >>> >>> It is not that a single test fails. USB is completely unusable >>> on the board. 'usb start' leads to an immediate crash. >> >> I am not applying any patches on SOM with HEAD and usb is partially >> working. > > Don't you see a crash when executing 'usb start'? > What QEMU are you using? > >> I can agree that it is not super stable with upstream only patches >> but that's different story. >> >>> >>> The problem already existed in v2021.01. >> >> Any log? > > $ git reset --hard origin/master > $ make xilinx_versal_virt_defconfig > $ CROSS_COMPILE=aarch64-linux-gnu- make -j$(nproc) > $ qemu-system-riscv64 --version > QEMU emulator version 9.0.2 (Debian 1:9.0.2+ds-4ubuntu7) > $ qemu-system-aarch64 -M xlnx-versal-virt \ > > -display none -m 4G -serial mon:stdio \ > > -device loader,file=u-boot,cpu-num=0 > > > U-Boot 2025.01-rc2-00172-g880fcc49eb40 (Nov 25 2024 - 11:18:35 +0100) > > CPU: UNKNOWN > Model: Xilinx Versal Virtual development board > DRAM: 2 GiB (effective 4 GiB) > EL Level: EL3 > Core: 32 devices, 13 uclasses, devicetree: board > Warning: Device tree includes old 'u-boot,dm-' tags: please fix by 2023.07! > MMC: sdhci@f1040000: 0, sdhci@f1050000: 1 > Loading Environment from nowhere... OK > In: uart@ff000000 > Out: uart@ff000000 > Err: uart@ff000000 > Bootmode: JTAG_MODE > Net: > ZYNQ GEM: ff0c0000, mdio bus ff0c0000, phyaddr 0, interface rgmii-id > > Warning: ethernet@ff0c0000 (eth0) using random MAC address - > 5e:f6:37:a3:68:24 > eth0: ethernet@ff0c0000 > ZYNQ GEM: ff0d0000, mdio bus ff0d0000, phyaddr 0, interface rgmii-id > > Warning: ethernet@ff0d0000 (eth1) using random MAC address - > 5e:8a:ec:a9:d7:e8 > , eth1: ethernet@ff0d0000 > MMC: no card present > MMC: no card present > Cannot persist EFI variables without system partition > Missing TPMv2 device for EFI_TCG_PROTOCOL > Missing RNG device for EFI_RNG_PROTOCOL > Hit any key to stop autoboot: 0 > Versal> usb start > starting USB... > Bus dwc3@fe200000: "Synchronous Abort" handler, esr 0x96000050 > elr: 0000000008068fd8 lr : 0000000008069940 (reloc) > elr: 000000007ff17fd8 lr : 000000007ff18940 > x0 : 00000000fe20c100 x1 : 0000000040000000 > x2 : 0000000033310000 x3 : 000000000000003f > x4 : 000000007ffa74b0 x5 : 000000007c112880 > x6 : 000000007ffa74c0 x7 : 000000007c300000 > x8 : 0000000000000684 x9 : 000000007bda668c > x10: 0000000000000003 x11: 0000000000000188 > x12: 0000000000000000 x13: 000000007bda6be0 > x14: 0000000000000000 x15: 000000007bda6224 > x16: 000000007fee9244 x17: 0000000000000000 > x18: 000000007bea6be0 x19: 000000007c111b48 > x20: 000000007c111240 x21: 0000000047822004 > x22: 000000007ff998b2 x23: 000000007ff998e8 > x24: 000000007ffd4514 x25: 0000000000000000 > x26: 0000000000000000 x27: 000000007c111130 > x28: 000000007c1110d0 x29: 000000007bda67b0 > > Code: b9030660 f9416e60 d5033fbf 52a80001 (b9060401) > Resetting CPU ... > > resetting ... > > $ cat u-boot.map > .text.dwc3_core_init > 0x0000000008068f24 0x6a0 drivers/usb/dwc3/ core.o > .text.dwc3_of_parse > 0x00000000080695c4 0x310 drivers/usb/dwc3/ core.o > 0x00000000080695c4 dwc3_of_parse > >> >>> Do you know of any QEMU/U-Boot combination where USB ever worked on the >>> board? >> >> Why was this visible in CI in past and why this pops up now? >> What has changed? I don't think there was any change in QEMu >> regarding USB but I can double check. > > We never started USB in the CI. > With patch 6/6 of the series usb_bootdev_hunter() is invoked which starts > USB.
Did you push this to gitlab CI? Which test/py is failing there?
Er, we don't do "usb start" in CI yet, is why it doesn't fail there. Or are you suggesting this is a QEMU problem ?
This is where it is failing from dwc3_core_init(). dwc3_writel(dwc->regs, DWC3_DCTL, DWC3_DCTL_CSFTRST);
It means it is likely qemu model limitation.
And since this is for the virt platform, doesn't it make sense to disable it until the model is fixed?
If we are talking about CI it is about pytests. It means we can simply just disable that particular test which wants to call it.
And I can't see any issue in CI when this series is applied on the top of rc3. https://source.denx.de/u-boot/custodians/u-boot-microblaze/-/ pipelines/23565
From my perspective make no sense to remove usb from defconfig because it is used on real HW (we are using this defconfig for real HW). If there is any issue with USB then we can just disable USB in CI only.
Hello Michal,
Thank you for the suggestion.
Overriding defconfigs in the CI is possible. I am currently testing with this patch
https://source.denx.de/u-boot/custodians/u-boot-efi/-/commit/ f1980dd387b77200a987c50c4856c3b52df664c6
diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml index 4ecf76eaa0b..bac577ec008 100644 --- a/.azure-pipelines.yml +++ b/.azure-pipelines.yml @@ -511,6 +511,7 @@ stages: TEST_PY_BD: "xilinx_versal_virt" TEST_PY_ID: "--id qemu" TEST_PY_TEST_SPEC: "not sleep" + OVERRIDE: "-a ~CONFIG_USB_DWC3" xtfpga: TEST_PY_BD: "xtfpga" TEST_PY_ID: "--id qemu" diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 2164ad79a72..714284a56df 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -508,6 +508,7 @@ xilinx_versal_virt test.py: TEST_PY_BD: "xilinx_versal_virt" TEST_PY_TEST_SPEC: "not sleep" TEST_PY_ID: "--id qemu" + OVERRIDE: "-a ~CONFIG_USB_DWC3" <<: *buildman_and_testpy_dfn
xtfpga test.py:
I more think to do it via u-boot pytest hooks like we are doing here for skipping tpm tests.
https://source.denx.de/u-boot/u-boot-test-hooks/-/blob/master/py/travis-ci/u...
It means if this is any EFI test there should be an option to disable the whole test.
Thanks, Michal
Michal Simek michal.simek@amd.com schrieb am Mo., 25. Nov. 2024, 19:04:
On 11/25/24 11:35, Heinrich Schuchardt wrote:
On 25.11.24 11:02, Michal Simek wrote:
On 11/25/24 10:21, Heinrich Schuchardt wrote:
On 11/25/24 09:32, Michal Simek wrote:
On 11/23/24 22:45, Heinrich Schuchardt wrote:
The CI uses the following command to launch
xilinx_versal_virt_defconfig:
qemu-system-aarch64 -M xlnx-versal-virt \ -display none -m 4G -serial mon:stdio \ -device loader,file=u-boot,cpu-num=0'usb start' or invoking eth_bootdev_hunt leads to a crash when
function
dwc3_core_init() tries to access a register at offset 0xc704
(DWC3_DCTL)
relative to the register start address 0xfe20c100.
Disable CONFIG_USB_DWC3 until the driver problem is fixed.
Signed-off-by: Heinrich Schuchardt <
heinrich.schuchardt@canonical.com>
v2: new patch
configs/xilinx_versal_virt_defconfig | 2 -- 1 file changed, 2 deletions(-)
diff --git a/configs/xilinx_versal_virt_defconfig b/configs/ xilinx_versal_virt_defconfig index c8f166c1221..06a240173ba 100644 --- a/configs/xilinx_versal_virt_defconfig +++ b/configs/xilinx_versal_virt_defconfig @@ -153,8 +153,6 @@ CONFIG_USB=y CONFIG_DM_USB_GADGET=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y -CONFIG_USB_DWC3=y -CONFIG_USB_DWC3_GENERIC=y CONFIG_USB_ULPI_VIEWPORT=y CONFIG_USB_ULPI=y CONFIG_USB_GADGET=y
NACK. That's not the way to go. If one test is failing in CI disable
that
test not really support which is for HW too.
Thanks, Michal
Hello Michal,
It is not that a single test fails. USB is completely unusable on the
board.
'usb start' leads to an immediate crash.
I am not applying any patches on SOM with HEAD and usb is partially
working.
Don't you see a crash when executing 'usb start'? What QEMU are you using?
I can agree that it is not super stable with upstream only patches but
that's
different story.
The problem already existed in v2021.01.
Any log?
$ git reset --hard origin/master $ make xilinx_versal_virt_defconfig $ CROSS_COMPILE=aarch64-linux-gnu- make -j$(nproc) $ qemu-system-riscv64 --version QEMU emulator version 9.0.2 (Debian 1:9.0.2+ds-4ubuntu7) $ qemu-system-aarch64 -M xlnx-versal-virt \
-display none -m 4G -serial mon:stdio \ -device loader,file=u-boot,cpu-num=0
U-Boot 2025.01-rc2-00172-g880fcc49eb40 (Nov 25 2024 - 11:18:35 +0100)
CPU: UNKNOWN Model: Xilinx Versal Virtual development board DRAM: 2 GiB (effective 4 GiB) EL Level: EL3 Core: 32 devices, 13 uclasses, devicetree: board Warning: Device tree includes old 'u-boot,dm-' tags: please fix by
2023.07!
MMC: sdhci@f1040000: 0, sdhci@f1050000: 1 Loading Environment from nowhere... OK In: uart@ff000000 Out: uart@ff000000 Err: uart@ff000000 Bootmode: JTAG_MODE Net: ZYNQ GEM: ff0c0000, mdio bus ff0c0000, phyaddr 0, interface rgmii-id
Warning: ethernet@ff0c0000 (eth0) using random MAC address -
5e:f6:37:a3:68:24
eth0: ethernet@ff0c0000 ZYNQ GEM: ff0d0000, mdio bus ff0d0000, phyaddr 0, interface rgmii-id
Warning: ethernet@ff0d0000 (eth1) using random MAC address -
5e:8a:ec:a9:d7:e8
, eth1: ethernet@ff0d0000 MMC: no card present MMC: no card present Cannot persist EFI variables without system partition Missing TPMv2 device for EFI_TCG_PROTOCOL Missing RNG device for EFI_RNG_PROTOCOL Hit any key to stop autoboot: 0 Versal> usb start starting USB... Bus dwc3@fe200000: "Synchronous Abort" handler, esr 0x96000050 elr: 0000000008068fd8 lr : 0000000008069940 (reloc) elr: 000000007ff17fd8 lr : 000000007ff18940 x0 : 00000000fe20c100 x1 : 0000000040000000 x2 : 0000000033310000 x3 : 000000000000003f x4 : 000000007ffa74b0 x5 : 000000007c112880 x6 : 000000007ffa74c0 x7 : 000000007c300000 x8 : 0000000000000684 x9 : 000000007bda668c x10: 0000000000000003 x11: 0000000000000188 x12: 0000000000000000 x13: 000000007bda6be0 x14: 0000000000000000 x15: 000000007bda6224 x16: 000000007fee9244 x17: 0000000000000000 x18: 000000007bea6be0 x19: 000000007c111b48 x20: 000000007c111240 x21: 0000000047822004 x22: 000000007ff998b2 x23: 000000007ff998e8 x24: 000000007ffd4514 x25: 0000000000000000 x26: 0000000000000000 x27: 000000007c111130 x28: 000000007c1110d0 x29: 000000007bda67b0
Code: b9030660 f9416e60 d5033fbf 52a80001 (b9060401) Resetting CPU ...
resetting ...
$ cat u-boot.map .text.dwc3_core_init 0x0000000008068f24 0x6a0 drivers/usb/dwc3/core.o .text.dwc3_of_parse 0x00000000080695c4 0x310 drivers/usb/dwc3/core.o 0x00000000080695c4 dwc3_of_parse
Do you know of any QEMU/U-Boot combination where USB ever worked on
the board?
Why was this visible in CI in past and why this pops up now? What has changed? I don't think there was any change in QEMu regarding
USB but
I can double check.
We never started USB in the CI. With patch 6/6 of the series usb_bootdev_hunter() is invoked which
starts USB.
Did you push this to gitlab CI? Which test/py is failing there?
M
This is the failed job. https://source.denx.de/u-boot/custodians/u-boot-efi/-/jobs/955501
https://source.denx.de/u-boot/custodians/u-boot-efi/-/commit/636a4f4793d4d50...
The board failed to boot.
Best regards
Heinrich
On 11/25/24 21:09, Heinrich Schuchardt wrote:
Michal Simek <michal.simek@amd.com mailto:michal.simek@amd.com> schrieb am Mo., 25. Nov. 2024, 19:04:
On 11/25/24 11:35, Heinrich Schuchardt wrote: > On 25.11.24 11:02, Michal Simek wrote: >> >> >> On 11/25/24 10:21, Heinrich Schuchardt wrote: >>> On 11/25/24 09:32, Michal Simek wrote: >>>> >>>> >>>> On 11/23/24 22:45, Heinrich Schuchardt wrote: >>>>> The CI uses the following command to launch xilinx_versal_virt_defconfig: >>>>> >>>>> qemu-system-aarch64 -M xlnx-versal-virt \ >>>>> -display none -m 4G -serial mon:stdio \ >>>>> -device loader,file=u-boot,cpu-num=0 >>>>> >>>>> 'usb start' or invoking eth_bootdev_hunt leads to a crash when function >>>>> dwc3_core_init() tries to access a register at offset 0xc704 (DWC3_DCTL) >>>>> relative to the register start address 0xfe20c100. >>>>> >>>>> Disable CONFIG_USB_DWC3 until the driver problem is fixed. >>>>> >>>>> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com <mailto:heinrich.schuchardt@canonical.com>> >>>>> --- >>>>> v2: >>>>> new patch >>>>> --- >>>>> configs/xilinx_versal_virt_defconfig | 2 -- >>>>> 1 file changed, 2 deletions(-) >>>>> >>>>> diff --git a/configs/xilinx_versal_virt_defconfig b/configs/ >>>>> xilinx_versal_virt_defconfig >>>>> index c8f166c1221..06a240173ba 100644 >>>>> --- a/configs/xilinx_versal_virt_defconfig >>>>> +++ b/configs/xilinx_versal_virt_defconfig >>>>> @@ -153,8 +153,6 @@ CONFIG_USB=y >>>>> CONFIG_DM_USB_GADGET=y >>>>> CONFIG_USB_XHCI_HCD=y >>>>> CONFIG_USB_XHCI_DWC3=y >>>>> -CONFIG_USB_DWC3=y >>>>> -CONFIG_USB_DWC3_GENERIC=y >>>>> CONFIG_USB_ULPI_VIEWPORT=y >>>>> CONFIG_USB_ULPI=y >>>>> CONFIG_USB_GADGET=y >>>> >>>> NACK. That's not the way to go. If one test is failing in CI disable that >>>> test not really support which is for HW too. >>>> >>>> Thanks, >>>> Michal >>> >>> Hello Michal, >>> >>> It is not that a single test fails. USB is completely unusable on the board. >>> 'usb start' leads to an immediate crash. >> >> I am not applying any patches on SOM with HEAD and usb is partially working. > > Don't you see a crash when executing 'usb start'? > What QEMU are you using? > >> I can agree that it is not super stable with upstream only patches but that's >> different story. >> >>> >>> The problem already existed in v2021.01. >> >> Any log? > > $ git reset --hard origin/master > $ make xilinx_versal_virt_defconfig > $ CROSS_COMPILE=aarch64-linux-gnu- make -j$(nproc) > $ qemu-system-riscv64 --version > QEMU emulator version 9.0.2 (Debian 1:9.0.2+ds-4ubuntu7) > $ qemu-system-aarch64 -M xlnx-versal-virt \ > > -display none -m 4G -serial mon:stdio \ > > -device loader,file=u-boot,cpu-num=0 > > > U-Boot 2025.01-rc2-00172-g880fcc49eb40 (Nov 25 2024 - 11:18:35 +0100) > > CPU: UNKNOWN > Model: Xilinx Versal Virtual development board > DRAM: 2 GiB (effective 4 GiB) > EL Level: EL3 > Core: 32 devices, 13 uclasses, devicetree: board > Warning: Device tree includes old 'u-boot,dm-' tags: please fix by 2023.07! > MMC: sdhci@f1040000: 0, sdhci@f1050000: 1 > Loading Environment from nowhere... OK > In: uart@ff000000 > Out: uart@ff000000 > Err: uart@ff000000 > Bootmode: JTAG_MODE > Net: > ZYNQ GEM: ff0c0000, mdio bus ff0c0000, phyaddr 0, interface rgmii-id > > Warning: ethernet@ff0c0000 (eth0) using random MAC address - 5e:f6:37:a3:68:24 > eth0: ethernet@ff0c0000 > ZYNQ GEM: ff0d0000, mdio bus ff0d0000, phyaddr 0, interface rgmii-id > > Warning: ethernet@ff0d0000 (eth1) using random MAC address - 5e:8a:ec:a9:d7:e8 > , eth1: ethernet@ff0d0000 > MMC: no card present > MMC: no card present > Cannot persist EFI variables without system partition > Missing TPMv2 device for EFI_TCG_PROTOCOL > Missing RNG device for EFI_RNG_PROTOCOL > Hit any key to stop autoboot: 0 > Versal> usb start > starting USB... > Bus dwc3@fe200000: "Synchronous Abort" handler, esr 0x96000050 > elr: 0000000008068fd8 lr : 0000000008069940 (reloc) > elr: 000000007ff17fd8 lr : 000000007ff18940 > x0 : 00000000fe20c100 x1 : 0000000040000000 > x2 : 0000000033310000 x3 : 000000000000003f > x4 : 000000007ffa74b0 x5 : 000000007c112880 > x6 : 000000007ffa74c0 x7 : 000000007c300000 > x8 : 0000000000000684 x9 : 000000007bda668c > x10: 0000000000000003 x11: 0000000000000188 > x12: 0000000000000000 x13: 000000007bda6be0 > x14: 0000000000000000 x15: 000000007bda6224 > x16: 000000007fee9244 x17: 0000000000000000 > x18: 000000007bea6be0 x19: 000000007c111b48 > x20: 000000007c111240 x21: 0000000047822004 > x22: 000000007ff998b2 x23: 000000007ff998e8 > x24: 000000007ffd4514 x25: 0000000000000000 > x26: 0000000000000000 x27: 000000007c111130 > x28: 000000007c1110d0 x29: 000000007bda67b0 > > Code: b9030660 f9416e60 d5033fbf 52a80001 (b9060401) > Resetting CPU ... > > resetting ... > > $ cat u-boot.map > .text.dwc3_core_init > 0x0000000008068f24 0x6a0 drivers/usb/dwc3/core.o > .text.dwc3_of_parse > 0x00000000080695c4 0x310 drivers/usb/dwc3/core.o > 0x00000000080695c4 dwc3_of_parse > >> >>> Do you know of any QEMU/U-Boot combination where USB ever worked on the board? >> >> Why was this visible in CI in past and why this pops up now? >> What has changed? I don't think there was any change in QEMu regarding USB but >> I can double check. > > We never started USB in the CI. > With patch 6/6 of the series usb_bootdev_hunter() is invoked which starts USB. Did you push this to gitlab CI? Which test/py is failing there? MThis is the failed job. https://source.denx.de/u-boot/custodians/u-boot-efi/-/jobs/955501 <https:// source.denx.de/u-boot/custodians/u-boot-efi/-/jobs/955501>
https://source.denx.de/u-boot/custodians/u-boot-efi/-/ commit/636a4f4793d4d5098afdd46b00205c7bb245570c <https://source.denx.de/u-boot/ custodians/u-boot-efi/-/commit/636a4f4793d4d5098afdd46b00205c7bb245570c>
I can't see any issue when I apply this series on the top of rc3
https://source.denx.de/u-boot/custodians/u-boot-microblaze/-/pipelines/23565
Thanks, Michal
On 11/26/24 08:56, Michal Simek wrote:
On 11/25/24 21:09, Heinrich Schuchardt wrote:
Michal Simek <michal.simek@amd.com mailto:michal.simek@amd.com> schrieb am Mo., 25. Nov. 2024, 19:04:
On 11/25/24 11:35, Heinrich Schuchardt wrote: > On 25.11.24 11:02, Michal Simek wrote: >> >> >> On 11/25/24 10:21, Heinrich Schuchardt wrote: >>> On 11/25/24 09:32, Michal Simek wrote: >>>> >>>> >>>> On 11/23/24 22:45, Heinrich Schuchardt wrote: >>>>> The CI uses the following command to launch xilinx_versal_virt_defconfig: >>>>> >>>>> qemu-system-aarch64 -M xlnx-versal-virt \ >>>>> -display none -m 4G -serial mon:stdio \ >>>>> -device loader,file=u-boot,cpu-num=0 >>>>> >>>>> 'usb start' or invoking eth_bootdev_hunt leads to a crash when function >>>>> dwc3_core_init() tries to access a register at offset 0xc704 (DWC3_DCTL) >>>>> relative to the register start address 0xfe20c100. >>>>> >>>>> Disable CONFIG_USB_DWC3 until the driver problem is fixed. >>>>> >>>>> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com mailto:heinrich.schuchardt@canonical.com> >>>>> --- >>>>> v2: >>>>> new patch >>>>> --- >>>>> configs/xilinx_versal_virt_defconfig | 2 -- >>>>> 1 file changed, 2 deletions(-) >>>>> >>>>> diff --git a/configs/xilinx_versal_virt_defconfig b/configs/ >>>>> xilinx_versal_virt_defconfig >>>>> index c8f166c1221..06a240173ba 100644 >>>>> --- a/configs/xilinx_versal_virt_defconfig >>>>> +++ b/configs/xilinx_versal_virt_defconfig >>>>> @@ -153,8 +153,6 @@ CONFIG_USB=y >>>>> CONFIG_DM_USB_GADGET=y >>>>> CONFIG_USB_XHCI_HCD=y >>>>> CONFIG_USB_XHCI_DWC3=y >>>>> -CONFIG_USB_DWC3=y >>>>> -CONFIG_USB_DWC3_GENERIC=y >>>>> CONFIG_USB_ULPI_VIEWPORT=y >>>>> CONFIG_USB_ULPI=y >>>>> CONFIG_USB_GADGET=y >>>> >>>> NACK. That's not the way to go. If one test is failing in CI disable that >>>> test not really support which is for HW too. >>>> >>>> Thanks, >>>> Michal >>> >>> Hello Michal, >>> >>> It is not that a single test fails. USB is completely unusable on the board. >>> 'usb start' leads to an immediate crash. >> >> I am not applying any patches on SOM with HEAD and usb is partially working. > > Don't you see a crash when executing 'usb start'? > What QEMU are you using? > >> I can agree that it is not super stable with upstream only patches but that's >> different story. >> >>> >>> The problem already existed in v2021.01. >> >> Any log? > > $ git reset --hard origin/master > $ make xilinx_versal_virt_defconfig > $ CROSS_COMPILE=aarch64-linux-gnu- make -j$(nproc) > $ qemu-system-riscv64 --version > QEMU emulator version 9.0.2 (Debian 1:9.0.2+ds-4ubuntu7) > $ qemu-system-aarch64 -M xlnx-versal-virt \ > > -display none -m 4G -serial mon:stdio \ > > -device loader,file=u-boot,cpu-num=0 > > > U-Boot 2025.01-rc2-00172-g880fcc49eb40 (Nov 25 2024 - 11:18:35 +0100) > > CPU: UNKNOWN > Model: Xilinx Versal Virtual development board > DRAM: 2 GiB (effective 4 GiB) > EL Level: EL3 > Core: 32 devices, 13 uclasses, devicetree: board > Warning: Device tree includes old 'u-boot,dm-' tags: please fix by 2023.07! > MMC: sdhci@f1040000: 0, sdhci@f1050000: 1 > Loading Environment from nowhere... OK > In: uart@ff000000 > Out: uart@ff000000 > Err: uart@ff000000 > Bootmode: JTAG_MODE > Net: > ZYNQ GEM: ff0c0000, mdio bus ff0c0000, phyaddr 0, interface rgmii-id > > Warning: ethernet@ff0c0000 (eth0) using random MAC address - 5e:f6:37:a3:68:24 > eth0: ethernet@ff0c0000 > ZYNQ GEM: ff0d0000, mdio bus ff0d0000, phyaddr 0, interface rgmii-id > > Warning: ethernet@ff0d0000 (eth1) using random MAC address - 5e:8a:ec:a9:d7:e8 > , eth1: ethernet@ff0d0000 > MMC: no card present > MMC: no card present > Cannot persist EFI variables without system partition > Missing TPMv2 device for EFI_TCG_PROTOCOL > Missing RNG device for EFI_RNG_PROTOCOL > Hit any key to stop autoboot: 0 > Versal> usb start > starting USB... > Bus dwc3@fe200000: "Synchronous Abort" handler, esr 0x96000050 > elr: 0000000008068fd8 lr : 0000000008069940 (reloc) > elr: 000000007ff17fd8 lr : 000000007ff18940 > x0 : 00000000fe20c100 x1 : 0000000040000000 > x2 : 0000000033310000 x3 : 000000000000003f > x4 : 000000007ffa74b0 x5 : 000000007c112880 > x6 : 000000007ffa74c0 x7 : 000000007c300000 > x8 : 0000000000000684 x9 : 000000007bda668c > x10: 0000000000000003 x11: 0000000000000188 > x12: 0000000000000000 x13: 000000007bda6be0 > x14: 0000000000000000 x15: 000000007bda6224 > x16: 000000007fee9244 x17: 0000000000000000 > x18: 000000007bea6be0 x19: 000000007c111b48 > x20: 000000007c111240 x21: 0000000047822004 > x22: 000000007ff998b2 x23: 000000007ff998e8 > x24: 000000007ffd4514 x25: 0000000000000000 > x26: 0000000000000000 x27: 000000007c111130 > x28: 000000007c1110d0 x29: 000000007bda67b0 > > Code: b9030660 f9416e60 d5033fbf 52a80001 (b9060401) > Resetting CPU ... > > resetting ... > > $ cat u-boot.map > .text.dwc3_core_init > 0x0000000008068f24 0x6a0 drivers/usb/ dwc3/core.o > .text.dwc3_of_parse > 0x00000000080695c4 0x310 drivers/usb/ dwc3/core.o > 0x00000000080695c4 dwc3_of_parse > >> >>> Do you know of any QEMU/U-Boot combination where USB ever worked on the board? >> >> Why was this visible in CI in past and why this pops up now? >> What has changed? I don't think there was any change in QEMu regarding USB but >> I can double check. > > We never started USB in the CI. > With patch 6/6 of the series usb_bootdev_hunter() is invoked which starts USB.
Did you push this to gitlab CI? Which test/py is failing there?
M
This is the failed job. https://source.denx.de/u-boot/custodians/u-boot-efi/-/jobs/955501 <https:// source.denx.de/u-boot/custodians/u-boot-efi/-/jobs/955501>
https://source.denx.de/u-boot/custodians/u-boot-efi/-/ commit/636a4f4793d4d5098afdd46b00205c7bb245570c <https:// source.denx.de/u-boot/ custodians/u-boot-efi/-/ commit/636a4f4793d4d5098afdd46b00205c7bb245570c>
I can't see any issue when I apply this series on the top of rc3
https://source.denx.de/u-boot/custodians/u-boot-microblaze/-/ pipelines/23565
Hello Michal,
The link https://source.denx.de/u-boot/custodians/u-boot-microblaze/-/pipelines/23565 is not valid for me (404 Page not found).
Could you, please, indicate the branch and commit.
Best regards
Heinrich
On Tue, Nov 26, 2024 at 09:05:47AM +0100, Heinrich Schuchardt wrote:
On 11/26/24 08:56, Michal Simek wrote:
On 11/25/24 21:09, Heinrich Schuchardt wrote:
Michal Simek <michal.simek@amd.com mailto:michal.simek@amd.com> schrieb am Mo., 25. Nov. 2024, 19:04:
On 11/25/24 11:35, Heinrich Schuchardt wrote: > On 25.11.24 11:02, Michal Simek wrote: >> >> >> On 11/25/24 10:21, Heinrich Schuchardt wrote: >>> On 11/25/24 09:32, Michal Simek wrote: >>>> >>>> >>>> On 11/23/24 22:45, Heinrich Schuchardt wrote: >>>>> The CI uses the following command to launch xilinx_versal_virt_defconfig: >>>>> >>>>> qemu-system-aarch64 -M xlnx-versal-virt \ >>>>> -display none -m 4G -serial mon:stdio \ >>>>> -device loader,file=u-boot,cpu-num=0 >>>>> >>>>> 'usb start' or invoking eth_bootdev_hunt leads to a crash when function >>>>> dwc3_core_init() tries to access a register at offset 0xc704 (DWC3_DCTL) >>>>> relative to the register start address 0xfe20c100. >>>>> >>>>> Disable CONFIG_USB_DWC3 until the driver problem is fixed. >>>>> >>>>> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com mailto:heinrich.schuchardt@canonical.com> >>>>> --- >>>>> v2: >>>>> new patch >>>>> --- >>>>> configs/xilinx_versal_virt_defconfig | 2 -- >>>>> 1 file changed, 2 deletions(-) >>>>> >>>>> diff --git a/configs/xilinx_versal_virt_defconfig b/configs/ >>>>> xilinx_versal_virt_defconfig >>>>> index c8f166c1221..06a240173ba 100644 >>>>> --- a/configs/xilinx_versal_virt_defconfig >>>>> +++ b/configs/xilinx_versal_virt_defconfig >>>>> @@ -153,8 +153,6 @@ CONFIG_USB=y >>>>> CONFIG_DM_USB_GADGET=y >>>>> CONFIG_USB_XHCI_HCD=y >>>>> CONFIG_USB_XHCI_DWC3=y >>>>> -CONFIG_USB_DWC3=y >>>>> -CONFIG_USB_DWC3_GENERIC=y >>>>> CONFIG_USB_ULPI_VIEWPORT=y >>>>> CONFIG_USB_ULPI=y >>>>> CONFIG_USB_GADGET=y >>>> >>>> NACK. That's not the way to go. If one test is failing in CI disable that >>>> test not really support which is for HW too. >>>> >>>> Thanks, >>>> Michal >>> >>> Hello Michal, >>> >>> It is not that a single test fails. USB is completely unusable on the board. >>> 'usb start' leads to an immediate crash. >> >> I am not applying any patches on SOM with HEAD and usb is partially working. > > Don't you see a crash when executing 'usb start'? > What QEMU are you using? > >> I can agree that it is not super stable with upstream only patches but that's >> different story. >> >>> >>> The problem already existed in v2021.01. >> >> Any log? > > $ git reset --hard origin/master > $ make xilinx_versal_virt_defconfig > $ CROSS_COMPILE=aarch64-linux-gnu- make -j$(nproc) > $ qemu-system-riscv64 --version > QEMU emulator version 9.0.2 (Debian 1:9.0.2+ds-4ubuntu7) > $ qemu-system-aarch64 -M xlnx-versal-virt \ > > -display none -m 4G -serial mon:stdio \ > > -device loader,file=u-boot,cpu-num=0 > > > U-Boot 2025.01-rc2-00172-g880fcc49eb40 (Nov 25 2024 - 11:18:35 +0100) > > CPU: UNKNOWN > Model: Xilinx Versal Virtual development board > DRAM: 2 GiB (effective 4 GiB) > EL Level: EL3 > Core: 32 devices, 13 uclasses, devicetree: board > Warning: Device tree includes old 'u-boot,dm-' tags: please fix by 2023.07! > MMC: sdhci@f1040000: 0, sdhci@f1050000: 1 > Loading Environment from nowhere... OK > In: uart@ff000000 > Out: uart@ff000000 > Err: uart@ff000000 > Bootmode: JTAG_MODE > Net: > ZYNQ GEM: ff0c0000, mdio bus ff0c0000, phyaddr 0, interface rgmii-id > > Warning: ethernet@ff0c0000 (eth0) using random MAC address - 5e:f6:37:a3:68:24 > eth0: ethernet@ff0c0000 > ZYNQ GEM: ff0d0000, mdio bus ff0d0000, phyaddr 0, interface rgmii-id > > Warning: ethernet@ff0d0000 (eth1) using random MAC address - 5e:8a:ec:a9:d7:e8 > , eth1: ethernet@ff0d0000 > MMC: no card present > MMC: no card present > Cannot persist EFI variables without system partition > Missing TPMv2 device for EFI_TCG_PROTOCOL > Missing RNG device for EFI_RNG_PROTOCOL > Hit any key to stop autoboot: 0 > Versal> usb start > starting USB... > Bus dwc3@fe200000: "Synchronous Abort" handler, esr 0x96000050 > elr: 0000000008068fd8 lr : 0000000008069940 (reloc) > elr: 000000007ff17fd8 lr : 000000007ff18940 > x0 : 00000000fe20c100 x1 : 0000000040000000 > x2 : 0000000033310000 x3 : 000000000000003f > x4 : 000000007ffa74b0 x5 : 000000007c112880 > x6 : 000000007ffa74c0 x7 : 000000007c300000 > x8 : 0000000000000684 x9 : 000000007bda668c > x10: 0000000000000003 x11: 0000000000000188 > x12: 0000000000000000 x13: 000000007bda6be0 > x14: 0000000000000000 x15: 000000007bda6224 > x16: 000000007fee9244 x17: 0000000000000000 > x18: 000000007bea6be0 x19: 000000007c111b48 > x20: 000000007c111240 x21: 0000000047822004 > x22: 000000007ff998b2 x23: 000000007ff998e8 > x24: 000000007ffd4514 x25: 0000000000000000 > x26: 0000000000000000 x27: 000000007c111130 > x28: 000000007c1110d0 x29: 000000007bda67b0 > > Code: b9030660 f9416e60 d5033fbf 52a80001 (b9060401) > Resetting CPU ... > > resetting ... > > $ cat u-boot.map > .text.dwc3_core_init > 0x0000000008068f24 0x6a0 drivers/usb/ dwc3/core.o > .text.dwc3_of_parse > 0x00000000080695c4 0x310 drivers/usb/ dwc3/core.o > 0x00000000080695c4 dwc3_of_parse > >> >>> Do you know of any QEMU/U-Boot combination where USB ever worked on the board? >> >> Why was this visible in CI in past and why this pops up now? >> What has changed? I don't think there was any change in QEMu regarding USB but >> I can double check. > > We never started USB in the CI. > With patch 6/6 of the series usb_bootdev_hunter() is invoked which starts USB.
Did you push this to gitlab CI? Which test/py is failing there?
M
This is the failed job. https://source.denx.de/u-boot/custodians/u-boot-efi/-/jobs/955501 <https:// source.denx.de/u-boot/custodians/u-boot-efi/-/jobs/955501>
https://source.denx.de/u-boot/custodians/u-boot-efi/-/ commit/636a4f4793d4d5098afdd46b00205c7bb245570c <https:// source.denx.de/u-boot/ custodians/u-boot-efi/-/ commit/636a4f4793d4d5098afdd46b00205c7bb245570c>
I can't see any issue when I apply this series on the top of rc3
https://source.denx.de/u-boot/custodians/u-boot-microblaze/-/ pipelines/23565
Hello Michal,
The link https://source.denx.de/u-boot/custodians/u-boot-microblaze/-/pipelines/23565 is not valid for me (404 Page not found).
This should work now. The trees initially defaulted to public pipelines being off, and I thought I had fixed everyone over the years, but, clearly not.
eth_bootdev_hunt() should not execute dhcp_run() as this itself would load a file and boot it if autostart=yes.
Instead just check that there is a network device.
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com --- v2: new patch --- net/eth_bootdev.c | 30 ++++++++++++++++++------------ 1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/net/eth_bootdev.c b/net/eth_bootdev.c index 6ee54e3c790..b0fca6e8313 100644 --- a/net/eth_bootdev.c +++ b/net/eth_bootdev.c @@ -64,9 +64,23 @@ static int eth_bootdev_bind(struct udevice *dev) return 0; }
+/** + * eth_bootdev_hunt() - probe all network devices + * + * Network devices can also come from USB, but that is a higher + * priority (BOOTDEVP_5_SCAN_SLOW) than network, so it should have been + * enumerated already. If something like 'bootflow scan dhcp' is used, + * then the user will need to run 'usb start' first. + * + * @info: info structure describing this hunter + * @show: true to show information from the hunter + * + * Return: 0 if device found, -EINVAL otherwise + */ static int eth_bootdev_hunt(struct bootdev_hunter *info, bool show) { int ret; + struct udevice *dev = NULL;
if (!test_eth_enabled()) return 0; @@ -78,19 +92,11 @@ static int eth_bootdev_hunt(struct bootdev_hunter *info, bool show) log_warning("Failed to init PCI (%dE)\n", ret); }
- /* - * Ethernet devices can also come from USB, but that is a higher - * priority (BOOTDEVP_5_SCAN_SLOW) than ethernet, so it should have been - * enumerated already. If something like 'bootflow scan dhcp' is used - * then the user will need to run 'usb start' first. - */ - if (IS_ENABLED(CONFIG_CMD_DHCP)) { - ret = dhcp_run(0, NULL, false); - if (ret) - return -EINVAL; - } + ret = -EINVAL; + uclass_foreach_dev_probe(UCLASS_ETH, dev) + ret = 0;
- return 0; + return ret; }
struct bootdev_ops eth_bootdev_ops = {
Hi Heinrich
On Sat, 23 Nov 2024 at 23:46, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
eth_bootdev_hunt() should not execute dhcp_run() as this itself would load a file and boot it if autostart=yes.
Instead just check that there is a network device.
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com
v2: new patch
net/eth_bootdev.c | 30 ++++++++++++++++++------------ 1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/net/eth_bootdev.c b/net/eth_bootdev.c index 6ee54e3c790..b0fca6e8313 100644 --- a/net/eth_bootdev.c +++ b/net/eth_bootdev.c @@ -64,9 +64,23 @@ static int eth_bootdev_bind(struct udevice *dev) return 0; }
+/**
- eth_bootdev_hunt() - probe all network devices
- Network devices can also come from USB, but that is a higher
- priority (BOOTDEVP_5_SCAN_SLOW) than network, so it should have been
- enumerated already. If something like 'bootflow scan dhcp' is used,
- then the user will need to run 'usb start' first.
- @info: info structure describing this hunter
- @show: true to show information from the hunter
- Return: 0 if device found, -EINVAL otherwise
- */
static int eth_bootdev_hunt(struct bootdev_hunter *info, bool show) { int ret;
struct udevice *dev = NULL; if (!test_eth_enabled()) return 0;@@ -78,19 +92,11 @@ static int eth_bootdev_hunt(struct bootdev_hunter *info, bool show) log_warning("Failed to init PCI (%dE)\n", ret); }
/** Ethernet devices can also come from USB, but that is a higher* priority (BOOTDEVP_5_SCAN_SLOW) than ethernet, so it should have been* enumerated already. If something like 'bootflow scan dhcp' is used* then the user will need to run 'usb start' first.*/if (IS_ENABLED(CONFIG_CMD_DHCP)) {ret = dhcp_run(0, NULL, false);if (ret)return -EINVAL;}
ret = -EINVAL;uclass_foreach_dev_probe(UCLASS_ETH, dev)ret = 0;
return 0;
return ret;
I agree with the reasoning above. Now that we have LWIP it would be a good idea to try to boot only if ww receive and parse option 66 on DHCP.
In any case FWIW Reviewed-by: Ilias Apalodimas ilias.apalodimas@linaro.org
}
struct bootdev_ops eth_bootdev_ops = {
2.45.2
Hi Heinrich,
On Sat, 23 Nov 2024 at 14:46, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
eth_bootdev_hunt() should not execute dhcp_run() as this itself would load a file and boot it if autostart=yes.
Instead just check that there is a network device.
If you look at dhcp_run() you will see an 'autoload' parameter. This is 'false' in this code, so it never loads a file.
Regards, Simon
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com
v2: new patch
net/eth_bootdev.c | 30 ++++++++++++++++++------------ 1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/net/eth_bootdev.c b/net/eth_bootdev.c index 6ee54e3c790..b0fca6e8313 100644 --- a/net/eth_bootdev.c +++ b/net/eth_bootdev.c @@ -64,9 +64,23 @@ static int eth_bootdev_bind(struct udevice *dev) return 0; }
+/**
- eth_bootdev_hunt() - probe all network devices
- Network devices can also come from USB, but that is a higher
- priority (BOOTDEVP_5_SCAN_SLOW) than network, so it should have been
- enumerated already. If something like 'bootflow scan dhcp' is used,
- then the user will need to run 'usb start' first.
- @info: info structure describing this hunter
- @show: true to show information from the hunter
- Return: 0 if device found, -EINVAL otherwise
- */
static int eth_bootdev_hunt(struct bootdev_hunter *info, bool show) { int ret;
struct udevice *dev = NULL; if (!test_eth_enabled()) return 0;@@ -78,19 +92,11 @@ static int eth_bootdev_hunt(struct bootdev_hunter *info, bool show) log_warning("Failed to init PCI (%dE)\n", ret); }
/** Ethernet devices can also come from USB, but that is a higher* priority (BOOTDEVP_5_SCAN_SLOW) than ethernet, so it should have been* enumerated already. If something like 'bootflow scan dhcp' is used* then the user will need to run 'usb start' first.*/if (IS_ENABLED(CONFIG_CMD_DHCP)) {ret = dhcp_run(0, NULL, false);if (ret)return -EINVAL;}
ret = -EINVAL;uclass_foreach_dev_probe(UCLASS_ETH, dev)ret = 0;
return 0;
return ret;}
struct bootdev_ops eth_bootdev_ops = {
2.45.2
On 11/26/24 01:32, Simon Glass wrote:
Hi Heinrich,
On Sat, 23 Nov 2024 at 14:46, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
eth_bootdev_hunt() should not execute dhcp_run() as this itself would load a file and boot it if autostart=yes.
Instead just check that there is a network device.
If you look at dhcp_run() you will see an 'autoload' parameter. This is 'false' in this code, so it never loads a file.
This is not the complete truth.
If $autostart=true and CONFIG_NET=y, dhcp_run(false) still tries to load a file.
In all cases dhcp_run() wastes boot time.
CONFIG_NET=y => dhcp_run BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 DHCP client bound to address 10.0.2.15 (1004 ms)
=> setenv autostart true => dhcp run BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 DHCP client bound to address 10.0.2.15 (1002 ms) Using e1000#0 device TFTP from server 10.0.2.2; our IP address is 10.0.2.15 Filename 'run'. Load address: 0x40200000 Loading: * TFTP error: 'File not found' (1) Not retrying...
CONFIG_NET_LWIP=y => dhcp_run DHCP client bound to address 10.0.2.15 (1007 ms)
Where command dhcp_run is provided by:
#include <command.h> #include <env.h> #include <net-common.h> #include <vsprintf.h>
static int do_dhcp_run(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]) { ulong addr = hextoul(env_get("loadaddr"), NULL);
dhcp_run(addr, NULL, false);
return 0; }
U_BOOT_CMD( dhcp_run, CONFIG_SYS_MAXARGS, 1, do_dhcp_run, "dhcp_run", NULL );
Best regards
Heinrich
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com
v2: new patch
net/eth_bootdev.c | 30 ++++++++++++++++++------------ 1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/net/eth_bootdev.c b/net/eth_bootdev.c index 6ee54e3c790..b0fca6e8313 100644 --- a/net/eth_bootdev.c +++ b/net/eth_bootdev.c @@ -64,9 +64,23 @@ static int eth_bootdev_bind(struct udevice *dev) return 0; }
+/**
- eth_bootdev_hunt() - probe all network devices
- Network devices can also come from USB, but that is a higher
- priority (BOOTDEVP_5_SCAN_SLOW) than network, so it should have been
- enumerated already. If something like 'bootflow scan dhcp' is used,
- then the user will need to run 'usb start' first.
- @info: info structure describing this hunter
- @show: true to show information from the hunter
- Return: 0 if device found, -EINVAL otherwise
*/ static int eth_bootdev_hunt(struct bootdev_hunter *info, bool show) { int ret;
struct udevice *dev = NULL; if (!test_eth_enabled()) return 0;@@ -78,19 +92,11 @@ static int eth_bootdev_hunt(struct bootdev_hunter *info, bool show) log_warning("Failed to init PCI (%dE)\n", ret); }
/** Ethernet devices can also come from USB, but that is a higher* priority (BOOTDEVP_5_SCAN_SLOW) than ethernet, so it should have been* enumerated already. If something like 'bootflow scan dhcp' is used* then the user will need to run 'usb start' first.*/if (IS_ENABLED(CONFIG_CMD_DHCP)) {ret = dhcp_run(0, NULL, false);if (ret)return -EINVAL;}
ret = -EINVAL;uclass_foreach_dev_probe(UCLASS_ETH, dev)ret = 0;
return 0;
return ret;}
struct bootdev_ops eth_bootdev_ops = {
-- 2.45.2
Hi Heinrich,
On Tue, 26 Nov 2024 at 00:42, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
On 11/26/24 01:32, Simon Glass wrote:
Hi Heinrich,
On Sat, 23 Nov 2024 at 14:46, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
eth_bootdev_hunt() should not execute dhcp_run() as this itself would load a file and boot it if autostart=yes.
Instead just check that there is a network device.
If you look at dhcp_run() you will see an 'autoload' parameter. This is 'false' in this code, so it never loads a file.
This is not the complete truth.
If $autostart=true and CONFIG_NET=y, dhcp_run(false) still tries to load a file.
Here is the code:
int dhcp_run(ulong addr, const char *fname, bool autoload) { char *dhcp_argv[] = {"dhcp", NULL, (char *)fname, NULL}; struct cmd_tbl cmdtp = {}; /* dummy */ char file_addr[17]; int old_autoload; int ret, result;
log_debug("addr=%lx, fname=%s, autoload=%d\n", addr, fname, autoload); old_autoload = env_get_yesno("autoload"); ret = env_set("autoload", autoload ? "y" : "n"); if (ret) return log_msg_ret("en1", -EINVAL);
It respects the autoload parameter. If there is a bug in that, we should fix it, but it seems to work OK to me. Please fix your commit message.
In all cases dhcp_run() wastes boot time.
Yes, it uses time. With bootstd the hunters are only called as needed. In your case you are calling all of them at once.
Is there a way to just call hunters which relate to block devices, perhaps?
CONFIG_NET=y => dhcp_run BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 DHCP client bound to address 10.0.2.15 (1004 ms)
=> setenv autostart true => dhcp run BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 DHCP client bound to address 10.0.2.15 (1002 ms) Using e1000#0 device TFTP from server 10.0.2.2; our IP address is 10.0.2.15 Filename 'run'. Load address: 0x40200000 Loading: * TFTP error: 'File not found' (1) Not retrying...
CONFIG_NET_LWIP=y => dhcp_run DHCP client bound to address 10.0.2.15 (1007 ms)
Where command dhcp_run is provided by:
#include <command.h> #include <env.h> #include <net-common.h> #include <vsprintf.h>
static int do_dhcp_run(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]) { ulong addr = hextoul(env_get("loadaddr"), NULL);
dhcp_run(addr, NULL, false); return 0;}
U_BOOT_CMD( dhcp_run, CONFIG_SYS_MAXARGS, 1, do_dhcp_run, "dhcp_run", NULL );
See above
[..]
Regards, Simon
On 26.11.24 16:38, Simon Glass wrote:
Hi Heinrich,
On Tue, 26 Nov 2024 at 00:42, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
On 11/26/24 01:32, Simon Glass wrote:
Hi Heinrich,
On Sat, 23 Nov 2024 at 14:46, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
eth_bootdev_hunt() should not execute dhcp_run() as this itself would load a file and boot it if autostart=yes.
Instead just check that there is a network device.
If you look at dhcp_run() you will see an 'autoload' parameter. This is 'false' in this code, so it never loads a file.
This is not the complete truth.
If $autostart=true and CONFIG_NET=y, dhcp_run(false) still tries to load a file.
Here is the code:
int dhcp_run(ulong addr, const char *fname, bool autoload) { char *dhcp_argv[] = {"dhcp", NULL, (char *)fname, NULL}; struct cmd_tbl cmdtp = {}; /* dummy */ char file_addr[17]; int old_autoload; int ret, result;
log_debug("addr=%lx, fname=%s, autoload=%d\n", addr, fname, autoload); old_autoload = env_get_yesno("autoload"); ret = env_set("autoload", autoload ? "y" : "n"); if (ret) return log_msg_ret("en1", -EINVAL);
It respects the autoload parameter. If there is a bug in that, we should fix it, but it seems to work OK to me. Please fix your commit message.
The cited code only sets "autoload". It does not adjust "autostart".
As I have shown below this leads to trying to boot via DHCP.
This is exactly what the commit message says: "load a file and boot it if autostart=yes".
In all cases dhcp_run() wastes boot time.
Yes, it uses time. With bootstd the hunters are only called as needed. In your case you are calling all of them at once.
Is there a way to just call hunters which relate to block devices, perhaps?
We need to probe network to provide the simple network protocol (lib/efi_loader/efi_net.c) but we don't need to execute DHCP.
We also need the correct device-tree provided by the extension hunter.
Best regards
Heinrich
CONFIG_NET=y => dhcp_run BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 DHCP client bound to address 10.0.2.15 (1004 ms)
=> setenv autostart true => dhcp run BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 DHCP client bound to address 10.0.2.15 (1002 ms) Using e1000#0 device TFTP from server 10.0.2.2; our IP address is 10.0.2.15 Filename 'run'. Load address: 0x40200000 Loading: * TFTP error: 'File not found' (1) Not retrying...
CONFIG_NET_LWIP=y => dhcp_run DHCP client bound to address 10.0.2.15 (1007 ms)
Where command dhcp_run is provided by:
#include <command.h> #include <env.h> #include <net-common.h> #include <vsprintf.h>
static int do_dhcp_run(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]) { ulong addr = hextoul(env_get("loadaddr"), NULL);
dhcp_run(addr, NULL, false); return 0;}
U_BOOT_CMD( dhcp_run, CONFIG_SYS_MAXARGS, 1, do_dhcp_run, "dhcp_run", NULL );
See above
[..]
Regards, Simon
Hi Heinrich,
On Tue, 26 Nov 2024 at 09:16, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
On 26.11.24 16:38, Simon Glass wrote:
Hi Heinrich,
On Tue, 26 Nov 2024 at 00:42, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
On 11/26/24 01:32, Simon Glass wrote:
Hi Heinrich,
On Sat, 23 Nov 2024 at 14:46, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
eth_bootdev_hunt() should not execute dhcp_run() as this itself would load a file and boot it if autostart=yes.
Instead just check that there is a network device.
If you look at dhcp_run() you will see an 'autoload' parameter. This is 'false' in this code, so it never loads a file.
This is not the complete truth.
If $autostart=true and CONFIG_NET=y, dhcp_run(false) still tries to load a file.
Here is the code:
int dhcp_run(ulong addr, const char *fname, bool autoload) { char *dhcp_argv[] = {"dhcp", NULL, (char *)fname, NULL}; struct cmd_tbl cmdtp = {}; /* dummy */ char file_addr[17]; int old_autoload; int ret, result;
log_debug("addr=%lx, fname=%s, autoload=%d\n", addr, fname, autoload); old_autoload = env_get_yesno("autoload"); ret = env_set("autoload", autoload ? "y" : "n"); if (ret) return log_msg_ret("en1", -EINVAL);
It respects the autoload parameter. If there is a bug in that, we should fix it, but it seems to work OK to me. Please fix your commit message.
The cited code only sets "autoload". It does not adjust "autostart".
As I have shown below this leads to trying to boot via DHCP.
This is exactly what the commit message says: "load a file and boot it if autostart=yes".
Oh, I just thought they were the same and I didn't remember about autostart
In all cases dhcp_run() wastes boot time.
Yes, it uses time. With bootstd the hunters are only called as needed. In your case you are calling all of them at once.
Is there a way to just call hunters which relate to block devices, perhaps?
We need to probe network to provide the simple network protocol (lib/efi_loader/efi_net.c) but we don't need to execute DHCP.
We also need the correct device-tree provided by the extension hunter.
It would be good to get some use of that, as it has no tests really.
As I ask on the other patch, why do you need to probe?
Best regards
Heinrich
CONFIG_NET=y => dhcp_run BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 DHCP client bound to address 10.0.2.15 (1004 ms)
=> setenv autostart true => dhcp run BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 DHCP client bound to address 10.0.2.15 (1002 ms) Using e1000#0 device TFTP from server 10.0.2.2; our IP address is 10.0.2.15 Filename 'run'. Load address: 0x40200000 Loading: * TFTP error: 'File not found' (1) Not retrying...
CONFIG_NET_LWIP=y => dhcp_run DHCP client bound to address 10.0.2.15 (1007 ms)
Where command dhcp_run is provided by:
#include <command.h> #include <env.h> #include <net-common.h> #include <vsprintf.h>
static int do_dhcp_run(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]) { ulong addr = hextoul(env_get("loadaddr"), NULL);
dhcp_run(addr, NULL, false); return 0;}
U_BOOT_CMD( dhcp_run, CONFIG_SYS_MAXARGS, 1, do_dhcp_run, "dhcp_run", NULL );
See above
[..]
Regards, Simon
Regards, Simon
On 27.11.24 14:08, Simon Glass wrote:
Hi Heinrich,
On Tue, 26 Nov 2024 at 09:16, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
On 26.11.24 16:38, Simon Glass wrote:
Hi Heinrich,
On Tue, 26 Nov 2024 at 00:42, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
On 11/26/24 01:32, Simon Glass wrote:
Hi Heinrich,
On Sat, 23 Nov 2024 at 14:46, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
eth_bootdev_hunt() should not execute dhcp_run() as this itself would load a file and boot it if autostart=yes.
Instead just check that there is a network device.
If you look at dhcp_run() you will see an 'autoload' parameter. This is 'false' in this code, so it never loads a file.
This is not the complete truth.
If $autostart=true and CONFIG_NET=y, dhcp_run(false) still tries to load a file.
Here is the code:
int dhcp_run(ulong addr, const char *fname, bool autoload) { char *dhcp_argv[] = {"dhcp", NULL, (char *)fname, NULL}; struct cmd_tbl cmdtp = {}; /* dummy */ char file_addr[17]; int old_autoload; int ret, result;
log_debug("addr=%lx, fname=%s, autoload=%d\n", addr, fname, autoload); old_autoload = env_get_yesno("autoload"); ret = env_set("autoload", autoload ? "y" : "n"); if (ret) return log_msg_ret("en1", -EINVAL);
It respects the autoload parameter. If there is a bug in that, we should fix it, but it seems to work OK to me. Please fix your commit message.
The cited code only sets "autoload". It does not adjust "autostart".
As I have shown below this leads to trying to boot via DHCP.
This is exactly what the commit message says: "load a file and boot it if autostart=yes".
Oh, I just thought they were the same and I didn't remember about autostart
In all cases dhcp_run() wastes boot time.
Yes, it uses time. With bootstd the hunters are only called as needed. In your case you are calling all of them at once.
Is there a way to just call hunters which relate to block devices, perhaps?
We need to probe network to provide the simple network protocol (lib/efi_loader/efi_net.c) but we don't need to execute DHCP.
We also need the correct device-tree provided by the extension hunter.
It would be good to get some use of that, as it has no tests really.
As I ask on the other patch, why do you need to probe?
You asked on the Network protocol.
If your idea is that the concept of extensions is not yet deployed, is there a good way to exclude BOOTDEV_HUNTER(extension_bootdev_hunter)?
Best regards
Heinrich
Best regards
Heinrich
CONFIG_NET=y => dhcp_run BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 DHCP client bound to address 10.0.2.15 (1004 ms)
=> setenv autostart true => dhcp run BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 DHCP client bound to address 10.0.2.15 (1002 ms) Using e1000#0 device TFTP from server 10.0.2.2; our IP address is 10.0.2.15 Filename 'run'. Load address: 0x40200000 Loading: * TFTP error: 'File not found' (1) Not retrying...
CONFIG_NET_LWIP=y => dhcp_run DHCP client bound to address 10.0.2.15 (1007 ms)
Where command dhcp_run is provided by:
#include <command.h> #include <env.h> #include <net-common.h> #include <vsprintf.h>
static int do_dhcp_run(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]) { ulong addr = hextoul(env_get("loadaddr"), NULL);
dhcp_run(addr, NULL, false); return 0;}
U_BOOT_CMD( dhcp_run, CONFIG_SYS_MAXARGS, 1, do_dhcp_run, "dhcp_run", NULL );
See above
[..]
Regards, Simon
Regards, Simon
Hi Heinrich,
On Wed, 27 Nov 2024 at 06:43, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
On 27.11.24 14:08, Simon Glass wrote:
Hi Heinrich,
On Tue, 26 Nov 2024 at 09:16, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
On 26.11.24 16:38, Simon Glass wrote:
Hi Heinrich,
On Tue, 26 Nov 2024 at 00:42, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
On 11/26/24 01:32, Simon Glass wrote:
Hi Heinrich,
On Sat, 23 Nov 2024 at 14:46, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote: > > eth_bootdev_hunt() should not execute dhcp_run() as this itself would load > a file and boot it if autostart=yes. > > Instead just check that there is a network device.
If you look at dhcp_run() you will see an 'autoload' parameter. This is 'false' in this code, so it never loads a file.
This is not the complete truth.
If $autostart=true and CONFIG_NET=y, dhcp_run(false) still tries to load a file.
Here is the code:
int dhcp_run(ulong addr, const char *fname, bool autoload) { char *dhcp_argv[] = {"dhcp", NULL, (char *)fname, NULL}; struct cmd_tbl cmdtp = {}; /* dummy */ char file_addr[17]; int old_autoload; int ret, result;
log_debug("addr=%lx, fname=%s, autoload=%d\n", addr, fname, autoload); old_autoload = env_get_yesno("autoload"); ret = env_set("autoload", autoload ? "y" : "n"); if (ret) return log_msg_ret("en1", -EINVAL);
It respects the autoload parameter. If there is a bug in that, we should fix it, but it seems to work OK to me. Please fix your commit message.
The cited code only sets "autoload". It does not adjust "autostart".
As I have shown below this leads to trying to boot via DHCP.
This is exactly what the commit message says: "load a file and boot it if autostart=yes".
Oh, I just thought they were the same and I didn't remember about autostart
In all cases dhcp_run() wastes boot time.
Yes, it uses time. With bootstd the hunters are only called as needed. In your case you are calling all of them at once.
Is there a way to just call hunters which relate to block devices, perhaps?
We need to probe network to provide the simple network protocol (lib/efi_loader/efi_net.c) but we don't need to execute DHCP.
We also need the correct device-tree provided by the extension hunter.
It would be good to get some use of that, as it has no tests really.
As I ask on the other patch, why do you need to probe?
You asked on the Network protocol.
If your idea is that the concept of extensions is not yet deployed, is there a good way to exclude BOOTDEV_HUNTER(extension_bootdev_hunter)?
Well, my approach with bootstd was to try to reverse-engineer what distro_boot did and extensions was one of those things.
I am not suggesting excluding it, merely that I am pleased that it is being used!
[..]
Regards, Simon
The bootmenu command can display
* menu entries defined by environment variables * menu entries defined by UEFI boot options
Not in all cases showing the UEFI boot options is desired. Provide a new parameter '-e' to select the display of UEFI boot options.
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com --- v2: new patch --- cmd/bootmenu.c | 39 +++++++++++++++++++++++++++++--------- doc/usage/cmd/bootmenu.rst | 13 ++++++++++--- 2 files changed, 40 insertions(+), 12 deletions(-)
diff --git a/cmd/bootmenu.c b/cmd/bootmenu.c index ffa63a4628d..90f4f3d583c 100644 --- a/cmd/bootmenu.c +++ b/cmd/bootmenu.c @@ -330,7 +330,13 @@ static int prepare_uefi_bootorder_entry(struct bootmenu_data *menu, } #endif
-static struct bootmenu_data *bootmenu_create(int delay) +/** + * bootmenu_create() - create boot menu entries + * + * @uefi: consider UEFI boot options + * @delay: autostart delay in seconds + */ +static struct bootmenu_data *bootmenu_create(int uefi, int delay) { int ret; unsigned short int i = 0; @@ -357,7 +363,7 @@ static struct bootmenu_data *bootmenu_create(int delay) goto cleanup;
#if (IS_ENABLED(CONFIG_CMD_BOOTEFI_BOOTMGR)) && (IS_ENABLED(CONFIG_CMD_EFICONFIG)) - if (i < MAX_COUNT - 1) { + if (uefi && i < MAX_COUNT - 1) { efi_status_t efi_ret;
/* @@ -481,7 +487,13 @@ static void handle_uefi_bootnext(void) run_command("bootefi bootmgr", 0); }
-static enum bootmenu_ret bootmenu_show(int delay) +/** + * bootmenu_show - display boot menu + * + * @uefi: generated entries for UEFI boot options + * @delay: autoboot delay in seconds + */ +static enum bootmenu_ret bootmenu_show(int uefi, int delay) { int cmd_ret; int init = 0; @@ -495,7 +507,7 @@ static enum bootmenu_ret bootmenu_show(int delay) efi_status_t efi_ret = EFI_SUCCESS; char *option, *sep;
- if (IS_ENABLED(CONFIG_CMD_BOOTEFI_BOOTMGR)) + if (IS_ENABLED(CONFIG_CMD_BOOTEFI_BOOTMGR) && uefi) handle_uefi_bootnext();
/* If delay is 0 do not create menu, just run first entry */ @@ -514,7 +526,7 @@ static enum bootmenu_ret bootmenu_show(int delay) return (cmd_ret == CMD_RET_SUCCESS ? BOOTMENU_RET_SUCCESS : BOOTMENU_RET_FAIL); }
- bootmenu = bootmenu_create(delay); + bootmenu = bootmenu_create(uefi, delay); if (!bootmenu) return BOOTMENU_RET_FAIL;
@@ -609,7 +621,7 @@ int menu_show(int bootdelay) int ret;
while (1) { - ret = bootmenu_show(bootdelay); + ret = bootmenu_show(1, bootdelay); bootdelay = -1; if (ret == BOOTMENU_RET_UPDATED) continue; @@ -635,11 +647,19 @@ int do_bootmenu(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]) { char *delay_str = NULL; int delay = 10; + int uefi = 0;
#if defined(CONFIG_BOOTDELAY) && (CONFIG_BOOTDELAY >= 0) delay = CONFIG_BOOTDELAY; #endif
+ if (argc >= 2) { + if (!strcmp("-e", argv[1])) { + uefi = 1; + --argc; + ++argv; + } + } if (argc >= 2) delay_str = argv[1];
@@ -649,13 +669,14 @@ int do_bootmenu(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]) if (delay_str) delay = (int)simple_strtol(delay_str, NULL, 10);
- bootmenu_show(delay); + bootmenu_show(uefi, delay); return 0; }
U_BOOT_CMD( bootmenu, 2, 1, do_bootmenu, "ANSI terminal bootmenu", - "[delay]\n" - " - show ANSI terminal bootmenu with autoboot delay" + "[-e] [delay]\n" + "-e - show UEFI entries\n" + "delay - show ANSI terminal bootmenu with autoboot delay" ); diff --git a/doc/usage/cmd/bootmenu.rst b/doc/usage/cmd/bootmenu.rst index 294cc02b17a..cd5597bc646 100644 --- a/doc/usage/cmd/bootmenu.rst +++ b/doc/usage/cmd/bootmenu.rst @@ -11,7 +11,7 @@ Synopsis -------- ::
- bootmenu [delay] + bootmenu [-e] [delay]
Description ----------- @@ -28,6 +28,14 @@ The "bootmenu" command interprets ANSI escape sequences, so an ANSI terminal is required for proper menu rendering and item selection.
+-e + show menu entries based on UEFI boot options + +delay + is the autoboot delay in seconds, after which the first + menu entry will be selected automatically + + The assembling of the menu is done via a set of environment variables "bootmenu_<num>" and "bootmenu_delay", i.e.::
@@ -35,8 +43,7 @@ The assembling of the menu is done via a set of environment variables bootmenu_<num>="<title>=<commands>"
<delay> - is the autoboot delay in seconds, after which the first - menu entry will be selected automatically + autostart delay in seconds
<num> is the boot menu entry number, starting from zero
On Sat, 23 Nov 2024 at 23:46, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
The bootmenu command can display
- menu entries defined by environment variables
- menu entries defined by UEFI boot options
Not in all cases showing the UEFI boot options is desired. Provide a new parameter '-e' to select the display of UEFI boot options.
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com
v2: new patch
cmd/bootmenu.c | 39 +++++++++++++++++++++++++++++--------- doc/usage/cmd/bootmenu.rst | 13 ++++++++++--- 2 files changed, 40 insertions(+), 12 deletions(-)
diff --git a/cmd/bootmenu.c b/cmd/bootmenu.c index ffa63a4628d..90f4f3d583c 100644 --- a/cmd/bootmenu.c +++ b/cmd/bootmenu.c @@ -330,7 +330,13 @@ static int prepare_uefi_bootorder_entry(struct bootmenu_data *menu, } #endif
-static struct bootmenu_data *bootmenu_create(int delay) +/**
- bootmenu_create() - create boot menu entries
- @uefi: consider UEFI boot options
- @delay: autostart delay in seconds
- */
+static struct bootmenu_data *bootmenu_create(int uefi, int delay) { int ret; unsigned short int i = 0; @@ -357,7 +363,7 @@ static struct bootmenu_data *bootmenu_create(int delay) goto cleanup;
#if (IS_ENABLED(CONFIG_CMD_BOOTEFI_BOOTMGR)) && (IS_ENABLED(CONFIG_CMD_EFICONFIG))
if (i < MAX_COUNT - 1) {
if (uefi && i < MAX_COUNT - 1) { efi_status_t efi_ret; /*@@ -481,7 +487,13 @@ static void handle_uefi_bootnext(void) run_command("bootefi bootmgr", 0); }
-static enum bootmenu_ret bootmenu_show(int delay) +/**
- bootmenu_show - display boot menu
- @uefi: generated entries for UEFI boot options
- @delay: autoboot delay in seconds
- */
+static enum bootmenu_ret bootmenu_show(int uefi, int delay) { int cmd_ret; int init = 0; @@ -495,7 +507,7 @@ static enum bootmenu_ret bootmenu_show(int delay) efi_status_t efi_ret = EFI_SUCCESS; char *option, *sep;
if (IS_ENABLED(CONFIG_CMD_BOOTEFI_BOOTMGR))
if (IS_ENABLED(CONFIG_CMD_BOOTEFI_BOOTMGR) && uefi) handle_uefi_bootnext(); /* If delay is 0 do not create menu, just run first entry */@@ -514,7 +526,7 @@ static enum bootmenu_ret bootmenu_show(int delay) return (cmd_ret == CMD_RET_SUCCESS ? BOOTMENU_RET_SUCCESS : BOOTMENU_RET_FAIL); }
bootmenu = bootmenu_create(delay);
bootmenu = bootmenu_create(uefi, delay); if (!bootmenu) return BOOTMENU_RET_FAIL;@@ -609,7 +621,7 @@ int menu_show(int bootdelay) int ret;
while (1) {
ret = bootmenu_show(bootdelay);
ret = bootmenu_show(1, bootdelay); bootdelay = -1; if (ret == BOOTMENU_RET_UPDATED) continue;@@ -635,11 +647,19 @@ int do_bootmenu(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]) { char *delay_str = NULL; int delay = 10;
int uefi = 0;#if defined(CONFIG_BOOTDELAY) && (CONFIG_BOOTDELAY >= 0) delay = CONFIG_BOOTDELAY; #endif
if (argc >= 2) {if (!strcmp("-e", argv[1])) {uefi = 1;--argc;++argv;}} if (argc >= 2) delay_str = argv[1];@@ -649,13 +669,14 @@ int do_bootmenu(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]) if (delay_str) delay = (int)simple_strtol(delay_str, NULL, 10);
bootmenu_show(delay);
bootmenu_show(uefi, delay); return 0;}
U_BOOT_CMD( bootmenu, 2, 1, do_bootmenu, "ANSI terminal bootmenu",
"[delay]\n"" - show ANSI terminal bootmenu with autoboot delay"
"[-e] [delay]\n""-e - show UEFI entries\n""delay - show ANSI terminal bootmenu with autoboot delay"); diff --git a/doc/usage/cmd/bootmenu.rst b/doc/usage/cmd/bootmenu.rst index 294cc02b17a..cd5597bc646 100644 --- a/doc/usage/cmd/bootmenu.rst +++ b/doc/usage/cmd/bootmenu.rst @@ -11,7 +11,7 @@ Synopsis
::
- bootmenu [delay]
- bootmenu [-e] [delay]
Description
@@ -28,6 +28,14 @@ The "bootmenu" command interprets ANSI escape sequences, so an ANSI terminal is required for proper menu rendering and item selection.
+-e
- show menu entries based on UEFI boot options
+delay
- is the autoboot delay in seconds, after which the first
- menu entry will be selected automatically
The assembling of the menu is done via a set of environment variables "bootmenu_<num>" and "bootmenu_delay", i.e.::
@@ -35,8 +43,7 @@ The assembling of the menu is done via a set of environment variables bootmenu_<num>="<title>=<commands>"
<delay> - is the autoboot delay in seconds, after which the first - menu entry will be selected automatically + autostart delay in seconds
<num> is the boot menu entry number, starting from zero -- 2.45.2
Reviewed-by: Ilias Apalodimas ilias.apalodimas@linaro.org
Some hard devices need specific routines to scan for block devices, e.g. NVMe (nvme scan), SCSI (scsi start).
Invoke bootdev_hunt() to find all block devices.
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com Reviewed-by: Ilias Apalodimas ilias.apalodimas@linaro.org Reviewed-by: Simon Glass sjg@chromium.org --- v2: no change --- lib/efi_loader/efi_setup.c | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c index aa59bc7779d..8e0ff16f3eb 100644 --- a/lib/efi_loader/efi_setup.c +++ b/lib/efi_loader/efi_setup.c @@ -7,6 +7,7 @@
#define LOG_CATEGORY LOGC_EFI
+#include <bootdev.h> #include <efi_loader.h> #include <efi_variable.h> #include <log.h> @@ -228,6 +229,13 @@ efi_status_t efi_init_obj_list(void) * Probe block devices to find the ESP. * efi_disks_register() must be called before efi_init_variables(). */ + if (CONFIG_IS_ENABLED(BOOTSTD)) { + int r; + + r = bootdev_hunt(NULL, 0); + if (r) + log_debug("No boot device available\n"); + } ret = efi_disks_register(); if (ret != EFI_SUCCESS) goto out;
participants (5)
-
Heinrich Schuchardt -
Ilias Apalodimas -
Michal Simek -
Simon Glass -
Tom Rini