14:29 <apritzel> warpme: please have a look at the first of the two U-Boot patches I just CC:ed you on

14:29 <warpme> indeed: saw them

14:30 <apritzel> that's just half of the work, I have another patch to autodetect this (similar to what we do in TF-A), but I need to test this still

14:31 <apritzel> the idea of patch 1/2 is that you set the RVBAR address in your board's defconfig file, for the "T507-style" board: CONFIG_SUNXI_RVBAR_ADDRESS=0x8100000

14:32 <apritzel> if you could test that this works for you, that would be great. That should save you this hack you carry to *replace* 0x9010000 with 0x8100000

14:38 <warpme> Honestly speaking removal of CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER is steep-back imho. I suspect main motivation from your side is code cleanness - and i agree with this arg. but for very initial stage of board bringup caps. of using vendor boot0 as spl might be v.helpful i.e. for parallel devel of spl and tpl; or for case where devel team doing board bringup has no skills in (v.speciffic) dram spl setup ind in this case only way to

14:38 <warpme> move forward is temp. usage of vendor boot0 as spl....

14:39 <warpme> ind->so

14:54 <apritzel> warpme: but that BOOT0_HEADER code doesn't help you with that, does it?

14:55 <junari> apritzel: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/20334/1/plat/allwinner/common/sunxi_pm.c#58

14:55 <apritzel> that was just for the A64 boot0, IIUC then the later boot0's (already the H5) changed the payload ID scheme

14:58 <apritzel> junari: ah, you mean the second call should use SUNXI_PER_CORE_RVBAR_HI_REG ???

14:58 <junari> Yep

14:58 <apritzel> warpme: can you test if that ^^^^ fixes it for you

14:59 <apritzel> junari: thanks for spotting this

15:02 <warpme> if i'm understanding things correctly: only thanx to fantastic help from junari - my bringup of h313 ddr3 box was possible. So without junari help - this box will now collect dust....unless: 1)somebody pointed me about BOOT0_HEADER - so i can use already extracted (and working well) vendor boot0.bin + 2)uboot will still have BOOT0_HEADER. In other words: removing BOOT0_HEADER will exclude case i'm describing here....

15:04 <apritzel> well, then reply to the email and point that out ;-)

15:05 <apritzel> that's why we have those lists and do things publicly

15:05 <junari> apritzel: my t507 board works with reclaim, here log https://gist.github.com/iuncuim/a3abdf2e78b9235fd685ad2c8529f63a

15:06 <junari> Thanks for your patches

15:11 <apritzel> warpme: but you would need some tool to fill that header, right?

15:15 <warpme> apritzel : probably :-) But this means that in such case like my initil case (before junari decides to help) - route with boot0 is option. removal of BOOT0_HEADER closes it...

15:16 <apritzel> warpme: I mean I was curious: back in the A64 I hacked up this tool to fill the boot0 header in the U-Boot binary, but this was for the A64 boot0 only

15:16 <apritzel> even with the H5 this didn't work anymore, since Allwinner changed the format

15:17 <apritzel> so how did you fill this header? Did the old A64 tool work for you?

15:21 <apritzel> warpme: and to make this clear: by sending patches to the list, I am particularly looking for this kind of feedback ;-)

15:21 <warpme> no i don't even try. my argument is following: not having fully working solution (i mean no tool for header extraction) doesn't mean we should remove capability to have working solution in future (i mean when somebody will create such tool).

15:22 <warpme> indeed. mu bad!

15:22 <warpme> mu->my

15:35 <apritzel> warpme: my point is that I haven't heard of anyone using this header.

15:36 <apritzel> One trick I use for early bringup is to load just boot0.bin from SD card, which then goes into FEL mode, if it doesn't find a payload

15:37 <apritzel> At least that works with some boot0 binaries. Another trick is to load boot0 via FEL, after having patched the binary to return to FEL before it accesses the SD card

15:38 <apritzel> of course the proper solution is to get jernej interested so that he provides the magic DRAM bits for the SPL ;-)

15:41 <warpme> apritzel junari : i tested atf patches on my 2 h313 boxes. all 4 cpus re nicely booting. I will test rest of 4 different h616 boxes i have - but i'm pretty sure all will be ok. GREAT WORK!

15:46 <jernej> apritzel: yeah, I'll get to it soon. I planned to do it last week, but it fell through

15:47 <apritzel> jernej: oh sorry, I didn't mean to pressure you on those patches! It was just a general statement: instead of hacking around with their awful boot0 for new SoCs, we should rather pursue proper DRAM support

15:49 <jernej> ah, that's true

15:49 <warpme> jernej : fyi: you may look on https://github.com/iuncuim/u-boot/commits/h616-dram-lpddr3 also for lpddr4 support....

15:50 <warpme> for my lpddr3 this repo works nicelly

15:53 <jernej> yeah, let me first update my patches with TPR2

15:53 <warpme> :-)

17:41 <jernej> smaeul: have you ever try to enable rtc CLK_OSC32K_FANOUT clock on H616?

17:44 <jernej> for some reason, it seems that referencing CLK_OSC32K_FANOUT in DT actually enables rtc-32k