LSDK 21.08 OP-TEE breaks boot

[endrunner_smw]

Custom board using LS1043AE have it secure booting just fine with no OP-TEE. Trying to introduce OP-TEE to the system and console outputs and hangs at:

NOTICE: 2 GB DDR4, 32-bit, CL=11, ECC off
NOTICE: BL2: v2.4(release):LSDK-21.08-1-ga08bfddba-dirty
NOTICE: BL2: Built : 22:39:20, Aug 31 2026
NOTICE: Initializing & configuring SEC block.
NOTICE: Sec is already initialized and configured.
NOTICE: Verifying RSA
NOTICE: Verifying hash
NOTICE: Verifying RSA
NOTICE: Verifying hash
NOTICE: Verifying RSA
NOTICE: Verifying hash
NOTICE: BL2: Booting BL31
NOTICE: BL31: v2.4(release):LSDK-21.08-1-ga08bfddba-dirty
NOTICE: BL31: Built : 22:39:48, Aug 31 2026
NOTICE: Welcome to ls1043aerb BL31 Phase

According to Google/Gemini it thinks there is a problem with GIC. ATF and OP-TEE appear to be using 64k page aligned, but in a uboot dts it has it at a 4k page aligned. I don't think it's this issue, or at least not yet. Because it doesn't appear to Initialize OP-TEE at all.

Thoughts?

[yipingwang]

It seems that there is problem with your u-boot.

Would you please try whether it can work to boot normal u-boot(not secured) with OPTEE enabled?

[endrunner_smw]

I don't mind trying that, but what is that testing for? What are you currently thinking is possibly wrong with uboot? Since it works without optee I'm curious as to what could be wrong or what I should look for?

[yipingwang]

What I would check first:

• Rebuild TF-A in debug mode and confirm the exact stop point.
  Use DEBUG=1 LOG_LEVEL=50 if practical, or add NOTICE() breadcrumbs in early BL31 platform code around:

• platform setup entry

• GIC init

• TZC/TZASC/TZPC setup

• secure payload dispatcher / OP-TEE setup

• BL32 entry-point preparation
  NXP support guidance for similar LS1043A hangs is to add ATF/U-Boot debug prints or use CodeWarrior/JTAG to inspect where execution is stuck.

• Verify the FIP actually contains BL32 and that BL31 was built with OP-TEE support.
  For OP-TEE in TF-A, the build must include SPD=opteed and BL32=<tee.bin> ; for secure boot/NXP CoT, the secure TF-A build flow also includes TRUSTED_BOARD_BOOT=1 , CST_DIR=... , BL32=$TEE_BIN , SPD=opteed , and BL33=$UBOOT_SECURE_BIN .
  Run something like:

 fiptool info fip.bin

and confirm BL31, BL32/OP-TEE, and BL33 are all present. If BL32 is missing or BL31 was not built with SPD=opteed , OP-TEE will never be entered.

• Check LS1043A secure-boot reserved-memory handling.
  There is a reported LS1043A secure-boot issue fixed by changing plat/nxp/soc-ls1043a/soc.def NXP_ROM_RSVD from 0x5900 to 0x8000 . Since you are already secure-booting and now adding another signed FIP component, this is worth checking early. It is more plausible than a later U-Boot DTS GIC alignment issue.

• Do not assume “RSA/hash verified” means the image layout is good.
  Your BL2 log proves authentication reached success for the components it validated, but it does not prove the runtime addresses, reserved-memory overlap, BL32 load address, or BL31 secure-payload configuration are correct. BL2 is documented as loading BL31/BL32/BL33 to DDR after validation before handing control to BL31.

• If the hang moves to BL31: Initializing BL32 , then shift focus to OP-TEE proper.
  At that later stage I would look at OP-TEE load address, secure DDR carveout, pager/non-pager layout, CAAM/SEC configuration, and OP-TEE console. There is NXP guidance in a related OP-TEE/crypto context to try disabling crypto/CAAM in OP-TEE with CFG_NXP_CAAM=n and CFG_CRYPTO_DRIVER=n when early OP-TEE crypto initialization is suspected. But your current log does not yet prove OP-TEE is being entered.

My strongest hypothesis: BL31 is built/configured differently when OP-TEE is enabled and is hanging in early BL31 platform/SPD setup before the OP-TEE banner or BL32 entry. I would first instrument BL31 around GIC/platform setup and verify FIP/ SPD=opteed / BL32=tee.bin /secure-boot CSF layout, then check the LS1043A NXP_ROM_RSVD=0x8000 issue.

[endrunner_smw]

So I built atf with debugging and the final message I get before silent hang is:

INFO: BL31: Initializing BL32

So if I understood your recommandation correctly, I should focus on OP-TEE specifically now, correct?

[yipingwang]

Yes, please verify OP-TEE with normal boot(not secured) first to make sure there is no problem with your building and deployment procedure with OP-TEE.

[endrunner_smw · Accepted solution]

I believe I was using the wrong tee.bin.

I was using the tee.bin that was generated during a manual build of OP-TEE and not the objcopy version I needed to generate. That appears to allow the system to initialize and boot into linux.

I do have more kernel logging messages about optee that I need to look into, but I will close this thread because this specific issue is resolved.