M4 Hello World on Aster / iMX7D not working

Hello there,

I’m trying to get something up and running on the M4 with my iMX7D+Aster carrier. The examples compile after updating to a newer toolchain (Toradex document is outdated), but still won’t run from uBoot 2019.07. I’m expecting the output to be on UART_B (X20.8 & X20.10) but there is no signal present.

I’ve looked at this uBoot patch Error while loading M4 Code in iMX7 - Toradex Community, but does that apply to this situation? I’m not running DDR or OCRAM example so this is TCM, right?

Could Toradex please improve their instructions for the correct ARM GCC toolchain and correct FreeRTOS repo?

Hi @lkoziarz and Welcome to the Toradex Community!

Could you provide the Software version of your module?

The examples compile after updating to a newer toolchain (Toradex document is outdated),

Which example did you mean?

Could Toradex please improve their instructions for the correct ARM GCC toolchain and correct FreeRTOS repo?

Which repo did you use?

Best regards,
Jaski

Hello Jaski,

I’m using the repo from https://github.com/toradex/FreeRTOS-Colibri-iMX7.git so I apologize - the documentation is correct on that aspect.

As for software version of the module - this is U-Boot 2019.07-0+ge1cbe8c74e, built from the b2qt yocto recipe (Qt for Devices v5.15.0 / Commercial license). The iMX7D is mask rev 1.3. Colibri is iMX7 Dual 1GB (eMMC) V1.1A.

At this point I’m only trying to compile the example at ./FreeRTOS-Colibri-iMX7/examples/imx7_colibri_m4/demo_apps/hello_world.

Using the ARM GCC toolchain (gcc-arm-none-eabi-9-2020-q2-update), I get a finished hello_world.elf that looks to be in the correct format (hello_world.elf: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, with debug_info, not stripped)

This is copied into the second partition of my SD card, the system is restarted into uBoot, and then loaded into memory using “fatload mmc 1:1 0x80800000 hello_world.elf”. Running “bootaux 0x80800000” responds with “Starting auxillary core at 0x80800000” and then does nothing at the UART_B pins.

Hi @lkoziarz!

Can you check the UART_B pins with an oscilloscope or logic analyzer?

Also, can you try loading the .elf to memory with fatload mmc 1:1 ${loadaddr} hello_world.elf and then running bootaux ${loadaddr}? The default load address might be different from what you’re using.

I had a USB scope on Aster X20.8 and X20.10, no signal at all. I will try one more time to verify this.

The loadaddr in my default uboot environment at the point of executing fatload is 0x80800000, I just expanded that variable for the sake of the ticket.

Checked again. No traffic on these pins.

Hi @lkoziarz!

I’ll try to reproduce that here and let you know my results.

@lkoziarz,

I was able to get the hello world demo working with output on UART_B on U-Boot 2019.07.

I’ve uploaded the M4 binary I used here: https://share.toradex.com/73kn24j5xk3esat.
Can you please try that?

Hello Gustavo.

I have a second SOM so I’ve been able to swap back and forth between two versions of UBoot and it looks like that is the source of the problem.

SOM A is untouched from Toradex and has U-Boot version 2016.11-1.8.0+g07edca0bb8. It runs your ELF binary and I get output on Aster.

SOM B is from my boot2qt build and has version 2019.07-0+ge1cbe8c74e. It does not produce output on Aster with your image.

Here’s the comparison of the two bootloaders:

U-Boot 2016.11-1.8.0+g07edca0bb8 (Oct 19 2018 - 13:34:00 +0000)
CPU:   Freescale i.MX7D rev1.3 996 MHz (running at 792 MHz)
CPU:   Extended Commercial temperature grade (-20C to 105C) at 41C
Reset cause: POR
DRAM:  1 GiB
PMIC:  RN5T567 LSIVER=0x01 OTPVER=0x0d
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
Using default environment

In:    serial
Out:   serial
Err:   serial
Model: Toradex Colibri iMX7 Dual 1GB (eMMC) V1.1A, Serial# 06514985
Net:   FEC0
Hit any key to stop autoboot:  0

Colibri iMX7 # fatload mmc 1:1 ${loadaddr} toradex_hello_world.elf
Colibri iMX7 # dcache off
Colibri iMX7 # bootaux ${loadaddr}
## Starting auxiliary core at 0x1FFF80BD

And here’s SOM B with the other bootloader:

U-Boot 2019.07-0+ge1cbe8c74e (Dec 16 2019 - 10:56:52 +0000)

CPU:   Freescale i.MX7D rev1.3 1000 MHz (running at 792 MHz)
CPU:   Extended Commercial temperature grade (-20C to 105C) at 27C
Reset cause: POR
DRAM:  1 GiB
PMIC:  RN5T567 LSIVER=0x01 OTPVER=0x0d
MMC:   FSL_SDHC: 1, FSL_SDHC: 0
Loading Environment from MMC... OK
In:    serial
Out:   serial
Err:   serial
Model: Toradex Colibri iMX7 Dual 1GB (eMMC) V1.1A, Serial# 06514944

Colibri iMX7 # fatload mmc 1:1 ${loadaddr} toradex_hello_world.elf
191904 bytes read in 34 ms (5.4 MiB/s)
Colibri iMX7 # dcache off
Colibri iMX7 # bootaux ${loadaddr}
## Starting auxiliary core at 0x80800000 ...

So it appears that the newer UBoot has a problem with bootaux. It’s not relocating the code. I’m going to look into what commit the boot2qt build is using and why. Adding this link again, although now it doesn’t seem related:

https://www.toradex.com/community/questions/50102/error-while-loading-m4-code-in-imx7.html
.

Hi @lkoziarz!

Glad you found the issue.

We’re using U-Boot 2019.07 on Torizon - that’s the image I used to test this on my Colibri iMX7. Perhaps you can check on the Torizon Yocto layers which commit is used and compare that to the one used by Boot2Qt. Also, might be useful to compare the configurations (as in the defconfig) in both cases.

Hello Gustavo,

I’m not that familiar with the Torizon repo, would you happen to know where that uboot commit is stored?

I’m also seeing more recent commits to uboot beyond 2019.07 that seem to help M4 booting. I might just pull up to the latest.

https://gitlab.denx.de/u-boot/u-boot/-/commit/c0f037f6a2ae2cb869a350534cef9771358fabcf

I’ll update when I try this out.

Thanks,
Louis

@lkoziarz,

Actually you can find the U-Boot sources we’re using for both our regular BSP and Torizon here: http://git.toradex.com/cgit/u-boot-toradex.git/?h=toradex_2019.07

I’ve already linked to our 2019.07 branch, you might use that as a starting point for a comparison with what you have.

Thanks, I’ll take a look. My current b2qt Yocto build seems to be pulling from Denx’s repo and not Toradex’s.

hi @lkoziarz

Is your issue solved now?

Best regards,
Jaski

Haven’t been able to integrate the newer uboot into my Yocto image recipe yet but should be able to try it soon.
Thanks. (FYI this will affect anyone using the Qt for Device Creation distro for Colibri so maybe it should get updated globally?)

Thanks for the feedback. Which version of Boot2Qt are you using?

Zeus with the Qt v5.15.0 manifest.

Thanks for your feedback. I will let check this by the responsible person.

Best regards,
Jaski