[U-Boot] [PATCH 1/3] ARM: tegra: Restrict usable RAM to 32-bit on 64-bit SoCs

[U-Boot] [PATCH 1/3] ARM: tegra: Restrict usable RAM to 32-bit on 64-bit SoCs

[Stephen Warren]

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
-- 
1.9.1

[U-Boot] [PATCH 2/3] ARM: tegra: Use standard cache enable for 64-bit

[Stephen Warren]

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 */
-- 
1.9.1

[U-Boot] [PATCH 3/3] ARM: tegra: Disable SPL and non-cached memory on 64-bit

[Stephen Warren]

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
-- 
1.9.1

[U-Boot] [PATCH 1/3] ARM: tegra: Restrict usable RAM to 32-bit on 64-bit SoCs

[Simon Glass]

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>

[U-Boot] [PATCH 2/3] ARM: tegra: Use standard cache enable for 64-bit

[Simon Glass]

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

[U-Boot] [PATCH 3/3] ARM: tegra: Disable SPL and non-cached memory on 64-bit

[Simon Glass]

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

[U-Boot] [PATCH 2/3] ARM: tegra: Use standard cache enable for 64-bit

[Stephen Warren]

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:-)

[U-Boot] [PATCH 3/3] ARM: tegra: Disable SPL and non-cached memory on 64-bit

[Stephen Warren]

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.

[U-Boot] [PATCH 3/3] ARM: tegra: Disable SPL and non-cached memory on 64-bit

[Simon Glass]

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

[U-Boot] [PATCH 3/3] ARM: tegra: Disable SPL and non-cached memory on 64-bit

[Stephen Warren]

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.

[U-Boot] [PATCH 3/3] ARM: tegra: Disable SPL and non-cached memory on 64-bit

[Simon Glass]

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