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.
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.
You are right! We will correct the article. Thanks
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 . We can check it with the Getting Started with MCUXpresso SDK for EVK-MIMX8MM.pdf. We will improve it as well.
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
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.
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.
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).
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.