On Thu, Aug 04, 2016 at 10:58:30PM +0300, Siarhei Siamashka wrote: > On Thu, 4 Aug 2016 11:40:25 -0400 > Tom Rini <tr...@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.siamas...@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
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
