v4: - New type "optee" renamed to "tee-bootable". We discussed making the namespace here more logical and obvious in another thread.
Kever may or may not end up adding "tee-combo". This patchset will result in "tee" and "tee-bootable" being valid names. Since "tee" is an existing image type the name will be maintained. - Tom - Added doc/README.trusted-execution-environment This gives a brief introduction on TEE plus some links to the spec and the op-tee website. In then lays out the difference between these two types "tee" (tee-standalone) "tee-bootable" - Bryan, Philipp - Small change made to comment on existing TEE - Bryan - Reworded the Kconfig option "OPTEE" Makes a little bit more sense to me re-reading now - Bryan - Add patch to define CONFIG_OPTEE_LOAD_ADDR An upcoming set of patches for a board will make use of this define in an OPTEE context. v3: - Rework printout to be added at the end as opposed to churn over three separate patches - Andrew - Reword patch 006 to better explain the thinking behind new image type - Andrew v2: - Added CONFIG_OPTEE_TZDRAM_BASE instead of #ifndef OPTEE_TZDRAM_BASE as an error. - Tom Rini - Added Tested-by: Peng Fan <peng....@nxp.com> - as indicated - Added better explanation text to patch 6/9 "tools: mkimage: add optee image type" - Fixed some checkpatch warnings in optee.c v1: This series adds a new OPTEE bootable image type to u-boot, which is directly bootable with the bootm command. There is already a TEE image type but, in this case the TEE firmware is loaded into RAM, jumped into and then back out of. This image type is a directly bootable image as described here : http://mrvan.github.io/optee-imx6ul Instead of reusing the Linux bootable image type instead a new image type is defined, which allows us to perform additional image verification, prior to handing off control via bootm. OPTEE images get linked to a specific address at compile time and must be loaded to this address too. This series extends out mkimage with a new image type that allows the OPTEE binary link location to be validated against CONFIG_OPTEE_TZDRAM_BASE and CONFIG_OPTEE_TZDRAM_SIZE respectively prior to proceeding through the bootm phase. Once applied you can generate a bootable OPTEE image like this mkimage -A arm -T optee -C none -d ./out/arm-plat-imx/core/tee.bin uTee.optee That image can then be booted directly by bootm. bootm will verify the header contents of the OPTEE binary against the DRAM area carved out in u-boot. If the defined DRAM area does not match the link address specified we refuse to boot. Kever - I'd like to suggest that your OPTEE SPL image takes a different image type IH_TYPE_OPTEE_SPL ? to indicate the different behavior your image type has versus a directly bootable bootm image. Bryan O'Donoghue (12): optee: Add lib entries for sharing OPTEE code across ports optee: Add CONFIG_OPTEE_TZDRAM_SIZE optee: Add CONFIG_OPTEE_TZDRAM_BASE optee: Add optee_image_get_entry_point() optee: Add optee_image_get_load_addr() image: Update comment for IH_TYPE_TEE tools: mkimage: add tee-bootable image type doc: TEE: Add documentation describing TEE in u-boot optee: Add optee_verify_bootm_image() optee: Add error printout bootm: optee: Add mechanism to validate a bootable TEE image optee: Add CONFIG_OPTEE_LOAD_ADDR common/bootm.c | 11 ++- common/image.c | 1 + doc/README.trusted-execution-environment | 123 +++++++++++++++++++++++++++++++ include/image.h | 3 +- include/tee/optee.h | 41 +++++++++++ lib/Kconfig | 1 + lib/Makefile | 1 + lib/optee/Kconfig | 29 ++++++++ lib/optee/Makefile | 7 ++ lib/optee/optee.c | 66 +++++++++++++++++ tools/default_image.c | 25 +++++-- 11 files changed, 300 insertions(+), 8 deletions(-) create mode 100644 doc/README.trusted-execution-environment create mode 100644 lib/optee/Kconfig create mode 100644 lib/optee/Makefile create mode 100644 lib/optee/optee.c -- 2.7.4 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot