On 07/30/2015 09:52 AM, Simon Glass wrote:
Hi,
On 30 July 2015 at 09:43, Stephen Warren swarren@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@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.