05:53 <wens> I think I will have to do the PRs tonight

08:19 <captainSail> Hi! My name is Max, and I am part of a team developing a RTOS for microcontrollers based on Allwinner processors

08:19 <captainSail> We have implemented a USB driver library that works well on several platforms, but for some reason, it fails to operate correctly on the Allwinner A40i. When connecting a high-speed device, the system hangs during the reset phase. Specifically, the reset bit in the port status register does not clear, and the enable bit is never set

08:19 <captainSail> To debug the issue, I’ve carefully reviewed the Linux kernel source as a reference for PLL, USB PHY, EHCI/OHCI, and even power management settings. Our current implementation closely follows the Linux initialization sequence, yet the problem persists under our OS

08:20 <captainSail> Since the same hardware successfully runs Linux with full USB functionality, I believe the issue is not hardware-related. I also connected an oscilloscope to the D+/D- lines and monitored the controller's behavior under our OS during the reset phase. The physical reset appears to be executed correctly, but I'm not entirely sure whether the hub and device successfully negotiate the transition to high-speed mode afterward...

08:20 <captainSail> If anyone has encountered a similar issue, I would greatly appreciate any advice. Thank you in advance!

08:49 <paulk> you've probably already looked at it but there's some glue in addition to traditional ehci/ohci

08:49 <paulk> you might also look at u-boot which also supports usb host on sunxi

10:36 <captainSail> thanks, paulk

10:58 <ing_warn> Hi! Currently migrating an old A20 board from kernel 5.4.47 to 6.16. Works well overall but it fails to bring up mass_storage and acm usb gadgets. On the board I see "musb-hdrc musb-hdrc.1.auto: request (ptrval) not queued to ep1in" every 30s while pc side keeps resetting the USB device. Didn't see anything obvious when comparing kernel config and devicetrees.

11:00 <apritzel> ing_warn: there is probably indeed something fishy with USB gadgets. Can you try kernels in between, somewhat crude bisecting?

11:00 <ing_warn> Short test with 6.6.91 showed the same result. Dmesg looks pretty much the same except for "usb_phy_generic usb_phy_generic.0.auto: dummy supplies not allowed for exclusive requests (id=vbus)" which seems to be regulator... this project doesn't really care that much about regulators tbh. Any advice is highly appreciated. Thanks!

11:01 <apritzel> ing_warn: well, the kernel and the board certainly care about regulators ;-)

11:02 <apritzel> captainSail: indeed looking into U-Boot code is often more helpful to figure out how hardware needs to be configured

11:03 <apritzel> captainSail: the glue logic in the EHCI/OCHI code is generic, e.g. it's for all ARM platforms, basically meaning: just enable all those clocks and resets, and init the PHY (which you wouldn't need to do explicitly on PCI)

11:04 <apritzel> but the core of the EHCI/OCHI code should be generic

11:04 <apritzel> and then there is of course the USB-PHY to setup, where most SoCs tend to need their special quirks

11:07 <ing_warn> apritzel: haha, very true. everything relevant for the board should be set and I would have expected this "dummy supplies not allowed" message to be moreless a warning(?). I can try to fix that as well if you think it might be related. Otherwise bisecting kernel versions would be a logical next step if nothing else comes to mind.

11:15 <captainSail> apritzel: Speaking of PHY. The A40 documentation does not describe this module, as well as the documentation for many allwinner processors. All this time I have been setting up PHY based on the read/write log in linux. Is there ANY description of this module?

11:17 <captainSail> Otherwise I'm already setting up everything you mentioned. Anyway I'll look into u-boot, thanks

11:59 <apritzel> ing_warn: yes, it looks like a warning, but if you look at the code, it bails out with some error value. Got some reports of that lately, but I don't think anybody looked at this so far

12:05 <apritzel> captainSail: the A40 is special when it comes to OTG, we don't officially support that even. But you are talking about EHCI/OCHI host, not MUSB, right?

12:06 <captainSail> apritzel: sure

12:06 <captainSail> Well, I've built the latest u-boot and tried connecting a regular USB flash drive. Surprisingly, there's the same issue in u-boot — the reset fails to complete

12:08 <apritzel> captainSail: interesting. I am pretty sure that still worked not so long ago. Can you try v2025.01?

12:15 <captainSail> apritzel: I took the commit from 09.03.25 on the master branch

13:30 <ing_warn> apritzel: thanks for your help, think I made it one step further. Getting rid of this issue requires enabling &usb_power_supply and adding "usb0_vbus_power-supply = <&usb_power_supply>;" to &usbphy. This has been added to the orangepi dt YEARS ago but isn't used in others(e.g. lime2). Gadgets not working yet but I have a different error now :-)

14:22 <ing_warn> apritzel: nevermind, celebrated too early. this just managed to tie it to the axp while the axp20x_usb_power module wasn't loaded, therefore the error didn't appear because it was still waiting for the supply.

15:51 <Jookia> i have a board that has a removable SD card but removing it can cause 'data error, sending stop command, send stop command failed' then the mmc bus to hang. i'm also getting command errors with SD cards that the mainline kernel doesn't seem to have

15:55 <apritzel> Jookia: does the card detect not work then?

15:55 <Jookia> it does work, yes

15:58 <Jookia> removing the card gives an 'mmc0: card aaaa removed'

16:00 <Jookia> i changed some dt flags to be a bit more like the bsp and that seems to have fixed the mmc bus hang with the card removal. not sure

16:00 <apritzel> "dt flags to be a bit more like the bsp" does NOT sound good ...

16:01 <Jookia> mainly i added 'cap-sd-highspeed;

16:01 <Jookia> and broken-cd. though i don't know what that means

16:01 <Jookia> i also added max-frequency stuff

16:02 <Jookia> yeah i think the broken-cd fixes the cd thing. i'm not sure why

16:04 <Jookia> i'm going to put down the other sd card errors to 'bad sd card'

16:04 <Jookia> the BSP might be more 'tolerant' of it somehow

16:09 <apritzel> Jookia: broken-cd means "broken card detect", that means the kernel does not rely on any GPIO to detect a card, but polls the data lines

16:10 <Jookia> hmm. i guess it's broken then since broken-cd works better

16:11 <apritzel> it's quite simple: if the card detection pin is not working, or not wired up in the first place, you specify this property: we do this in mainline DTs, where needed

16:11 <Jookia> what does 'not working' mean though, like ... it's there, but it just seems slow

16:12 <apritzel> what board is that?

16:14 <apritzel> is the card detect switch weirdly place, so it triggers to late, when the card already lost contact?

16:14 <apritzel> placed*

16:23 <apritzel> Jookia: oh, and cap-sd-highspeed is BSP snake-oil: we always enable that in the driver

16:23 <Jookia> ooh interesting

16:23 <Jookia> yeah in the end i think it was broken-cd

19:19 <Lightsword> apritzel, so if I want to make an efuse that's normally hidden viewable by linux would that be something to modify in TF-A?