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

[Siarhei Siamashka]

On Mon, 5 Sep 2016 09:23:00 +0100
Andre Przywara <andre.przywara at arm.com> wrote:

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

We have this information in the linux-sunxi wiki since a long time ago
(at least for the SoC variants that I have and could experiment with)
and it is available here:

    https://linux-sunxi.org/BROM#U-Boot_SPL_limitations

All the new SoCs have a 32K size limit for the SPL code, which can be
loaded by the BROM. Older A10/A20 SoCs artificially limit it to 24K,
probably trying to forcefully encourage the users to have 8K stack in
the remaining part of the SRAM A1.

On A64, we have 32K of SRAM A1. Then we have 108K of SRAM C, which is a
continuation of SRAM A1 in the address space thus making it look like a
nice single 140K chunk. Then we also have 64K of SRAM A2, which is
supposed to be used by the OpenRISC core and is the only memory area,
which has a reasonable performance when used by OpenRISC:

    https://linux-sunxi.org/AR100#Memory_Map

The idea was to let the BROM load up to 32K of the SPL code to the
SRAM A1 (like it normally does) and then have 8K of stack a bit higher
in the address space in SRAM C. But it turned out that the SRAM C is a
bit quirky and suffers from data corruption problems if we reclock
AHB1 too early.

Now there are two possible ways to move forward on A64:
  1) Try to use SRAM C in such a way that it does not fail (and hope
     that no additional quirks get discovered later).
  2) Move the initial SPL stack to SRAM A2.

If we move everything to SRAM A2, then we will have to make sure that
all the SRAM users (the FEL storage area, the SPL stack, the ATF and
the yet to be implemented OpenRISC firmware) never clash with each
other.

About the 31K code size. This does not look good and is very close to
the BROM limit (32K). Just using a different compiler may bring us into
a trouble. Or some minor code tweaks and feature additions.

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

We have already discussed this off-list a long time ago. I know that
both you and Alexander Graf are generally in favour of compiling the
SPL as 64-bit code.

I think that this is the usual case of utility versus fashion. Everyone
wants to plug every hole with 64-bit ARM code right now just because it
is new and innovative. But this fad will fade away in a few years. Now
just imagine an alternative reality, where ARM64 is an old and boring
thing, while Thumb2 is a recent invention to improve code density in
microcontrollers and other code space constrained systems. I'm sure
that everyone would be trying to find a way to replace the legacy
bloated 64-bit ARM code in the SPL with the new and shiny Thumb2
stuff for improving code density ;-)

If we take a pragmatic approach and try to evaluate pro- and cons-
factors, then we can see that the 64-bit code in the SPL on
Allwinner A64 hardware does not give us any real improvements.
Quite the contrary: it offers worse code density than 32-bit
Thumb2 and also a functional USB FEL boot support becomes much
more tricky (because the boot ROM implements FEL as a 32-bit code).

The only real argument in favour of having a 64-bit SPL is that we
can use a single AArch64 toolchain to build both the SPL and the
main U-Boot. And we are in this situation only because the AArch64
toolchain does not support the "-m32" option. There is no technical
justification for this. ARM decided to be different just for the
sake of being different (every other architecture has the -m32
option in GCC if the processor is able to work in both modes).
If the "-m32" option was supported, then building a 32-bit SPL
would have been mostly a trivial matter of adding "-m32 -mthumb"
options to CFLAGS.

But we can try to do a 32-bit SPL build by introducing something like
a CROSS_COMPILE_SPL environment variable, just like suggested some
time ago: http://lists.denx.de/pipermail/u-boot/2012-April/122236.html

Also I'm finally going to submit the runtime SPL code decompression
patches for the next U-Boot release, because there is no need to delay
the implementation of this feature any longer. Yes, I know that any
saved space will be wasted almost instantly by various gimmicks, but
that's just how it is.

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

If you mean https://patchwork.ozlabs.org/patch/665608/ then it only
gives us the freedom to move CONFIG_SYS_INIT_SP_ADDR somewhere else.

And moving the initial stack if the U-Boot proper into the DRAM would
make a lot of sense. We only need to agree what kind of DRAM address to
use. After all, even the SPL relocates the stack into the DRAM. Why
does the U-Boot proper want to use the SRAM for its stack again?

-- 
Best regards,
Siarhei Siamashka