[U-Boot] [PATCH 1/3] ARM: tegra: Restrict usable RAM to 32-bit on 64-bit SoCs
From: Thierry Reding treding@nvidia.com
Most peripherals on Tegra can do DMA only to the lower 32-bit address space, even on 64-bit SoCs. This limitation is typically overcome by the use of an IOMMU. Since the IOMMU is not entirely trivial to set up and serves no other purpose (I/O protection, ...) in U-Boot, restrict 64-bit Tegra SoCs to the lower 32-bit address space for RAM. This ensures that the physical addresses of buffers that are programmed into the various DMA engines are valid and don't alias to lower addresses.
Signed-off-by: Thierry Reding treding@nvidia.com Signed-off-by: Tom Warren twarren@nvidia.com Signed-off-by: Stephen Warren swarren@nvidia.com --- These 3 patches are pre-requisites for T210 support (either compile-time or run-time) but don't seem to have been sent to the mailing lists recently.
arch/arm/mach-tegra/board2.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)
diff --git a/arch/arm/mach-tegra/board2.c b/arch/arm/mach-tegra/board2.c index ce9b6959efb1..e0d8687cbcfa 100644 --- a/arch/arm/mach-tegra/board2.c +++ b/arch/arm/mach-tegra/board2.c @@ -274,3 +274,19 @@ void pad_init_mmc(struct mmc_host *host) #endif /* T30 */ } #endif /* MMC */ + +#ifdef CONFIG_ARM64 +/* + * Most hardware on 64-bit Tegra is still restricted to DMA to the lower + * 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. + */ +ulong board_get_usable_ram_top(ulong total_size) +{ + if (gd->ram_top > 0x100000000) + return 0x100000000; + + return gd->ram_top; +} +#endif
From: Thierry Reding treding@nvidia.com
On 64-bit SoCs the I-cache isn't enabled in early code, so the default cache enable functions for 64-bit ARM can be used.
Signed-off-by: Thierry Reding treding@nvidia.com Signed-off-by: Tom Warren twarren@nvidia.com Signed-off-by: Stephen Warren swarren@nvidia.com --- arch/arm/mach-tegra/board.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-tegra/board.c b/arch/arm/mach-tegra/board.c index 222de6a7352d..58e996ecff70 100644 --- a/arch/arm/mach-tegra/board.c +++ b/arch/arm/mach-tegra/board.c @@ -182,7 +182,7 @@ void board_init_uart_f(void) setup_uarts(uart_ids); }
-#ifndef CONFIG_SYS_DCACHE_OFF +#if !defined(CONFIG_SYS_DCACHE_OFF) && !defined(CONFIG_ARM64) void enable_caches(void) { /* Enable D-cache. I-cache is already enabled in start.S */
Hi,
On 27 July 2015 at 11:45, Stephen Warren swarren@wwwdotorg.org wrote:
From: Thierry Reding treding@nvidia.com
On 64-bit SoCs the I-cache isn't enabled in early code, so the default cache enable functions for 64-bit ARM can be used.
Signed-off-by: Thierry Reding treding@nvidia.com Signed-off-by: Tom Warren twarren@nvidia.com Signed-off-by: Stephen Warren swarren@nvidia.com
arch/arm/mach-tegra/board.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Does this mean that U-Boot starts slowly?
Regards, Simon
On 07/28/2015 09:33 AM, Simon Glass wrote:
Hi,
On 27 July 2015 at 11:45, Stephen Warren swarren@wwwdotorg.org wrote:
From: Thierry Reding treding@nvidia.com
On 64-bit SoCs the I-cache isn't enabled in early code, so the default cache enable functions for 64-bit ARM can be used.
Signed-off-by: Thierry Reding treding@nvidia.com Signed-off-by: Tom Warren twarren@nvidia.com Signed-off-by: Stephen Warren swarren@nvidia.com
arch/arm/mach-tegra/board.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Does this mean that U-Boot starts slowly?
I haven't noticed it being slow:-)
From: Thierry Reding treding@nvidia.com
For 64-bit ARM SoCs we rely on non-U-Boot code to bring up the CPU in AArch64 mode so that we don't need the SPL. Non-cached memory is not implemented (yet) for 64-bit ARM.
Signed-off-by: Thierry Reding treding@nvidia.com Signed-off-by: Tom Warren twarren@nvidia.com Signed-off-by: Stephen Warren swarren@nvidia.com --- include/configs/tegra-common.h | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/include/configs/tegra-common.h b/include/configs/tegra-common.h index 7b4c0d70636e..49fa8b321064 100644 --- a/include/configs/tegra-common.h +++ b/include/configs/tegra-common.h @@ -43,7 +43,9 @@ #define CONFIG_SYS_MALLOC_LEN (4 << 20) /* 4MB */ #endif
+#ifndef CONFIG_ARM64 #define CONFIG_SYS_NONCACHED_MEMORY (1 << 20) /* 1 MiB */ +#endif
/* * NS16550 Configuration @@ -101,9 +103,11 @@ #define CONFIG_SYS_MEMTEST_START (NV_PA_SDRC_CS0 + 0x600000) #define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_MEMTEST_START + 0x100000)
+#ifndef CONFIG_ARM64 #ifndef CONFIG_SPL_BUILD #define CONFIG_USE_ARCH_MEMCPY #endif +#endif
/*----------------------------------------------------------------------- * Physical Memory Map
Hi,
On 27 July 2015 at 11:45, Stephen Warren swarren@wwwdotorg.org wrote:
From: Thierry Reding treding@nvidia.com
For 64-bit ARM SoCs we rely on non-U-Boot code to bring up the CPU in AArch64 mode so that we don't need the SPL. Non-cached memory is not implemented (yet) for 64-bit ARM.
Signed-off-by: Thierry Reding treding@nvidia.com Signed-off-by: Tom Warren twarren@nvidia.com Signed-off-by: Stephen Warren swarren@nvidia.com
include/configs/tegra-common.h | 4 ++++ 1 file changed, 4 insertions(+)
What does start up the CPU? Is this something that will be implemented in SPL later?
Regards, Simon
On 07/28/2015 09:33 AM, Simon Glass wrote:
Hi,
On 27 July 2015 at 11:45, Stephen Warren swarren@wwwdotorg.org wrote:
From: Thierry Reding treding@nvidia.com
For 64-bit ARM SoCs we rely on non-U-Boot code to bring up the CPU in AArch64 mode so that we don't need the SPL. Non-cached memory is not implemented (yet) for 64-bit ARM.
Signed-off-by: Thierry Reding treding@nvidia.com Signed-off-by: Tom Warren twarren@nvidia.com Signed-off-by: Stephen Warren swarren@nvidia.com
include/configs/tegra-common.h | 4 ++++ 1 file changed, 4 insertions(+)
What does start up the CPU? Is this something that will be implemented in SPL later?
At least initially, the plan is to use a separate bootloader on the boot CPU (was named AVP, but got renamed to BPMP lite in Tegra210). It's vaguely possible that U-Boot SPL support will exist in the future, but I'm not sure.
Hi Stephen,
On 28 July 2015 at 09:44, Stephen Warren swarren@wwwdotorg.org wrote:
On 07/28/2015 09:33 AM, Simon Glass wrote:
Hi,
On 27 July 2015 at 11:45, Stephen Warren swarren@wwwdotorg.org wrote:
From: Thierry Reding treding@nvidia.com
For 64-bit ARM SoCs we rely on non-U-Boot code to bring up the CPU in AArch64 mode so that we don't need the SPL. Non-cached memory is not implemented (yet) for 64-bit ARM.
Signed-off-by: Thierry Reding treding@nvidia.com Signed-off-by: Tom Warren twarren@nvidia.com Signed-off-by: Stephen Warren swarren@nvidia.com
include/configs/tegra-common.h | 4 ++++ 1 file changed, 4 insertions(+)
What does start up the CPU? Is this something that will be implemented in SPL later?
At least initially, the plan is to use a separate bootloader on the boot CPU (was named AVP, but got renamed to BPMP lite in Tegra210). It's vaguely possible that U-Boot SPL support will exist in the future, but I'm not sure.
Ah OK. Where does that live? I think SPL would be better.
Regards, Simon
On 07/28/2015 09:50 AM, Simon Glass wrote:
Hi Stephen,
On 28 July 2015 at 09:44, Stephen Warren swarren@wwwdotorg.org wrote:
On 07/28/2015 09:33 AM, Simon Glass wrote:
Hi,
On 27 July 2015 at 11:45, Stephen Warren swarren@wwwdotorg.org wrote:
From: Thierry Reding treding@nvidia.com
For 64-bit ARM SoCs we rely on non-U-Boot code to bring up the CPU in AArch64 mode so that we don't need the SPL. Non-cached memory is not implemented (yet) for 64-bit ARM.
Signed-off-by: Thierry Reding treding@nvidia.com Signed-off-by: Tom Warren twarren@nvidia.com Signed-off-by: Stephen Warren swarren@nvidia.com
include/configs/tegra-common.h | 4 ++++ 1 file changed, 4 insertions(+)
What does start up the CPU? Is this something that will be implemented in SPL later?
At least initially, the plan is to use a separate bootloader on the boot CPU (was named AVP, but got renamed to BPMP lite in Tegra210). It's vaguely possible that U-Boot SPL support will exist in the future, but I'm not sure.
Ah OK. Where does that live? I think SPL would be better.
We haven't yet worked out the logistics of how to release it. I expect it will be a little while yet.
As an aside, I don't think SPL is the right mechanism at least for new Tegra chips, although using the U-Boot code base on the boot CPU might be reasonable, and is something we might look at after we've got the first round SW stack up. The boot CPU and main CPU complex have always been different CPUs and even ARM architectures. While we were able to hack around this with Tegra124 and earlier since they were both 32-bit ARM, so the same compiler and variable sizes etc. could be used, this likely isn't possible on Tegra210 and later, since the boot CPU is 32-bit ARM and the main CPU complex is 64-bit ARM. It'd be better to build two completely separate builds of U-Boot for the two CPU types, and then combine them together during the flash image generation process.
Hi Stephen,
On 28 July 2015 at 10:05, Stephen Warren swarren@wwwdotorg.org wrote:
On 07/28/2015 09:50 AM, Simon Glass wrote:
Hi Stephen,
On 28 July 2015 at 09:44, Stephen Warren swarren@wwwdotorg.org wrote:
On 07/28/2015 09:33 AM, Simon Glass wrote:
Hi,
On 27 July 2015 at 11:45, Stephen Warren swarren@wwwdotorg.org wrote:
From: Thierry Reding treding@nvidia.com
For 64-bit ARM SoCs we rely on non-U-Boot code to bring up the CPU in AArch64 mode so that we don't need the SPL. Non-cached memory is not implemented (yet) for 64-bit ARM.
Signed-off-by: Thierry Reding treding@nvidia.com Signed-off-by: Tom Warren twarren@nvidia.com Signed-off-by: Stephen Warren swarren@nvidia.com
include/configs/tegra-common.h | 4 ++++ 1 file changed, 4 insertions(+)
What does start up the CPU? Is this something that will be implemented in SPL later?
At least initially, the plan is to use a separate bootloader on the boot CPU (was named AVP, but got renamed to BPMP lite in Tegra210). It's vaguely possible that U-Boot SPL support will exist in the future, but I'm not sure.
Ah OK. Where does that live? I think SPL would be better.
We haven't yet worked out the logistics of how to release it. I expect it will be a little while yet.
As an aside, I don't think SPL is the right mechanism at least for new Tegra chips, although using the U-Boot code base on the boot CPU might be reasonable, and is something we might look at after we've got the first round SW stack up. The boot CPU and main CPU complex have always been different CPUs and even ARM architectures. While we were able to hack around this with Tegra124 and earlier since they were both 32-bit ARM, so the same compiler and variable sizes etc. could be used, this likely isn't possible on Tegra210 and later, since the boot CPU is 32-bit ARM and the main CPU complex is 64-bit ARM. It'd be better to build two completely separate builds of U-Boot for the two CPU types, and then combine them together during the flash image generation process.
Sounds reasonable. In a way this is similar to SPL works, except I think you are saying that there would be no need for SPL to load U-Boot since they would be packaged together, as now.
My understanding is that the motivation for having SPL at all with Tegra was these CPU differences. So from that POV I suppose Tegra 210 isn't any different.
Regards, Simon
On 27 July 2015 at 11:45, Stephen Warren swarren@wwwdotorg.org wrote:
From: Thierry Reding treding@nvidia.com
Most peripherals on Tegra can do DMA only to the lower 32-bit address space, even on 64-bit SoCs. This limitation is typically overcome by the use of an IOMMU. Since the IOMMU is not entirely trivial to set up and serves no other purpose (I/O protection, ...) in U-Boot, restrict 64-bit Tegra SoCs to the lower 32-bit address space for RAM. This ensures that the physical addresses of buffers that are programmed into the various DMA engines are valid and don't alias to lower addresses.
Signed-off-by: Thierry Reding treding@nvidia.com Signed-off-by: Tom Warren twarren@nvidia.com Signed-off-by: Stephen Warren swarren@nvidia.com
These 3 patches are pre-requisites for T210 support (either compile-time or run-time) but don't seem to have been sent to the mailing lists recently.
arch/arm/mach-tegra/board2.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)
Reviewed-by: Simon Glass sjg@chromium.org
participants (2)
-
Simon Glass -
Stephen Warren