[U-Boot] [PATCH 1/5] ti: omap5: Add Kconfig options for secure EMIF reservations

[Allred, Daniel]

On 9/6/2016 3:23 PM, Andrew F. Davis wrote:
> On 09/02/2016 12:40 AM, Daniel Allred wrote:
>> Adds start address and size config options for setting aside
>> a portion of the EMIF memory space for usage by security software
>> (like a secure OS/TEE). There are two sizes, a total size and a
>> protected size. The region is divided into protected (secure) and
>> unprotected (public) regions, that are contiguous and start at the
>> start address given. If the start address is zero, the intention
>> is that the region will be automatically placed at the end of the
>> available external DRAM space.
>>
>> Signed-off-by: Daniel Allred <d-allred at ti.com>
>> ---
>>  arch/arm/cpu/armv7/omap5/Kconfig | 26 ++++++++++++++++++++++++++
>>  1 file changed, 26 insertions(+)
>>
>> diff --git a/arch/arm/cpu/armv7/omap5/Kconfig b/arch/arm/cpu/armv7/omap5/Kconfig
>> index a8600b1..25474ed 100644
>> --- a/arch/arm/cpu/armv7/omap5/Kconfig
>> +++ b/arch/arm/cpu/armv7/omap5/Kconfig
>> @@ -24,6 +24,32 @@ endchoice
>>  config SYS_SOC
>>  	default "omap5"
>>  
>> +config TI_SECURE_EMIF_REGION_START
>> +	hex "Reserved EMIF region start address"
>> +	depends on TI_SECURE_DEVICE
>> +	default 0x0
>> +	help
>> +	  Reserved EMIF region start address. Set to "0" to auto-select
>> +	  to be at the end of the external memory region.
> 
> The secure image that is placed in this location (OPTEE OS for now) will
> probably not be relocatable, what happens when we add RAM to a board
> (some boards take regular ram sticks), will our secure world suddenly
> break? What do we gain from having the location auto-selected?
See the answer I provided to the other patch about PRAM. Auto-selection isn't the key, but putting it at the end out of the way of all potential conflicts is. If the secure OS/TEE is not PIC, then re-linking will be required if the RAM size changes. But I personally see a change in RAM size as a new platform/board, so I don't think rebuilding some of the SW for that platform is completely unreasonable. Ultimately, it will depend on the secure OS/TEE.
> 
>> +
>> +config TI_SECURE_EMIF_TOTAL_REGION_SIZE
> 
> Instead of having the total combined size of both the protected and
> non-protected secure region then subtracting out the protected below to
> get the non-protected, why not have:
> 
> TI_SECURE_EMIF_PUBLIC_REGION_SIZE
> TI_SECURE_EMIF_PROTECTED_REGION_SIZE
> 
> then add the two to get the total region size? This would also remove
> some checks to make sure the total isn't smaller than one part, plus it
> removes the need for any mental math in figuring the size of the public
> region.
We had it this way previously, but the code ended up more complicated (though maybe the preprocessor checks were simpler). Having seen it both ways, I think it is a wash.

Daniel
> 
>> +	hex "Reserved EMIF region size"
>> +	depends on TI_SECURE_DEVICE
>> +	default 0x0
>> +	help
>> +	  Total reserved EMIF region size. Default is 0, which means no reserved EMIF
>> +	  region on secure devices.
>> +
>> +config TI_SECURE_EMIF_PROTECTED_REGION_SIZE
>> +	hex "Size of protected region within reserved EMIF region"
>> +	depends on TI_SECURE_DEVICE
>> +	default 0x0
>> +	help
>> +	  This config option is used to specify the size of the portion of the total
>> +	  reserved EMIF region set aside for secure OS needs that will  be protected
>> +	  using hardware memory firewalls. This value must be smaller than the
>> +	  TI_SECURE_EMIF_TOTAL_REGION_SIZE value.
>> +
>>  source "board/compulab/cm_t54/Kconfig"
>>  source "board/ti/omap5_uevm/Kconfig"
>>  source "board/ti/dra7xx/Kconfig"
>>