[U-Boot] [PATCH] ARM: tegra: Use the IRAM for the early stack
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.
Signed-off-by: Alban Bedel alban.bedel@avionic-design.de --- include/configs/tegra-common.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/tegra-common.h b/include/configs/tegra-common.h index 522cd41..340f5aa 100644 --- a/include/configs/tegra-common.h +++ b/include/configs/tegra-common.h @@ -124,7 +124,7 @@
#define CONFIG_SYS_BOOTMAPSZ (256 << 20) /* 256M */
-#define CONFIG_SYS_INIT_RAM_ADDR CONFIG_STACKBASE +#define CONFIG_SYS_INIT_RAM_ADDR EARLY_CPU_STACK #define CONFIG_SYS_INIT_RAM_SIZE CONFIG_SYS_MALLOC_LEN #define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_INIT_RAM_ADDR + \ CONFIG_SYS_INIT_RAM_SIZE - \
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? 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.
On Mon, 09 Dec 2013 10:09:49 -0700 Stephen Warren swarren@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.
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.
But for LP0 I don't really understand what the problem would be. Do the u-boot loading+relocation needs to be run when comming out of LP0?
Alban
On 12/09/2013 11:09 AM, Alban Bedel wrote:
On Mon, 09 Dec 2013 10:09:49 -0700 Stephen Warren swarren@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.
participants (2)
-
Alban Bedel -
Stephen Warren