2025-01-23 10:56 AM - last edited on 2025-01-23 12:33 PM by Peter BENSCH
Hello,
I am trying to load an .elf file on the M33 core on my stm32mp257f processor. When I launch the remote core using remoteproc I get the following errors.
root@stm32mp257f-hydra-mx:~# echo -n /home/root > /sys/module/firmware_class/parameters/path
root@stm32mp257f-hydra-mx:~# echo Sparta.elf > /sys/class/remoteproc/remoteproc0/firmware
root@stm32mp257f-hydra-mx:~# echo start > /sys/class/remoteproc/remoteproc0/state
[ 119.336297] remoteproc remoteproc0: powering up m33
[ 119.511444] remoteproc remoteproc0: Booting fw image Sparta.elf, size 6237772
[ 119.513130] remoteproc remoteproc0: unsupported fw ver: 0
[ 119.518401] remoteproc remoteproc0: no resource table found for this firmware
E/TC:0 stm32_iac_itr:192 IAC exceptions [159:128]: 0x200
E/TC:0 stm32_iac_itr:197 IAC exception ID: 137
E/TC:0 stm32_risaf_dump_erroneous_data:256
DUMPING DATA FOR risaf@420d0000
E/TC:0 stm32_risaf_dump_erroneous_data:257 =====================================================
E/TC:0 stm32_risaf_dump_erroneous_data:258 Status register (IAESR0): 0x91
E/TC:0 stm32_risaf_dump_erroneous_data:266 -----------------------------------------------------
E/TC:0 stm32_risaf_dump_erroneous_data:268 Faulty address (IADDR0): 0x80000000
E/TC:0 stm32_risaf_dump_erroneous_data:287 =====================================================
E/TC:1 stm32_iac_itr:192 IAC exceptions [159:128]: 0x200
[ 119.587786] remoteproc remoteproc0: unsupported fw ver: 0
[ 119.592833] remoteproc remoteproc0: remote processor m33 is now up
root@stm32mp257f-hydra-mx:~# E/TC:1 stm32_iac_itr:197 IAC exception ID: 137
E/TC:1 stm32_iac_itr:197 IAC exception ID: 132
E/TC:1 stm32_risaf_dump_erroneous_data:256
DUMPING DATA FOR risaf@420d0000
E/TC:1 stm32_risaf_dump_erroneous_data:257 =====================================================
E/TC:1 stm32_risaf_dump_erroneous_data:258 Status register (IAESR0): 0x91
E/TC:1 stm32_risaf_dump_erroneous_data:266 -----------------------------------------------------
E/TC:1 stm32_risaf_dump_erroneous_data:268 Faulty address (IADDR0): 0x80000080
E/TC:1 stm32_risaf_dump_erroneous_data:287 =====================================================
E/TC:1 stm32_risab_dump_erroneous_data:146
DUMPING DATA FOR risab@42130000
E/TC:1 stm32_risab_dump_erroneous_data:147 =====================================================
E/TC:1 stm32_risab_dump_erroneous_data:148 Status register (IAESR): 0x12
E/TC:1 stm32_risab_dump_erroneous_data:150 -----------------------------------------------------
E/TC:1 stm32_risab_dump_erroneous_data:151 Faulty address (IADDR): 0xa080004
E/TC:1 stm32_risab_dump_erroneous_data:154 =====================================================
Any suggestions?
2025-01-23 01:34 PM
Hi @nielsenni101 ,
Seems you are trying to start an unsigned .elf while by default OpenSTLinux requires a signed binary.
Note also that running M33 firmware requires appropriate Riff configuration.
In Starter package you might use m33-exemples flavor of tsv.
Please check Wiki :
Modify, rebuild and reload the firmware - stm32mpu
Hope it help
Olivier
2025-01-24 08:27 AM
Thanks for your response,
I was thinking that there is an RIF issue, I have just not been able to figure out what is wrong.
I believe the issue is due to something over here at address 0xa080000?
From what I understand the error below means CID2 is making an illegal access to address 0xa080004. But from the configuration above I do not see why that is happening.
DUMPING DATA FOR risab@42130000
E/TC:1 stm32_risab_dump_erroneous_data:147 =====================================================
E/TC:1 stm32_risab_dump_erroneous_data:148 Status register (IAESR): 0x12
E/TC:1 stm32_risab_dump_erroneous_data:150 -----------------------------------------------------
E/TC:1 stm32_risab_dump_erroneous_data:151 Faulty address (IADDR): 0xa080004
E/TC:1 stm32_risab_dump_erroneous_data:154 =====================================================
Just to preface, I am running on custom hardware.
I set up the m33_rproc node to support the non-signed .elf file. See below
&m33_rproc {
status = "okay";
/* USER CODE BEGIN m33_rproc */
compatible = "st,stm32mp2-m33";
mboxes = <&ipcc1 0x100>, <&ipcc1 0x101>, <&ipcc1 2>;
mbox-names = "vq0", "vq1", "shutdown";
memory-region = <&ipc_shmem_1>, <&vdev0vring0>,<&vdev0vring1>,
<&vdev0buffer>, <&cm33_sram1>, <&cm33_sram2>, <&cm33_retram>, <&cm33_cube_fw>, <&cm33_cube_data>;
/* The resets are managed by the Linux remoteproc driver */
resets = <&scmi_reset RST_SCMI_C2_R>,
<&scmi_reset RST_SCMI_C2_HOLDBOOT_R>;
reset-names = "mcu_rst", "hold_boot";
/* declare boot address register */
st,syscfg-nsvtor = <&a35ss_syscfg 0xa8 0xffffff80>;
/* USER CODE END m33_rproc */
};
Is there something in openstlinux that can be configured to allow unsigned packages?
2025-01-27 06:55 AM
Hello,
could you add dynamic trace in the linux kernel befor staring the Cortex-M33 firmware?
echo -n 'file stm32_rproc.c +p' > /sys/kernel/debug/dynamic_debug/control
Loading and staring the Cortex-M33, you have similar extra debug traces:
[ 44.224640] remoteproc remoteproc0: phdr: type 1 da 0x80100000 memsz 0x540 filesz 0x540
[ 44.224651] remoteproc remoteproc0: phdr: type 1 da 0x80100600 memsz 0x8 filesz 0x8
[ 44.224660] remoteproc remoteproc0: phdr: type 1 da 0x80a00000 memsz 0x18488 filesz 0x18488
[ 44.224737] remoteproc remoteproc0: phdr: type 1 da 0x80e00000 memsz 0x12070 filesz 0x1f8
[ 44.224762] remoteproc remoteproc0: phdr: type 1 da 0x81200000 memsz 0x8c filesz 0x8c
[ 44.224775] remoteproc remoteproc0: boot vector address = 0x80100000
This provides addresses and sizes of Cortex-M33 firmware segments that contain code and data.
Then you have to give RIF access rights to both CID1 (for the load) and CID2 (for the execution) on these memory regions.
A simpler alternative is to suppress CID filtering on these memory regions. Since you are not using OP-TEE with firmware signature and authentication, protecting the memory region is not really necessary.
2025-01-27 07:31 AM
Thanks for your reply. I tried your suggestion and I did not see those extra messages show up. See output below.
Could you explain suppressing CID filtering? I do not see an option for that on MX on the DDR memory region table.
root@stm32mp257f-hydra-mx:~# echo -n 'file stm32_rproc.c +p' > /sys/kernel/debug/dynamic_debug/control
root@stm32mp257f-hydra-mx:~# echo Sparta.elf > /sys/class/remoteproc/remoteproc0/firmware
root@stm32mp257f-hydra-mx:~# echo start > /sys/class/remoteproc/remoteproc0/state
[ 87.386076] remoteproc remoteproc0: powering up m33
[ 87.767794] remoteproc remoteproc0: Booting fw image Sparta.elf, size 6202364
[ 87.769542] remoteproc remoteproc0: unsupported fw ver: 0
[ 87.774806] remoteproc remoteproc0: no resource table found for this firmware
[ 87.782044] remoteproc remoteproc0: unsupported fw ver: 0
[ 87.787433] remoteproc remoteproc0: remote processor m33 is now up
root@stm32mp257f-hydra-mx:~# dmesg | grep remoteproc
[ 1.511514] remoteproc remoteproc0: cannot get detach mbox
[ 1.517049] remoteproc remoteproc0: m33 is available
[ 87.386076] remoteproc remoteproc0: powering up m33
[ 87.767794] remoteproc remoteproc0: Booting fw image Sparta.elf, size 6202364
[ 87.769542] remoteproc remoteproc0: unsupported fw ver: 0
[ 87.774806] remoteproc remoteproc0: no resource table found for this firmware
[ 87.782044] remoteproc remoteproc0: unsupported fw ver: 0
[ 87.787433] remoteproc remoteproc0: remote processor m33 is now up
root@stm32mp257f-hydra-mx:~# echo -n 'file stm32_rproc.c +p' > /sys/kernel/debug/dynamic_debug/control
root@stm32mp257f-hydra-mx:~# echo stop > /sys/class/remoteproc/remoteproc0/state
[ 290.943341] remoteproc remoteproc0: warning: remote FW shutdown without ack
[ 290.944816] remoteproc remoteproc0: stopped remote processor m33
root@stm32mp257f-hydra-mx:~# echo start > /sys/class/remoteproc/remoteproc0/state
[ 293.608073] remoteproc remoteproc0: powering up m33
[ 293.784058] remoteproc remoteproc0: Booting fw image Sparta.elf, size 6202364
[ 293.785696] remoteproc remoteproc0: unsupported fw ver: 0
[ 293.791064] remoteproc remoteproc0: no resource table found for this firmware
[ 293.798320] remoteproc remoteproc0: unsupported fw ver: 0
[ 293.803579] remoteproc remoteproc0: remote processor m33 is now up
root@stm32mp257f-hydra-mx:~# dmesg | grep remoteproc
[ 1.511514] remoteproc remoteproc0: cannot get detach mbox
[ 1.517049] remoteproc remoteproc0: m33 is available
[ 87.386076] remoteproc remoteproc0: powering up m33
[ 87.767794] remoteproc remoteproc0: Booting fw image Sparta.elf, size 6202364
[ 87.769542] remoteproc remoteproc0: unsupported fw ver: 0
[ 87.774806] remoteproc remoteproc0: no resource table found for this firmware
[ 87.782044] remoteproc remoteproc0: unsupported fw ver: 0
[ 87.787433] remoteproc remoteproc0: remote processor m33 is now up
[ 290.943341] remoteproc remoteproc0: warning: remote FW shutdown without ack
[ 290.944816] remoteproc remoteproc0: stopped remote processor m33
[ 293.608073] remoteproc remoteproc0: powering up m33
[ 293.784058] remoteproc remoteproc0: Booting fw image Sparta.elf, size 6202364
[ 293.785696] remoteproc remoteproc0: unsupported fw ver: 0
[ 293.791064] remoteproc remoteproc0: no resource table found for this firmware
[ 293.798320] remoteproc remoteproc0: unsupported fw ver: 0
[ 293.803579] remoteproc remoteproc0: remote processor m33 is now up
I
2025-01-27 08:50 AM
Bad command, the traces are printed in the remoteproc framework. Please use following one:
#echo -n 'file remoteproc*.c +p' > /sys/kernel/debug/dynamic_debug/control
Concerning Cube MX:
you have a "CID filtering" column in RIF. Unchecking the box should disable the filtering.
2025-01-27 09:26 AM
That new command worked thanks.
Here is my view of the DDR page. I do not see the CID filtering column
2025-01-27 11:49 AM
[ 796.821804] remoteproc remoteproc0: powering up m33
[ 796.997700] remoteproc remoteproc0: Firmware is an elf32 file
[ 796.997725] remoteproc remoteproc0: Booting fw image Sparta.elf, size 6202388
[ 796.999342] remoteproc remoteproc0: unsupported fw ver: 0
[ 797.004718] remoteproc remoteproc0: no resource table found for this firmware
[ 797.011864] remoteproc remoteproc0: phdr: type 1 da 0x80000000 memsz 0x540 filesz 0x540
[ 797.011880] remoteproc remoteproc0: phdr: type 1 da 0x80000600 memsz 0x8 filesz 0x8
[ 797.011890] remoteproc remoteproc0: phdr: type 1 da 0x80a00000 memsz 0xed28 filesz 0xb788
[ 797.011955] remoteproc remoteproc0: phdr: type 1 da 0x81200000 memsz 0x8c filesz 0x8c
[ 797.011967] remoteproc remoteproc0: unsupported fw ver: 0
[ 797.017345] remoteproc remoteproc0: remote processor m33 is now up
[ 802.925958] remoteproc remoteproc0: warning: remote FW shutdown without ack
[ 802.927419] remoteproc remoteproc0: stopped remote processor m33
Here is the output now with the new command. I those IAC exceptions are now gone after removing the CID filtering from retram. Now I do not see any sign that my program is running on the M33 core. It should be printing out message over uart and toggling a GPIO, but I do not see any of those things happening.
2025-01-28 12:35 AM
Do you try to debug your M33 firmware with cube IDE ?
See https://wiki.st.com/stm32mpu/wiki/Getting_started/STM32MP2_boards/STM32MP257x-DK/Develop_on_Arm_Cortex-M33/Modify,_rebuild_and_reload_the_firmware for details
Another root cause could be the boot address that is not correctly set
using
echo -n 'file stm32_rproc.c +p' > /sys/kernel/debug/dynamic_debug/control
you should see a trace indicating your boot address
[ 44.224775] remoteproc remoteproc0: boot vector address = 0x80100000
The boot address is computed based on ".isr_vectors" section that should be defined in your Cortex-M33 firmware linker script.
/* The startup code into "NS_VECTOR_TBL" Ram type memory
* Do not update the ".isr_vectors" section name. the name
* is used by the Linux kernel to retrieve the address
* of the vector table*/
.isr_vectors :
{
. = ALIGN(4);
KEEP(*(.isr_vectors))
. = ALIGN(4);
} >NS_VECTOR_TBL
2025-01-31 11:56 AM
Thanks for the tip. After debugging I saw that the code was crashing because it was failing to initialize the UART. After some investigation, I noticed that the generated code was not setting the baud rate for the UART, after I manually added that line, the uart initialized and my code was running as expected.
See code below, I needed to add the baud rate since cube MX was not generating it. Any reason why that would be the case? I have also noticed issues with other peripherals as I have been adding then where I experience similar issues with code generation causing compile errors due to missing pieces.
static void MX_UART7_Init(void)
{
/* USER CODE BEGIN UART7_Init 0 */
/* USER CODE END UART7_Init 0 */
/* USER CODE BEGIN UART7_Init 1 */
huart7.Init.BaudRate = 115200;
/* USER CODE END UART7_Init 1 */
huart7.Instance = UART7;
huart7.Init.WordLength = UART_WORDLENGTH_8B;
huart7.Init.StopBits = UART_STOPBITS_1;
huart7.Init.Parity = UART_PARITY_NONE;
huart7.Init.Mode = UART_MODE_TX_RX;
huart7.Init.HwFlowCtl = UART_HWCONTROL_NONE;
huart7.Init.OverSampling = UART_OVERSAMPLING_16;
huart7.Init.OneBitSampling = UART_ONE_BIT_SAMPLE_DISABLE;
huart7.Init.ClockPrescaler = UART_PRESCALER_DIV1;
huart7.AdvancedInit.AdvFeatureInit = UART_ADVFEATURE_NO_INIT;
if (HAL_UART_Init(&huart7) != HAL_OK)
{
Error_Handler();
}
if (HAL_UARTEx_SetTxFifoThreshold(&huart7, UART_TXFIFO_THRESHOLD_1_8) != HAL_OK)
{
Error_Handler();
}
if (HAL_UARTEx_SetRxFifoThreshold(&huart7, UART_RXFIFO_THRESHOLD_1_8) != HAL_OK)
{
Error_Handler();
}
if (HAL_UARTEx_DisableFifoMode(&huart7) != HAL_OK)
{
Error_Handler();
}
/* USER CODE BEGIN UART7_Init 2 */
/* USER CODE END UART7_Init 2 */
}