[iMX8QM-MEK] Unable to change firmware on M4 core - remote core state attached

[ChrisC05]

Hey,

I am attempting to change the firmware that is running on one of the M4 cores of the iMX8QM-MEK by using an .elf file compiled using MCUXpresso IDE. I have copied both the .elf file and the .bin file to the boot SD and configured U-boot to load the .bin image to the M4 core by changing:

=> print m4_0_image
m4_0_image=hello_world_m40.bin

I am running into some peculiar issues regarding the remote core in both U-boot and the kernel. First of all, it seems that this power mode switching task runs before U-boot prints its first lines to the console, which might indicate that something is happening in SFCW.

In U-boot, when I Interrupt auto-boot and run the booting script, I get the following:

=> print m4boot_0
m4boot_0=run loadm4image_0; dcache flush; bootaux ${loadaddr} 0
=> print loadm4image_0
loadm4image_0=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${m4_0_image}
=> run m4boot_0
14800 bytes read in 10 ms (1.4 MiB/s)
## Auxiliary core is already up

 And when I boot into the kernel and read the state of remoteproc0 I get the following state, which disallows me from loading any firmware to the core, or stopping the core:

root@imx8qmmek:~# cat /sys/class/remoteproc/remoteproc0/state
attached
root@imx8qmmek:~# echo stop > /sys/class/remoteproc/remoteproc0/state
[ 84.896858] imx-rproc imx8qm-cm4-0: Failed to stop remote core
[ 84.902759] remoteproc remoteproc0: can't stop rproc: -13
-sh: echo: write error: Permission denied

Looking at dmesg yields:

root@imx8qmmek:~# dmesg | grep rproc
[ 3.022630] remoteproc remoteproc0: imx-rproc is available
[ 3.031813] remoteproc remoteproc0: attaching to imx-rproc
[ 3.043022] rproc-virtio rproc-virtio.1.auto: assigned reserved memory node vdevbuffer@90400000
[ 3.057679] rproc-virtio rproc-virtio.1.auto: registered virtio0 (type 7)
[ 3.064485] rproc-virtio rproc-virtio.2.auto: assigned reserved memory node vdevbuffer@90400000
[ 3.085832] rproc-virtio rproc-virtio.2.auto: registered virtio1 (type 7)
[ 3.092648] remoteproc remoteproc0: remote processor imx-rproc is now attached
[ 3.101451] remoteproc remoteproc1: imx-rproc is available
[ 3.107032] remoteproc remoteproc1: attaching to imx-rproc
[ 3.113075] rproc-virtio rproc-virtio.3.auto: assigned reserved memory node vdevbuffer@90400000
[ 3.127700] rproc-virtio rproc-virtio.3.auto: registered virtio2 (type 7)
[ 3.141984] rproc-virtio rproc-virtio.4.auto: assigned reserved memory node vdevbuffer@90400000
[ 3.163620] rproc-virtio rproc-virtio.4.auto: registered virtio3 (type 7)
[ 3.177037] remoteproc remoteproc1: remote processor imx-rproc is now attached

 I'm not sure how to stop the remote core so that I can swap the firmware in the linux kernel instead of via U-boot, and I cannot find any information on the attached state for remoteproc.

If it's not possible to stop the core in U-boot, and only start it, how can I prevent whatever process runs before U-boot from starting the core, so that I can start it in U-boot or in the kernel?

I built my bootable .wic file using Yocto poky 5.0.4 scarthgap.

--- U-Boot info ---

U-Boot SPL 2024.04-lf_v2024.04+g6c4545203d1+p0 (Nov 15 2024 - 04:02:13 +0000)
Normal Boot
Trying to boot from MMC2_2
Primary set selected
Load image from MMC/SD 0x7c800

U-Boot 2024.04-lf_v2024.04+g6c4545203d1+p0 (Nov 15 2024 - 04:02:13 +0000)

CPU: NXP i.MX8QM RevB A53 at 1200 MHz at 26C

