AM620-Q1: MCU only mode - Discussion

Hello,

Are you using SDK 10.00 as you mentioned in a previous thread?

Can you provide the steps you followed to build the ipc_rpmesg_echo application?

Thanks,

Anshu

Hi,

Steps I have followed:

1. Cloned the latest MCU+SDK 10.00 for am62x platform.

2. To build the  ipc_rpmesg_echo application(ipc_rpmsg_echo_linux.mcu-m4f0_0.release.strip.out), I did - ``make -s all PROFILE=release `` in the directory - ``~/ti/mcu_plus_sdk_am62x_10_00_00_14/examples/drivers/ipc/ipc_rpmsg_echo_linux/am62x-sk-lp/m4fss0-0_freertos/ti-arm-clang``

3. Stopped the remoteproc0 ( echo stop > state)

4. Created a symbolic link to point to my build .out, replacing the default one(/usr/lib/firmware/ti-ipc/am62xx/ipc_echo_test_mcu2_0_release_strip.xer5f), using the below command.

ln -s  /path/to/built/ipc_rpmsg_echo_linux.mcu-m4f0_0.release.strip.out am62-mcu-m4f0_0-fw

5. Started the remoteproc0 (echo start > state)

Hello Kanishk,

Let's do a couple of tests to narrow down what could be causing the behavior you observe.

1) Does the core initialization method make a difference?

gracefully shutting down and restarting a core during runtime is one way to load firmware into a core. The other way would be just rebooting the board. Refer to https://dev.ti.com/tirex/explore/node?node=A__AckaMLLzyxszvNaSLSFIQg__AM62-ACADEMY__uiYMDcq__LATEST for details.

Since you already updated the link, your new firmware will get loaded into the M4F on the next boot.

Do you see the same behavior after a board reboot?

2) Can you verify that the M4F firmware is actually running? 

There are a couple ways to do this:
try to run the IPC Echo example and see if it works
check the Print statements in the Linux trace log
connect over CCS

Links here:
Running the IPC demo: https://dev.ti.com/tirex/explore/node?node=A__AXINfJJ0T8V7CR5pTK41ww__AM62-ACADEMY__uiYMDcq__LATEST
Debugging a remote core during runtime: https://dev.ti.com/tirex/explore/node?node=A__AZkAO-6yNxds0ZkyrWWiHw__AM62-ACADEMY__uiYMDcq__LATEST

3) If echo stop --> echo start does NOT work, but rebooting does, please show me your terminal output

We are tracking down some issues with graceful shutdown on AM64x R5F cores (i.e., rebooting the board is the ONLY supported method to load new firmware into an R5F on AM64x Linux SDK 10.0). My assumption is that the issue is specific to R5F cores, but it would be good to know if AM62x M4F is also affected.

Regards,

Nick

Hello Nick,

I tried loading the my .out fw both the ways,
1) gracefully shutting down by stopping & starting the remoteproc,
2) Rebooting the board after adding the link to the fw image.

In either cases, I couldn't wakeup the device using MCU UART, when firmware points to my newly built file.

I tried the above two cases with the default firmware, it works!. A key press on the MCU UART wakes up the device, when I load the default one.

Nick Saulnier said:

1) Does the core initialization method make a difference?

No, it doesn't

Nick Saulnier said:

2) Can you verify that the M4F firmware is actually running? 

Yeah, M4F firmware is up and running

root@am62xx-lp-evm:/sys/class/remoteproc/remoteproc0# rpmsg_char_simple -r 9 -n 3
Created endpt device rpmsg-char-9-1237, fd = 4 port = 1025
Exchanging 3 messages with rpmsg device rpmsg-char-9-1237 on rproc id 9 ...

Sending message #0: hello there 0!
Received message #0: round trip delay(usecs) = 168635
hello there 0!
Sending message #1: hello there 1!
Received message #1: round trip delay(usecs) = 60245
hello there 1!
Sending message #2: hello there 2!
Received message #2: round trip delay(usecs) = 59550
hello there 2!

