[U-Boot] [PATCH] ARM: tegra: Use the IRAM for the early stack

[Stephen Warren]

On 12/09/2013 11:09 AM, Alban Bedel wrote:
> On Mon, 09 Dec 2013 10:09:49 -0700
> Stephen Warren <swarren at wwwdotorg.org> wrote:
> 
>> On 12/09/2013 10:06 AM, Alban Bedel wrote:
>>> Unlike many other platforms the tegra platform has the luxury of
>>> already having the SDRAM running during the early init, and it is used
>>> for the early stack. However the memory test of the POST subsystem is
>>> expecting the SDRAM to be unused, and on tegra platforms the test fail
>>> to run as it destroy the stack.
>>>
>>> To fix the problem simply use the IRAM for the initial stack.
>>
>> Can't the POST code simply touch an unused RAM address?
> 
> The memtest is run pre-relocation to in fact avoid having to take care
> about some special memory regions, beside the u-boot image and
> pre-relocation code.

If it's avoiding the U-Boot image, can't it also avoid the stack?

>> There is IRAM content that needs to be preserved, so we need to make
>> sure we don't stomp on that. Examples are:
>>
>> * BIT (Boot Information Table)
>> * BCT that was used to boot the system
>> * Perhaps the whole IRAM is filled with code/data in the LP0
>> suspend/resume case.
> 
> BIC and BCT shouldn't be problem if enough IRAM is left for the
> relocation. After relocation the stack move to the SDRAM anyway.

Right, but we need to be careful to avoid those. Where is the stack in
IRAM after this patch.

Does the RAM test happen while U-Boot is running on the AVP (i.e. during
the SPL) or while running on the main CPU (i.e. main U-Boot binary). If
AVP, then using IRAM for stack might be OK. If main CPU, then the AVP
owns the IRAM and could be executing arbitrary code (in general, in a
complete customer system) and could be using arbitrary portions of it
itself, so U-Boot couldn't touch it.

> But for LP0 I don't really understand what the problem would be. Do the
> u-boot loading+relocation needs to be run when coming out of LP0?

Yes, LP0 is "chip off", so the chip/CPU boots through (at least part of)
the boot ROM and potentially bootloader. Actually, I guess perhaps not
the full bootloader, but just a small stub whose location is passed to
the boot ROM before suspend, so perhaps the operation of U-Boot is just
limited to setting that up, not actually running on resume.