[U-Boot] [PATCH] ARM: tegra: restrict usable RAM size further

[Stephen Warren]

On 07/30/2015 09:52 AM, Simon Glass wrote:
> Hi,
>
> On 30 July 2015 at 09:43, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>
>> On 07/30/2015 05:04 AM, Thierry Reding wrote:
>>>
>>> On Wed, Jul 29, 2015 at 01:47:58PM -0600, Stephen Warren wrote:
>>>>
>>>> From: Stephen Warren <swarren at nvidia.com>
>>>>
>>>> Additionally, ARM64 devices typically run a secure monitor in EL3 and
>>>> U-Boot in EL2, and set up some secure RAM carve-outs to contain the EL3
>>>> code and data. These carve-outs are located at the top of 32-bit address
>>>> space. Restrict U-Boot's RAM usage to well below the location of those
>>>> carve-outs. Ideally, we would the secure monitor would inform U-Boot of
>>>> exactly which RAM it could use at run-time. However, I'm not sure how to
>>>> do that at present (and even if such a mechanism does exist, it would
>>>> likely not be generic across all forms of secure monitor).
>>>
>>>
>>> 0xe0000000-0xffffffff is 512 MiB, surely a secure monitor can live with
>>> less than that!
>>
>>
>> I'm sure it does. However, it's a nice round number and leaves plenty of space for arbitrary expansion of the secure monitor, secure OS, other security-related carve-outs, (video regions, LP0 resume firmware, etc.) There's still plenty of space left for U-Boot after that.
>
> I'd really hope that these can be in U-Boot's remit. except perhaps
> the secure OS. Should we figure out how to build the secure monitor
> within the U-Boot environment? Is creating a bootable image going to
> become really complicated? Why would video regions and resume firmware
> not be set up by U-Boot?

The secure OS may (depending on exactly which applications it hosts I 
guess) use some of these regions itself. So, everything needs to be set 
up before the secure OS runs IIUC.

I can imagine a secure OS wanting to do display output (e.g. in an 
overlay plane at least). The same goes for pretty much any feature of 
the system really; it's up to the SW stack builder to decide which 
functions to partition into their secure vs non-secure SW.

The system should be able to suspend/resume under the control of the 
secure OS (taking requests from whatever non-secure SW stack may be 
running and interacting with the user, or autonomously if more system 
level control is implemented in the secure OS). Hence, all the system 
level SW needs to be set up early.

At least initially, we're targeting booting the system with the same 
bootloader that L4T and Android use for unification. U-Boot runs after 
the base security/... environment is set up to provide a flexible user 
experience for untrusted OS loading. Hopefully this won't make flashing 
a system too much more complex, but there will inevitably be some 
differences. Hopefully it'll get mostly hidden by tegra-uboot-flasher or 
some other tool.

At some point I hope we'll be able to get U-Boot to act as the first 
stage bootloader rather than just the non-secure bootloader. However, 
that requires a lot more work so certainly isn't something that's in the 
first round of Tegra210 support.