iMX8qm Boot Core A72_0

kamohan

Hello NXP Forum,

on iMX8qm, can we have the bootup done from A72 core? Does SCUFW permit that.

Thanks

kamohan

Hello,

I have followed the following steps to build bootloader, but the bootloader fails without any logs.

Could you please validate attached steps.

Thanks

mkdir Scarthgap_New

cd Scarthgap_New

1. Get the Security Controller Binaries

mkdir SECO

cd SECO

wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/imx-seco-5.9.4.1-0333596.bin

chmod +x imx-seco-5.9.4.1-0333596.bin

./imx-seco-5.9.4.1-0333596.bin

mkashyap@cse-dev02:~/iMX8/Scarthgap_New/SECO/imx-seco-5.9.4.1-0333596/firmware/seco$ ls -al

total 976

drwxrwxr-x 2 mkashyap mkashyap 4096 Aug 26 22:21 .

drwxrwxr-x 3 mkashyap mkashyap 4096 Aug 26 22:21 ..

-rw-r--r-- 1 mkashyap mkashyap 194 Jul 29 2024 commit-id.txt

-rw-r--r-- 1 mkashyap mkashyap 163840 Jul 29 2024 mx8dxla1-ahab-container.img

-rw-r--r-- 1 mkashyap mkashyap 163840 Jul 29 2024 mx8dxlb0-ahab-container.img

-rw-r--r-- 1 mkashyap mkashyap 76944 Jul 29 2024 mx8qmb0-ahab-container.img

-rw-r--r-- 1 mkashyap mkashyap 71312 Jul 29 2024 mx8qxb0-ahab-container.img

-rw-r--r-- 1 mkashyap mkashyap 78408 Jul 29 2024 mx8qxc0-ahab-container.img

-rwxr-xr-x 1 mkashyap mkashyap 423875 Jul 29 2024 SECO_FW_release_note.pdf

mkashyap@cse-dev02:~/iMX8/Scarthgap_New/SECO/imx-seco-5.9.4.1-0333596/firmware/seco$

we use mx8qmb0-ahab-container.img

cd ../../../..

2. Download and build ATF

mkdir ATF

cd ATF

git clone https://github.com/varigit/imx-atf -b lf_v2.10_6.6.52-2.2.0_var01

cd imx-atf

source /opt/fsl-imx-xwayland/6.6-scarthgap/environment-setup-armv8a-poky-linux

unset LDFLAGS

make PLAT=imx8qm bl31

mkashyap@cse-dev02:~/iMX8/Scarthgap_New/ATF/imx-atf/build/imx8qm/release$ ls -al

total 76

drwxrwxr-x 7 mkashyap mkashyap 4096 Aug 26 22:37 .

drwxrwxr-x 3 mkashyap mkashyap 4096 Aug 26 22:36 ..

drwxrwxr-x 3 mkashyap mkashyap 4096 Aug 26 22:37 bl31

-rwxrwxr-x 1 mkashyap mkashyap 45213 Aug 26 22:37 bl31.bin

drwxrwxr-x 2 mkashyap mkashyap 4096 Aug 26 22:37 lib

drwxrwxr-x 2 mkashyap mkashyap 4096 Aug 26 22:37 libc

drwxrwxr-x 2 mkashyap mkashyap 4096 Aug 26 22:37 libwrapper

drwxrwxr-x 2 mkashyap mkashyap 4096 Aug 26 22:37 romlib

cd ../../../../../

3. Download and build SCFW

mkdir SCFW

cd SCFW

wget https://developer.arm.com/-/media/Files/downloads/gnu-rm/8-2018q4/gcc-arm-none-eabi-8-2018-q4-major-...

sudo tar xf gcc-arm-none-eabi-8-2018-q4-major-linux.tar.bz -C ./opt

git clone https://github.com/varigit/imx-sc-firmware.git -b 1.17.0

cd imx-sc-firmware/src/scfw_export_mx8qm_b0

export TOOLS=/home/mkashyap/iMX8/Scarthgap_New/SCFW/Opt

