i.MX ProcessorsのトピックRe: iMX8qm Boot Core A72_0

iMX8qm Boot Core A72_0

kamohan — Tue, 25 Aug 2026 01:33:10 GMT

Hello NXP Forum,

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

Thanks

Re: iMX8qm Boot Core A72_0

yipingwang — Tue, 25 Aug 2026 07:43:54 GMT

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.

Re: iMX8qm Boot Core A72_0

kamohan — Wed, 26 Aug 2026 03:22:28 GMT

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

Re: iMX8qm Boot Core A72_0

yipingwang — Wed, 26 Aug 2026 03:43:11 GMT

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 .