[0/9] Add new OPTEE bootm support to u-boot

Message ID 1515768744-25246-1-git-send-email-bryan.odonoghue@linaro.org
Headers show
Series
  • Add new OPTEE bootm support to u-boot
Related show

Message

Bryan O'Donoghue Jan. 12, 2018, 2:52 p.m.
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 (9):
  optee: Add lib entries for sharing OPTEE code across ports
  optee: Add CONFIG_OPTEE_TZDRAM_SIZE
  optee: Make OPTEE_TZDRAM_BASE a mandatory define
  optee: Add optee_image_get_entry_point()
  optee: Add optee_image_get_load_addr()
  tools: mkimage: add optee image type
  optee: Add optee_verify_bootm_image()
  optee: Improve error printout
  bootm: optee: Add mechanism to validate an OPTEE image before boot

 common/bootm.c        | 11 +++++++-
 common/image.c        |  1 +
 include/image.h       |  1 +
 include/tee/optee.h   | 41 ++++++++++++++++++++++++++++++
 lib/Kconfig           |  1 +
 lib/Makefile          |  1 +
 lib/optee/Kconfig     | 16 ++++++++++++
 lib/optee/Makefile    |  7 ++++++
 lib/optee/optee.c     | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++
 tools/default_image.c | 25 ++++++++++++++-----
 10 files changed, 166 insertions(+), 7 deletions(-)
 create mode 100644 lib/optee/Kconfig
 create mode 100644 lib/optee/Makefile
 create mode 100644 lib/optee/optee.c

Comments

Peng Fan Jan. 15, 2018, 4 a.m. | #1
Hi Bryan,
On Fri, Jan 12, 2018 at 02:52:15PM +0000, Bryan O'Donoghue wrote:
>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 (9):
>  optee: Add lib entries for sharing OPTEE code across ports
>  optee: Add CONFIG_OPTEE_TZDRAM_SIZE
>  optee: Make OPTEE_TZDRAM_BASE a mandatory define
>  optee: Add optee_image_get_entry_point()
>  optee: Add optee_image_get_load_addr()
>  tools: mkimage: add optee image type
>  optee: Add optee_verify_bootm_image()
>  optee: Improve error printout
>  bootm: optee: Add mechanism to validate an OPTEE image before boot
>
> common/bootm.c        | 11 +++++++-
> common/image.c        |  1 +
> include/image.h       |  1 +
> include/tee/optee.h   | 41 ++++++++++++++++++++++++++++++
> lib/Kconfig           |  1 +
> lib/Makefile          |  1 +
> lib/optee/Kconfig     | 16 ++++++++++++
> lib/optee/Makefile    |  7 ++++++
> lib/optee/optee.c     | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++
> tools/default_image.c | 25 ++++++++++++++-----
> 10 files changed, 166 insertions(+), 7 deletions(-)
> create mode 100644 lib/optee/Kconfig
> create mode 100644 lib/optee/Makefile
> create mode 100644 lib/optee/optee.c

Thanks for patchset. I gave a test on i.MX7D-SDB and it works well.

Tested-by: Peng Fan <peng.fan@nxp.com>

>
>-- 
>2.7.4
>
>_______________________________________________
>U-Boot mailing list
>U-Boot@lists.denx.de
>https://lists.denx.de/listinfo/u-boot
Kever Yang Jan. 15, 2018, 4:39 a.m. | #2
Hi Bryan,

On 01/12/2018 10:52 PM, Bryan O'Donoghue wrote:
> 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 is how OP-TEE upstream designed flow, isn't it?
> This image type is a
> directly bootable image as described here :
> http://mrvan.github.io/optee-imx6ul