make clean-qm

make qm R=B0 B=var_som V=1

mkashyap@cse-dev02:~/iMX8/Scarthgap_New/SCFW/imx-sc-firmware/src/scfw_export_mx8qm_b0/build_mx8qm_b0$ ls -al

total 3384

drwxrwxr-x 11 mkashyap mkashyap 4096 Aug 26 22:47 .

drwxrwxr-x 6 mkashyap mkashyap 4096 Aug 26 22:47 ..

drwxrwxr-x 3 mkashyap mkashyap 4096 Aug 26 22:47 board

drwxrwxr-x 3 mkashyap mkashyap 4096 Aug 26 22:44 devices

drwxrwxr-x 25 mkashyap mkashyap 4096 Aug 26 22:47 drivers

drwxrwxr-x 2 mkashyap mkashyap 4096 Aug 26 22:44 main

-rwxrwxr-x 1 mkashyap mkashyap 184448 Aug 26 22:47 scfw_tcm.bin

-rwxrwxr-x 1 mkashyap mkashyap 2787784 Aug 26 22:47 scfw_tcm.elf

-rw-rw-r-- 1 mkashyap mkashyap 513123 Aug 26 22:47 scfw_tcm.map

drwxrwxr-x 4 mkashyap mkashyap 4096 Aug 26 22:44 soc

drwxrwxr-x 26 mkashyap mkashyap 4096 Aug 26 22:44 ss

drwxrwxr-x 9 mkashyap mkashyap 4096 Aug 26 22:47 svc

drwxrwxr-x 10 mkashyap mkashyap 4096 Aug 26 22:44 test

drwxrwxr-x 2 mkashyap mkashyap 4096 Aug 26 22:44 utilities

cd ../../../../../

4. Build u-boot

mkdir u-boot

cd u-boot

git clone https://github.com/varigit/uboot-imx.git -b lf_v2024.04_6.6.52-2.2.0_var01

cd uboot-imx

cp ../../SECO/imx-seco-5.9.4.1-0333596/firmware/seco/mx8qmb0-ahab-container.img ./mx8qm-ahab-container.img

cp ../../SCFW/imx-sc-firmware/src/scfw_export_mx8qm_b0/build_mx8qm_b0/scfw_tcm.bin ./mx8qm-mek-scfw-tcm.bin

make mrproper

make imx8qm_var_som_defconfig

make -j8

cd ../../

5. Make Image

mkdir MkImage

cd MkImage

git clone https://github.com/varigit/imx-mkimage -b lf-6.6.52_2.2.0_var01

cd imx-mkimage

cp ../../SECO/imx-seco-5.9.4.1-0333596/firmware/seco/mx8qmb0-ahab-container.img ./iMX8QM/

cp ../../SCFW/imx-sc-firmware/src/scfw_export_mx8qm_b0/build_mx8qm_b0/scfw_tcm.bin ./iMX8QM/

cp ../../u-boot/uboot-imx/u-boot.bin ./iMX8QM/

cp ../../u-boot/uboot-imx/spl/u-boot-spl.bin ./iMX8QM/

cp ../../ATF/imx-atf/build/imx8qm/release/bl31.bin ./iMX8QM/

make SOC=iMX8QM flash_ca72

cd iMX8QM

make -f soc.mak SOC=iMX8QM MKIMG=../mkimage_imx8 PAD_IMAGE=./pad_image.sh flash_ca72

mkashyap@cse-dev02:~/iMX8/Scarthgap_New/MkImage/imx-mkimage/iMX8QM$ ls -al

total 6792

drwxrwxr-x 3 mkashyap mkashyap 4096 Aug 26 23:08 .

drwxrwxr-x 13 mkashyap mkashyap 4096 Aug 26 23:06 ..

-rwxrwxr-x 1 mkashyap mkashyap 45213 Aug 26 23:06 bl31.bin

-rwxrwxr-x 1 mkashyap mkashyap 2564 Aug 26 22:59 expand_c_define.sh