Communicated 3 messages successfully on rpmsg-char-9-1237

TEST STATUS: PASSED

Maybe, I'll try to flash the ipc application via UART (using uart_uniflash.py)  to the specific offset (0x100000 for m4f), instead of the above remoteproc steps, and see if that works?

Hello,

Can you confirm you've added the MCU UART wakeup source? It can be found in this device tree overlay: git.ti.com/.../k3-am62x-sk-lpm-wkup-sources.dtso

Here are the SDK instructions for adding a DTS overlay: https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/latest/exports/docs/linux/How_to_Guides/Target/How_to_enable_DT_overlays_in_linux.html#howto-dt-overlays

I'll ask Nick to comment on the last item.

Thanks,

Anshu

Hello Kanishk,

Nick mentioned using the UART Uniflash for this case is not possible because IPC application requires Linux to initialize resources defined in the resource table as discussed here: https://dev.ti.com/tirex/explore/node?node=A__AfR2ju5RKoCJDj50kzWghg__AM62-ACADEMY__uiYMDcq__LATEST

Thanks,

Anshu

Hello,

I get it. But I need a bit more clarification on this.

So far, I have come across MCU only mode with linux booting early, also I have tried and tested it. But our requirement is to boot m4f before Linux. This early boot can be achieved by flashing the application via UART to emmc boot partition. 

python3 uart_uniflash.py -p /dev/ttyUSB0 --cfg=sbl_prebuilt/am62x-sk-lp/default_sbl_emmc_linux_hs_fs.cfg

SYSFW Firmware Version 10.0.8--v10.00.08 (Fiery Fox)
SYSFW Firmware revision 0xa
SYSFW ABI revision 4.0

[BOOTLOADER_PROFILE] Boot Media       : eMMC
[BOOTLOADER_PROFILE] Boot Media Clock : 200.000 MHz
[BOOTLOADER_PROFILE] Boot Image Size  : 159 KB
[BOOTLOADER_PROFILE] Cores present    :
m4f0-0
r5f0-0
[BOOTLOADER PROFILE] System_init                      :      33537us
[BOOTLOADER PROFILE] Board_init                       :          0us
[BOOTLOADER PROFILE] Drivers_open                     :      19524us
[BOOTLOADER PROFILE] Board_driversOpen                :          0us
[BOOTLOADER PROFILE] Sciclient Get Version            :      10203us
[BOOTLOADER PROFILE] App_loadImages                   :       6428us
[BOOTLOADER PROFILE] App_loadSelfcoreImage            :       7786us
[BOOTLOADER_PROFILE] SBL Total Time Taken             :      77481us

Image loading done, switching to application ...
Starting MCU-m4f and 2nd stage bootloader

SYSFW Firmware Version 10.0.8--v10.00.08 (Fiery Fox)
SYSFW Firmware revision 0xa
SYSFW ABI revision 4.0

[BOOTLOADER_PROFILE] Boot Media       : eMMC
[BOOTLOADER_PROFILE] Boot Media Clock : 200.000 MHz
[BOOTLOADER_PROFILE] Boot Image Size  : 1081 KB
[BOOTLOADER_PROFILE] Cores present    :
hsm-m4f0-0
r5f0-0
a530-0
[BOOTLOADER PROFILE] System_init                      :       2659us
[BOOTLOADER PROFILE] Board_init                       :          1us
[BOOTLOADER PROFILE] Drivers_open                     :      19555us
[BOOTLOADER PROFILE] Board_driversOpen                :          1us
[BOOTLOADER PROFILE] Sciclient Get Version            :      10228us
[BOOTLOADER PROFILE] App_loadImages                   :       5299us
[BOOTLOADER PROFILE] App_loadSelfcoreImage            :       8702us
[BOOTLOADER PROFILE] App_loadLinuxImages              :      29485us
[BOOTLOADER_PROFILE] SBL Total Time Taken             :      75933us