Still not clear about the detail flow you are using :( I don't 
understand why
we need to support OP-TEE in bootm.
Do you make U-Boot working in secure word?
>
> 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.

Well, I think we can decide after everything is clear.

Thanks,
-Kever
>
> Bryan O'Donoghue (9):
>    optee: Add lib entries for sharing OPTEE code across ports
>    optee: Add CONFIG_OPTEE_TZDRAM_SIZE
>    optee: Make OPTEE_TZDRAM_BASE a mandatory define
>    optee: Add optee_image_get_entry_point()
>    optee: Add optee_image_get_load_addr()
>    tools: mkimage: add optee image type
>    optee: Add optee_verify_bootm_image()
>    optee: Improve error printout
>    bootm: optee: Add mechanism to validate an OPTEE image before boot
>
>   common/bootm.c        | 11 +++++++-
>   common/image.c        |  1 +
>   include/image.h       |  1 +
>   include/tee/optee.h   | 41 ++++++++++++++++++++++++++++++
>   lib/Kconfig           |  1 +
>   lib/Makefile          |  1 +
>   lib/optee/Kconfig     | 16 ++++++++++++
>   lib/optee/Makefile    |  7 ++++++
>   lib/optee/optee.c     | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++
>   tools/default_image.c | 25 ++++++++++++++-----
>   10 files changed, 166 insertions(+), 7 deletions(-)
>   create mode 100644 lib/optee/Kconfig
>   create mode 100644 lib/optee/Makefile
>   create mode 100644 lib/optee/optee.c
>
Philipp Tomsich Jan. 15, 2018, 10:24 a.m. | #3
> On 15 Jan 2018, at 05:39, Kever Yang <kever.yang@rock-chips.com> wrote:
> 
> Hi Bryan,
> 
> On 01/12/2018 10:52 PM, Bryan O'Donoghue wrote:
>> 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 is how OP-TEE upstream designed flow, isn't it?
>> This image type is a
>> directly bootable image as described here :
>> http://mrvan.github.io/optee-imx6ul
> 
> Still not clear about the detail flow you are using :( I don't understand why
> we need to support OP-TEE in bootm.
> Do you make U-Boot working in secure word?

I would also prefer if we could leave the secure world prior to executing the
full U-Boot… it reduces the attack surface and will be similar to what we do
on ARMv8 with ATF.

>> 
>> 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.
> 
> Well, I think we can decide after everything is clear.
> 
> Thanks,
> -Kever
>> 
>> Bryan O'Donoghue (9):
>>   optee: Add lib entries for sharing OPTEE code across ports
>>   optee: Add CONFIG_OPTEE_TZDRAM_SIZE
>>   optee: Make OPTEE_TZDRAM_BASE a mandatory define
>>   optee: Add optee_image_get_entry_point()
>>   optee: Add optee_image_get_load_addr()
>>   tools: mkimage: add optee image type
>>   optee: Add optee_verify_bootm_image()
>>   optee: Improve error printout
>>   bootm: optee: Add mechanism to validate an OPTEE image before boot
>> 
>>  common/bootm.c        | 11 +++++++-
>>  common/image.c        |  1 +
>>  include/image.h       |  1 +
>>  include/tee/optee.h   | 41 ++++++++++++++++++++++++++++++
>>  lib/Kconfig           |  1 +
>>  lib/Makefile          |  1 +
>>  lib/optee/Kconfig     | 16 ++++++++++++
>>  lib/optee/Makefile    |  7 ++++++
>>  lib/optee/optee.c     | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++
>>  tools/default_image.c | 25 ++++++++++++++-----
>>  10 files changed, 166 insertions(+), 7 deletions(-)
>>  create mode 100644 lib/optee/Kconfig
>>  create mode 100644 lib/optee/Makefile
>>  create mode 100644 lib/optee/optee.c
>> 
> 
>
Philipp Tomsich Jan. 15, 2018, 10:29 a.m. | #4
> On 15 Jan 2018, at 11:24, Dr. Philipp Tomsich <philipp.tomsich@theobroma-systems.com> wrote:
> 
>> 
>> On 15 Jan 2018, at 05:39, Kever Yang <kever.yang@rock-chips.com> wrote:
>> 
>> Hi Bryan,
>> 
>> On 01/12/2018 10:52 PM, Bryan O'Donoghue wrote:
>>> 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 is how OP-TEE upstream designed flow, isn't it?
>>> This image type is a
>>> directly bootable image as described here :
>>> http://mrvan.github.io/optee-imx6ul
>> 
>> Still not clear about the detail flow you are using :( I don't understand why
>> we need to support OP-TEE in bootm.
>> Do you make U-Boot working in secure word?
> 
> I would also prefer if we could leave the secure world prior to executing the
> full U-Boot… it reduces the attack surface and will be similar to what we do
> on ARMv8 with ATF.

I forgot to mention that Falcon-mode w/ OPTEE will only be possible if the
OPTEE is loaded from SPL.

As I would like to avoid having two different ways to load an OPTEE within
U-Boot, this seems to also bias the “default boot sequence” towards inserting
OPTEE between SPL and the OS-stage (whether this is IH_OS_U_BOOT,
IH_OS_LINUX or something else).

Regards,
Philipp.

> 
>>> 
>>> 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.
>> 
>> Well, I think we can decide after everything is clear.
>> 
>> Thanks,
>> -Kever
>>> 
>>> Bryan O'Donoghue (9):
>>>  optee: Add lib entries for sharing OPTEE code across ports
>>>  optee: Add CONFIG_OPTEE_TZDRAM_SIZE
>>>  optee: Make OPTEE_TZDRAM_BASE a mandatory define
>>>  optee: Add optee_image_get_entry_point()
>>>  optee: Add optee_image_get_load_addr()
>>>  tools: mkimage: add optee image type
>>>  optee: Add optee_verify_bootm_image()
>>>  optee: Improve error printout
>>>  bootm: optee: Add mechanism to validate an OPTEE image before boot
>>> 
>>> common/bootm.c        | 11 +++++++-
>>> common/image.c        |  1 +
>>> include/image.h       |  1 +
>>> include/tee/optee.h   | 41 ++++++++++++++++++++++++++++++
>>> lib/Kconfig           |  1 +
>>> lib/Makefile          |  1 +
>>> lib/optee/Kconfig     | 16 ++++++++++++
>>> lib/optee/Makefile    |  7 ++++++
>>> lib/optee/optee.c     | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++
>>> tools/default_image.c | 25 ++++++++++++++-----
>>> 10 files changed, 166 insertions(+), 7 deletions(-)
>>> create mode 100644 lib/optee/Kconfig
>>> create mode 100644 lib/optee/Makefile
>>> create mode 100644 lib/optee/optee.c
Peng Fan Jan. 15, 2018, 12:03 p.m. | #5
On Mon, Jan 15, 2018 at 11:29:41AM +0100, Dr. Philipp Tomsich wrote:
>
>> On 15 Jan 2018, at 11:24, Dr. Philipp Tomsich <philipp.tomsich@theobroma-systems.com> wrote:
>> 
>>> 
>>> On 15 Jan 2018, at 05:39, Kever Yang <kever.yang@rock-chips.com> wrote:
>>> 
>>> Hi Bryan,
>>> 
>>> On 01/12/2018 10:52 PM, Bryan O'Donoghue wrote:
>>>> 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 is how OP-TEE upstream designed flow, isn't it?
>>>> This image type is a
>>>> directly bootable image as described here :
>>>> http://mrvan.github.io/optee-imx6ul
>>> 
>>> Still not clear about the detail flow you are using :( I don't understand why
>>> we need to support OP-TEE in bootm.
>>> Do you make U-Boot working in secure word?
>> 
>> I would also prefer if we could leave the secure world prior to executing the
>> full U-Boot??? it reduces the attack surface and will be similar to what we do
>> on ARMv8 with ATF.
>
>I forgot to mention that Falcon-mode w/ OPTEE will only be possible if the
>OPTEE is loaded from SPL.

Falcon-mode is a good feature, but not everyone use Falcon-mode.

>
>As I would like to avoid having two different ways to load an OPTEE within
>U-Boot, this seems to also bias the ???default boot sequence??? towards inserting
>OPTEE between SPL and the OS-stage (whether this is IH_OS_U_BOOT,
>IH_OS_LINUX or something else).


Providing the bootm way gives developer a choice for those that does not
support SPL.  We have been using bootm to boot optee for long time.

Thanks,
Peng

>
>Regards,
>Philipp.
>
>> 
>>>> 
>>>> 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.
>>> 
>>> Well, I think we can decide after everything is clear.
>>> 
>>> Thanks,
>>> -Kever
>>>> 
>>>> Bryan O'Donoghue (9):
>>>>  optee: Add lib entries for sharing OPTEE code across ports
>>>>  optee: Add CONFIG_OPTEE_TZDRAM_SIZE
>>>>  optee: Make OPTEE_TZDRAM_BASE a mandatory define
>>>>  optee: Add optee_image_get_entry_point()
>>>>  optee: Add optee_image_get_load_addr()
>>>>  tools: mkimage: add optee image type
>>>>  optee: Add optee_verify_bootm_image()
>>>>  optee: Improve error printout
>>>>  bootm: optee: Add mechanism to validate an OPTEE image before boot
>>>> 
>>>> common/bootm.c        | 11 +++++++-
>>>> common/image.c        |  1 +
>>>> include/image.h       |  1 +
>>>> include/tee/optee.h   | 41 ++++++++++++++++++++++++++++++
>>>> lib/Kconfig           |  1 +
>>>> lib/Makefile          |  1 +
>>>> lib/optee/Kconfig     | 16 ++++++++++++
>>>> lib/optee/Makefile    |  7 ++++++
>>>> lib/optee/optee.c     | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++
>>>> tools/default_image.c | 25 ++++++++++++++-----
>>>> 10 files changed, 166 insertions(+), 7 deletions(-)
>>>> create mode 100644 lib/optee/Kconfig
>>>> create mode 100644 lib/optee/Makefile
>>>> create mode 100644 lib/optee/optee.c
>
>_______________________________________________
>U-Boot mailing list
>U-Boot@lists.denx.de
>https://lists.denx.de/listinfo/u-boot
Philipp Tomsich Jan. 15, 2018, 1:26 p.m. | #6
> On 15 Jan 2018, at 13:03, Peng Fan <van.freenix@gmail.com> wrote:
> 
> On Mon, Jan 15, 2018 at 11:29:41AM +0100, Dr. Philipp Tomsich wrote:
>> 
>>> On 15 Jan 2018, at 11:24, Dr. Philipp Tomsich <philipp.tomsich@theobroma-systems.com> wrote:
>>> 
>>>> 
>>>> On 15 Jan 2018, at 05:39, Kever Yang <kever.yang@rock-chips.com> wrote:
>>>> 
>>>> Hi Bryan,
>>>> 
>>>> On 01/12/2018 10:52 PM, Bryan O'Donoghue wrote:
>>>>> 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 is how OP-TEE upstream designed flow, isn't it?
>>>>> This image type is a
>>>>> directly bootable image as described here :
>>>>> http://mrvan.github.io/optee-imx6ul
>>>> 
>>>> Still not clear about the detail flow you are using :( I don't understand why
>>>> we need to support OP-TEE in bootm.
>>>> Do you make U-Boot working in secure word?
>>> 
>>> I would also prefer if we could leave the secure world prior to executing the
>>> full U-Boot??? it reduces the attack surface and will be similar to what we do
>>> on ARMv8 with ATF.
>> 
>> I forgot to mention that Falcon-mode w/ OPTEE will only be possible if the
>> OPTEE is loaded from SPL.
> 
> Falcon-mode is a good feature, but not everyone use Falcon-mode.
> 
>> 
>> As I would like to avoid having two different ways to load an OPTEE within
>> U-Boot, this seems to also bias the ???default boot sequence??? towards inserting
>> OPTEE between SPL and the OS-stage (whether this is IH_OS_U_BOOT,
>> IH_OS_LINUX or something else).
> 
> 
> Providing the bootm way gives developer a choice for those that does not
> support SPL.  We have been using bootm to boot optee for long time.

Interesting to hear. Could you provide some additional feedback on how you
boot these boards today (e.g. how is U-Boot loaded, if there is no SPL; is
U-Boot running in secure mode, as we seem to have inferred from the earlier
conversation)?

> 
> Thanks,
> Peng
> 
>> 
>> Regards,
>> Philipp.
>> 
>>> 
>>>>> 
>>>>> 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.
>>>> 
>>>> Well, I think we can decide after everything is clear.
>>>> 
>>>> Thanks,
>>>> -Kever
>>>>> 
>>>>> Bryan O'Donoghue (9):
>>>>> optee: Add lib entries for sharing OPTEE code across ports
>>>>> optee: Add CONFIG_OPTEE_TZDRAM_SIZE
>>>>> optee: Make OPTEE_TZDRAM_BASE a mandatory define
>>>>> optee: Add optee_image_get_entry_point()
>>>>> optee: Add optee_image_get_load_addr()
>>>>> tools: mkimage: add optee image type
>>>>> optee: Add optee_verify_bootm_image()
>>>>> optee: Improve error printout
>>>>> bootm: optee: Add mechanism to validate an OPTEE image before boot
>>>>> 
>>>>> common/bootm.c        | 11 +++++++-
>>>>> common/image.c        |  1 +
>>>>> include/image.h       |  1 +
>>>>> include/tee/optee.h   | 41 ++++++++++++++++++++++++++++++
>>>>> lib/Kconfig           |  1 +
>>>>> lib/Makefile          |  1 +
>>>>> lib/optee/Kconfig     | 16 ++++++++++++
>>>>> lib/optee/Makefile    |  7 ++++++
>>>>> lib/optee/optee.c     | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>> tools/default_image.c | 25 ++++++++++++++-----
>>>>> 10 files changed, 166 insertions(+), 7 deletions(-)
>>>>> create mode 100644 lib/optee/Kconfig
>>>>> create mode 100644 lib/optee/Makefile
>>>>> create mode 100644 lib/optee/optee.c
>> 
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot@lists.denx.de <mailto:U-Boot@lists.denx.de>
>> https://lists.denx.de/listinfo/u-boot <https://lists.denx.de/listinfo/u-boot>
> 
> --
Bryan O'Donoghue Jan. 15, 2018, 2:01 p.m. | #7
On 15/01/18 12:03, Peng Fan wrote:
> Providing the bootm way gives developer a choice for those that does not
> support SPL.  We have been using bootm to boot optee for long time.
> 
> Thanks,
> Peng

Philipp,

My understanding is that bootm is the preferred armv7 method..

In principle we should be able to support both the SPL and bootm methods.