Skip to main content
Graduate
September 1, 2023
Solved

STM32MP1 - How to start the coprocessor from the bootloader

  • September 1, 2023
  • 2 replies
  • 2569 views
I am working on a STM32MP157D-DK1 board, and I am trying to follow the guide from the wiki to start the coprocessor from u-boot:
 
I have pulled the u-boot source code:
devtool modify u-boot-stm32mp
 
 
And modified include/configs/stm32mp15_st_common.h to contain:
 
#define CONFIG_EXTRA_ENV_SETTINGS \
STM32MP_MEM_LAYOUT \
STM32MP_BOOTCMD \
STM32MP_PARTS_DEFAULT \
BOOTENV \
"m4fw_name=my-m4-fw.elf\0" \
  "m4fw_addr=${kernel_addr_r}\0" \
"boot_m4fw=rproc init; rproc load 0 ${m4fw_addr} ${filesize}; rproc start 0\0" \
  "boot_m4_mmc0=if load mmc 0#bootfs ${m4fw_addr} ${m4fw_name} ; then run boot_m4fw; fi;\0"\
  "bootcmd=echo \"Loading the firmware!\"; echo \"ELF files is: ${m4fw_name}\"; run boot_m4_mmc0; run bootcmd_mmc0\0"
 
I have rebuild the distribution as:
bitbake st-image-weston
 
(No issues or erros)
 
and uploaded all image files via CubeProgrammer using the FlashLayout_sdcard_stm32mp157d-dk1-optee.tsv file.
 
I have copied the my-m4-fw.elf to the bootfs partition, but when u-boot launches and I type in:
STM32MP> env print bootcmd 
 
I still get:
bootcmd=run bootcmd_stm32mp
 
instead of the command I manually configured from the wiki example.
 
What am I doing wrong?
    This topic has been closed for replies.
    Best answer by mjuels

    Thank you so much for the reply - Although very silly, your first suggestion turned out to help; I had confused "stm32mp15_st_common.h" with "stm32mp15_common.h" and edited the wrong one.

    I still have problems, but I will add them in a separate post to stay on topic.

    Thank you.

    2 replies

    September 2, 2023

    It appears that your modification to the U-Boot environment settings is not taking effect when U-Boot is launched. To troubleshoot this issue, you can follow these steps:

    1. Double-check your modifications: Make sure you have saved your changes to the include/configs/stm32mp15_st_common.h file after adding the CONFIG_EXTRA_ENV_SETTINGS lines. Sometimes, changes might not be saved properly.

    2. Rebuild U-Boot: After making changes to the U-Boot configuration, you should rebuild U-Boot to incorporate your modifications. You mentioned that you rebuilt the distribution (st-image-weston), but it's essential to ensure that U-Boot itself is rebuilt with your custom configuration. You can rebuild U-Boot by running the following command in your Yocto build environment:

      Copy code
      bitbake u-boot-stm32mp

      This command will rebuild U-Boot with your custom environment settings.

    3. Flash the modified U-Boot image: After rebuilding U-Boot, make sure that you flash the updated U-Boot image to the appropriate location on your STM32MP157D-DK1 board.

    4. Confirm the environment variables: After flashing the updated U-Boot image, reboot your board and enter U-Boot. Then, check the environment variables to ensure that your changes are reflected:

      shellCopy code
      STM32MP> printenv

      This will display the current U-Boot environment variables, including bootcmd. Verify that your custom bootcmd is set correctly.

    5. Save the environment: If you see that your custom bootcmd is correct but not taking effect, you may need to save the environment changes. You can do this by running the following command in U-Boot:

      shellCopy code
      STM32MP> saveenv

      This command will save the current environment settings to non-volatile storage so that they persist across reboots.

    6. Reboot the board: After saving the environment, you can reboot the board and see if your custom bootcmd is executed as expected.

    If you follow these steps carefully and ensure that your custom bootcmd is set correctly in the U-Boot environment, it should work as intended. Make sure to double-check the U-Boot image's flash location and that your changes are saved correctly to the U-Boot environment

    mjuelsAuthorAnswer
    Graduate
    September 6, 2023

    Thank you so much for the reply - Although very silly, your first suggestion turned out to help; I had confused "stm32mp15_st_common.h" with "stm32mp15_common.h" and edited the wrong one.

    I still have problems, but I will add them in a separate post to stay on topic.

    Thank you.

    Visitor II
    May 21, 2025

    Hi,

    Were you able to solve the problem?

    In my log I see:
    [2.155832] remoteproc remoteproc0: m4 is available
    [2.160247] remoteproc remoteproc0: Direct firmware load for rproc-m4-fw failed with error -2
    [2.168705] remoteproc remoteproc0: powering up m4
    [ 2.170700] st,stm32-i2s 4000b000.audio-controller: No cache defaults, reading back from HW
    [ 2.175527] remoteproc remoteproc0: Direct firmware load for rproc-m4-fw failed with error -2
    [ 2.184272] stm32-usbphyc 5a006000.usbphyc: registered rev:1.0
    [2.190257] remoteproc remoteproc0: request_firmware failed: -2

    And I have already modified my configuration like this:
    #define CONFIG_EXTRA_ENV_SETTINGS \
    STM32MP_MEM_LAYOUT \
    ST_STM32MP1_BOOTCMD\
    STM32MP_PARTS_DEFAULT\
    BOOTENV\
    STM32MP_EXTRA \
    STM32MP_BOARD_EXTRA_ENV \
    "copro_fw_name=rproc-m4-fw\0" \
    "boot_copro_fw=reproc init; rproc load 0 ${kernel_addr_r} ${filesize}; rproc start 0 \0" \
    "load_copro_fw=if ext4load mmc ${EMMCDEV}:${EMMCPART} ${kernel_addr_r} /boot/${copro_fw_name};" \
    "then echo \"Loaded Cortex-M FW from eMMC\"; run boot_copro_fw; else echo \"Could not load Cortex-M FW\"; fi; \0"

    What else do I have to do to get the m4 to boot?

    Best regards.