- Forums
- Product Forums
- General Purpose MicrocontrollersGeneral Purpose Microcontrollers
- i.MX Forumsi.MX Forums
- QorIQ Processing PlatformsQorIQ Processing Platforms
- Identification and SecurityIdentification and Security
- Power ManagementPower Management
- Wireless ConnectivityWireless Connectivity
- RFID / NFCRFID / NFC
- Advanced AnalogAdvanced Analog
- Neural Processing UnitsNeural Processing Units
- MCX Microcontrollers
- S32G
- S32K
- S32V
- MPC5xxx
- Other NXP Products
- S12 / MagniV Microcontrollers
- Powertrain and Electrification Analog Drivers
- Sensors
- Vybrid Processors
- Digital Signal Controllers
- 8-bit Microcontrollers
- ColdFire/68K Microcontrollers and Processors
- PowerQUICC Processors
- OSBDM and TBDML
- S32M
- S32Z/E
-
- Solution Forums
- Software Forums
- MCUXpresso Software and ToolsMCUXpresso Software and Tools
- CodeWarriorCodeWarrior
- MQX Software SolutionsMQX Software Solutions
- Model-Based Design Toolbox (MBDT)Model-Based Design Toolbox (MBDT)
- FreeMASTER
- eIQ Machine Learning Software
- Embedded Software and Tools Clinic
- S32 SDK
- S32 Design Studio
- GUI Guider
- Zephyr Project
- Voice Technology
- Application Software Packs
- Secure Provisioning SDK (SPSDK)
- Processor Expert Software
- Generative AI & LLMs
-
- Topics
- Mobile Robotics - Drones and RoversMobile Robotics - Drones and Rovers
- NXP Training ContentNXP Training Content
- University ProgramsUniversity Programs
- Rapid IoT
- NXP Designs
- SafeAssure-Community
- OSS Security & Maintenance
- Using Our Community
-
- Cloud Lab Forums
-
- Knowledge Bases
- ARM Microcontrollers
- i.MX Processors
- Identification and Security
- Model-Based Design Toolbox (MBDT)
- QorIQ Processing Platforms
- S32 Automotive Processing Platform
- Wireless Connectivity
- CodeWarrior
- MCUXpresso Suite of Software and Tools
- MQX Software Solutions
- RFID / NFC
- Advanced Analog
- Neural Processing Units
-
- NXP Tech Blogs
- Home
- :
- Translated Content
- :
- Multi Source Translation Content
- :
- 2407908_en-US
2407908_en-US
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
2407908_en-US
2407908_en-US
Hello NXP Forum,
on iMX8qm, can we have the bootup done from A72 core? Does SCUFW permit that.
Thanks
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 .
How do we proceed
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.
Hello,
I have followed the following steps to build bootloader, but the bootloader fails without any logs.
Could you please validate attached steps.
Thanks
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.