Re: Using the Cortex M4 on IMX7D

Michael Graichen

Am 26.02.21 um 18:06 schrieb Arnaud POULIQUEN:

-----Original Message-----
From: Kumar Gala <>
Sent: vendredi 26 février 2021 17:27
To: Michael Graichen <>
Subject: Re: [Zephyr-users] Using the Cortex M4 on IMX7D

On Feb 26, 2021, at 3:43 AM, Michael Graichen
<> wrote:


I have just started working on a IMX7D
factors/smarc/smarc-samx7.html) together with Zephyr I noticed that the
Colibri iMX7 Board has support for the Cortex M4.
So I've build an example by using:

cmake -GNinja -DBOARD=colibri_imx7d_m4 ../samples/basic/blinky

and tried to load that on the Cortex M4

echo -n zephyr.elf > /sys/class/remoteproc/remoteproc0/firmware
echo -n start > /sys/class/remoteproc/remoteproc0/state

Unfortunatly the start fails because the elf-file has no resource table.
I can select TOP ---> Additional libraries ---> [*] coprocessor
resource table within menuconfig but the resulting elf-file is still missing the
resource table.

What am i missing? How can a add a resource table to the elf-file?
The Linux remoteproc framework allows you to load a firmware without a resource table.
The resource table is useful only if you want to use the RPMsg protocol or a trace buffer.
So this should work, except if the IMX platform driver doesn't allow this....

best regards

I don’t believe the remoteproc loading was ever supported for the imx family
with zephyr. This is something you’d need to add support for. I think it might
be supported on the STM32 MP1 as an example. (I added Arnaud on CC as he
added the STM32 MP1 support).
Right, I think today only the stm32mp1 support the resource table in zephyr, but this should be enough generic to
be supported by another platform.
Anyway if you don't want to use RPMsg, probably better as a first step to understand why you
can not load a firmware without resource table.

For the I think you can load via u-boot and there’s a section in the zephyr
board docs here about it:

- k

Hey Arnaud,

Thanks for your reply.

I've seen that stm32_rproc driver has additionally functions within static const struct rproc_ops st_rproc_ops

.parse_fw = stm32_rproc_parse_fw,

within the plain rproc driver

rproc->ops->parse_fw = rproc_elf_load_rsc_table

is registerd within "static int rproc_alloc_ops()"

and is called by doing the "echo start" command.

but fails after the find_table() function.

so if i just skip that for a test in, does that take me over the point?
I can not see the code where rproc actually "loads" the firmware to the M4?

best regards and a great weekend

Join to automatically receive all group messages.