cancel
Showing results for 
Search instead for 
Did you mean: 

Problem booting optee 4.0 / kernel 6.6

UVV
Associate III

Hey there,

I'm trying to boot my custom stm32mp153c board using the new Scarthgap version of the meta-st-stm32mp layer. I had it working with the previous combination of optee 3.19 / kernel 6.1 (See this post). Ater some adaptation of device trees and my layer I've got OPTEE booting and loading the kernel, but unfortunately it stops right at the kernel loading. Any ideas what I might be missing or how to debug it further?

 

Starting kernel ...

D/TC:0 psci_cpu_on:172 core 1, ns_entry 0xc0301a40, state 0
I/TC: Secondary CI/TC: Secondary CPU 1 switching to normal world boot
D/TC:0 pwr_scv_handler:56 PWR service: write 0x0 at offset 0x28
D/TC:0 pwr_scv_handler:56 PWR service: set 0x3f at offset 0x20
I/TC: Reserved shared memory is disabled
I/TC: Dynamic shared memory is enabled
I/TC: Normal World virtualization support is disabled
I/TC: Asynchronous notifications are disabled
D/TC:1 0 stat_handle_fault:1740 nfaults 11264 npages 17 (min 16)
D/TC:? 0 tee_ta_init_session_with_context:562 Re-open trusted service 7011a688-ddde-4053-a5a9-7b3c4ddf13b8
D/TC:? 0 tee_ta_init_session_with_context:562 Re-open trusted service a8cfe406-d4f5-4a2e-9f8d-a25dc754c099
D/TC:? 0 tee_ta_close_session:465 csess 0x2ffe8bd8 id 2
D/TC:? 0 tee_ta_close_session:484 Destroy session
D/TC:? 0 tee_ta_init_session_with_context:562 Re-open trusted service ab7a617c-b8e7-4d8f-8301-d09b61036b64
D/TC:? 0 tee_ta_close_session:465 csess 0x2ffe8d60 id 1
D/TC:? 0 tee_ta_close_session:484 Destroy session
D/TC:? 0 tee_ta_init_session_with_context:562 Re-open trusted service a8cfe406-d4f5-4a2e-9f8d-a25dc754c099
D/TC:? 0 stm32mp1_clk_get_parent:739 No parent selected for clk 148
D/TC:? 0 stm32mp1_clk_get_parent:739 No parent selected for clk 148
D/TC:? 0 stm32mp1_clk_get_parent:739 No parent selected for clk 148

 

1 ACCEPTED SOLUTION

Accepted Solutions
UVV
Associate III

I finally located the problem in my BSP.

What happened is the following. The kernel config didn't have

CONFIG_HWSPINLOCK_STM32=y

kernel parameter. The reason was the not applied config fragment in the kernel recipe. That's because when upgrading to scarthgap I missed "stm32mp15common" machine override.

General message to ST about meta-st-stm32mp layer. I like your work towards upstream, but your layer targets only your DK and evaluation boards tailored to your OpenSTLinux distribution. In particular machine configuration and its includes. The includes are interdependent, e.g. st-machine-common-stm32mp.inc includes all the rest. Nobody uses these machines apart from the reference image bring-up / test run. All this forces the users to create their own machines / configuration, because we can't rely on the base layer, and this is the source of a lot of mistakes. The machine configuration (or at least includes) should be as generic as possible and shouldn't pull OpenSTLinux specific parts like partition layout.

View solution in original post

3 REPLIES 3
UVV
Associate III

After enabling earlyprintk and setting the proper console device I've got some more logs:

