[U-Boot] [PATCH 4/5] ti_omap5_common: mark region of DRAM protected on HS parts

Allred, Daniel
2016-09-07T03:48:14Z

On 9/6/2016 3:54 PM, Andrew F. Davis wrote:
> On 09/02/2016 12:40 AM, Daniel Allred wrote:
>> If the ending portion of the DRAM is reserved for secure
>> world use, then u-boot cannot use this memory for its relocation
>> purposes. To prevent issues, we mark this memory as PRAM and this
>> prevents it from being used by u-boot at all.
>>
>> Signed-off-by: Daniel Allred <d-allred@ti.com>
>> ---
>> include/configs/ti_omap5_common.h | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/include/configs/ti_omap5_common.h b/include/configs/ti_omap5_common.h
>> index e42c88e..70fdc6e 100644
>> --- a/include/configs/ti_omap5_common.h
>> +++ b/include/configs/ti_omap5_common.h
>> @@ -146,6 +146,14 @@
>> */
>> #define TI_OMAP5_SECURE_BOOT_RESV_SRAM_SZ 0x1000
>> #define CONFIG_SPL_TEXT_BASE 0x40301350
>> +/* If no specific start address is specified then the secure EMIF
>> + * region will be placed at the end of the DDR space. In order to prevent
>> + * the main u-boot relocation from clobbering that memory and causing a
>> + * firewall violation, we tell u-boot that memory is protected RAM (PRAM)
>> + */
>> +#if (CONFIG_TI_SECURE_EMIF_REGION_START == 0)
>
> What about if we set the start address manually, what prevents u-boot
> from over-writing that memory?
Nothing. The PRAM mechanism, as it is currently defined in the u-boot code, can only protect the RAM at the end. It prevents u-boot from seeing that memory so that it won't try to relocate itself there during the u-boot relocation. We found this was needed because the firewalls are warm-reset insensitive and so u-boot could cause firewall violations after a warm reset. So we really need to put this memory somewhere where it can be set aside from all other uses, and the CONFIG_PRAM mechanism accomplishes this.

If you manually place it anywhere else in the DRAM, you have to make sure that memory will not be used by any u-boot code. I think we saw one case early on in development where the location of the secure OS ended up conflicting with the Ethernet buffer memory, thus breaking network/NFS booting (that was when we were loading the TEE under Linux, so we only saw the violation on warm reset, not the initial boot). Since all other DRAM users in u-boot avoid the end of DRAM because of its use for u-boot relocation, using the PRAM option to put it there avoids all possible issues. So manual placement can work, but it has more risks. But you can then place the secure OS/TEE at a fixed location, which could be helpful if it is not PIC and you want to support it across quite a few platforms with different memory sizes without a re-link.

Regards, Daniel
>
>> +#define CONFIG_PRAM (CONFIG_TI_SECURE_EMIF_TOTAL_REGION_SIZE) >> 10
>> +#endif
>> #else
>> /*
>> * For all booting on GP parts, the flash loader image is
>>