Model: NXP i.MX8QM MEK
Board: iMX8QM MEK
Boot: SD1
Reset cause: POR
DRAM: 5.8 GiB
TCPC: Vendor ID [0x1fc9], Product ID [0x5110], Addr [I2C0 0x51]
Core: 188 devices, 32 uclasses, devicetree: separate
MMC: FSL_SDHC: 0, FSL_SDHC: 1
Loading Environment from MMC... OK
[*]-Video Link 0it6263_i2c_reg_read, read err 3
faill to read from it6263 revision, ret 3
(1280 x 720)
[0] dpu@56180000, video
[1] lvds-channel@0, display
[2] lvds-to-hdmi-bridge@4c, video_bridge
In: serial
Out: serial
Err: serial

BuildInfo:
- SCFW 83624b99, SECO-FW 7d5462e6, IMX-MKIMAGE 71b8c18a, ATF android
- U-Boot 2024.04-lf_v2024.04+g6c4545203d1+p0

switch to partitions #0, OK
mmc1 is current device
flash target is MMC:1
Net: eth0: ethernet@5b040000 [PRIME]Could not get PHY for FEC1: addr 1

Fastboot: Normal
Normal Boot
Hit any key to stop autoboot: 0

=> bdinfo
boot_params = 0x0000000000000000
DRAM bank = 0x0000000000000000
-> start = 0x0000000080200000
-> size = 0x0000000007e00000
DRAM bank = 0x0000000000000001
-> start = 0x0000000092000000
-> size = 0x000000006c000000
DRAM bank = 0x0000000000000002
-> start = 0x0000000880000000
-> size = 0x0000000100000000
flashstart = 0x0000000000000000
flashsize = 0x0000000000000000
flashoffset = 0x0000000000000000
baudrate = 115200 bps
relocaddr = 0x0000000087627000
reloc off = 0x0000000007607000
Build = 64-bit
current eth = ethernet@5b040000
ethaddr = 00:04:9f:06:5e:76
IP addr = <NULL>
fdt_blob = 0x0000000085215210
new_fdt = 0x0000000085215210
fdt_size = 0x0000000000011b20
Video = dpu@56180000 active
FB base = 0x0000000087700000
FB size = 1280x720x32
lmb_dump_all:
memory.cnt = 0x3 / max = 0x10
memory[0] [0x80200000-0x87ffffff], 0x07e00000 bytes flags: 0
memory[1] [0x92000000-0xfdffffff], 0x6c000000 bytes flags: 0
memory[2] [0x880000000-0x97fffffff], 0x100000000 bytes flags: 0
reserved.cnt = 0x2 / max = 0x10
reserved[0] [0x85210ba0-0x87ffffff], 0x02def460 bytes flags: 0
reserved[1] [0x90000000-0x91ffffff], 0x02000000 bytes flags: 4
devicetree = separate
arch_number = 0x0000000000000000
TLB addr = 0x0000000087f50000
irq_sp = 0x0000000085215200
sp start = 0x0000000085215200
Early malloc usage: 28e0 / 8000

--- Kernel info ---

root@imx8qmmek:~# uname -a
Linux imx8qmmek 6.6.52-lts-next-ge0f9e2afd4cf #1 SMP PREEMPT Tue Nov 19 23:01:49 UTC 2024 aarch64 GNU/Linux

[ChrisC05 · Accepted solution]

Okay, I found a solution which works for me.

(assume root folder is the cloned git repo - so the parent folder of build-<board>)

I modified the following 3 files to force Yocto to build the image using "flash_spl" instead of "flash_linux_m4", as defined in soc.mak in both the imx-mkimage tool and in ./build-<board>/tmp/deploy/images/<board>/imx-boot-tools/soc.mak:

in ./sources/meta-freescale/recipes-bsp/imx-mkimage/imx-boot_1.0.bb - change line 230 from flash_linux_m4 to flash_spl

in ./sources/meta-imx/meta-imx-bsp/recipes-bsp/imx-mkimage/imx-boot_1.0.bb - change line 230 from flash_linux_m4 to flash_spl

