00:35 <MasterR3C0RD> For those planning to or already playing around with my U-Boot changes: on a quick glance, it would appear the timings for H616 and A133 are the same for LPDDR4, and I would presume the same goes for LPDDR3 and DDR3, so I'm going to allow the choosing of H616 timings. I just ported over the LPDDR4 timings from A133's boot0, which might help with

00:35 <MasterR3C0RD> devices that have certain flags set

03:00 <MasterR3C0RD> Made a few messy commits (I'll fix them up again at some point), but set up configuration so it can be done from the rest of the configs: https://github.com/BrokenR3C0RD/u-boot

06:29 <MasterR3C0RD> apritzel: I'll be re-preparing the rebased patch series for submission tomorrow evening; I missed that there was some feedback on a few of the patches, so I'll need to implement those. I'll also need to replace one of the commits (the one that added the device-tree binding for the USB PHY); will follow the advice you gave at that time and add a

06:29 <MasterR3C0RD> compatible to the a64 bindings instead

06:32 <MasterR3C0RD> Once I have them ready to go, would you be willing to give it a quick sanity check before I send it off? Will be my first kernel submission so I'd like to get ahead of any potential rookie mistakes

09:35 <apritzel> MasterR3C0RD: sure, feel free to send them to me first

17:16 <loki666> apritzel: is dynamic CPU freq gov working on H616 boards? On H700 (Anbernic RG35XX lineup) it's still crashing randomly but consistently (it's unusable)

17:20 <loki666> What could be the issue, something missing wrong in DT (regulator... Or I don't know), and what could be done to track the issue (kernel print/debug). ATF issue, delays missing somewhere... I really have no clue

17:20 <loki666> Also perf and power save gov are stables

17:23 <loki666> Switching between them seems also fine, but maybe switching in thighs loop (with CPU busy) could also crash. I could probably run a small script to test that

18:59 <apritzel> loki666: how does "crashing randomly" manifest? Do you see kernel panics, and if yes, is there a pattern?

19:08 <loki666> Kernel panics usually with some NMI errors stuck / being migrated to another CPU

19:09 <loki666> But sometimes other kind of kernel errors or simply hangs

19:16 <apritzel> right, so those weird random hangs typically point to hardware issues. In this context I would suspect the CPU PLL becoming unstable briefly, and its glitches triggering any kind of weird issues

19:17 <apritzel> the H616 manual suggests a specific method for changing the CPU PLL, which involves re-parenting briefly to the (600 MHz) PLL_PERIPH0(1x)

19:17 <apritzel> 3.3.3.1. "Frequency Adjustment of PLL_CPUX"

19:37 <apritzel> but if the reports are solely from the H700 (or maybe that's the only model tested in anger?), it could be something simpler: like one somehow dodgy frequency, maybe, since the H700 got its own list

19:43 <apritzel> loki666: so can you maybe play with the list of OPPs for the H700? For instance remove this H700-exclusive 1032MHz OPP, or remove the H700 (bit 5, so anything starting with 0x2x or 0x3x) from the 1008MHz OPP

19:44 <loki666> Well that why I asked about H616, I can only test H700. It share the same CPU opp with H616 but I think there is flag/param that only enable some freq of that list

19:44 <loki666> Ok I'll try that

19:46 <apritzel> another thing to try is to change the enable bits for the CPU PLL to what we use on the D1: keep bit 31 enabled all the time, and flip bit 27

19:53 <apritzel> loki666: how easily can you reproduce it?

19:53 <loki666> Easy with schedutil it crash very quick

19:53 <loki666> On demand a bit less

19:54 <loki666> So I just need to rebuild the DTB and test

21:49 <apritzel> loki666: do you use something specific to trigger it? I guess benchmark are not so well suited, since they keep the cores busy, so always at full speed?