[U-Boot] pine64 and "sunxi: Move the SPL stack top to 0x1A000 on Allwinner A64/A80"

[Tom Rini]

On Thu, Aug 04, 2016 at 10:58:30PM +0300, Siarhei Siamashka wrote:
> On Thu, 4 Aug 2016 11:40:25 -0400
> Tom Rini <trini at konsulko.com> wrote:
> 
> > On Thu, Aug 04, 2016 at 11:36:01AM -0400, Tom Rini wrote:
> > > On Thu, Aug 04, 2016 at 04:14:21PM +0100, Andre Przywara wrote:  
> > > > Hi,
> > > > 
> > > > On 04/08/16 16:01, Tom Rini wrote:  
> > > > > Hey guys,
> > > > > 
> > > > > I just started trying out my Pine64 1GB and mainline U-Boot and I've
> > > > > found that:
> > > > > commit 1a83fb4a17d959d7b037999ab7ed7e62429abe34
> > > > > Author: Siarhei Siamashka <siarhei.siamashka at gmail.com>
> > > > > Date:   Tue May 31 01:48:06 2016 +0300
> > > > > 
> > > > >     sunxi: Move the SPL stack top to 0x1A000 on Allwinner A64/A80
> > > > > 
> > > > > is breaking boot for me.  boot0 seems to run fine and then the last bit
> > > > > of output that I get is:
> > > > > boot0: start load other image
> > > > > boot0: Loading BL3-1
> > > > > Loading file 0 at address 0x40000000,size 0x00000200 success
> > > > > boot0: Loading scp
> > > > > Loading file 2 at address 0x00040000,size 0x0000c200 success
> > > > > set arisc reset to de-assert state
> > > > > Ready to disable icache.
> > > > > Jump to secend Boot.
> > > > > NOTICE:  BL3-1: Running in SRAM A2 (@0x44000)
> > > > > NOTICE:  Configuring SPC Controller
> > > > > NOTICE:  BL3-1: v1.0(debug):d697594
> > > > > NOTICE:  BL3-1: Built : 09:15:57, Aug  4 2016
> > > > > NOTICE:  Configuring AXP PMIC
> > > > > NOTICE:  PMIC: already configured for RSB
> > > > > NOTICE:  PMIC: setup successful
> > > > > INFO:    BL3-1: Initializing runtime services
> > > > > INFO:    BL3-1: Preparing for EL3 exit to normal world
> > > > > INFO:    BL3-1: Next image address: 0x4a000000, SPSR: 0x3c9
> > > > > 
> > > > > I'm using d697594 from
> > > > > https://github.com/apritzel/arm-trusted-firmware.git for ATF and
> > > > > boot0.img from the 20160701 Debian "longsleep" image.  Any ideas?  
> > > > 
> > > > Yes, we were experiencing similar issues, basically it's stuck in
> > > > start.S, as far as I could quickly check.
> > > > Siarhei and I were doubtful that this commit (which we eyed at before)
> > > > could be the culprit, as it _should_ affect only SPL code, which we
> > > > don't use atm.  
> 
> Well, it does affect the main U-Boot binary too, as we checked some
> days ago on IRC. I was about to send some patches to address this issue.
> 
> > > It's not touching SPL code tho.  You're changing CONFIG_SYS_INIT_SP_ADDR
> > > which is the start of _main in arch/arm/lib/crt0_64.S
> > >   
> > 
> > Or to be extra clear:
> > @@ -100,7 +100,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       0x08000 /* FIXME: 40 KiB ? */
> > +#define CONFIG_SYS_INIT_RAM_SIZE       0xA000  /* 40 KiB */
> >  #else
> >  #define CONFIG_SYS_INIT_RAM_ADDR       0x0
> >  #define CONFIG_SYS_INIT_RAM_SIZE       0x8000  /* 32 KiB */
> > 
> > is changing CONFIG_SYS_INIT_SP_ADDR which is in U-Boot proper.  To
> > change the SPL stack pointer you use CONFIG_SPL_STACK which is what the
> > second hunk tweaks.
> 
> Yes, except that apparently there is a bug in
> "arch/arm/cpu/armv7/lowlevel_init.S" and it also uses
> CONFIG_SYS_INIT_SP_ADDR for the SPL.

That particular set of code could use yet another thinking over and
checking, yeah.

> It is safe to revert this patch right now and come up with a better fix
> later. The patch only tries to ensure the availability of more space
> for the SPL, because the SPL code size was bigger than 24K on
> Pine64 before switching to tiny printf.

OK.  Can you please send a revert?  Or shall I?

> The root cause of all these troubles is that on Allwinner A64 the
> SRAM C is apparently temporarily leased from the Cedar VE accelerator
> during the boot time. This was a relatively recent discovery:
> 
> http://irclog.whitequark.org/linux-sunxi/2016-06-29#16862925;
> 
> And an ugly part of it is that accessing SRAM C directly by the CPU
> is unreliable if AHB1 is clocked at 200MHz (default when running the
> Allwinner's Linux kernel). But the SRAM C works fine with AHB1 clocked
> at 100MHz (which is, for example the default clock speed in the
> FEL mode). So after AHB1 is reclocked (by boot0), nobody can safely
> access SRAM C anymore.

Ah, that is interesting and good to know.  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160804/01d00116/attachment.sig>