-rw-rw-r-- 1 mkashyap mkashyap 1895424 Aug 26 23:08 flash.bin

-rw-rw-r-- 1 mkashyap mkashyap 9 Aug 26 23:06 head.hash

-rwxrwxr-x 1 mkashyap mkashyap 2078 Aug 26 22:59 mkimage_fit_atf.sh

-rw-r--r-- 1 mkashyap mkashyap 76944 Aug 26 23:02 mx8qmb0-ahab-container.img

-rwxrwxr-x 1 mkashyap mkashyap 184448 Aug 26 23:03 scfw_tcm.bin

drwxrwxr-x 2 mkashyap mkashyap 4096 Aug 26 22:59 scripts

-rwxrwxr-x 1 mkashyap mkashyap 13271 Aug 26 22:59 soc.mak

-rwxrwxr-x 1 mkashyap mkashyap 1631521 Aug 26 23:06 u-boot-atf.bin

-rw-rw-r-- 1 mkashyap mkashyap 1500440 Aug 26 23:04 u-boot.bin

-rw-rw-r-- 1 mkashyap mkashyap 1500449 Aug 26 23:06 u-boot-hash.bin

-rw-rw-r-- 1 mkashyap mkashyap 139387 Aug 26 23:04 u-boot-spl.bin

The generated flash.bin was used as an bootloader image

yipingwang

For your specific procedure, the important point is this:

make SOC=iMX8QM flash_ca72

is the correct target conceptually if your intent is to load the bootloader to the A72 instead of the A53 . NXP community guidance describes flash_ca72 as similar to the basic flash_b0 image, but loaded to the A72 rather than the A53 .

The “no logs” symptom does not automatically mean SCFW rejected A72 boot . A known gotcha is that A53 and A72 do not use the same log terminal , so if you monitor the usual A-core/A53 UART you may see nothing even though the A72 image is running or failing later on a different console path.

Validation of your steps:

Area	Assessment
SECO container	mx8qmb0-ahab-container.img is the right class of container for i.MX8QM B0.
ATF	make PLAT=imx8qm bl31 is reasonable for i.MX8QM.
SCFW	Building make qm R=B0 B=var_som V=1 is consistent with an i.MX8QM B0 Variscite target.
U-Boot	imx8qm_var_som_defconfig is the key item to confirm: it must be compatible with the A72 boot path and console configuration.
mkimage target	flash_ca72 is the right target only for A72 boot. For normal Linux BSP boot, the documented i.MX8QM command is make SOC=iMX8QM flash .
SPL copy	u-boot-spl.bin is likely irrelevant for flash_ca72 ; that target is not the SPL-based flow.
Duplicate image build	Running both top-level make SOC=iMX8QM flash_ca72 and then manually running make -f soc.mak ... flash_ca72 is unnecessary. Use one clean top-level command.

I would correct/clean the image-generation part to:

cd ~/iMX8/Scarthgap_New/MkImage/imx-mkimage

cp ../../SECO/imx-seco-5.9.4.1-0333596/firmware/seco/mx8qmb0-ahab-container.img ./iMX8QM/

cp ../../SCFW/imx-sc-firmware/src/scfw_export_mx8qm_b0/build_mx8qm_b0/scfw_tcm.bin ./iMX8QM/

cp ../../u-boot/uboot-imx/u-boot.bin ./iMX8QM/

cp ../../ATF/imx-atf/build/imx8qm/release/bl31.bin ./iMX8QM/

make clean

make SOC=iMX8QM flash_ca72

Then use:

iMX8QM/flash.bin

Also fix/check this SCFW path:

export TOOLS=/home/mkashyap/iMX8/Scarthgap_New/SCFW/Opt

You extracted into ./opt , but exported .../SCFW/Opt . Linux paths are case-sensitive. Since you did produce scfw_tcm.bin , your actual shell may have had a valid tool path, but this line should be verified.

Recommended debug sequence:

First build and boot the standard image:

make SOC=iMX8QM flash

