Cortex-M binary update OTA

Technical Support
, , ,
1

Hello! I am using the TorizonCore Builder to create a custom Torizon OS 6.8.1 for the Verdin iMX8M-Plus.

I want to add the binary of the M7, so that it can be deployed with an OS update.

I don’t want to use the M7 update using RemoteProc, because the boot time is slower when using that method.

2

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

Did you like my answer?

:+1: :-1:

Hello!

To include a Cortex-M7 binary in your custom TorizonCore OS image for the Verdin iMX8M-Plus, you can follow these steps:

  1. Storing the Binary in the Filesystem:

    • Store the Cortex-M7 binary in a directory within the root filesystem that is accessible during the boot process. A common choice is /lib/firmware or a custom directory like /opt/firmware. This ensures the binary is included in the OS image and accessible by U-Boot.

  2. Configuring U-Boot to Load the Binary:

    • Use the ext4load command in U-Boot to load the binary from the eMMC. Specify the partition and path to the binary. For example:
      ext4load mmc 0:1 0x7e0000 /lib/firmware/your_m7_binary.bin
      Here, mmc 0:1 refers to the first partition of the eMMC, 0x7e0000 is the memory address for loading, and /lib/firmware/your_m7_binary.bin is the path to your binary.

  3. Avoiding RemoteProc:

    • Since you prefer not to use RemoteProc, configure your U-Boot environment to load and execute the binary directly. Set up the appropriate boot commands in U-Boot to load the binary into memory and start execution.

  4. Testing and Validation:

    • Test the boot process to ensure the Cortex-M7 binary is correctly loaded and executed. Adjust memory addresses and paths as needed based on your setup.

By following these steps, you can integrate the Cortex-M7 binary into your TorizonCore OS image and manage its deployment through OS updates, while maintaining efficient boot times.

Best regards,
Toradex AI Assistant.

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

How to flash uboot and kernel image into emmc- Verdin IMX8MP.

3

Greetings @i.staehli,

How do I know where the folders are located from an U-Boot point of view, as described in

I’ll address this part first since it’s straightforward. You basically would just use ext4ls mmc 2:1 to navigate the filesystem from U-Boot. As the article shows /var would correspond to /ostree/deploy/torizon/var/ in U-Boot. Though most other filesystem locations would be in /ostree/boot.1/torizon/<some hash>/0/, as I will show below.

What location should I use to store the binary using the filesystem changes?

From the sounds of it you want to store the M7 binary on the OS filesystem so that it can be updated as part of a OS update, is that correct?

If that is the case you don’t want this in /var. The /var directory is a special directory that is not tracked by OSTree, meaning it can’t be updated. This is by design to have a persistent location that is not affected by updates.

Typically the usual location for filesystem changes would be in /etc. Though this does pose another challenge. The path for /etc from U-Boot’s point of view is not so straightforward. For example on my device, from U-Boot the path would be: ostree/boot.1/torizon/aaeaee85433c423a8386667f25a9c812d2f4bd3f9e4eebc067895183f81570cf/0/etc/

The challenge here is that the hash part of the path: aaeaee85433c423a8386667f25a9c812d2f4bd3f9e4eebc067895183f81570cf

This hash changes whenever the OSTree deployment changes, which happens on every OS update. Meaning it would not be very consistent to set this path in U-Boot.

Probably a better alternative would be to use what we call “subsystem updates”. With this you can define the parameters and logic for an update. In this way you can specifically update only your specific M7 binary file without updating the rest of the OS/filesystem as well. You can even update/change directories that OSTree does not manage itself (like /var).

We actually have a webinar showing how one can use subsystem updates to manage and update M-core binaries/firmware: https://www.youtube.com/watch?v=djXt6HaI1jY

The demo in that webinar uses remoteproc, but the same principles would apply even if you aren’t using remoteproc. In theory you would just create a subsystem update that copies the new M7 binary to a known consistent location on the filesystem (i.e /var which is always /ostree/deploy/torizon/var/ from the U-Boot point of view). Then you would just need reboot the system to reload the new binary.

Furthermore, you can design whatever further logic or checks you want to occur during the update for further control. You could even designate your own rollback/failure logic if you want.

Best Regards,
Jeremias

1 Like