00:40 <tokyovigilante> if you can run the vendor BSP on your device it should be fine for 1.5GHz at 1.16v, part of the chip binning process is failing out those that won’t run at high clocks or with all cores enabled, that’s how Intel etc get their ranges across i3-i9 etc.

08:37 <loki666> I know it runs fine at 1.5GHz on anbernic OS, I just don't know how to check the voltage

08:50 <Jookia> for anyone interested i've posted all my u-boot LCD patches to the list and released a version of my u-boot fork with working LCD :)

09:05 <junari> loki666: first to set max freq dd if=/dev/zero of=/dev/null &

09:06 <junari> then cat /sys/kernel/debug/regulator/regulator_summary

09:06 <junari> and fg CTRL+C

09:11 <Raqbit> I don't know if this is related to tinkering with the device, but it appears the battery in my RG35XX-H wants to escape its case

09:12 <Raqbit> I suppose I'll contact Anbernic to see if they can get me a replacement battery, since it appears to be somewhat custom?

09:29 <loki666> Can't you just glue it back with a double sided tape?

09:30 <loki666> I can send you pictures so you where to place the battery pack if you want

09:31 <loki666> Thanks junari

10:00 <loki666> tokyovigilante indeed, it's runnig at 1.5Ghz / 1.16v on anbernic OS

10:01 <loki666> then I don't know, why it's failing on mine, If I post a sdimage, would you try it ?

10:07 <junari> warpme: Have you encountered hdmi output problems on your AW devices?

10:21 <loki666> to the question is why is my kernel stable when applying cpufreq on 6.10rc3 but not when using tokyovigilante branches, which includes patches to enable iommu, lcd, panfrost etc ... ? apritzel any idea ?

10:24 <apritzel> well, there you have it: lots of patches ;-)

10:25 <Jookia> sometimes you have to have lots of patches :(

10:25 <apritzel> loki666: how's the instability showing? sudden hangs? Or splats in dmesg?

10:30 <loki666> hangs (whith an error like moving NMI from one cpu to another), but not completly because after some time, i might get a kernel oops (usually related to rcu tasks not responding or something)

10:30 <loki666> but it's kind of random, sometime it's something completly different

10:31 <apritzel> sudden hangs are mostly due to clocks or regulators, but they tend to show up more consistently

10:32 <loki666> https://pastebin.com/wa6kTyAq

10:32 <apritzel> things like random page faults are often DRAM related: the DRAM parameters are not *quite* right, which only shows under stress, so when more DMA masters access the DRAM concurrently

10:33 <loki666> 10s between both errors

10:34 <apritzel> RCU and NMI issues often mean a CPU core is "gone fishing", either stuck waiting for a lock, or lost in (PSCI) firmware

10:34 <junari> apritzel: I also have problems with kernel 6.6 and the latest patches. I have to use a fixed frequency

10:35 <junari> And there are no problems with a fixed frequency

10:36 <loki666> https://pastebin.com/XrFjUNw0 here is another of the same variation

10:37 <loki666> I'll try with only the performance gov

10:39 <junari> Has anyone encountered an unusual implementation of HPD? I just can’t figure out why my h616 tvbox doesn’t respond to HDMI in Linux

10:43 <apritzel> loki666: can you boot with "clk_ignore_unused" on the kernel command line? The RCU complaint is somewhat close to "clk: Disabling unused clocks"

10:44 <apritzel> junari: how does "6.6 and the latest patches" fit together? Are you talking about backports of the H616 cpufreq patches to 6.6?

10:51 <loki666> apritzel: nope clk_ignore_unused doesn't fix it

10:56 <loki666> tokyovigilante: if you wanna try my image https://we.tl/t-KPd5GFEEHr

10:59 <junari> apritzel: yes, backporting

14:03 <Raqbit> loki666: I should have been more clear, but I meant that the battery seems to have swollen a bit, making the case bulge.

14:28 <loki666> Raqbit, ouch in that case I would unplug it and stop using it right now, pressure on li-ion battery can ignite them

14:28 <loki666> and contact anbernic yes

14:34 <loki666> Raqbit: how did you charge it, with a USB computer port, or with a wall plug adapter ?

14:36 <loki666> cheap wall plug adapter can have "PWM like" output and if the device doesn't have circuit to rectify it, it will damage the battery

14:42 <loki666> but we are getting out of topic here

16:26 <Raqbit> loki666: Yes, I know and put it aside for now. I think I last charged it with my phone charger, which is a PD charger made by Samsung I believe.

19:28 <tokyovigilante> Raqbit: yup definitely stop using it. macromorgan has done some work with the battery driver to prevent overcurrent/overvoltage from PD chargers, we are advising people not to use them with the Anbernic devices in other forums as there are a couple of other reports of swollen batteries after PD charging.

19:28 <Raqbit> Yikes,

19:29 <tokyovigilante> loki666: if you have a working commit and a non-working commit could you git bisect? however that is exactly the behaviour I saw with non-working OPPs, and later kernel versions seem to have fixed it.

19:29 <Raqbit> well, at least I'll know how to prevent that from happening in the future,

19:33 <tokyovigilante> Raqbit: to be entirely fair I think the problem is that the device is not intended for PD charging, but some chargers seem to supply overcharging current (even 3A @5V which is higher than standard 5V/2A USB 2) despite the device not requesting it. I don’t think the device is asking for 65W PD charging or anything. however the stock firmware doesn’t seem to prevent the PMIC forcing

19:33 <tokyovigilante> that current through to the battery either, which is an issue, but one Anbernic could fix and we can definitely fix in software. the Reddit posts about the batteries are also from low-reputation accounts and may also reflect individual device failure. still not ideal but I wouldn’t panic. definitely don’t use a physically deformed battery though.

19:36 <Raqbit> Yeah, I'll start a support case at Anbernic and see how far that goes.

19:42 <Raqbit> It's very subtle: https://i.imgur.com/2PhxXzK.png

20:13 <tokyovigilante> are you sure that’s not just one of the case clips not in? just asking because the -H has clips and the -Plus doesn’t.

20:45 <loki666> tokyovigilante: I need to find another workflow then, I don't think bisecting with buildroot is practical

21:29 <apritzel> loki666: can't you just replace the kernel in the image that buildroot generates?

21:31 <loki666> yes, but I'm not sure how to use the toolchain the buildroot build, need to dig

21:32 <apritzel> what distro are you on? Most distros provide well maintainted cross toolchains, super easy to install

21:33 <loki666> ubuntu derivate

21:33 <apritzel> apt-get install crossbuild-essential-arm64

21:33 <loki666> ok and to use it when building kernel

21:33 <apritzel> export CROSS_COMPILE=aarch64-linux-gnu-

21:33 <apritzel> export ARCH=arm64

21:34 <apritzel> make defconfig

21:34 <apritzel> make -j 8 Image

21:34 <apritzel> fill the gaps as needed

21:34 <loki666> thanks, I'll give it a shot

22:00 <tokyovigilante> would also recommend FEL-boot for u-boot and TFTP-boot for the kernel, allows very rapid iteration. you can leave the modules on the SD card as long as you have your essential SoC and file system drivers built into the kernel.

22:20 <apritzel> exactly, for convenience I upload the kernel and a (generated) U-Boot boot script via FEL as well, using a shell script: ./fel_boot_kernel.sh Image-6.10-rc3.gz