Verdin AM62 remoteproc bad phdr

[Jens0501]

Hello,

I am working with the verdin AM62 on a custom carrier board. I would like to use the cortex M4 processor to run real time applications like SPI,… To start I just wanted to load the hello_world example from the TI SDK.

I have followed the following links for building the file:
https://dev.ti.com/tirex/explore/node?node=A__AfYgbWBIjChq3Hqi.DeMuA__AM62-ACADEMY__uiYMDcq__LATEST

I was able to compile the project and it generated the hello_world.release.out file (not a .elf, but does a .out file work as well?). I put this file on the verdin AM62, used the remoteproc driver to load and start the M4 core, but here something goes wrong. When I look at dmesg, I see the following error:

[  341.790825] remoteproc remoteproc0: powering up 30074000.pru
[  341.796873] remoteproc remoteproc0: Booting fw image hello_world.release.out, size 279376
[  341.796928] remoteproc remoteproc0: bad phdr da 0x8200 mem 0x5380
[  341.803033] remoteproc remoteproc0: Failed to load program segments: -22
[  341.810209] remoteproc remoteproc0: Boot failed: -22

Am I missing something? I made no changes in the code or in the device tree. I am using Torizon OS.

[ToradexAI]

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

---

The error message you’re encountering, “bad phdr da 0x8200 mem 0x5380,” suggests that there is an issue with the program header in the firmware file you’re trying to load. The .out file format is typically used by TI’s tools and may not be directly compatible with the RemoteProc framework, which expects an ELF file format.

Here are a few steps you can take to resolve this issue:

1. Convert the .out file to an ELF file: Use TI’s tools to convert the .out file to an ELF file. The RemoteProc framework expects an ELF file, which contains the necessary program headers for loading the firmware correctly.

2. Check the Firmware Path: Ensure that the firmware file is placed in a location that is accessible by the RemoteProc framework. Since Torizon OS has a read-only filesystem, you might need to place the firmware in a writable location like /tmp/ and update the path accordingly.

3. Verify Device Tree Overlays: Make sure that the correct device tree overlays are enabled for the M4 core. This can be done by checking the overlays.txt file and ensuring the appropriate overlay is listed.

4. Check Compatibility: Ensure that the firmware is compatible with the specific version of the RemoteProc driver and the hardware configuration of the Verdin AM62.

If these steps do not resolve the issue, you may need to consult additional resources or support from TI or Toradex to ensure compatibility and correct configuration.

Please, also check if these links can help you solve your problem:

Use remoteproc to start M7 core on Verdin iMX8M-Plus

In the past few months I’ve been able to start M7 coreof Verdin iMX8M-Plus (or Mini) loading the firmware and running it from u-boot. The following topics: Embed M7 firmware in TorizonCore and load it automatically on Verdin iMX8M-Mini RPMSG on TorizonCore 6 with Verdin iMX8M-Mini The help from @hfranco.tx was great! At that time (summer 2023) the only reliable solution was from u-boot because remoteproc from TorizonOS was non 100% reliable. Last week I talked to @stefano.tx and he told me…

No Output on UART-B After Flashing hello_world.elf to Cortex-M on Colibri iMX7

Hello Toradex Community, I am experiencing challenges with displaying output via UART-B after flashing a hello_world.elf example to the Cortex-M4 of a Colibri iMX7 module using a Colibri Evaluation Board V.3.2b. Below are the details of my setup and the steps I’ve followed: Setup: Host Machine: MacBook M2 Target: Colibri iMX7 on Colibri Evaluation Board V.3.2b Connections: UART-A: Connected via USB-B to USB-A cable, plugged into the X27 connector. Output to the console is visible here. UART…

Boot MCU from U-Boot on AM62X.

[Jens0501]

1. I changed the Makefile so that it outputs an ELF file, still the same error
2. I followed the toradex ‘how-to-use-remoteproc’ guide and used the following command to adjsut the filepath

echo -n new_path > /sys/module/firmware_class/parameters/path  

3. I did not change anything in the overlays, but this is the m4 part of the active device tree. Is it correct?

			m4fss@5000000 {
				compatible = "ti,am64-m4fss";
				reg = <0x00 0x5000000 0x00 0x30000 0x00 0x5040000 0x00 0x10000>;
				reg-names = "iram\0dram";
				ti,sci = <0x06>;
				ti,sci-dev-id = <0x09>;
				ti,sci-proc-ids = <0x18 0xff>;
				resets = <0x0d 0x09 0x01>;
				firmware-name = "am62-mcu-m4f0_0-fw";
				wakeup-source;
				phandle = <0x7c>;
			};

4. I should be using the latest firmware of everything

[lucas_az.tx]

Hi @Jens0501!

I already ran the hello_world example on Cortex M4 of Verdin AM62 and it can be very tricky.

You can use hello_world.release.out as Cortex M4 firmware.

In order to validate it, you must change your device tree overlay for the verdin-am62_hmp_overlay.dts (if you didn’t do it, please follow this article). After this, you can copy hello_world.release.out to /lib/firmware. You probably won’t have permission to do that (if you are using Torizon OS), because /usr is a read-only directory, so you must do the following:

