Documentation update for "FreeRTOS on the Cortex-M4 of a Verdin iMX8M Mini"

In section Connection between Verdin Development Board and PC I read

via a single USB micro-B connector (X66)

But my Development Board V1.1 has a USB-C connector, as described by the datasheet.
Probably the old Development Board V1.0 had a USB micro-B connector, but now the documentation needs an update.

One more question:
is the section Run The Examples from U-Boot up to date?
I mean, when it states

Currently U-Boot does not support loading .elf files.

Thanks in advance.

I try to give other suggestions on how to improve the documentation (based on the doubts/issues I had when I tried to follow it for the first time):
Improve the section Connection between Verdin Development Board and PC adding a link to this KB - Configuring Serial Port Debug Console (Linux/U-Boot).
I think it’s useful because it describes what the /dev/ttyUSBx are and it gives a link on a document that describes how to setup a terminal.

Moreover, specify which example (DDR, FLASH or RAM) must be used together with the instruction provided here.
Since I see

Verdin iMX8MM # setenv m4addr 0x7e0000

I suppose it’s the RAM example (i.e. TCML), but fell free to correct me if I’m wring.

Hi @vix !

Thanks a lot for all the feedback!

You are right! We will correct the article. Thanks :slight_smile:

To be fair, I just overviewed the Getting Started with MCUXpresso SDK for EVK-MIMX8MM.pdf (from Verdin iMX8M Mini’s MCUXpresso) again and I didn’t find there a statement explicitly saying that .elf shouldn’t be used in U-Boot. Seems to be a U-Boot limitation (and looking at its code, really seems like .elf - specifically ELF64 - is not supported for iMX8).

Certainly a good improvement. We will update it. Thanks!

Also right :dart:. We can check it with the Getting Started with MCUXpresso SDK for EVK-MIMX8MM.pdf. We will improve it as well.

All feedbacks are most welcome.

Have a nice day!

Best regards,

Hi @henrique.tx
thanks a lot to you.

I see you posted a link to the toradex U-Boot.
Not sure if this is a fork from the original U-Boot, but when I look to Freescal/u-boot I see a different file layout.
In imx_bootaux.c there is

and it seems elf is supported.

Can you clarify a little bit this point, please?

Hi @vix !

The U-Boot that is used in Toradex’s layers (talking about Yocto here) is from Toradex’s git, not directly from NXP/Freescale.

You can actually check it by taking a look at U-Boot’s recipe that is fetched on Toradex’s layers.

Does it help to clarify you?

Best regards,

I supposed this was the situation.
I wonder if Toradex can merge the NXP/Freescale upstream U-Boot.
As far as I understand, NXP (who is the device manufacturer) is the first actor who is in charge to develop adn functionalities to the U-Boot for a given device.
For the end user perspective, the best scenario is when the SoM manufacturer (Toradex in this case) merge all the available features from the upstream.

Do you see any problems in doing this?

Hi @vix !

Actually, Toradex contributes to the upstream repository.

You can actually see it in the file referred on your message: imx: bootaux fix elf loading · Freescale/u-boot-fslc@31cf6b4 · GitHub

At some point, NXP would merge it, and then we would merge it back to our repository.

Best regards,

I can see that Toradex contributes to the upstream repository and this is great!
But I think there is a misunderstanding on the concept of “NXP would merge it”.
The commit from Toradex team is on branch 2021.04+fslc which is the default branch (as you can see here).
At the moment (March 2022) the only other active branch is 2022.01+fslc.
All the other branches are stale.

The problem is that U-Boot’s recipe that is fetched on Toradex’s layers
refers to 2020.04 and 2020.07 that (looking to the source files) seems to refer to the stale branches 2020.04+fslc and 2020.07+fslc.

I think no more merges by NXP on this stale branch.
I think that Toradex should include branch 2021.04+fslc in its Yocto recipe (since Toradex team has already contributed to it).

Does this sounds good to you?

Toradex must make some choices to keep the best compatibility (and maintainability) possible among all active modules. One of those choices is to stick to a U-Boot version for a BSP major version.

The U-Boot is chosen based on interesting features that are suitable for the next BSP (and U-Boot is an important part of the BSP).

Sticking to a given U-Boot version makes the monthly and quarterly releases updates to be smoother and without breaking things unnecessarily. Also, there is a lot of work (maintenance and tests) to keep it working as well as possible

Nonetheless, you can always use the U-Boot version that you need. But doing so will face limited support from Toradex.

Best regards,