AnsweredAssumed Answered

Handling OpTEE binary header with Arm Trusted Firmware on iMX8M

Question asked by Neil Shipp on Sep 27, 2018
Latest reply on Oct 10, 2018 by Diego Adrian Cuevas

I'm attempting to load OpTEE on the MCIMX8MEVK board and am having an issue with the image loading. 

 

The build process for OpTEE on https://source.codeaurora.org/external/imx/imx-optee-os/tree/core/arch/arm/kernel/link.mk?h=imx_4.9.88_2.0.0_ga produces a tee.bin with a 24 byte header, and two more files tee-pager.bin and a zero length tee-pageable.bin.  The mkimage build process on https://source.codeaurora.org/external/imx/imx-mkimage/tree/iMX8M/mkimage_fit_atf.sh?h=imx_4.9.123_imx8mm_ga looks for a tee.bin and puts it into the fit unchanged. Finally the opteed_setup code in https://source.codeaurora.org/external/imx/imx-atf/tree/services/spd/opteed/opteed_main.c?h=imx_4.9.123_imx8mm_ga assumes that there's no header and uses the binary as is.  This results in the processor attempting to execute the header block.

 

I can resolve this by using the tee-pager.bin file as the input to mkimage, but this throws away the header information. And will cause problems if data is moved into the tee-pageable.bin file. The change to handle this header has been available since 2014 in the Linaro-SecureWorkingGroup tree, https://github.com/linaro-swg/arm-trusted-firmware/commit/f6244e85df1d931e2ed6bd80e76fbf05a1b32f23#diff-5b5a3d8c61b39e1fe27ee096c7bc41ee  which checks for the header and shifts the memory region.  In NXP's https://source.codeaurora.org/external/imx/imx-atf/tree/lib/optee/optee_utils.c?h=imx_4.9.123_imx8mm_ga there is code that reads the OpTEE header, but it is only used by arm_bl2_setup.c which isn't built using the current yocto recipes.

 

I'm wondering it is NXP's plan to merge this change to the ATF opteed SPD, or to what their recommendation is for using OpTEE on imx8m?

Outcomes