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?