imx8mm-lpddr4-evk broken since Kirkstone

[richardweinberger]

The following commit breaks the imx8mm-lpddr4-evk board:
9e409a0

I tried to get said board boot with a recent Yocto but it always stopped right after the SPL:

U-Boot SPL 2022.10+fslc+gcbd7eb17ac+p0 (Dec 13 2022 - 00:42:37 +0000)
No pmic
SEC0:  RNG instantiated
Normal Boot
WDT:   Started watchdog@30280000 with servicing (60s timeout)
Trying to boot from MMC1
NOTICE:  BL31: v2.6(release):automotive-13.0.0_1.1.0-0-g3c1583ba0-dirty
NOTICE:  BL31: Built : 11:00:38, Nov 21 2022

First I narrowed it down to a breakage between Yocto Honister and Kirkstone.
Bitsecting brought me to commit 9e409a0. Reverting this commit makes the board
boot again.

My build configuration (KAS):

header:
  version: 11
machine: imx8mm-lpddr4-evk
distro: poky
target: core-image-minimal
repos:
  poky:
    url: "https://git.yoctoproject.org/poky"
    refspec: kirkstone
    layers:
      meta:
      meta-poky:
      meta-yocto-bsp:
  meta-openembedded:
    url: "git://git.openembedded.org/meta-openembedded"
    refspec: kirkstone
    layers:
      meta-oe:
  meta-freescale:
    layers:
      meta-freescale:
local_conf_header:
  evk: |
    IMX_DEFAULT_BSP = "nxp"
    ACCEPT_FSL_EULA = "1"
    CORE_IMAGE_EXTRA_INSTALL += "optee-os"
    IMAGE_FEATURES += "empty-root-password allow-empty-password ssh-server-openssh"
    DISTRO_FEATURES += "optee"

@otavio

[otavio]

You can try to test using the NXP BSP and forcing it to use the U-Boot imx bootloader.

[richardweinberger]

You can try to test using the NXP BSP and forcing it to use the U-Boot imx bootloader.

So, yes adding IMX_DEFAULT_BOOTLOADER = "u-boot-imx" to my local.conf makes the board boot again.

[otavio]

@fabioestevam, is it possible for you to take a look at this? I think the U-Boot mainline is broken, so if you could take a look at the bootloader side, that would be very helpful.

[richardweinberger]

@fabioestevam, is it possible for you to take a look at this? I think the U-Boot mainline is broken, so if you could take a look at the bootloader side, that would be very helpful.

Maybe it's related to OP-TEE?

[richardweinberger]

@fabioestevam, is it possible for you to take a look at this? I think the U-Boot mainline is broken, so if you could take a look at the bootloader side, that would be very helpful.

Maybe it's related to OP-TEE?

Without OP-TEE uboot-fslc works better. MACHINE_FEATURES:remove = "optee"

U-Boot SPL 2022.10+fslc+gcbd7eb17ac+p0 (Dec 13 2022 - 00:42:37 +0000)
No pmic
SEC0:  RNG instantiated
Normal Boot
WDT:   Started watchdog@30280000 with servicing (60s timeout)
Trying to boot from MMC1
NOTICE:  BL31: v2.6(release):automotive-13.0.0_1.1.0-0-g3c1583ba0-dirty
NOTICE:  BL31: Built : 11:00:38, Nov 21 2022


U-Boot 2022.10+fslc+gcbd7eb17ac+p0 (Dec 13 2022 - 00:42:37 +0000)

CPU:   Freescale i.MX8MMQ rev1.0 at 1200 MHz
Reset cause: POR
Model: FSL i.MX8MM EVK board
DRAM:  2 GiB
Core:  160 devices, 20 uclasses, devicetree: separate
WDT:   Started watchdog@30280000 with servicing (60s timeout)
MMC:   FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... *** Warning - bad CRC, using default environment

In:    serial@30890000
Out:   serial@30890000
Err:   serial@30890000
SEC0:  RNG instantiated
Net:   eth0: ethernet@30be0000
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:1...
47383 bytes read in 3 ms (15.1 MiB/s)
No EFI system partition
BootOrder not defined
EFI boot manager: Cannot load any image
switch to partitions #0, OK
mmc2(part 0) is current device
ethernet@30be0000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
Could not initialize PHY ethernet@30be0000
BOOTP broadcast 1
....

Loading and booting the kernel manually works fine, though.

[fabioestevam]

U-Boot 2022 is a bit old. I have tried U-Boot 2026.04, and it boots correctly.

I use https://github.com/fabioestevam/kas-imx8mmevk to test it.

[richardweinberger]

U-Boot 2022 is a bit old. I have tried U-Boot 2026.04, and it boots correctly.

I use https://github.com/fabioestevam/kas-imx8mmevk to test it.

But that's not using meta-freescale at all?
I see the very same problem also with a more recent u-boot. I have just narrowed it down to that old version where it broke fist.

[fabioestevam]

On Tue, May 19, 2026 at 6:50 PM richardweinberger ***@***.***> wrote: But that's not using meta-freescale at all?

