STM32MP157D-DK1: Loading M4 firmware examples from U-boot fails with non-specific error message

[AmateurECE]

Hi there! I'm trying to load one of the M4 example projects from U-boot following this procedure in the ST documentation and this documentation in this repository. I download the firmware over YMODEM using the loady command in U-boot, and when I try to load the firmware, I get a non-specific error from the rproc command:

STM32MP> rproc init
STM32MP> rproc load 0 ${loadaddr} ${filesize}
Load Remote Processor 0 with data@addr=0xc2000000 32908 bytes: Failed!

Loading the same GPIO_EXTI.elf image from the Linux side works as expected:

# cd /usr/lib/Cube-M4-examples/GPIO_EXTI/
# ./fw_cortex_m4.sh start
fw_cortex_m4.sh: fmw_name=GPIO_EXTI.elf
cp: can't stat 'lib/firmw[  285.094355] remoteproc remoteproc0: powering up m4
[  285.099054] remoteproc remoteproc0: Booting fw image GPIO_EXTI.elf, size 32908
[  285.105921] remoteproc remoteproc0: header-less resource table
[  285.111786] remoteproc remoteproc0: no resource table found for this firmware
[  285.119036] remoteproc remoteproc0: header-less resource table
[  285.124797] remoteproc remoteproc0: remote processor m4 is now up
are/GPIO_EXTI.elf': No such file or directory

(Note: It seems to have worked, even though that cp command fails. I'm not sure why that is, however, I did notice that I had to explicitly copy the .elf file over using lrzsz, because it wasn't populated in /lib/firmware even after I enabled the M4 projects package in my config. I think this might be an unrelated issue with the M4 projects makefile).

I'm using the st/2024.02.3 branches of the bootlin buildroot tree and this repository (with no modifications to the st_stm32mp157d_dk1_defconfig config except to add the lrzsz and M4 projects packages), and this is on an STM32MP157D-DK1 development kit. Thanks for your help!

[tpetazzoni]

Thanks for reporting your issue. We have not validated running the M4 examples from U-Boot as part of this Buildroot integration. Of course, there is no reason for it not to work, but we have simply not tested this. I'll assign my colleague @kmaincent to this issue, but he will not be able to answer before the week of Sep 9.

[AmateurECE]

Not a problem! Do you accept community pull requests to this repository? I'll likely be digging into this over the next few days anyways.

[tpetazzoni]

Yes, we do accept community pull requests, sure!

[AmateurECE]

Sorry for the noise! I think this is actually not a bug. I didn't read enough of the docs to realize that coprocessor support is only built into the demo configurations.

However, I think I did discover a true, actual bug. The coprocessor firmware itself seems to be missing from both of the demo images linked in the README. Compare this output from the st_stm32mp157d_dk1_demo image on the st/2024.02.3 branch:

[amateurece@gentoo ~]$ find /mnt/sdcard/lib/firmware/
/mnt/sdcard/lib/firmware/
/mnt/sdcard/lib/firmware/brcm
/mnt/sdcard/lib/firmware/brcm/brcmfmac43430-sdio.txt

Versus the same command for one of the st_stm32mp157f_dk2_demo images:

[amateurece@gentoo ~]$ find /mnt/sdcard/lib/firmware/
/mnt/sdcard/lib/firmware/
/mnt/sdcard/lib/firmware/ADC_SingleConversion_TriggerTimer_DMA.elf
/mnt/sdcard/lib/firmware/AI_Character_Recognition.elf
/mnt/sdcard/lib/firmware/CORTEXM_MPU.elf
/mnt/sdcard/lib/firmware/CRC_UserDefinedPolynomial.elf
/mnt/sdcard/lib/firmware/CRYP_AES_DMA.elf
/mnt/sdcard/lib/firmware/CoproSync_ShutDown.elf
/mnt/sdcard/lib/firmware/DMA_FIFOMode.elf
/mnt/sdcard/lib/firmware/FreeRTOS_ThreadCreation.elf
/mnt/sdcard/lib/firmware/GPIO_EXTI.elf
# ...

Here's a quick summary of the images I tested:

	st/2024.02.3	openstlinux-6.1-buildroot-2024.02.3-mpu-v24.06.26
st_stm32mp157d_dk1_demo	Missing	Missing
st_stm32mp157f_dk2_demo	Missing	Present