STM32MP151C [U-boot] stm32prog/DFU hangs with OP-TEE

[PPiwk.1]

Hi there, 

During OP-TEE integration of our custom platform based on STM32MP151C MPU I'm facing an issue with DFU. It looks like the dfu command stucks in `run_usb_dnl_gadget` inside the loop and waits forever for the flush flag:

 

NOTICE: CPU: STM32MP151CAC Rev.Z
NOTICE: Model: STMicroelectronics custom STM32CubeMX board (TF-A)
INFO: Reset reason (0x15):
INFO: Power-on Reset (rst_por)
INFO: FCONF: Reading TB_FW firmware configuration file from: 0x2ffe2000
INFO: FCONF: Reading firmware configuration information for: stm32mp_io
INFO: Using USB
INFO: Instance 2
INFO: Boot used partition fsbl1
NOTICE: BL2: v2.6-stm32mp1-r1.0(debug):v2.6-dirty
NOTICE: BL2: Built : 13:14:26, Nov 23 2021
INFO: BL2: Doing platform setup
INFO: RAM: DDR3-DDR3L 16bits 533000Khz
INFO: Memory size = 0x8000000 (128 MB)
INFO: DFU USB START...
INFO: phase ID :3, Manifestation 3 at c7159862
INFO: Send detach request
INFO: Receive DFU Detach
INFO: DFU USB STOP...
INFO: BL2: Loading image id 31
INFO: Loading image id=31 at address 0x2ffff000
INFO: Image id=31 loaded: 0x2ffff000 - 0x2ffff1fa
INFO: FCONF: Reading FW_CONFIG firmware configuration file from: 0x2ffff000
INFO: FCONF: Reading firmware configuration information for: dyn_cfg
INFO: FCONF: Reading firmware configuration information for: stm32mp1_firewall
INFO: BL2: Loading image id 4
INFO: Loading image id=4 at address 0x2ffc0000
INFO: Image id=4 loaded: 0x2ffc0000 - 0x2ffc002c
INFO: OPTEE ep=0x2ffc0000
INFO: OPTEE header info:
INFO: magic=0x4554504f
INFO: version=0x2
INFO: arch=0x0
INFO: flags=0x0
INFO: nb_images=0x2
INFO: BL2: Loading image id 21
INFO: Loading image id=21 at address 0x2ffc0000
INFO: Image id=21 loaded: 0x2ffc0000 - 0x2ffda710
INFO: BL2: Loading image id 22
INFO: Loading image id=22 at address 0xc6200000
INFO: Image id=22 loaded: 0xc6200000 - 0xc6254000
INFO: BL2: Loading image id 23
INFO: Loading image id=23 at address 0xc0500000
INFO: Image id=23 loaded: 0xc0500000 - 0xc0511fb0
INFO: BL2: Skip loading image id 26
INFO: BL2: Loading image id 5
INFO: Loading image id=5 at address 0xc0100000
INFO: Image id=5 loaded: 0xc0100000 - 0xc01d8e54
NOTICE: BL2: Booting BL32
INFO: Entry point address = 0x2ffc0000
INFO: SPSR = 0x1d3
I/TC: Early console on UART#4
I/TC: 
I/TC: Pager is enabled. Hashes: 2784 bytes
I/TC: Pager pool size: 60kB
I/TC: Non-secure external DT found
I/TC: Embedded DTB found
I/TC: OP-TEE version: 3.16.0-dev (gcc version 12.2.0 (GCC)) #24 Fri Jan 28 02:28:18 PM UTC 2022 arm
I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html
I/TC: Primary CPU initializing
I/TC: DT clock tree configurations were ignored
I/TC: WARNING: All debug access are allowed
I/TC: Platform stm32mp1: flavor PLATFORM_FLAVOR - DT stm32mp151c-0068-new-1-mx.dts
I/TC: DTB enables console (non-secure)
I/TC: Primary CPU switching to normal world boot

U-Boot 2021.10-stm32mp-r1-dirty (Oct 04 2021 - 15:09:26 +0000)

