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.schucha...@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_boot_boardenv_xilinx_versal_virt_qemu.py?ref_type=heads#L1
It means if this is any EFI test there should be an option to disable the whole
test.
Thanks,
Michal
