[U-Boot] "optee" Kbuild seems to have weird dependencies

[Bryan O'Donoghue]

On 23/04/2019 10:22, Jens Wiklander wrote:
> Hi Robert,
> 
> On Thu, Apr 18, 2019 at 10:19 PM Robert P. J. Day <rpjday at crashcourse.ca> wrote:
>>
>>
>>    going over the u-boot.cfg generated from zynq_zed_defconfig, and
>> noticed the following:
>>
>>    #define CONFIG_OPTEE_TZDRAM_BASE 0x00000000
>>    #define CONFIG_OPTEE_TZDRAM_SIZE 0x0000000
>>
>> i thought that was strange as CONFIG_OPTEE was not selected, so i
>> checked, and here's the relevant snippet from lib/optee/Kconfig:
>>
>>    config OPTEE
>>          bool "Support OPTEE images"
>>          help
>>            U-Boot can be configured to boot OPTEE images.
>>            Selecting this option will enable shared OPTEE library code and
>>            enable an OPTEE specific bootm command that will perform additional
>>            OPTEE specific checks before booting an OPTEE image created with
>>            mkimage.
>>
>>    config OPTEE_TZDRAM_SIZE
>>          hex "Amount of Trust-Zone RAM for the OPTEE image"
>>          default 0x0000000
>>          help
>>            The size of pre-allocated Trust Zone DRAM to allocate for the OPTEE
>>            runtime.
>>
>>    config OPTEE_TZDRAM_BASE
>>          hex "Base address of Trust-Zone RAM for the OPTEE image"
>>          default 0x00000000
>>          help
>>            The base address of pre-allocated Trust Zone DRAM for
>>            the OPTEE runtime.
>>
>> those two Kbuild directives are (strangely?) not dependent on OPTEE,
>> which is why they show up in u-boot.cfg. is this deliberate? i know
>> nothing about TEE, but it seems odd that OPTEE-related settings don't
>> depend on OPTEE.
>>
>>    am i misreading something?
> 
> It seems that the dependency was removed by Rui in c7b3a7ee5351
> ("optee: adjust dependencies and default values for dram").
> 
> If OPTEE_TZDRAM_SIZE and OPTEE_TZDRAM_BASE are needed or not depends
> on the platform and should be selected in some way by the platform.

We can probably zap those two defines. Do we really need them to verify 
the image ? No. Could we live without them ? Yes. You could just as 
easily have an environment variable and ignore the size, which is in 
effect what we do with most other load addresses anyway.

I'll patch that out.

> 
>>
>> rday
>>
>> p.s. the MAINTAINERS entry for TEE seems incomplete as well:
>>
>> TEE
>> M:      Jens Wiklander <jens.wiklander at linaro.org>
>> S:      Maintained
>> F:      drivers/tee/
>> F:      include/tee.h
>> F:      include/tee/
>>
>>    one suspects that should include, at the very least:
>>
>>    * lib/optee
>>    * include/config/optee
>>
> 
> I understand that this is confusing. OP-TEE is supported by U-Boot in
> two in two ways which are orthogonal.
> 
> We have loading and booting OP-TEE which is handled by lib/optee. In
> this case U-Boot is used as a Secure world boot loader. This was added
> by Bryan.
> 
> Then there's the TEE subsystem which includes a driver for
> communicating with OP-TEE in Secure world. This is mostly to support
> the Android Verified Boot 2.0 (AVB) use case, but can be used for
> other purposes too. In this case U-Boot is a Normal world boot loader.
> This was added by me.
> 
> I happen to know something about how OP-TEE is loaded, but I don't
> know much about the boards on which U-Boot is used for that purpose. I
> guess the best would be if Bryan added an entry for lib/optee in
> MAINTAINERS.

and I'll patch that too :)

---
bod