in ./sources/meta-imx/meta-imx-bsp/conf/layer.conf - change line 308 from flash_linux_m4 to flash_spl

After rebuilding the image in bitbake, flash the newly generated .wic file to an SD card. Verify if the boot-imx symlink in ./build-<board>/deploy/images/<board> points to a file ending in flash_spl.

Then, in U-boot, make sure that the environment variable fdt_file=<board>.dtb so not <board>-rpmesg.dtb, since this causes strange bootloops.

After booting in the kernel, check whether rpmsg_char and rpmsg_ctrl are loaded using $ lsmod
If they are not loaded, you can either load them manually using insmod or modprobe, or you can load them on boot using files like /etc/rc.local

As a final check, you can call $ cat /sys/class/remoteproc/remoteproc?/state to verify if the remote cores are offline.

Following these steps allowed me to finally load my own .elf files to the remote cores, without shutting off the device.

[Chavira]

Hi @ChrisC05!

Thank you for contacting NXP Support!

I am not having the same issues by my side!

That are my log file.

root@imx8qmmek:~# cat  /sys/class/remoteproc/remoteproc0/state
offline
root@imx8qmmek:~# echo -n /lib/firmware/imx8qx_m4_TCM_hello_world.elf > /sys/class/remoteproc/remoteproc0/firmware
root@imx8qmmek:~# echo start > /sys/class/remoteproc/remoteproc0/state
[   48.826504] remoteproc remoteproc0: powering up imx-rproc
[   48.832113] remoteproc remoteproc0: Direct firmware load for /lib/firmware/imx8qx_m4_TCM_hello_world.elf failed with error -2
[   48.843484] remoteproc remoteproc0: Falling back to sysfs fallback for: /lib/firmware/imx8qx_m4_TCM_hello_world.elf
[   48.857911] remoteproc remoteproc0: Booting fw image /lib/firmware/imx8qx_m4_TCM_hello_world.elf, size 170108
[   48.868149] remoteproc remoteproc0: remote processor imx-rproc is now up
root@imx8qmmek:~# echo stop > /sys/class/remoteproc/remoteproc0/state
[   55.686720] remoteproc remoteproc0: stopped remote processor imx-rproc
root@imx8qmmek:~# echo start > /sys/class/remoteproc/remoteproc0/state
[   57.262522] remoteproc remoteproc0: powering up imx-rproc
[   57.268094] remoteproc remoteproc0: Direct firmware load for /lib/firmware/imx8qx_m4_TCM_hello_world.elf failed with error -2
[   57.279475] remoteproc remoteproc0: Falling back to sysfs fallback for: /lib/firmware/imx8qx_m4_TCM_hello_world.elf
[   57.291340] remoteproc remoteproc0: Booting fw image /lib/firmware/imx8qx_m4_TCM_hello_world.elf, size 170108
[   57.301833] remoteproc remoteproc0: remote processor imx-rproc is now up
root@imx8qmmek:~# echo stop > /sys/class/remoteproc/remoteproc0/state
[   58.654715] remoteproc remoteproc0: stopped remote processor imx-rproc
root@imx8qmmek:~# echo start > /sys/class/remoteproc/remoteproc0/state
[   62.362524] remoteproc remoteproc0: powering up imx-rproc
[   62.368089] remoteproc remoteproc0: Direct firmware load for /lib/firmware/imx8qx_m4_TCM_hello_world.elf failed with error -2
[   62.380199] remoteproc remoteproc0: Falling back to sysfs fallback for: /lib/firmware/imx8qx_m4_TCM_hello_world.elf
[   62.391978] remoteproc remoteproc0: Booting fw image /lib/firmware/imx8qx_m4_TCM_hello_world.elf, size 170108
[   62.402415] remoteproc remoteproc0: remote processor imx-rproc is now up
root@imx8qmmek:~# echo stop > /sys/class/remoteproc/remoteproc0/state
[   63.854715] remoteproc remoteproc0: stopped remote processor imx-rproc
root@imx8qmmek:~# echo start > /sys/class/remoteproc/remoteproc0/state
[   71.054540] remoteproc remoteproc0: powering up imx-rproc
[   71.060119] remoteproc remoteproc0: Direct firmware load for /lib/firmware/imx8qx_m4_TCM_hello_world.elf failed with error -2
[   71.071486] remoteproc remoteproc0: Falling back to sysfs fallback for: /lib/firmware/imx8qx_m4_TCM_hello_world.elf
[   71.083307] remoteproc remoteproc0: Booting fw image /lib/firmware/imx8qx_m4_TCM_hello_world.elf, size 170108
[   71.093741] remoteproc remoteproc0: remote processor imx-rproc is now up
root@imx8qmmek:~# echo stop > /sys/class/remoteproc/remoteproc0/state
[   72.106732] remoteproc remoteproc0: stopped remote processor imx-rproc
root@imx8qmmek:~# dmesg | grep rproc
[    3.138247] remoteproc remoteproc0: imx-rproc is available
[   13.009374] remoteproc remoteproc1: imx-dsp-rproc is available
[   48.826504] remoteproc remoteproc0: powering up imx-rproc
[   48.868149] remoteproc remoteproc0: remote processor imx-rproc is now up
[   55.686720] remoteproc remoteproc0: stopped remote processor imx-rproc
[   57.262522] remoteproc remoteproc0: powering up imx-rproc
[   57.301833] remoteproc remoteproc0: remote processor imx-rproc is now up
[   58.654715] remoteproc remoteproc0: stopped remote processor imx-rproc
[   62.362524] remoteproc remoteproc0: powering up imx-rproc
[   62.402415] remoteproc remoteproc0: remote processor imx-rproc is now up
[   63.854715] remoteproc remoteproc0: stopped remote processor imx-rproc
[   71.054540] remoteproc remoteproc0: powering up imx-rproc
[   71.093741] remoteproc remoteproc0: remote processor imx-rproc is now up
[   72.106732] remoteproc remoteproc0: stopped remote processor imx-rproc
root@imx8qmmek:~# uname -a
Linux imx8qmmek 6.6.52-lts-next-ge0f9e2afd4cf #1 SMP PREEMPT Tue Nov 19 23:01:49 UTC 2024 aarch64 GNU/Linux
root@imx8qmmek:~#

