i.MX8M Mini: unable to boot on closed device when ATF is configured with OP-TEE support

[gabrielvalcazar]

My company has successfully implemented a security infrastructure on our current i.MX-based platforms (using i.MX6, i.MX6UL, i.MX8X and i.MX8M Nano). Said infrastructure makes use of the existing HAB/AHAB/CST framework to add secure boot support to our products. I'm currently testing this infrastructure for a product based on the i.MX8M Mini, using what we've implemented on the i.MX8M Nano as a starting point. I'm using BSP v5.4.70_2.3.1 as a base and including OP-TEE in our images to be able to use the encryption features of the CAAM.

So far I've signed both the SPL and the FIT following the steps and templates in the U-Boot HABv4 documentation, and I can successfully boot the SPL on a closed device. The SPL also authenticates the FIT signature, but I can't see anything else in the debug console after that:

U-Boot SPL dub-2020.04-r3.1-git+ga6aa6b8b9c (Feb 14 2021 - 10:26:30 +0000)
DDRINFO: start DRAM init
DDRINFO: DRAM rate 3000MTS
DDRINFO:ddrphy calibration done
DDRINFO: ddrmix config done
Normal Boot
Trying to boot from USB SDP
SDP: initialize...
SDP: handle requests...
Downloading file of size 3065504 to 0x40400000... done
Jumping to header at 0x40400000
Header Tag is not an IMX image
Found header at 0x40427fa0
   Authenticate image from DDR location 0x401fcdc0... OK

<target hangs>

The signed image boots fine on an open device. Also, I've tested building a signed imx-boot image using the default ATF binary instead of the one with OP-TEE support, and that image boots fine on the closed target. So something about the combination of the ATF w/ OP-TEE support and the closed device causes it to hang indefinitely. Note that our platform is using the same memory chip as the 8M Mini EVK. Also, a signed imx-boot image with the OP-TEE ATF works fine on a closed 8M Nano device.

My question is: are there any differences I'm not aware of between the 8M Mini and the 8M Nano when it comes to secure boot (HAB version, CSF entries, signing process, boot/authentication process, addresses...)? Is there any logical explanation as to why the combination of the ATF binary w/ OP-TEE support and the closed target causes this behavior?

Also, a secondary question: are there any special steps needed to see console output from the ATF? So far I've tried building with DEBUG=1 and changing IMX_BOOT_UART_BASE to UART1 (it's what we use on our platform for the debug console), but I still can't see anything. It's worth noting that the UART1 interface is mux'ed from SAI2 pads instead of the default UART1 pads, but I also don't see any movement on the lines attached to said pads.

[gabrielvalcazar · Accepted solution]

I found the issue... I thought I was using the HABv4 CSF templates in the U-Boot documentation but I was missing the entry that unlocked the CAAM's MID registers. I thought I had tested this earlier but it turns out my Yocto recipe in charge of obtaining the CSF templates was pointing to a different U-Boot branch instead of the one with my changes.

Once I add the entry to unlock the CAAM MID registers in the SPL CSF, as mentioned in U-Boot's HABv4 documentation, the system boots fine and I'm able to use the CAAM to encrypt artifacts.

[gabrielvalcazar]

I found the part of the imx-atf code that causes the target to freeze in plat/imx/imx8m/imx8mm/imx8mm_bl31_setup.c:

	/* Populate entry point information for BL32 */
	SET_PARAM_HEAD(&bl32_image_ep_info, PARAM_EP, VERSION_1, 0);
	SET_SECURITY_STATE(bl32_image_ep_info.h.attr, SECURE);
	bl32_image_ep_info.pc = BL32_BASE;
	bl32_image_ep_info.spsr = 0;

This is code that is only compiled if OP-TEE support is enabled, and I assume it's setting up the entry point info for the OP-TEE firmware. If I comment this specific part of the code, then the target boots - but I'm sure it's an integral part of the OP-TEE functionality.

I also noticed that, later on, a section of memory containing an FDT overlay generated by the SPL is erased. From what I understand, this overlay adds nodes related with OP-TEE to the bootloader's device tree. Could it be that the source device tree is missing something, causing the OP-TEE to fail mid-boot?