01:57 <eeschalier> In sunxi-tools, what architectures is uart0-helloworld-sdboot meant to build for? It seems to build for 32-bit arm; I've been hacking it up a bit to get it to run on the D1, and I'm unclear whether it would be a goal to have an executable that can run on both RV64 and ARM32, or if they should just be left as separate things?

12:03 <mkazantsev> Hello, does anybody know how to reset the RTC peripheral on D1/T113/maybe H6 completely without disconnecting the battery?

12:04 <mkazantsev> The auto-switch function that switches from external OSC32K to internal RC when OSC32K isn't right, once it switched to RC it won't let me restart OSC32K and select it as LOSC source until I

12:04 <mkazantsev> disconnect the battery

12:07 <Jookia> mkazantsev: have you tried the standard approaches of poking reset registers and things?

12:09 <buZz> mkazantsev: are you convinced the battery is even still full?

12:09 <buZz> just random hunch

12:18 <mkazantsev> Jookia: that's the thing, I've found no reset bits for RTC peripheral in CCU registers, no software reset bits of any kind in RTC's registers

12:19 <mkazantsev> The manual says "The RTC module has the independent reset signal, the signal follows VCC-RTC. When VCC-RTC powers on, the reset

12:19 <mkazantsev> signal resets the RTC module; after VCC-RTC reaches stable, the reset signal always holds high level."

12:19 <Jookia> oh dear

12:19 <mkazantsev> So the only reset mentioned is tied to the battery

12:22 <mkazantsev> buZz: No, the battery's ok, when auto-switch function is triggered it sets the EXT_LOSC_STA "External 32.768k OSC work abnormally." bit in the status register, and that bit is stored across power cycles (main power)

12:23 <buZz> ok

12:40 <mkazantsev> So far the closest I've got in the RTC regs is PWROFF_GAT_RTC_CFG "Power off gating control signal" but it just makes RTC registers read as zeros, the "abnormal" bit is still there after a power cycle

12:41 <mkazantsev> And RTC_VIO_REGU register for selecting the internal LDO voltage, it has a setting that says "001: 0.65 V (the configuration can cause RTC reset)"

12:41 <mkazantsev> I wish it did

13:28 <apritzel> mkazantsev: did you try offset 0x20c in the PRCM (r-ccu)? Has RESET and CLOCK GATE

13:28 <apritzel> 0x701020c

14:28 <wens> apritzel: I don't remember ever seeing a reset control for the RTC on earlier chips though

14:30 <apritzel> wens: that's what the A523 manual (which describes the PRCM) says, and we have that gate + reset in ccu-sun20i-d1-r.c

14:31 <wens> interesting

14:31 <apritzel> not sure how far the reset actually goes, it might indeed just affect the register interface, but not the actual RTC operation

15:44 <mkazantsev> apritzel: actually no, I'll try that

16:52 <mkazantsev> apritzel: the register is there but yes it only resets the bus, "abnormal" status bit stays

16:52 <mkazantsev> apritzel: thanks for the hint, that A523 manual is much bigger than what I have

16:52 <wens> and the RTC time?

16:55 <mkazantsev> wens: time isn't reset either

17:11 <jernej> eliasbakken: you're right about ARISC, only thing needed to do is load FW to SRAM A2 and then release reset at 0x7050000

17:12 <jernej> so my TF-A port should be fully compatible with it, if you provide it in a form of scp.bin

17:13 <jernej> let me check what else could we miss

17:14 <loki666> apritzel: this is what I have for the GPU pll reparent https://gist.github.com/loki666/c398cfd4c341551d93f3216b350f5f37

17:14 <loki666> but I'm not sure about you said for "PLL_PERIPH(2x)/(m+1), to be precise, so you should also program m to at least 2,"

17:16 <apritzel> loki666: the manual says the reset value is m=0, so the clock would be 1.2GHz. Since nothing references this clock directly, it's probably still at that value

17:16 <jernej> eliasbakken: so maybe VDD-CPUS is not enabled (CPUSLDO at AXP717)

17:24 <apritzel> loki666: so you would need to program CLK_GPU1 in probe(), to set the divider to say 3

17:25 <apritzel> and where does "bypass_index = 5" come from? Should be 1, shouldn't it?

17:26 <loki666> Ah it's an index in the parent array... Wasn't sure 😄

17:27 <apritzel> yes

17:29 <apritzel> the rest looks okay, so just change the bypass_index, plus enable CLK_CPU1 and set its divider to 3, in probe()

17:30 <loki666> PLL and clock generation is Chinese to me

17:30 <loki666> Thanks

17:35 <apritzel> loki666: you mean 锁相环 ?

17:39 <loki666> Yea

17:40 <loki666> apritzel: I suppose you meant enable CLK_GPU1

17:41 <apritzel> yes, maybe it needs to be marked as CRITICAL even, otherwise the CCF might turn it off

18:03 <loki666> there is also a "GPU Bus Gating Reset Register" ...

18:17 <loki666> apritzel: this is what I have https://gist.github.com/loki666/6b63d06b9a9a838eba129ff3ec08dbdb

20:49 <apritzel> loki666: yes, that looks alright. Does it work? ;-)

20:50 <apritzel> how reproducible is your issue anyway?

20:53 <loki666> Compiling... With the retro gaming distro I'm working on, it's quite easy... Let the simeple_ondemand gov and panfrost will oops very quickly, sometime it will completely hang the renderings

22:31 <loki666> apritzel: so far so good

22:32 <loki666> I'll do more tests, and post this could you help me with the comments arround enabling and setting the M factor of CLK_GPU1 ?

22:36 <apritzel> sure

22:37 <loki666> should I try without the CLK_CRITICAL flag ?

22:37 <apritzel> yes, please try that. Should crash immediately

22:37 <apritzel> or hang

22:38 <loki666> k

22:39 <apritzel> which reminds me that I should test/check your previous (OTG) series!

22:39 <loki666> here is my latest version (which compile) https://gist.github.com/loki666/6c9804045efa8dfba75184ec34fc0d43

22:41 <loki666> I'll "play" more tomorrow with the device, but so fare not a single oops

22:41 <apritzel> \o/

22:42 <loki666> thanks for your help

22:43 <loki666> what if I ref the GPU1 clock from the gpu node in dts ?

22:43 <loki666> currently it's only clocks = <&ccu CLK_GPU0>, <&ccu CLK_BUS_GPU>;

22:43 <loki666> ok is BUS_GPU the same as GPU1 ?

23:11 <apritzel> no, you cannot really do that

23:11 <apritzel> the first clock is the clock driving the actual GPU, the second clock is the gate for the GPU registers

23:12 <apritzel> that's the Mali DT binding, you cannot change that

23:16 <apritzel> we could think about extending the notification callbacks to also enable CLK_GPU1, across the change

23:17 <apritzel> but that could be a later optimisation