This checks that SECO + SCFW + ATF + U-Boot + board DDR/console are basically correct. The Linux User’s Guide documents this standard i.MX8QM flash.bin generation path.

Then rebuild with:

make SOC=iMX8QM flash_ca72

Monitor the A72 console/UART , not only the normal A53 console. The A53 and A72 log terminals differ.

If still silent, compare the generated flash.bin size/layout between flash and flash_ca72 , and confirm that the Variscite U-Boot config actually enables the console used by the A72 boot target.

So the direct answer is: SCFW does permit starting the Cortex-A side on A72 through the flash_ca72 image flow, but SCFW still owns the initial boot orchestration. Your procedure is mostly valid for A72 boot, but remove the duplicate soc.mak invocation, verify the SCFW tool path, and most importantly check the A72 UART/console.

Takeaway: A72 boot on i.MX8QM is supported via flash_ca72 ; a silent boot is more likely an image/config/console issue than SCFW simply refusing to start A72.

yipingwang

Yes — on i.MX8QM, the application-processor boot image can be targeted to the Cortex-A72 instead of the Cortex-A53, and SCFW permits that flow. NXP’s imx-mkimage has a flash_ca72 target described as the A72 variant of the normal A53 boot image, intended to bring up the A72 as early as possible for boot-time optimization .

The important distinction is:

First code after reset: not the A72. The device boot flow still starts through ROM/SCU/SCFW.
AP-side bootloader / OS bring-up: yes, this can be done on the A72. SCFW initializes DDR, loads Cortex-A images, then boots the cores and sets their start addresses.
Configuration mechanism: the boot container can specify an AP image for a72 , e.g. examples show -ap ... a72 ... in imx-mkimage usage.

So the answer is: SCFW does allow booting the AP software path from A72, but A72 is not the reset/ROM boot master; it is started by SCFW according to the boot container configuration.

kamohan

There is a small point we would like to clarify/validate: the `flash_ca72` target currently references `u-boot-atf.bin`, while a separate `u-boot-atf-a72.bin` is also available in the same configuration.

How do we proceed

yipingwang

Proceed with the existing flash_ca72 target first; do not replace u-boot-atf.bin with u-boot-atf-a72.bin unless you are intentionally using the cockpit / multi-AP image flow.

The evidence points to this distinction:

flash_ca72 is described as the same basic boot image as the normal A-core boot target, but loaded to the A72 instead of the A53.
u-boot-atf.bin is the combined ATF + U-Boot image: bl31.bin plus u-boot.bin / u-boot-hash.bin .
u-boot-atf-a72.bin appears in the flash_cockpit target, where the image contains two AP payloads : one for A53 and a separate one for A72: -ap u-boot-atf.bin a53 0x80000000 ... -ap u-boot-atf-a72.bin a72 0xC0000000 ... .

So the important selector is not only the filename; it is the imx-mkimage -ap ... a72 ... argument in the target. For a single A72 boot image, flash_ca72 using u-boot-atf.bin is consistent with the documented intent: the payload is loaded to A72 by the target rule, even if the filename is not suffixed -a72 .

Recommended path:

Build the standard A72-only image using the existing target:

make SOC=iMX8QM flash_ca72

Use the CA72 device tree / configuration on the Linux side. NXP documentation notes that the i.MX8QM MEK CA72 DTB supports the two Cortex-A72 cores only and requires the special boot image built with flash_ca72 .

Reserve u-boot-atf-a72.bin for flows that explicitly package a second A72 AP image, such as flash_cockpit , unless your BSP’s soc.mak comments or release notes say otherwise.

Validate at boot that the image is actually entering the A72 path: check the imx-mkimage command emitted by make V=1 SOC=iMX8QM flash_ca72 or inspect iMX8QM/soc.mak and confirm the AP line uses a72 .

Takeaway: treat the current flash_ca72 reference to u-boot-atf.bin as intentional; u-boot-atf-a72.bin is for the separate A72 payload used in cockpit/multi-partition style images, not automatically the replacement for flash_ca72 .