[U-Boot] [PATCH 3/3] ARM: tegra: Disable SPL and non-cached memory on 64-bit
Simon Glass
sjg at chromium.org
Tue Jul 28 18:12:08 CEST 2015
Hi Stephen,
On 28 July 2015 at 10:05, Stephen Warren <swarren at 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 at wwwdotorg.org> wrote:
>>>
>>> On 07/28/2015 09:33 AM, Simon Glass wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> On 27 July 2015 at 11:45, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>>>>
>>>>>
>>>>> From: Thierry Reding <treding at 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 at nvidia.com>
>>>>> Signed-off-by: Tom Warren <twarren at nvidia.com>
>>>>> Signed-off-by: Stephen Warren <swarren at 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
More information about the U-Boot
mailing list