STM32MP157 small hiccups

Embedded Linux Discussions
1

Having a few small issues getting started with the DK2 board following the rather excellent instructions (thanks Robert!) at Debian: Getting Started with the STM32MP157 , specifically the biggest issue is that my USB powers down after boot. Extracts from from syslog;

[   14.896426] dwc2 49000000.usb-otg: supply vusb_d not found, using dummy regulator
[   14.896835] dwc2 49000000.usb-otg: supply vusb_a not found, using dummy regulator
[   14.985167] stm32-dwmac 5800a000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
[   14.985239] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   15.028098] dwc2 49000000.usb-otg: EPs: 9, dedicated fifos, 952 entries in SPRAM
[   15.036614] dwc2 49000000.usb-otg: DWC OTG Controller
[   15.036694] dwc2 49000000.usb-otg: new USB bus registered, assigned bus number 2
[   15.037272] dwc2 49000000.usb-otg: irq 53, io mem 0x49000000
[   15.041225] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.10
[   15.041251] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   15.041263] usb usb2: Product: DWC OTG Controller
[   15.041274] usb usb2: Manufacturer: Linux 5.10.41-armv7-lpae-x41 dwc2_hsotg
[   15.041285] usb usb2: SerialNumber: 49000000.usb-otg
[   15.043447] hub 2-0:1.0: USB hub found
[   15.045352] hub 2-0:1.0: 1 port detected

…and if I have a usb memory stick plugged in at this point it will init it, but later;

[   33.763695] vref: supplied by vdd
[   33.763930] reg11: supplied by vdd
[   33.764060] usb33: supplied by vdd_usb
[   33.764222] vref: disabling
[   33.764241] reg11: disabling
[   33.764268] vdda: disabling

…and my memory stick is still there as /dev/sda1, but gives me access errors. Really a bit stuck on this one!

The second issue is that I cannot bring up WiFi, but I’ll keep fighting on that one because I suspect the problem is between the screen and the keyboard rather than anywhere inside the SoC.

Regards
DAVE

2

Hi @mubes , which USB port are you using? I wonder if we configure the regulators for USB to be:

regulator-always-on;
regulator-boot-on;

as usb33 is used on: usbotg_hs

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/stm32mp151.dtsi?h=v5.13-rc7#n1142

usbphyc regulator are also the same:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/stm32mp151.dtsi?h=v5.13-rc7#n1495

Regards,

3

Hi Robert,

Not sure I quite understand what you’re saying. I’m using the 4-port USB-A on the board which, I think, is behind a hub. I don’t see those two phrases (regulator-always-on, regulator-boot-on) in the file armv7-lpae-multiplatform/KERNEL/arch/arm/boot/dts/stm32mp151.dtsi anywhere…are you suggesting I should add them under the usbotg_hs and usbphyc configurations?

Regards

DAVE

4

Ah perfect, so looking at the schematic:

Regulators
Regulators1210×698 163 KB

VDD33 controls the USB2514B, and it looks like 5V just comes from Vin…

So the first thing i’d test is:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/stm32mp151.dtsi?h=v5.13-rc7#n1142

			usb33: usb33 {
				regulator-name = "usb33";
				regulator-min-microvolt = <3300000>;
				regulator-max-microvolt = <3300000>;
			};

to:

			usb33: usb33 {
				regulator-name = "usb33";
				regulator-min-microvolt = <3300000>;
				regulator-max-microvolt = <3300000>;
				regulator-always-on;
				regulator-boot-on;
			};

and let’s see if that does anything…

The other thing, the main 3v3 rail is defined here:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/stm32mp15xx-dkx.dtsi?h=v5.13-rc7#n326

			v3v3: buck4 {
				regulator-name = "v3v3";
				regulator-min-microvolt = <3300000>;
				regulator-max-microvolt = <3300000>;
				regulator-always-on;
				regulator-over-current-protection;
				regulator-initial-mode = <0>;
			};

mainrail
mainrail725×112 13.8 KB

More digging…

USBRESET

So as soon as the 3v3 rail is turns ‘off’ then ‘on’ the usb phy reset’s… I suppose that would work, i’d rather that was a gpio we could toggle… But i have a feeling, the usb hub is reseting when jumping from u-boot → linux…

Regards,

5

Robert,
I tried the device tree change, with no effect. The v3v3 matches to what you have above and doesn’t seem to an issue.

The usb is powering up correctly and the hub is being initialised by Linux. I think the power supplies might be a red herring since the usb doesn’t seem to be dependent on any of the supplies that are being disabled. From what I can see even VDDA33 on U7 is powered from the 3v3 rail, and the SDA/SDL are DNF so I don’t see that having any impact either. I’d be very surprised if the 3v3 were being toggled as it is needed all over the place.

If I have a keyboard plugged in at boot it comes up like this;

001/input/input2
Jun 22 21:26:00 arm kernel: [   19.591324] hid-generic 0003:0472:0065.0001: input,hidraw0: USB HID v1.00 Keyboard [Chicony  PFU-65 USB Keyboard] on usb-5800d000.usb-1.2
.1/input0

…

The usb interface that is in use appears to be defined by this;

		usbh_ohci: usb@5800c000 {
			compatible = "generic-ohci";
			reg = <0x5800c000 0x1000>;
			clocks = <&rcc USBH>;
			resets = <&rcc USBH_R>;
			interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
			status = "disabled";
		};

		usbh_ehci: usb@5800d000 {
			compatible = "generic-ehci";
			reg = <0x5800d000 0x1000>;
			clocks = <&rcc USBH>;
			resets = <&rcc USBH_R>;
			interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
			companion = <&usbh_ohci>;
			status = "disabled";
		};

I’m not overly familiar with this stuff, so any pointers gratefully accepted! One more datapoint, it does seem like something is active;

# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

…but devices plugged in elicit no responses at all.
DAVE

6

Hi @mubes
Okay, sorry for the delay, i can confirm the issue with v5.10.x… But please give v5.13.x a quick try, as it’s working for me. :wink:

git clone https://github.com/RobertCNelson/armv7-lpae-multiplatform
cd armv7-lpae-multiplatform/
git checkout origin/v5.13.x -b tmp

Regards,

7

So, just to run this one to ground. The problem is reg11 in stm32mp151.dsti. If you modify that to always be on, then the USB behaves itself. @RobertCNelson Is this a patch that I need to submit somewhere, or can you handle it from this PR?

Updated code (Starting at line 1125) reads;

			reg11: reg11 {
				regulator-name = "reg11";
				regulator-min-microvolt = <1100000>;
				regulator-max-microvolt = <1100000>;
				regulator-always-on;
				regulator-boot-on;                                			};
8

Looks like our posts crossed…see above!

DAVE

9

Ah, cool, let’s try that with v5.10.x, as i have everything setup…

Regards,

10

Great! I’m off to bed but will pick this up again tomorrow. The WiFi looks like it might have gotten tangled in the brcm* → cy* renaming process, but I’ve not looked into that one yet. Once again, thanks for the great work on this. It’s appreciated.

DAVE

11

That also works, (survives reboots) and merged!

Yeah, the brcm* → cypress* is a mess, I hope they don’t rename it again to Infineon…

Regards,