Correct. It does not use meta-freescale.

I see the very same problem also with a more recent u-boot. I have just narrowed it down to that old version where it broke fist.

U-Boot 2026.04 boots correctly here: ``` U-Boot SPL 2026.04 (Apr 06 2026 - 17:59:18 +0000) No pmic WDT: Started ***@***.*** with servicing every 1000ms (60s timeout) SEC0: RNG instantiated Trying to boot from MMC1 load_simple_fit: Skip load 'tee': image size is 0! NOTICE: Do not release JR0 to NS as it can be used by HAB NOTICE: BL31: v2.12.0(release):v2.12.0 NOTICE: BL31: Built : 22:30:24, Nov 20 2024 U-Boot 2026.04 (Apr 06 2026 - 17:59:18 +0000) CPU: NXP i.MX8MMQ Rev1.0 A53 at 1200 MHz CPU: Consumer temperature grade (0C to 95C) at 32C Model: FSL i.MX8MM EVK board DRAM: 2 GiB optee optee: OP-TEE api uid mismatch Core: 195 devices, 27 uclasses, devicetree: separate WDT: Started ***@***.*** with servicing every 1000ms (60s timeout) MMC: FSL_SDHC: 1, FSL_SDHC: 2 Loading Environment from MMC... Reading from MMC(1)... OK In: ***@***.*** Out: ***@***.*** Err: ***@***.*** SEC0: RNG instantiated switch to partitions #0, OK mmc1 is current device Net: eth0: ***@***.*** Hit any key to stop autoboot: 0 Scanning for bootflows in all bootdevs Seq Method State Uclass Part Name Filename --- ----------- ------ -------- ---- ------------------------ ---------------- Scanning global bootmeth 'efi_mgr': optee optee: OP-TEE api uid mismatch Unable to open OP-TEE session (err=-19) mm_communicate failed! Scanning bootdev ***@***.***': 0 extlinux ready mmc 2 ***@***.*** /boot/extlinux/extlinux.conf ** Booting bootflow ***@***.***_2' with extlinux 1: imx8mmevk Linux Distribution Retrieving file: /boot/extlinux/../Image append: root=/dev/mmcblk1p2 rootwait rw console=ttymxc1,115200 Retrieving file: /boot/extlinux/../imx8mm-evk.dtb ## Flattened Device Tree blob at 48000000 Booting using the fdt blob at 0x48000000 Working FDT set to 48000000 Loading Device Tree to 000000004fff2000, end 000000004ffff0a1 ... OK Working FDT set to 4fff2000 Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] [ 0.000000] Linux version 6.12.86-stable-standard ***@***.***) (aarch64-imx8mmevklinux-linux-gcc (GCC) 13.4.0, GNU ld (GNU Binutils) 2.42.0.20240723) #1 SMP PREEMPT Thu May 7 04:09:48 UTC 2026 ``` What is the exact error you get with U-Boot 2026.04?

[richardweinberger]

On Tue, May 19, 2026 at 6:50 PM richardweinberger @.***> wrote:
But that's not using meta-freescale at all?
Correct. It does not use meta-freescale.
What is the exact error you get with U-Boot 2026.04?

As I posted in the very first comment here, it's just stuck at:

U-Boot SPL 2022.10+fslc+gcbd7eb17ac+p0 (Dec 13 2022 - 00:42:37 +0000)
No pmic
SEC0:  RNG instantiated
Normal Boot
WDT:   Started watchdog@30280000 with servicing (60s timeout)
Trying to boot from MMC1
NOTICE:  BL31: v2.6(release):automotive-13.0.0_1.1.0-0-g3c1583ba0-dirty
NOTICE:  BL31: Built : 11:00:38, Nov 21 202

The u-boot version does not matter. I tried first the latest Yocto release and chased it down to Kirkstone.
So, the problem I'm reporting is not U-Boot being broken, I use it on many imx8mm systems, the problem is that meta-freescale is broken.
To me it looks like it configures U-Boot in combination with OP-TEE wrongly for the EVK board.

Thanks,
//richard

[richardweinberger]

optee optee: OP-TEE api uid mismatch

@fabioestevam Your setup does not seem to use OP-TEE at all.

[fabioestevam]

On Wed, May 27, 2026 at 3:50 PM richardweinberger ***@***.***> wrote: @fabioestevam Your setup does not seem to use OP-TEE at all.

Yes, it does not use OP-TEE. Is this issue related to OP-TEE? Does it boot if you do not use OP-TEE?

[richardweinberger]

On Wed, May 27, 2026 at 3:50 PM richardweinberger @.***> wrote:
@fabioestevam Your setup does not seem to use OP-TEE at all.
Yes, it does not use OP-TEE.

Is this issue related to OP-TEE? Does it boot if you do not use OP-TEE?

Yes, as I wrote in #2518 (comment)

[richardweinberger]

@otavio I found some time to look again, I think the key difference is UBOOT_PROVIDES_BOOT_CONTAINER.
As soon u-boot's mechanism to generate flash.bin is used, the board won't boot.
...and only when OP-TEE is enabled.