00:04 <cyrozap> apritzel: I PM'd you a link to the file. I'll try with the one you posted now.

00:10 <cyrozap> The SPL you posted didn't work for me--same error.

00:25 <apritzel> cyrozap: interesting, dug out my OPi Zero2, and both your and my version indeed failed ...

00:30 <machinehum> apritzel: Amazing

00:30 <machinehum> Boss level

00:32 <cyrozap> apritzel: I just sent you the SPL I built a year ago that _does_ work with FEL. Maybe you could try that on your Zero2, too, and see if that works?

00:32 <cyrozap> Just to confirm that your Zero2 isn't broken.

00:33 <apritzel> cyrozap: but the respective version (GCC 12.1.0) worked on my TV box - the only difference should be some slightly different DRAM setup parameters

00:33 <apritzel> cyrozap: also: GCC 11.2.0 failed as well, but GCC 10.3.0 worked

00:34 <apritzel> cyrozap: and your version as well

00:37 <cyrozap> Well, I'm glad you can reproduce the issue now, and it's not just me, haha :)

00:38 <apritzel> cyrozap: thanks for helping in narrowing this down, I will have deeper look tomorrow, and probably pick some brains of our compiler guys

00:38 <apritzel> cyrozap: might be some undefined behaviour in U-Boot, newer compilers tend to exploit them more heavily

00:40 <cyrozap> And thank you for looking into this so diligently! I'm going to re-build the old version of the SPL with GCC 12.1.0 again, and then pop both the working SPL and the broken SPL into Ghidra and see if there's any major differences around the "Return to FEL" code.

00:43 <apritzel> cyrozap: my hunch is that the problem is in the DRAM code, because the slightly different code between the Mate X96 and the OPiZero2 seems to make a difference

12:51 <cyrozap> apritzel: I think I might have found a possible source of the problem, but I may also have simply misunderstood the Allwinner boot process.

13:34 <cyrozap> I used the command `sunxi-fel spl u-boot/spl/sunxi-spl.bin` to load the working U-Boot SPL (built last year) and return to FEL mode. Then, I used `sunxi-fel dump 0x20000 0xa000` to dump what looks mostly like the SPL, but with several differences: 1) The eGON header is slightly modified (I assume to tell the boot ROM to enter FEL mode). 2) Bytes 0x21000 to 0x22000 are filled with (apparently random)

13:34 <cyrozap> data that differs significantly from the SPL that was originally uploaded.

13:36 <apritzel> cyrozap: yes, the BROM modifies the SPL header, to put the boot source into, plus the SPL does that to communicate something to U-Boot proper, like the detected DRAM size

13:37 <apritzel> and then, depending on the SoC type, we use part of the SRAM for stack and other data

13:39 <apritzel> IIRC for the H616 we use the end of SRAM C for that, so below 0x58000

13:40 <cyrozap> Oh, I see now--on H616, 0x21000 is used as a swap buffer: `{ .buf1 = 0x21000, .buf2 = 0x52a00, .size = 0x1000 }`

13:40 <apritzel> plus the BROM uses parts of SRAM A1 for its stack

13:40 <apritzel> yeah, this is the BROM stack, which we have to preserve when we later plan to re-enter FEL

13:42 <apritzel> so sunxi-fel backs up this part, into SRAM C, and when we jump back into FEL at the end of the SPL, we restore this, then return to the BROM

13:44 <apritzel> cyrozap: https://linux-sunxi.org/FEL/USBBoot#General_description_of_the_.22sunxi-fel_uboot.22_command_implementation has the gory details

13:59 <cyrozap> Wow, what a nightmare. Makes me glad that MediaTek provides plenty of SRAM on their chips (between 256kB and 512kB on the devices I own) dedicated to the SPL ("preloader", in their terms), with a separate 64kB SRAM for the mask ROM's data and stack.

14:16 <cyrozap> Well, anyways, I guess that pokes a hole in my "return-to-FEL code is getting corrupted" hypothesis.

14:22 <cyrozap> Oh, and for the sake of completeness, comparing the old U-Boot SPL to the recently-built one didn't turn up any significant results.

14:24 <cyrozap> As far as I could tell, none of the code that might affect the "return to FEL" code path was changed in a way that changed any of the logic.

14:25 <cyrozap> That's why I thought maybe the offsets were what were causing the problems--while the code was mostly the same, a bunch of it got moved around inside the binary in the newly-built SPL.

14:56 <apritzel> cyrozap: thanks for checking that, and bummer that it didn't show something easily

14:56 <apritzel> cyrozap: can you check whether the address of fel_stash_addr moved?