Update for OpenSTLinux 4 (Kirkstone)

[piratecarrot]

Should be updated for the latest OpenSTLinux

[arduzilla]

Indeed, but they do not care

[mingzhangqun]

We are actively upgrading.

[rhaberkorn]

I was using the patches from this layer successfully with Hardknott. Now I am trying to upgrade to Scarthgap. Let's see whether this works out. They changed a lot in meta-st-stm32mp. Perhaps I will also have to go back to 4.x after all.

[mingzhangqun]

Yeah, I'm working on mickledore. When I'm done testing, I'll release it.

[rhaberkorn]

@mingzhangqun Are you using the optee boot scheme? I was using "trusted", but they removed it beginning with 4.0. Still struggling with the migration to optee.

[mingzhangqun]

@rhaberkorn Yes, I'm using optee.

[rhaberkorn]

Yes, I'm using optee.

Do you have it already booting into u-boot?

[mingzhangqun]

Yes, I'm using optee.

Do you have it already booting into u-boot?

I'll do it this week.

[mingzhangqun]

@rhaberkorn I'm still working on mickledore, and I'm having some issues, and they'll be resolved as soon as possible.

[rhaberkorn]

@rhaberkorn I'm still working on mickledore, and I'm having some issues, and they'll be resolved as soon as possible.

Interesting, I had a very similar panic:

I/TC: Embedded DTB found
I/TC: OP-TEE version: 3.19.0-dev (gcc version 13.3.0 (GCC)) #11 Fri Oct 14 19:00:05 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
E/TC:0 0 probe_driver_node:413 Failed to probe stm32_i2c on node i2c@40013000: 0xffff0006
E/TC:0 0 print_probe_list:366 |- Driver stm32_i2c on node i2c@40013000 failed
I/TC: Platform stm32mp1: flavor PLATFORM_FLAVOR - DT stm32mp157c-odyssey.dts
I/TC: DTB enables console (non-secure)
E/TC:0 0 probe_dt_drivers:750 Probe sequence result: 0x80000000
E/TC:0 0 print_probe_list:366 |- Driver stm32_i2c on node i2c@40013000 failed
E/TC:0 0 Panic
E/TC:0 0 TEE load address @ 0xde000000
E/TC:0 0 Call stack:
E/TC:0 0  0xde002375
E/TC:0 0  0xde0129c5
E/TC:0 0  0xde0120bd
E/TC:0 0  0xde0133c3
E/TC:0 0  0xde0021c5
E/TC:0 0  0xde00019c

This was on Scarthgap and the device tree is heavily modified compared to the Odyssey SOM, but I didn't touch the I2Cs. This is completely left as in stm32mp157c-odyssey.dtsi. The panic in both cases appears to be somehow linked to i2c2 (i2c@40013000). But I cannot exclude the possibility that I did some kind of mistake when I ported it. Especially, "exti_pwr" referenced in pmic, which is also on i2c2 no longer exists.

You can get the backtrace by adding EXTRA_OEMAKE += "CFG_UNWIND=y". There is a script in optee for analyzing the backtrace. That's where I stopped and would continue debugging.

[mingzhangqun]

I have solved the optee boot problem. This is mainly due to optee's lack of I2C clock support.
You can try it with this commit, and I will push it later after I finish testing.

[rhaberkorn]

I have solved the optee boot problem. This is mainly due to optee's lack of I2C clock support.
You can try it with this commit, and I will push it later after I finish testing.

Thanks. Why did the device tree from meta-st-odyssey work in dunfell at all?
But I now got a different error:

E/TC:0 0 regulator_list_voltages:414 regul ldo3: max value 750 is invalid
E/TC:0 0 register_pmic_regulator:406 Failed to register ldo3, error: 0xffff0000

Could you send your entire device tree (stm32mp157c-odyssey.dtsi), please?

[mingzhangqun]

@rhaberkorn Because optee support was officially removed from mickledore. Could you give me the full log.txt?

[rhaberkorn]

@rhaberkorn Because optee support was officially removed from mickledore. Could you give me the full log.txt?

You mean "trusted" was removed from Mickledore. I thought you were using the Optee device trees already in Dunfell?

Here's my boot log (with backtrace, but without debug logging):
boot.txt

And this is my current device tree patch (forward ported from meta-st-odyssey):
0001-Add-stm32mp157c-odyssey.dts-to-support-odyssey-npi-s.patch.gz
I have the PLLs in another dtsi for our Seeed-based platform, generated by CubeMX. These worked on Hardknott, so I assumed that the recently-generated PLLs will also work.

I have optee-os 3.19.0 in Scarthgap, but that's the same version as in Mickledore, so there shouldn't be differences at least until the u-boot stage.

[mingzhangqun]

Have you tried this mingzhangqun/st-optee_os@dddf3f2#diff-d28b30032aee1dc28a0aa61afa9499ea82e5b39aed8666078a25abc97782d4f4 ?

[github-actions]

This issue is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[rhaberkorn]

@mingzhangqun Off-topic, but can you explain this "mcuram" section from the stm32mp157c-odyssey-som.dtsi?

                mcuram: mcuram@30000000 {
                        compatible = "shared-dma-pool";
                        reg = <0x30000000 0x40000>;
                        no-map;
                };

This looks like it's reserved for the M4 core. But there is no such memory exposed to the M4 according to the official RAM map.

[github-actions]

This issue is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[mingzhangqun]

@mingzhangqun Off-topic, but can you explain this "mcuram" section from the stm32mp157c-odyssey-som.dtsi?

                mcuram: mcuram@30000000 {
                        compatible = "shared-dma-pool";
                        reg = <0x30000000 0x40000>;
                        no-map;
                };

This looks like it's reserved for the M4 core. But there is no such memory exposed to the M4 according to the official RAM map.

https://wiki.stmicroelectronics.cn/stm32mpu/wiki/STM32MP15_RAM_mapping#MCU_SRAM1_-26_SRAM2

Notice that the MCURAM is aliased so accessible at addresses 0x10000000 or 0x30000000. In consequence mcuram and mcuram2 memory sections definitions have to be coherent.