U-Boot code: C0100000 -> C01C0BF4 BSS: -> C01CD568
psci psci: set_state_simple op missing
stm32mp_bsec efuse@5c005000: set_state_simple op missing
CPU: STM32MP151CAC Rev.Z
Model: STMicroelectronics custom STM32CubeMX (U-Boot)
Board: stm32mp1 in trusted mode (st,stm32mp151c-0068-new-linux-mx)
DRAM: stm32mp1_ddr ddr@5a003000: set_state_simple op missing
Monitor len: 000CD568
Ram size: 08000000
Ram top: C6200000
Reserving 821k for U-Boot at: c6122000
Reserving 33024k for malloc() at: c40e2000
Reserving 1M for noncached_alloc() at: c3f00000
Reserving 72 Bytes for Board Info at: c3efffb0
Reserving 216 Bytes for Global Data at: c3effed0
Reserving 72640 Bytes for FDT at: c3eee310

RAM Configuration:
Bank #0: c0000000 
DRAM: 128 MiB
New Stack Pointer is: c3eee2f0
Relocation Offset is: 06022000
Relocating to c6122000, new gd at c3effed0, sp at c3eee2f0
Clocks:
- MPU : 650 MHz
- MCU : 200 MHz
- AXI : 266.500 MHz
- PER : 0 MHz
- DDR : 533 MHz
WDT: Started with servicing (32s timeout)
NAND: 0 MiB
MMC: pinconfig sdmmc2_mx-0: set_state_simple op missing
STM32 SD/MMC: 1, STM32 SD/MMC: 0
Loading Environment from nowhere... OK
In: serial@40010000
Out: serial@40010000
Err: serial@40010000
Net: Ethernet disabled.
Hit any key to stop autoboot: 0 
Boot over usb0!
stm32prog_is_stm32_header_v1:invalid magic number : 0x55555555
stm32prog_is_stm32_header_v2:invalid magic number : 0x55555555
stm32prog_is_stm32_header_v1:invalid magic number : 0x55555555
stm32prog_is_stm32_header_v2:invalid magic number : 0x55555555
DFU alt info setting: dfu_alt_add(ram, NULL,@FlashLayout/0x00/1*256Ke) result 0
dfu_alt_add(virt,241,@virtual/0xf1/1*512Be) result 0
optee_ta result 0
dfu_alt_add(virt,242,@OTP/0xf2/1*776Be) result 0
dfu_alt_add(virt,244,@PMIC/0xf4/1*8Be) result 0
done
dwc2-udc-otg usb-otg@49000000: set_state_simple op missing
stm32mp1_clk rcc@50000000: stm32mp1_clk_enable: id clock 166 has been enabled
stm32_rcc_reset rcc@50000000: reset id = 19656 bank = 2456 offset = 8)
stm32_rcc_reset rcc@50000000: reset id = 19656 bank = 2456 offset = 8)
registering UDC driver [<NULL>]
==== PP: run_usb_dnl_gadget:42

I also observed that `ID 0483:df11 STMicroelectronics STM Device in DFU Mode` USB device is missing on my host at that state.

The same configuration works well without OP-TEE and STM32_Programmer_CLI successfully uploads the images. I don't see any relation between OP-TEE and stm32prog/DFU, but looks like something is wrong or missing.

I use the stm32mpu-ecosystem-v4 provided by the meta-st-stm32mp yocto layer (langdale).

I would be grateful for any hints or places that should be checked in such a case.

Thanks in advance

[PatrickD]

Hi,

 

When I check your trace,

the stm32prog command in U-Boot start the USB gadget stack and

wait the falshlayout file normally sent by the programmer. 

 

But this file is not sent that it is normal if Host don't see the expected DFU USB after enumeration in U-Boot,

as you indicate it :

 

 ID 0483:df11 STMicroelectronics STM Device in DFU Mode

 

So something is not functional in USB gadget on USTOTG for your board in U-Boot....

without error in USB stack

 

can you check that you have  in U-Boot device tree addon

 

&usbotg_hs {

u-boot,force-b-session-valid;

};

 

It is commmon source of issue.

An other source of issue is the management of USB regulator.

 

=> you need to debug the USB gadget in U-Boot (with DFU or UMS command),

   
PS: if you can us Sd-Card Boot on your design, you don't necessary need

       to use stm32prog / boot form USB to test USB enumeration

 

Or Clr^C in U-Boot console to stop stm32prog command and

then you can use U-Boot commands to debug the issue

 

for example:

 

> regulator status -a

> clk dump
> dm tree

 

 

To answer at your last question, normally we have no direct link between USB OTG device in U-Boot and STM32MP15 OP-TEE,

 

If RCC is not secured (see TZEN / MCKPROT) and if the PMIC is not managed in OP-TEE.

