ARM: tegra: restrict usable RAM size further
Subsystems (3)
PATCH 1/1 ARM: tegra: restrict usable RAM size further
From: Stephen Warren <[email protected]>
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).
--- arch/arm/mach-tegra/board2.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-)
arch/arm/mach-tegra/board2.c +11 -2
@@ -287,11 +287,20 @@ void pad_init_mmc(struct mmc_host *host)* 32-bits of the physical address space. Cap the maximum usable RAM area * at 4 GiB to avoid DMA buffers from being allocated beyond the 32-bit * boundary that most devices can address. +* +* 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). */ ulong board_get_usable_ram_top (ulong total_size) { -if (gd->ram_top >0x100000000 ) -return 0x100000000 ; +if (gd->ram_top >0xe0000000 ) +return 0xe0000000 ;return gd->ram_top; }
Signature · 1 line
1.9.1
PATCH 1/1 ARM: tegra: restrict usable RAM size further
Quoted 10 lines · Stephen Warren
From: Stephen Warren <[email protected]>
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!
Thierry
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150730/6e1c4adc/attachment.sig>
PATCH 1/1 ARM: tegra: restrict usable RAM size further
Quoted 12 lines · Thierry Reding
Quoted 10 lines · Stephen Warren
From: Stephen Warren <[email protected]>
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).
Quoted 2 lines
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.
PATCH 1/1 ARM: tegra: restrict usable RAM size further
Hi,
Quoted 17 lines · Stephen Warren
Quoted 15 lines · Thierry Reding
Quoted 11 lines · Stephen Warren
From: Stephen Warren <[email protected]>
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).
Quoted 5 lines
Quoted 2 lines
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?
Regards,
Simon
PATCH 1/1 ARM: tegra: restrict usable RAM size further
Quoted 24 lines · Simon Glass
Hi,
Quoted 21 lines · Stephen Warren
Quoted 17 lines · Thierry Reding
Quoted 11 lines · Stephen Warren
From: Stephen Warren <[email protected]>
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!
Quoted 7 lines
Quoted 1 line
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.
PATCH 1/1 ARM: tegra: restrict usable RAM size further
Hi Stephen,
Quoted 68 lines · Stephen Warren
Quoted 38 lines · Simon Glass
Hi,
Quoted 28 lines · Stephen Warren
Quoted 20 lines · Thierry Reding
Quoted 4 lines · Stephen Warren
From: Stephen Warren <[email protected]>
Quoted 10 lines
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).Quoted 2 lines
0xe0000000-0xffffffff is 512 MiB, surely a secure monitor can live with less than that!
Quoted 4 lines
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.
Quoted 5 lines
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.
Quoted 4 lines
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.
Thanks for the explanation. Booting ARM devices might get as hard as x86 if we try really hard. Maybe we can add some run-time services as well...good luck!
Regards,
Simon
PATCH 1/1 ARM: tegra: restrict usable RAM size further
Quoted 3 lines · Simon Glass
Hi Stephen,
On 30 July 2015 at 12:47, Stephen Warren <[email protected]> wrote:
...
Quoted 7 lines
Quoted 7 lines
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.
Quoted 8 lines
Quoted 4 lines
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.
Thanks for the explanation. Booting ARM devices might get as hard as x86 if we try really hard. Maybe we can add some run-time services as well...good luck!
Well, at least PSCI is required by the ARM64 kernel now I believe, and there's plenty of push for ACPI in some environments too, so I expect the complexity will indeed converge!
PATCH 1/1 ARM: tegra: restrict usable RAM size further
In reply to Stephen WarrenQuoted 10 lines · Stephen Warren
From: Stephen Warren <[email protected]>
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).
TomW, what are your thoughts on applying this given the discussion thread? Thanks.
PATCH 1/1 ARM: tegra: restrict usable RAM size further
Quoted 19 lines
-----Original Message-----
From: Stephen Warren [mailto:swarren at wwwdotorg.org]
Sent: Wednesday, August 05, 2015 11:33 AM
To: Tom Warren
Cc: u-boot at lists.denx.de; Simon Glass; Stephen Warren; Thierry Reding
Subject: Re: [U-Boot] [PATCH] ARM: tegra: restrict usable RAM size furtherQuoted 10 lines · Stephen Warren
From: Stephen Warren <[email protected]>
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).
Quoted 2 lines
TomW, what are your thoughts on applying this given the discussion thread? Thanks.
I think this patch is fine. I have not set up any TZ/other carveouts (NVDEC,VPR,GPU,TSEC, etc.) yet in U-Boot, but I have in coreboot, and right now we're using approx. 153MB (0xf66c0000 - 0x100000000). So 512MB here seems large but OK, given that we'll still have tons of SDRAM left on most any modern board.
I can take this in on the next pass, if no one objects. Adding Marcel for Colibri T20/T30, since this'll affect those boards, too.
Tom
--
nvpublic
PATCH 1/1 ARM: tegra: restrict usable RAM size further
Quoted 19 lines · Tom Warren
Quoted 19 lines
-----Original Message-----
From: Stephen Warren [mailto:swarren at wwwdotorg.org]
Sent: Wednesday, August 05, 2015 11:33 AM
To: Tom Warren
Cc: u-boot at lists.denx.de; Simon Glass; Stephen Warren; Thierry Reding
Subject: Re: [U-Boot] [PATCH] ARM: tegra: restrict usable RAM size furtherQuoted 10 lines · Stephen Warren
From: Stephen Warren <[email protected]>
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).
Quoted 6 lines
Quoted 2 lines
TomW, what are your thoughts on applying this given the discussion thread? Thanks.
I think this patch is fine. I have not set up any TZ/other carveouts (NVDEC,VPR,GPU,TSEC, etc.) yet in U-Boot, but I have in coreboot, and right now we're using approx. 153MB (
0xf66c0000-0x100000000). So 512MB here seems large but OK, given that we'll still have tons of SDRAM left on most any modern board.I can take this in on the next pass, if no one objects. Adding Marcel for Colibri T20/T30, since this'll affect those boards, too.
Thanks. This should only affect Tegra210 boards, since the function I modified is under #ifdef CONFIG_ARM64.
PATCH 1/1 ARM: tegra: restrict usable RAM size further
Quoted 40 lines
-----Original Message-----
From: Stephen Warren [mailto:swarren at wwwdotorg.org]
Sent: Wednesday, August 05, 2015 12:27 PM
To: Tom Warren
Cc: u-boot at lists.denx.de; Simon Glass; Stephen Warren; Thierry Reding; Marcel Ziswiler
Subject: Re: [U-Boot] [PATCH] ARM: tegra: restrict usable RAM size furtherQuoted 11 lines · Tom Warren
Quoted 11 lines
-----Original Message-----
From: Stephen Warren [mailto:swarren at wwwdotorg.org]
Sent: Wednesday, August 05, 2015 11:33 AM
To: Tom Warren
Cc: u-boot at lists.denx.de; Simon Glass; Stephen Warren; Thierry Reding
Subject: Re: [U-Boot] [PATCH] ARM: tegra: restrict usable RAM size furtherQuoted 2 lines · Stephen Warren
From: Stephen Warren <[email protected]>
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
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 ofsecure monitor).
Quoted 5 lines
Quoted 3 lines
TomW, what are your thoughts on applying this given the discussion thread? Thanks.
I think this patch is fine. I have not set up any TZ/other carveouts
(NVDEC,VPR,GPU,TSEC, etc.) yet in U-Boot, but I have in coreboot, and right now we're using approx. 153MB (
0xf66c0000-0x100000000). So 512MB here seems large but OK, given that we'll still have tons of SDRAM left on most any modern board.Quoted 1 line
Quoted 5 lines
Quoted 1 line
I can take this in on the next pass, if no one objects. Adding Marcel for Colibri
T20/T30, since this'll affect those boards, too.
Thanks. This should only affect Tegra210 boards, since the function I modified is under #ifdef
CONFIG_ARM64.
Ah, yes. Missed that.
--
nvpublic