00:07 <apritzel> jernej: it's a bit hacky, and not really suited for mainline, but compiling the SPL for arm(32) fixes the Avaota-A1 return-to-FEL issue for me (since we don't need to go to AArch64 and back):

00:08 <apritzel> https://gist.github.com/apritzel/b6e67a7ab72c7362350947c074154953

05:12 <jernej> apritzel: thanks! IIRC that's also good enough to boot TF-A, since that has independent code for switching to aarch64, right?

10:26 <apritzel> jernej: TF-A itself has no provision to switch to AArch64, it expects to be always entered in AArch64/EL3

10:26 <apritzel> but you can use the "reset64" feature of sunxi-fel to do this for you

10:27 <apritzel> that's what the "uboot" command would do internally: upload everything from the FIT image, then do a reset64 to the TF-A load address

11:35 <apritzel> jernej: one interesting design question we would need to answer is where to put TF-A into. Traditionally SRAM-A2 would be the place, and it looks big enough, but is also used by the SPL

16:30 <BroderTuck> apritzel: (or anyone else with a A523-family SoC) Did anyone else see the weirdness that I saw with the rtc clock, where the rtc ends up on this line in clk_summary

16:30 <BroderTuck> bus-r-cpucfg 1 1 0 100000000 0 0 50000 Y 7090000.rtc bus

17:15 <BroderTuck> Been staring at the code, but can't really make heads or tail of it

17:17 <jernej> apritzel: I concur, SRAM A2 seems like a good candidate. TF-A could be located in DRAM at first and then it relocates itself to SRAM A2? U-Boot proper already does that.

17:29 <apritzel> TF-A should never be in DRAM, we just did this for the H616, because there is no suitable SRAM available there

17:30 <apritzel> so I was thinking to split SRAM A2, and leave say the first 64K for the SPL, and the rest (80K?) for TF-A

17:31 <apritzel> jernej: compare to the A64 and H6: we use only SRAM A2 for TF-A there, no DRAM involved

17:31 <apritzel> jernej: btw: if you compile for PLAT=sun50i_r329, and use that, you should see at least some output from TF-A, because the UART address is the same on the R329

17:32 <apritzel> you might need to adjust the TF-A load address, though

17:33 <jernej> ah, yes, split SRAM A2 is easiest. my current SPL size is 40 KB, so plenty of space left for complicated DRAM driver ;)

17:35 <jernej> apritzel: RISC-V uses SRAM A3 and MCU uses SRAM A1, right?

17:36 <jernej> just to be sure to avoid already used regions

17:36 <apritzel> jernej: those are good questions!

17:37 <apritzel> I thought the RISC-V core *is* the MCU?

17:37 <apritzel> similar to OpenRISC and arisc?

17:37 <apritzel> but pretty surely we should leave SRAM A3 alone

17:38 <apritzel> and since the manual indeed says "MCU uses SRAM A1", I was trying to avoid that region, since there might be say crust running there, during boot even (suspend/resume)

17:39 <apritzel> and oddly enough the BROM doesn't use SRAM A1 either, at least not for loading boot0/SPL

17:40 <jernej> right, A1 and A3 are for MCU, a.k.a. RISC-V

17:40 <apritzel> and the manual doesn't mention this, but traditionally SRAM A2 is the secure SRAM, so not accessible by non-secure world, which makes it perfect for TF-A

17:41 <apritzel> (ignoring for a moment that at least A64 and H6 ignore this fact unless you use "secure boot")

17:42 <apritzel> actually TF-A could use even more of SRAM A2, since when TF-A starts, SPL should not be there anymore

17:42 <jernej> did you check how secure A2 is?

17:45 <apritzel> don't remember, need to check on that tablet, but I think I never ran non-secure code there. But I guess with your DRAM code I could actually run U-Boot now ...

17:46 <jernej> note that usually also cedrus and display engine use SRAM C, but I don't see any mention of them here

17:46 <jernej> so that would also be interesting to check

17:47 <jernej> and system controller documentation is sadly missing

21:35 <apritzel> BroderTuck: ah, found the reason for your RTC issue: the clock numbers in the DT binding headers changed, between the kernel on my Github and my local trees

21:36 <apritzel> BroderTuck: you can fix this for now by renumbering the clocks in include/dt-bindings/clock/sun55i-a523-r-ccu.h: CLK_BUS_R_SPI must become 11, and everything from down there must follow

21:36 <apritzel> so that CLK_BUS_R_RTC will be 25, not 24

21:37 <apritzel> then recompile the kernel - I know, sorry! ;-)

21:38 <BroderTuck> apritzel: Well, I guessed it was an off-by-one somewhere, just didn't know enought to figure out where it came from

21:39 <BroderTuck> Will try this as soon as my H3 box is behaving again (had a bit of a problem with the sd card, trying to rebuild a new working fs for that machine)

22:04 <BroderTuck> I see now that there are 2 other TV boxes with H728 available, but both of them only have 1 USB2.0 (and one 3.0)

22:26 <BroderTuck> So, CLK_BUS_R_PWMCTRL stays 9, but CLK_BUS_R_SPI and everything after gets shifted 1 step?

22:29 <apritzel> yes, because I inserted CLK_R_SPI, that's the new 10

22:49 <BroderTuck> Not surprising then, most clocks remained the same, only a few got shifted around. Sounds like it will fix the issue, and why noone else seems to have noticed

22:49 <BroderTuck> Will have it tested by tomorrow

22:52 <BroderTuck> Now if only fixing the emmc was as easy :)

23:02 <apritzel> BroderTuck: most people either don't care about the RTC, or just use consistent DTs. Your issue was because I put a newer DT in U-Boot, not matching the binding used in the kernel on my github

23:03 <apritzel> since the DT and the whole code is in development, that's expected

23:09 <BroderTuck> Things being in flux, yeah, that's to be expected. I had more or less verified that it was not my kernel itself that was the problem, so was actually wondering if it was some incompatibility with your uboot, and indeed it turned out to be.