[ 2.273178][ T30] scmi_core: (scmi) Creating SCMI device 'scmi_dev.1' for protocol 0x10 (__scmi_transport_device_tx_10)
[ 2.288013][ T30] scmi_protocol scmi_dev.1: Enabled polling mode TX channel - prot_id:16
[ 2.296780][ T30] arm-scmi firmware:scmi: SCMI Notifications - Core Enabled.
[ 2.306678][ T30] arm-scmi firmware:scmi: SCMI Protocol v2.0 'ST:' Firmware version 0x0
[ 2.315116][ T30] scmi_core: (scmi) Creating SCMI device 'scmi_dev.2' for protocol 0x14 (clocks)
[ 2.324792][ T30] stm32-etzpc 5c007000.bus: Failed to create device link (0x180) with scmi_dev.2
[ 2.333985][ T30] stm32-etzpc 5c007000.bus: Failed to create device link (0x180) with scmi_dev.2
[ 2.349126][ T30] stm32-etzpc 5c007000.bus: Failed to create device link (0x180) with scmi_dev.2
[ 2.358176][ T30] stm32-etzpc 5c007000.bus: Failed to create device link (0x180) with scmi_dev.2
[ 2.367444][ T30] scmi_core: (scmi) Creating SCMI device 'scmi_dev.3' for protocol 0x16 (reset)
[ 2.376920][ T30] stm32-etzpc 5c007000.bus: Failed to create device link (0x180) with scmi_dev.3
[ 2.386106][ T30] stm32-etzpc 5c007000.bus: Failed to create device link (0x180) with scmi_dev.3
[ 2.395811][ T30] stm32-etzpc 5c007000.bus: Failed to create device link (0x180) with scmi_dev.3
[ 2.404924][ T30] stm32-etzpc 5c007000.bus: Failed to create device link (0x180) with scmi_dev.3
[ 2.440875][ T30] stm32-dma 48000000.dma-controller: STM32 DMA driver registered
[ 2.452736][ T30] stm32-mdma 58000000.dma-controller: STM32 MDMA driver registered
[ 2.473907][ T30] stm32_rtc 5c004000.rtc: registered as rtc0
[ 2.479911][ T30] stm32_rtc 5c004000.rtc: setting system clock to 2025-01-03T08:49:09 UTC (1735894149)
[ 2.489971][ T30] stm32_rtc 5c004000.rtc: registered rev:1.2
[ 2.539649][ T1] clk: Disabling unused clocks

And that's where it stops. I appreciate any suggestions how to get it fixed

UPDATE: Scratch that, these were caused by the missing firewall entries in the optee device tree. The So I still don't have further leads how to investigate it...

Hi @UVV,

I see in the first logs:

D/TC:? 0 stm32mp1_clk_get_parent:739 No parent selected for clk 148
D/TC:? 0 stm32mp1_clk_get_parent:739 No parent selected for clk 148
D/TC:? 0 stm32mp1_clk_get_parent:739 No parent selected for clk 148

that the clock get_parent function returns that there is no parent for the clock 148. Looking at core/include/dt-bindings/clock/stm32mp1-clks.h file in OP-TEE, I see that this is the clock of the USART1 (#define USART1_K 148), that I guess you use for the Linux console? The USART1 clock seems to be an SCMI clock. Therefore, its handling is done by OP-TEE through SCMI calls. I suspect an issue in the clock tree in OP-TEE.

Can you send the OP-TEE board device tree file where the clock tree is defined please?

Thanks,

Gatien

 
UVV
Associate III

I finally located the problem in my BSP.

What happened is the following. The kernel config didn't have

CONFIG_HWSPINLOCK_STM32=y

kernel parameter. The reason was the not applied config fragment in the kernel recipe. That's because when upgrading to scarthgap I missed "stm32mp15common" machine override.

General message to ST about meta-st-stm32mp layer. I like your work towards upstream, but your layer targets only your DK and evaluation boards tailored to your OpenSTLinux distribution. In particular machine configuration and its includes. The includes are interdependent, e.g. st-machine-common-stm32mp.inc includes all the rest. Nobody uses these machines apart from the reference image bring-up / test run. All this forces the users to create their own machines / configuration, because we can't rely on the base layer, and this is the source of a lot of mistakes. The machine configuration (or at least includes) should be as generic as possible and shouldn't pull OpenSTLinux specific parts like partition layout.