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