cancel
Showing results for 
Search instead for 
Did you mean: 

galcore module expiring when patching kernel with X-LINUX-RT in the OpenSTLinux Developer Package

ally1
Associate II

Hi,

I have the STM32MP257F-EV1 and I would like to load a kernel patched with X-LINUX-RT. I am after the PREEMPT_RT functionality.

I have followed the instructions from https://wiki.st.com/stm32mpu/wiki/X-LINUX-RT_expansion_package#How_to_install_X-LINUX-RT_in_the_OpenSTLinux_Developer_Package so that I can patch the kernel and load it to my board.

I have followed these instructions and also applied the patches and fragments from https://wiki.st.com/stm32mpu/wiki/Getting_started/STM32MP2_boards/STM32MP257x-EV1/Develop_on_Arm%C2%AE_Cortex%C2%AE-A35/Modify,_rebuild_and_reload_the_Linux%C2%AE_kernel#Prepare_the_Linux-C2-AE_kernel_source_code

The build happened fine but when I load the kernel and modules to the board I get the following error and get stuck in boot loop:

[   24.393964] Time out check load galcore module expired
[   25.312479] stm32mp_pm_domain power-domain-d1: sync_state() pending due to 48280000.gpu
E/TC:0   Panic 'Watchdog' at /usr/src/debug/optee-os-stm32mp/4.0.0-stm32mp-r2/core/drivers/stm32_iwdg.c:218 <stm32_iwdg_it_handler>
E/TC:0   TEE load address @ 0x82000000
E/TC:0   Call stack:
E/TC:0    0x82007ef0
E/TC:0    0x82043428
E/TC:0    0x8201c104
E/TC:0    0x82040f5c
E/TC:0    0x820141d0
E/TC:0    0x820017dc
I/TC: Halting CPU 1
NOTICE:  CPU: STM32MP257FAI Rev.Y
NOTICE:  Model: STMicroelectronics STM32MP257F-EV1 Evaluation Board
NOTICE:  Board: MB1936 Var1.0 Rev.D-01
NOTICE:  Reset reason: IWDG system reset (iwdgX_out_rst) (0x2134

Can someone please advise?

1 ACCEPTED SOLUTION

Accepted Solutions

Hello @ally1 ,
I made some investigation and it seems that for a performance reason, as Watchdog pings are made through OP-TEE trusted application (and it takes some time), it has been chosen  to disable the 32s Watchdog service in the Linux kernel. However, if we do not ping the watchdog anymore from Linux, and the watchdog is still activated, we will just finish to make it triggered and the crash you see appear. This is why in the complete distribution, watchdog is disabled in other BSP components (device tree change).

A quick workaroung for you would be to change the Linux kernel config and activate CONFIG_ARM_SMC_WATCHDOG=y

You should not see the crash anymore after. 

However I would like to mention that now, Linux-rt provided by ST is more adapted for the Distribution Package process, instead of Developer package process.

I hope it will help you to go forward.

Kind regards,
Erwan.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

View solution in original post

6 REPLIES 6
Erwan SZYMANSKI
ST Employee

Hello @ally1 ,
The galcore module expiration is not root cause of your issue I think. Galcore is an out of tree module that should be compiled aside, and deployed on the board. If you recompile the kernel, the galcore module magic version is not aligned anymore with the kernel and the other modules, so it cannot be loaded. It should not produce a fail, but just avoid the GPU to be used.

From which OpenSTLinux release did you start ? Which Flash image did you deploy on your board ?

Did you only change the Linux RT part or did you also make other changes in your system ?

Kind regards,
Erwan.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
ally1
Associate II

Hi Erwan!

Thank you for the reply, hopefully I can correctly provide info to your questions below:

  • OpenSTLinux release: I flashed to the SD card according to these instructions. I used v6.6 - stm32mp2-openstlinux-6.6-yocto-scarthgap-mpu-v25.06.11
  • Flash Image: stm32mp2-openstlinux-6.6-yocto-scarthgap-mpu-v25.06.11\images\stm32mp2\flashlayout_st-image-weston\optee\FlashLayout_sdcard_stm32mp257f-ev1-optee.tsv
  • What did I change?
  • Then I pretty much copied the instructions here to build a new image.gz, dtb and modules: ...\stm32mp-openstlinux-6.6-yocto-scarthgap-mpu-v25.08.27\sources\ostl-linux\linux-stm32mp-6.6.78-stm32mp-r2-r0\README.HOW_TO.txt.stm32mp2 
    • The patches applied: 
      • 0001-v6.6-stm32mp-r2.patch from linux-stm32mp-6.6.78-stm32mp-r2-r0 folder
      • 0010-Rebase-on-v6.6.78-rt51.patch from ...\meta-st-x-linux-rt\recipes-kernel\linux\linux-stm32mp\6.6
      • 0011-v6.6-stm32mp-rt-r2.patch from ...\meta-st-x-linux-rt\recipes-kernel\linux\linux-stm32mp\6.6
    • The fragments applied:
      • fragment-03-systemd.config from linux-stm32mp-6.6.78-stm32mp-r2-r0 folder
      • fragment-04-modules.config from linux-stm32mp-6.6.78-stm32mp-r2-r0 folder
      • fragment-10-network-improvment.config from ...\meta-st-x-linux-rt\recipes-kernel\linux\linux-stm32mp\6.6
      • Looking back it looks like I missed fragment-12-rt-optimization.config from ...\meta-st-x-linux-rt\recipes-kernel\linux\linux-stm32mp\6.6 so I will try again with that applied.
    • Then I built with the commands from the readme and copied the filed over with scp via ssh.
    • That's all.

Thanks for your time in advance!

Ally

ally1
Associate II

I also wanted to note that I applied the fragments defined in https://wiki.st.com/stm32mpu/wiki/X-LINUX-RT_expansion_package#Add_and_apply_new_config_fragments - so: 

arch/arm64/configs/fragment-07-rt-sysvinit.config
arch/arm64/configs/fragment-07-rt.config

 This is probably why I didn't apply fragment-12-rt-optimization.config because it wasn't referenced in the wiki instructions.

Erwan SZYMANSKI
ST Employee

Hello @ally1 ,
Indeed, I can reproduce the same Watchdog as you have on your side, I think there is a missing instruction in the wiki. Let me check and come back to you.

Kind regards,
Erwan.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

Hello @ally1 ,
I made some investigation and it seems that for a performance reason, as Watchdog pings are made through OP-TEE trusted application (and it takes some time), it has been chosen  to disable the 32s Watchdog service in the Linux kernel. However, if we do not ping the watchdog anymore from Linux, and the watchdog is still activated, we will just finish to make it triggered and the crash you see appear. This is why in the complete distribution, watchdog is disabled in other BSP components (device tree change).

A quick workaroung for you would be to change the Linux kernel config and activate CONFIG_ARM_SMC_WATCHDOG=y

You should not see the crash anymore after. 

However I would like to mention that now, Linux-rt provided by ST is more adapted for the Distribution Package process, instead of Developer package process.

I hope it will help you to go forward.

Kind regards,
Erwan.

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

Thanks Erwan ~~~~