Image loading done, switching to application ...
Starting linux and RTOS/Baremetal applications
NOTICE:  BL31: v2.10.0(release):v2.10.0-367-g00f1ec6b87-dirty
NOTICE:  BL31: Built : 16:09:05, Feb  9 2024

Once the device is up, I could see the ipc application is running but yet I couldn't see the logs in MCU UART when I put the device to MCU only mode and neither I couldn't wake up from sleep?

So, could u elaborate me on the MCU ONLY mode with the scenarios above?(Linux booting ahead of RTOS cores and M4F booting ahead of Linux)

Hello,

"flashing via UART" is not a boot method. It looks like the boot method you are using above is SBL boot (the default boot method in MCU+ SDK), as opposed to SPL boot (the default boot method in Linux SDK).

Please refer to this documentation for more information:
https://dev.ti.com/tirex/explore/node?node=A__AXoA3i9lx8c-jH8btw5.pA__AM62-ACADEMY__uiYMDcq__LATEST

Regards,

Nick

Hello Nick, 

Thanks for the sharing documentation!

Yes, I am using SBL boot (SBL emmc).

When I do SBL boot, the remote cores are being initialized even before the Linux boots. Hence, Linux is moving the core's state to attached and by that when I try to enter into MCU only mode, It's not entering. 

[    6.484988] k3-m4-rproc 5000000.m4fss: assigned reserved memory node m4f-dma-memory@9cb00000
[    6.494262] k3-m4-rproc 5000000.m4fss: configured M4 for IPC-only mode
[    6.501259] remoteproc remoteproc0: 5000000.m4fss is available
[    6.507291] remoteproc remoteproc0: attaching to 5000000.m4fss
[    6.515635] m_can_platform 4e08000.can: m_can device registered (irq=0, version=32)
[    6.533968] k3-m4-rproc 5000000.m4fss: M4 initialized in IPC-only mode
[    6.540779] rproc-virtio rproc-virtio.2.auto: assigned reserved memory node m4f-dma-memory@9cb00000

From this log, I assume, the remote core is already running when the Linux remoteproc driver gets called. Remoteproc driver is initializing the memory to do RPMsg IPC , and attaches to the remote core. Also, it's configuring M4 in IPC only mode.

This is the terminal output, when I try MCU only mode.

root@am62xx-lp-evm:~# echo mem > /sys/power/state
[  709.823391] PM: suspend entry (deep)
[  709.838101] Filesystems sync: 0.010 seconds
[  709.861772] k3-m4-rproc 5000000.m4fss: k3_m4_rproc_stop cannot be invoked in IPC-only mode
[  709.870545] remoteproc remoteproc0: can't stop rproc: -22
[  709.880272] Freezing user space processes
[  709.886477] Freezing user space processes completed (elapsed 0.001 seconds)
[  709.893481] OOM killer disabled.
[  709.896718] Freezing remaining freezable tasks
[  709.902364] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
[  709.909769] printk: Suspending console(s) (use no_console_suspend to debug)

Could u guide me on how I can disable the remote core initialization during SBL boot. I only want remote cores to be initialized by Linux Remoteproc driver, so that I can enter into MCU only mode without above errors.

Hello Kanishk,

Nick is out of office this week. If you haven't already, review the Multicore Academy section about Booting and Disabling Processors Cores: https://dev.ti.com/tirex/explore/node?node=A__AdnCtmyMLBJQE.U38-Dw4w__AM62-ACADEMY__uiYMDcq__LATEST

Best Regards,

Anshu

Hello Kanishk,

To clarify, the Multicore academy does NOT yet discuss how to tell SBL boot to not load remote cores.

I am sending your thread over to a member of our MCU+ team to discuss how to tell SBL boot to not load remote cores. I'll keep an eye on the thread and use the information you discuss to update the academy documentation.

Regards,

Nick