sudo mount -o remount,rw /usr
sudo mv /path-to-file/hello_world.release.out /lib/firmware/am62-mcu-m4f0_0-fw
sudo reboot

Then, after it boots, you’ll see Hello World! on Cortex M4 terminal.

I strongly recommend following this way, at least for validation purposes, because, in my opinion, this is the easiest way. After you validate it, you can start to customize the paths and file names.

Best regards.
Lucas Azeituno

[Jens0501]

Hi Lucas,

After my initial post I did indeed use the overlay that you’ve also mentioned, but this did not change anything at that moment.

I copied the firmware to the location like you suggested (I am indeed using Torizon OS). Looking at dmesg it appears that the firmware is loaded correctly:

[    7.931432] k3-m4-rproc 5000000.m4fss: assigned reserved memory node m4f-dma-memory@9cb00000
[    7.931832] k3-m4-rproc 5000000.m4fss: configured M4 for remoteproc mode
[    7.952856] k3-m4-rproc 5000000.m4fss: local reset is deasserted for device
[    7.962731] remoteproc remoteproc0: 5000000.m4fss is available
[    7.969084] remoteproc remoteproc0: powering up 5000000.m4fss
[    7.969131] remoteproc remoteproc0: Booting fw image am62-mcu-m4f0_0-fw, size 266704

However, I do not see any output on the M4 terminal yet. I will check if there is maybe a conflict with UART0 somewhere, altough I disabled it in the devicetree.

Also: when I try to run it via remoteproc after the system is rebooted, it fails loading the firmware:

[  279.712137] remoteproc remoteproc0: powering up 5000000.m4fss
[  279.712878] remoteproc remoteproc0: Booting fw image am62-mcu-m4f0_0-fw, size 266704
[  279.713288] remoteproc remoteproc0: Boot failed: -22

best regards

[lucas_az.tx]

Hi @Jens0501!

The overlay does not do anything “visible” but reserves the memory that rproc assigns for cortex M4.

Could you please detail the steps you took to build the hello_world example? Also, what board did you select to build (in TI’s MCU), and did you have to make changes on SysConfig?

Best regards.
Lucas Azeituno.

[Jens0501]

Hi Lucas,

The thing about the overlay was meant to say that I had tested the firmware again after applying the overlay, but the errors persisted

For building the example, I followed the exact steps in the following link:

GitHub - TexasInstruments/mcupsdk-core-k3: TI MCU+ SDK core source code repository with...

I downloaded the SDK for the AM62x devices, installed all dependencies and libraries and finally I build the example via the make command.
I did not change anything in the sysconfig and I build the example under the folders …/am62x-sk/m4fss0-0_nortos/

Today I tried building the RPMSG example and this worked almost. The firmware was loaded correctly, the core was started and the M4 terminal showed an output. I am just not able to send an echo from linux to the M4 via /dev/rpmsg0. There is no error, but nothing gets received by the M4. This makes me believe that the hello-world example is missing the resource-table or something related. I need to compare both examples to figure it out

Best regards

[lucas_az.tx]

Hi @Jens0501!

I think I found the problem. I checked the SysConfig for m4fss0-0_nortos and I saw that IPC was not enabled, and it must be enabled because it is responsible for the inter-processor communication (as its name suggests).

Although, if you just enable it in SysConfig, you will get a memory space error. To bypass it, you can go to the IPC tab on SysConfig and reduce the number and the size of RPMessage buffers (as far as I tested, 64 buffers of 64 bytes should be reduced enough to bypass the error).

After that, you can deploy the firmware to the module and load it as I explained before, and you should see the “Hello World!” on Cortex M4 terminal.

[lucas_az.tx]

Hi @Jens0501!

I just realized that, for some reason, the module is rebooting when I use m4fss0-0_nortos, but I tried m4fss0-0_freertos with the same SysConfig and it worked.

So, for validation purposes, I think you can use m4fss0-0_freertos.

Best regards.
Lucas Azeituno

[Jens0501]

Hi Lucas,

I tried your SysConfig modification on both the freertos and nortos firmware and I can confirm that for me both of these are working as expected now!

Now that this is validated, I can start developing the application on the M4. The goal is to use the M4 to read an SPI interface and simultaneously write these measurements to a shared memory so Linux can access it. Do you know of any other ‘tricks’ or things I should keep in mind with the TI environment and the AM62 module?

Thanks for your help.
Jens

[lucas_az.tx]

Hi @Jens0501!

I’m glad to know that it is working!

About TI’s environment, I would say that it is good to start from their examples.

I verified and they have an SPI example in /path-to-mcu/examples/drivers/mcspi, you could start from there and then try to reproduce your own. I did something similar when I was working with CAN communication using Cortex M4.

Another important point is to always check SysConfig, it is the base of TI’s environment and sometimes a simple configuration can change everything in the project.

If you have any other doubts or issues, please feel free to open another topic.

Best regards.
Lucas Azeituno.