[U-Boot] [PATCH 1/4] Revert "sunxi: Move the SPL stack top to 0x1A000 on Allwinner A64/A80"

[Andre Przywara]

Hi,

On 05/09/16 05:12, Siarhei Siamashka wrote:
> On Mon,  5 Sep 2016 01:32:38 +0100
> Andre Przywara <andre.przywara at arm.com> wrote:
> 
>> This commit moved the SPL stack into SRAM C, which worked when the SPL
>> set the AHB1 clock down to 100 MHz to cope with the flaky SRAM C access
>> from the CPU.
>> However booting with boot0 (and thus not using SPL at all) we still run
>> with a 200 MHz AHB1, so any access to SRAM C is prone to fail.
>> Since this commit does _not_ only affect the SPL code, but also the
>> U-Boot proper, we fail when booting with boot0.
> 
> Yes, it unfortunately affected both the SPL and the U-Boot
> proper because currently both CONFIG_SPL_STACK and
> CONFIG_SYS_INIT_SP_ADDR defines affect the SPL stack
> location and in practice this only works in a predictable
> way if they are set to the same value. I have sent a patch
> to address this problem (but the fix may be unsafe for
> v2016.09 because many ARM platforms are affected):
> 
>     https://patchwork.ozlabs.org/patch/665608/
> 
> After this problem is resolved, the CONFIG_SYS_INIT_SP_ADDR
> define can be decoupled from CONFIG_SPL_STACK and configured to
> even use the DRAM instead of thrashing some part of the scarce
> SRAM space (which may be already occupied by the OpenRISC
> firmware and/or the ATF at the time when the U-Boot proper is
> starting).
> 
>> As the introduction of tiny-printf reduced the size of the SPL, we
>> can afford to have the SPL stack in SRAM A1.
> 
> We still need to check how much space is really available. The FIT
> support is rather heavyweight and we may want to enable some other
> features too.

Yes, I had to learn this yesterday ;-)
So 64-bit SPL works for me now with Jens' DRAM support patches (yeah!),
but enabling FIT support makes mksunxiboot barf about the file being to
big. The actual SPL code is about 31K, so maybe I can talk mksunxiboot
into relaxing its alignment requirements a bit (from 8K down to 512) and
also increase the available SRAM size - it says 0x7600 for sun4i, is
this still true to newer SoCs/BROMs?

Trying this in the past (with libdram) and compiling for (32-bit) Thumb2
worked, but I need to check what the actual size with Jens' patches are
these days for Thumb2.

Anyway, thanks for your patch, I will try tonight if I can squeeze all
the bits in.

>  
>> This reverts commit 1a83fb4a17d959d7b037999ab7ed7e62429abe34
>> and fixes booting the Pine64 when using boot0.
>>
>> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> 
> But as discussed earlier, reverting this patch is a reasonable
> solution for v2016.09, so it is
> 
> Reviewed-by: Siarhei Siamashka <siarhei.siamashka at gmail.com>

Thanks for that!

Cheers,
Andre.

> 
>> ---
>>  include/configs/sunxi-common.h | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
>> index f64edd4..708ab17 100644
>> --- a/include/configs/sunxi-common.h
>> +++ b/include/configs/sunxi-common.h
>> @@ -99,7 +99,7 @@
>>   * the 1 actually activates the mapping of the first 32 KiB to 0x00000000.
>>   */
>>  #define CONFIG_SYS_INIT_RAM_ADDR	0x10000
>> -#define CONFIG_SYS_INIT_RAM_SIZE	0xA000	/* 40 KiB */
>> +#define CONFIG_SYS_INIT_RAM_SIZE	0x08000	/* FIXME: 40 KiB ? */
>>  #else
>>  #define CONFIG_SYS_INIT_RAM_ADDR	0x0
>>  #define CONFIG_SYS_INIT_RAM_SIZE	0x8000	/* 32 KiB */
>> @@ -220,7 +220,8 @@
>>  #define CONFIG_SPL_PAD_TO		32768		/* decimal for 'dd' */
>>  
>>  #if defined(CONFIG_MACH_SUN9I) || defined(CONFIG_MACH_SUN50I)
>> -#define LOW_LEVEL_SRAM_STACK		0x0001A000
>> +/* FIXME: 40 KiB instead of 32 KiB ? */
>> +#define LOW_LEVEL_SRAM_STACK		0x00018000
>>  #define CONFIG_SPL_STACK		LOW_LEVEL_SRAM_STACK
>>  #else
>>  /* end of 32 KiB in sram */
> 
> 
>