Loading firmware into the Cortex-M0 MCU via remoter processor interface

2025-08-02 9:55

Hi,

I would like to run some special bare-metal Firwmare on the Cortex-M0 MCU. I did not find proper information how to load and start MCU FW so I started developing remote processor driver for the RK3506 MCU.

I've created a project on the github here:

github.com/nvitya/rk3506-mcu

When this remote processor starts working that would be great for lot of your users!

Unfortunately something is still missing.
The FW gets loaded properly, but the MCU does not execute it.
(The test FW is very simple, written in ASM, entry point is at the beginning. All sources included in the github project page)

I really need some help.
You can answer me either here or on the github page (github.com/nvitya/rk3506-mcu).

Thank You!

2025-08-04 3:41

Hello, in our last update, we have already released the AMP-related configuration. You can refer to the startup process of the AMP image to troubleshoot the issue where your project fails to start the MCU.

1. Modify $SDK/device/rockchip/rk3506/amp_linux_mcu.its

Code: Select all

configurations {
default = "conf";
conf {
description = "Rockchip AMP images";
rollback-index = <0x0>;
-                      	                       loadables = "amp2";
+                      	               loadables = "mcu";


signature {
algo = "sha256,rsa2048";
padding = "pss";
key-name-hint = "dev";
sign-images = "loadables";
};

2. Select rk3506g_buildroot_spinand_amp_defconfig

Code: Select all

./build.sh lunch                                    hxj@luckfox-System-Product-Name




############### Rockchip Linux SDK ###############


Manifest: luckfox_linux6.1_rk3506_release_v1.4_20250620.xml 

Log colors: message notice warning error fatal


Log saved at /mnt/zitai-ssd/hxj/lyra_release_250623/output/sessions/2025-08-04_11-30-54
You're building on Linux
Lunch menu... pick the Luckfox Lyra hardware version:
Select the Luckfox Lyra hardware version: [0] RK3506G_Luckfox_Lyra
[1] RK3506G_Luckfox_Lyra_Plus
[2] RK3506B_Luckfox_Lyra_Ultra
[3] RK3506B_Luckfox_Lyra_Ultra_W
[4] RK3506B_Luckfox_Lyra_Zero_W
[5] RK3506B_Luckfox_Lyra_Pi
[6] RK3506B_Luckfox_Lyra_Pi_W
[7] custom
Which would you like? [0~7][default:0]: 7
Pick a defconfig:


1. luckfox_lyra_buildroot_sdmmc_defconfig
2. luckfox_lyra_buildroot_spinand_defconfig
3. luckfox_lyra_pi-w_buildroot_emmc_defconfig
4. luckfox_lyra_pi-w_buildroot_sdmmc_defconfig
5. luckfox_lyra_pi_buildroot_emmc_defconfig
6. luckfox_lyra_pi_buildroot_sdmmc_defconfig
7. luckfox_lyra_plus_buildroot_sdmmc_defconfig
8. luckfox_lyra_plus_buildroot_spinand_defconfig
9. luckfox_lyra_ultra-w_buildroot_emmc_defconfig
10. luckfox_lyra_ultra_buildroot_emmc_defconfig
11. luckfox_lyra_zero-w_buildroot_sdmmc_defconfig
12. luckfox_lyra_zero-w_buildroot_spinand_defconfig
13. rk3506b_buildroot_emmc_amp_defconfig
14. rk3506b_buildroot_spinand_amp_defconfig
15. rk3506g_buildroot_spinand_amp_defconfig
Which would you like? [1]: 15 Switching to defconfig: /mnt/zitai-ssd/hxj/lyra_release_250623/device/rockchip/.chip/rk3506g_buildroot_spinand_amp_defconfig
#
# configuration written to /mnt/zitai-ssd/hxj/lyra_release_250623/output/.config
#
Using the latest kernel version (6.1)

2. Complete burning of the image
3. Refer to $SDK/hal/project/rk3506-mcu/src/main.c. GPIO1_C2 is used for UART_TX and GPIO1_C3 is for UART_RX. This can be connected to the serial port module to view the printed information.

The AMP configuration is still in the testing phase, so it is not directly displayed on the ./build.sh lunch interface. Currently, the development plans related to AMP have a relatively low priority. If you have any related questions, it is recommended to seek help from Rockchip.

2025-08-05 19:11

Hello,

Thank you for your answer.
I managed to compile and install the AMP version of your image.
I got indeed "[HAL INFO] Hello RK3506 mcu" on the UART4 at u-boot time.
But nothing more. And also one A7 CPU less, it seems that one A7 CPU is also reserved for the AMP system.

Developing an MCU Firmware this way is pretty hard, takes too much time for trying out with the burning and board restart.

It seems that I need to seek help at Rockchip.
Do you know where / how can I try to get contact to Rockchip on this matter?

2025-08-26 2:41

Usually, you can get in touch with Rockchip by visiting their official website: https://www.rock-chips.com/a/en/About_R ... index.html

2025-09-21 6:20

Hello,

Finally I managed to have my remote processor module working!

I shared the source code along several information on this github page:
https://github.com/nvitya/rk3506-mcu

Two issues are still open, and I'm seeking help for solve these:

1. Hot-swapping the MCU FW:

Once the MCU code is running, the SRAM becomes inaccessible and cannot be modified by the Linux system (until the next restart), and I don't know how to make it accessible again. For the SRAM unmapping probably there is a special trusted FW call (arm_smccc_smc()), but I don't know which. The reference manual says: "System SRAMx using as TCM is configured by mcu_tcm_selx in SGRF_PMU" which is not documented in the TRM part 1 and the registers at 0xFF960000 are unaccessible from Linux.

2. SWD (Serial Wire Debugging):

For the professional code development this is a must.

When the FW Hot-Swapping works then this is lesser important to me. In the u-boot source code at "fit_standalone_release()" there was an inactive section with

Code: Select all

  // select jtag m1 GPIO0C6 GPIO0C7
  //writel(0x00220000, 0xff960000);  // <-- SGRF_PMU
  //writel(0x00300020, 0xff288000);
  //writel(0x00ff0022, 0xff4d8064);
  //writel(0xff002200, 0xff950014);

From the four lines I understand three. But the first one points to SGRF_PMU (0xff960000), which is not documented and not accessible from Linux. Does this one activate the SWD for the Cortex-M0? Is there a arm_smccc_smc() call for this?

I tried to contact to Rockchip too but I did not get any response. (They might ignore small developers like me?)

If you have access more information regarding these issues please help me.