00:01 <apritzel> smaeul: I moved the SPL stack to below the save area

00:03 <apritzel> this is actually a bug in U-Boot for the H616: we place the SPL stack at the end of SRAM C (0x58000), but the BROM's FEL routine uses some bytes at 0x57d00

00:04 <apritzel> but I am still scratching my head why this didn't explode earlier, my best theory is that this area is not used for the FEL return, or it is re-initialised

00:05 <apritzel> I definitely see the BROM code for clearing 0x57d00-0x58000, near the beginning of the FEL entry point

00:05 <smaeul> this may be the secure monitor stack?

00:06 <smaeul> or the scratch area used by SBROM. it's been a long while since I looked at H616 BROM, but I remember there was code in NBROM to wipe SRAM used by SBROM

00:09 <apritzel> I see, clearing this area would someone explain it, although I would expect this to be done by the SBROM.

00:10 <apritzel> I also see some pointers to the first few words of this area, so there is some usage, but maybe not in the code path we are using

00:30 <apritzel> smaeul: what AArch64 toolchain do you use? Can you FEL boot the OrangePi Zero2?

02:18 <smaeul> apritzel: gcc version 11.1.0 (GCC) // Trying to boot from FEL // usb_bulk_send() ERROR -7: Operation timed out

02:29 <smaeul> with "gcc version 10.1.0 (GCC)" and both current U-Boot master and with 38be6b838780 + f43312c974ea + c629ba854f2e, return to FEL works, and running TF-A works, but it gets stuck before the U-Boot proper banner

02:34 <smaeul> oh, nevermind on the getting stuck. I had patched my sunxi-fel to support 32-bit FIT loading in a way that broke 64-bit FIT loading. so gcc 10.1.0 works fine

03:00 <smaeul> http://ix.io/3Z3C verifies that we do get back to 32-bit mode even with newer GCC

04:30 <smaeul> gcc 11 works if I mark mctl_phy_read_calibration as noinline

08:49 <apritzel> smaeul: ah, many thanks for the confirmation and the extra tests, some nice new puzzle pieces ;-)

10:15 <apritzel> cyrozap: I was wondering if you could add a udelay(1); at the beginning and the end of mctl_phy_read_calibration(), to see if the aggressive inlining is too fast for the DRAM controller

10:17 <apritzel> I am still scratching my head about how some DRAM code problem could spoil the return to FEL, if apparently we get to the very end of the SPL just fine

20:57 <apritzel> cyrozap, smaeul: putting a udelay(0); (yes, 0) at the beginning of mctl_phy_read_calibration() also fixes it for me

21:07 <apritzel> I wonder if this is a barrier problem, because GCC too aggressively reorders the code. And we have no barriers in place for the clrsetbits() calls