01:26 <apritzel> Hi, is there anyone left (except wens) who cares about sunxi-tools? libv? I figured the CI is broken (for a while, actually), also make check fails

01:28 <apritzel> I fixed this all in a new PR (https://github.com/linux-sunxi/sunxi-tools/pull/171), but merges were somewhat sluggish in the recent past (wens: many thanks for doing that!)

01:30 <apritzel> for instance there is PR#164 which is good to go, but sits there for a while now

01:31 <apritzel> and I think we are ready for a new release after more than five years ...

14:25 <adjtm> hi smaeul, I have some question about D1

14:26 <adjtm> doesn't D1 have GMAC? The support table says N/A but the allwinner web page says it has gigabit EMAC

14:27 <adjtm> also, I want to run andriod on D1, is RV Panel board support planed?

17:24 <Hypfer> Hi, we have a thermal shutdown issue with a rooted vacuum robot based on the allwinner MR813. According to the kernel log, it shuts itself down, because thermal_zone0 reaches more than 110°C

17:24 <Hypfer> Is there something else we could check from an ssh session apart from the temperature reading?

18:21 <smaeul> adjtm: yes, D1 has an EMAC, and that EMAC supports gigabit Ethernet. I suppose that could go in the GMAC row of the table as well, even though there's no "GMAC" hardware block

18:22 <adjtm> I thought that gigabit EMAC was the same thing as GMAC :)

18:23 <smaeul> some older chips had two separate MACs: one for 10/100, and one for gigabit. the EMAC in the A83T and newer supports all speeds with one MAC

18:24 <smaeul> the Lichee RV Panel will be supported by Linux once someone writes a device tree, but that is a long way from getting Android running

19:58 <gamiee> Hello, bit generic question, but what is the best way to test stability and temperature performance of Allwinner SoC? I have Allwinner H3 SBC and I want to test how stable it will be when max cpu usage and ram bandwidth will be used, and how much temperature it will reach. Thanks

20:24 <evgeny_boger> Hypfer: do you use mainline kernel? If so, maybe your dts is lacking calibration data for temperature sensor. It's unique for each unit and stored in OTP memory

20:25 <Hypfer> evgeny_boger that's a good question. No idea honestly. Is there a way to figure that out?

20:27 <Hypfer> The robot is a Dreame Z10. We're just rooting those, meaning that the whole software image is made by the vendor of that thing

20:28 <Hypfer> The kernel features /proc/config.gz Maybe a flag in there might tell us something about whether or not it is mainline?

20:28 <evgeny_boger> well, if you get your Linux kernel shipped with device, it's probably not a mainline kernel

20:28 <evgeny_boger> right, it's not

20:36 <evgeny_boger> But even if the THS sensor gives wrong reading, I tihnk the recent vendor kernel should lower frequency first in case of overheating. Shutdown is the last resort. I would try to lower the CPU frequency via cpufreq and see what happens next. If it's still overheating, I would say either the particular part is dead or something is VERY wrong with the schematics

20:36 <evgeny_boger> well, I would trust the temperature reading in this case. There is a tiny chance it's software problem. Maybe an error in Allwinner BSP or vendor somehow messed up with THS driver. But otherwise I would look for hardware issue.

21:07 <Hypfer> Yeah it's probably a hardware failure of some sort. According to the user, the problem just appeared out of the blue

21:07 <Hypfer> I do wonder what kind of component failure would cause this though

21:08 <Hypfer> Like.. maybe a voltage regulator that puts out too much?

21:28 <jernej> smaeul: is MMU issue resolved for D1?

21:29 <jernej> I mean, did maintainers find acceptable way to add quirk for D1?

23:46 <smaeul> jernej: current status is https://lore.kernel.org/lkml/20220209123800.269774-1-heiko@sntech.de/T/ which seems like it will be accepted