Today it is not the case for STMicroelectronics boards on STM32MP15, I assumed it inot the case for your port if you aligned your board with our boards.

 

But is if the RCC/PWR/OP-TEE are securized, the associated ressource are no more accessible,

and the associated regulator must be exported by as it is done SCMI STM32MP13:

 

usbotg_hs: usb-otg@49000000 {

compatible = "st,stm32mp15-hsotg", "snps,dwc2";

......

usb33d-supply = <&usb33>;                             => MP15

usb33d-supply = <&scmi_usb33>;                        => MP13

.....

status = "disabled";

};

A strange line in the trace

I/TC: DT clock tree configurations were ignored

If the clock tree is not coorectly applied in OP-TEE, that explain some USB issue....
You can compare the clock tree in OP-TEE with ST boards.

regards

 

Patrick

[PPiwk.1]

---

@PatrickD wrote:

can you check that you have  in U-Boot device tree addon

&usbotg_hs {

u-boot,force-b-session-valid;

};

---

This property doesn't change anything in my case.

 

---

Or Clr^C in U-Boot console to stop stm32prog command and

then you can use U-Boot commands to debug the issue

for example:

> regulator status -a

> clk dump
> dm tree

---

The output of above commands looks exactly the same as in the working setup without OP-TEE integrated. I also found out that in the OP-TEE variant there is no possibility to enable the usb33 regulator:

STM32MP> regulator dev usb33
dev: usb33 @ usb33
STM32MP> regulator enable
stm32mp_pwr_regulator usb33: Turning on usb33
D/TC:0 pwr_scv_handler:54 PWR service: write 0x1000000 at offset 0xc
stm32mp_pwr_regulator usb33: usb33: timeout
Regulator: usb33 - can't enable!
Error: -110 (Connection timed out)

 

---

If RCC is not secured (see TZEN / MCKPROT) and if the PMIC is not managed in OP-TEE.

Today it is not the case for STMicroelectronics boards on STM32MP15, I assumed it inot the case for your port if you aligned your board with our boards.

The OP-TEE reports something like this:

D/TC:0 0 check_rcc_secure_configuration:506 RCC/PWR secure hardening: TZEN enable, MCKPROT enable

 

---

But is if the RCC/PWR/OP-TEE are securized, the associated ressource are no more accessible,

and the associated regulator must be exported by as it is done SCMI STM32MP13:

 

usbotg_hs: usb-otg@49000000 {

compatible = "st,stm32mp15-hsotg", "snps,dwc2";

......

usb33d-supply = <&usb33>;                             => MP15

usb33d-supply = <&scmi_usb33>;                        => MP13

.....

status = "disabled";

};

---

So, if I understand correctly, according to my TZEN/MCKPROT settings, there is a need to do the same as it is declared in u-boot's arch/arm/dts/stm32mp131.dtsi:

firmware {
 // ...
 scmi: scmi {
 // ...
 scmi_voltd: protocol@17 {
 reg = <0x17>;
 scmi_regu: regulators {
 // ..
 scmi_usb33: voltd-usb33 {
 voltd-name = "usb33";
 regulator-name = "usb33";
 };
 };
 };
 };
};

And after that, the new scmi_usb33 regulator has to be assigned to the usbotg_hs node. Am I right?

 

---

A strange line in the trace

I/TC: DT clock tree configurations were ignored

If the clock tree is not coorectly applied in OP-TEE, that explain some USB issue....
You can compare the clock tree in OP-TEE with ST boards.

According to comment describing that message (core/drivers/clk/clk-stm32mp15.c:1468), I guess it is fine:

/*
* OP-TEE core is not in charge of configuring clock parenthood.
* This is expected from an earlier boot stage. Modifying the clock
* tree parenthood here may jeopardize already configured clocks.
* The sequence below ignores such DT directives with a friendly
* debug trace.
*/

 

Thank you for support,

[PPiwk.1]

The missing part that makes it work is an assignment of the correct phys and phy-supply properties to the u-boot's DTS as follows:

 

&usbotg_hs{
 u-boot,dm-pre-reloc;
 status = "okay";
 phys = <&usbphyc_port1 0>;
};
&usbphyc_port0{
 u-boot,dm-pre-reloc;
 status = "okay";
 phy-supply = <&fixed_3v3>;
};
&usbphyc_port1{
 u-boot,dm-pre-reloc;
 status = "okay";
 phy-supply = <&fixed_3v3>;
};