Imx-boot broken if overriding machine name in yocto

Technical Support
, , , ,
1

Hi all,

I’ve got a strange issue, I’m trying to override the machine name in my image for various reasons.

I’m doing so like this

require conf/machine/verdin-imx8mp.conf
MACHINEOVERRIDES =. "my-controller:verdin-imx8mp:"

Everything builds fine however the machine won’t boot.

You see this in uboot and then the watchdog kicks in.

U-Boot SPL 2022.04-0+git.d262075124dc (Mar 08 2024 - 14:27:40 +0000)
DDRINFO: start DRAM init
DDRINFO: DRAM rate 4000MTS
DDRINFO:ddrphy calibration done
DDRINFO: ddrmix config done
DDR configured as dual rank
SEC0:  RNG instantiated
Normal Boot
WDT:   Started watchdog@30280000 with servicing (60s timeout)
Trying to boot from BOOTROM
Boot Stage: Primary boot
Find img info 0x&4802a600, size 888
Need continue download 1024
Download 952320, Total size 953424

However if instead of using my-machine I revert machine to MACHINE ??= “verdin-imx8mp” everything builds and boots as expected.

Is there a safer way of overriding the machine name? Or is anyone please able to help me figure out exactly why overriding the machine name as above would cause this sympton?

Any help would be greatly appreciated.

2

Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:

Hello,

Overriding the machine name in Yocto as you’ve described can lead to issues because the machine name (MACHINE) is a critical variable that influences many aspects of the build process, including which kernel configurations, device trees, and other machine-specific settings are used. When you override the machine name directly in your configuration, it can disrupt the build system’s understanding of which hardware-specific configurations to apply, potentially leading to a non-bootable image.

In your case, it seems like the build process completes without errors, but the resulting image does not boot properly. This could be because the overridden machine name leads to incorrect or missing configurations for the bootloader, kernel, or device tree, which are essential for the boot process.

A safer approach to achieve customization without changing the MACHINE variable directly is to use Yocto’s append files (.bbappend) and overlay mechanisms to modify or extend the configurations of your target machine (verdin-imx8mp in this case) without altering its identity. This way, you can apply custom settings, patches, or configurations specific to your needs while maintaining the integrity of the machine configuration.

For example, if you need to add or override kernel configurations, you can create a .bbappend file for the kernel recipe used by verdin-imx8mp and specify your custom configurations there. Similarly, for device tree modifications, you can provide an overlay or a custom device tree file and modify the build to include it, again without changing the MACHINE variable.

This approach ensures that your customizations are applied on top of the base configuration for verdin-imx8mp, minimizing the risk of disrupting essential configurations and improving the likelihood of a successful boot.

Best regards,
Toradex AI Assistant

Please, also check if these links can help you solve your problem:

How to Speed-up Docker Image Builds on Linux | Toradex Developer Center.

3

Digging into this a bit more, was trying to see what the difference is, comparing the hex of the generated imx-boot files I see

So there’s just a small difference in the binaries based on the machine name.

image
image1510×41 11.8 KB

With 0011 working and 2011 not…

Trying to dig into the code some more to see what might be causing this…

4

Okay that took some hunting, the problem was the generated bl32 binary.
When changing the machine name the value here didn’t work

meta-toradex-nxp/conf/machine/verdin-imx8mp.conf
59:SOC_ATF_BOOT_UART_BASE:verdin-imx8mp = "0x30880000"

For now I’ve changed it so my conf file does

require conf/machine/verdin-imx8mp.conf

MACHINEOVERRIDES =. "meercam-controller:verdin-imx8mp:"
# Without this the bl31 ( arm secure boot loader ) produces a subtly
# different output which prevents the u-boot from finding everything
# in the right place and it just hangs.
ATF_BOOT_UART_BASE = "0x30880000"

but there might be a better way.

5

Hello @alan01252,

It looks like the MACHINEOVERRIDES is being prepended again in conf/machine/include/imx-base.inc and maybe some more subsequent .inc files from verdin-imx8mp.conf.

conf/machine/include/imx-base.inc
19: MACHINEOVERRIDES =. "use-${IMX_DEFAULT_BSP}-bsp:"

While this solution solves this specific issue, it would not account for other overrides which are not considered because of this behavior.
Can you test with the following?

require conf/machine/verdin-imx8mp.conf

MACHINEOVERRIDES =. "meercam-controller:verdin-imx8mp:mx8:mx8m:mx8mp:"

This way you manually carry over the overrides defined in verdin-imx8mp.conf.
From a simple test, this does attribute the correct value for ATF_BOOT_UART_BASE.

Best Regards,
Bruno

6

Hi @bruno.tx

I did try that, but I wonder if properly cleaned the state for the ifu-aft recipe at that point, as I was thinking it was in the imx-boot prior to this.

I’ll give this a go and report back!

Ty

7

@bruno.tx that didn’t work for me, I remove my variable and set the MACHINE as you described but the logs for the do.compile show the old value remains.

builder@nixos:/build/tmp/work/controller-poky-linux/imx-atf/2.6+gitAUTOINC+3c1583ba0a-r0/temp$ cat log.do_compile
DEBUG: Executing shell function do_compile
NOTE: make -j 12 CROSS_COMPILE=aarch64-poky-linux- PLAT=imx8mp LD=aarch64-poky-linux-ld.bfd CC=aarch64-poky-linux-gcc IMX_BOOT_UART_BASE=0x30890000 bl31

8

Hello @alan01252,

It turns out that you actually need to append the MACHINEOVERRIDES, instead of prepending them:

require conf/machine/verdin-imx8mp.conf

MACHINEOVERRIDES .= ":verdin-imx8mp:meercam-controller"

From my testing this does result in the correct IMX_BOOT_UART_BASE during compilation.

In addition to that, I would also recommend that you manually set the DISTRO variable in your local.conf file:

DISTRO = "tdx-xwayland"

The existing configuration will set the DISTRO depending on the MACHINE, which is different than expected in this case.

Best Regards,
Bruno

9

Thank you (again) @bruno.tx I’ll give this a go too :slight_smile:

10

I can confirm this works :slight_smile: Thank you so much!

11

Hello @alan01252,

Thanks for the update.

Best Regards,
Bruno