I am using the hello_world.bin in u-boot and using the hello_world.elf in Linux.

Can you try again?

Are you compiling for TCM?

Can you share your project/binary that are you using?

Best Regards!

Chavira

[ChrisC05]

Hello @Chavira 

After a more thorough investigation it seems like my Yocto build automatically bakes the "Power mode task" into the final boot-imx binary after running bitbake imx-image-core, which is then eventually flashed to an SD card. This pretty much exhibits the same behaviour as if I were to use imx-mkimage tool to make a flash.bin containing the firmware for an M4 core and flash this bin to the SD card (following the instructions mentioned in MCUXpresso ch 6.1).

Perhaps the better question on my end is to ask how I can let the M4 cores boot without also flashing firmware to them before U-boot is loaded, so hopefully the kernel can take ownership of the cores instead of attaching to them.

Anyway, I tried again with exactly the same results. As far as I know, I am compiling for TCM and not for DDR or anything of the sorts.

I am using Yocto 5.0 (scarthgap) to create a .wic image that is flashed to an SD card, from which the board boots. To build the bootable image, I did the following steps:

1. Cloned the following repo and synced it

repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-scarthgap -m imx-6.6.36-2.1.0.xml

2. Set up the build environment as follows:

MACHINE=imx8qmmek DISTRO=fsl-imx-wayland source ./imx-setup-release.sh -b build-imx8qmmek

3. built core image

bitbake imx-image-core

4. built SDK for this core image

bitbake -c populate_sdk imx-image-core

The .wic image is too large to attach however I will attach the project that I intend to load to the cores instead.