<clarity>
I might be thinking of a tool called secure boot console
<clarity>
but who knows maybe sign tool does the same thing
Daaanct12 has joined #linux-rockchip
Daanct12 has quit [Read error: Connection reset by peer]
Daaanct12 has quit [Quit: WeeChat 4.5.2]
Daanct12 has joined #linux-rockchip
ldevulder has quit [Ping timeout: 268 seconds]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #linux-rockchip
ldevulder has joined #linux-rockchip
MyNetAz has quit [Remote host closed the connection]
MyNetAz has joined #linux-rockchip
<linkmauve>
Hi, from userland, how do I figure out which thermal_zone corresponds to which core? I’d like to fix htop to display the temperature on the rk3588, but I can’t figure out the link in sysfs, even though it’s properly described in the dts.
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<linkmauve>
qschulz, that only gives the thermal zones, I don’t see any link to the devices described in the cooling-maps property.
<linkmauve>
Same as /sys/class/thermal/thermal_zone*/
<linkmauve>
Hmm actually the cooling-maps property is described as only being there to handle trip nodes, not for generic mapping between a thermometer and a cores cluster.
Daanct12 has quit [Quit: WeeChat 4.5.2]
warpme has joined #linux-rockchip
naoki has quit [Quit: naoki]
MyNetAz has quit [Remote host closed the connection]
MyNetAz has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #linux-rockchip
ldevulder has quit [Ping timeout: 260 seconds]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Stat_headcrabbed has joined #linux-rockchip
<robmur01>
yeah, I don't think you can rely on that - technically every device can cool every zone, it's just that some will be more effective than others
<robmur01>
and the practicality is that if you do assign a device to multiple zones, then the governors end up fighting each other
<robmur01>
(at least last time I looked)
<robmur01>
I guess you just have to trust the sensors to be named descriptively
Stat_headcrabbed has quit [Client Quit]
robmur01 has quit [Remote host closed the connection]
robmur01 has joined #linux-rockchip
ldevulder has joined #linux-rockchip
warpme has joined #linux-rockchip
psydroid has joined #linux-rockchip
<warpme>
Kwiboo : i'm playing with yours nice rk3528 enablement code (uboot & 6.14 mainline). Small Q: have you got working Eth on rock2a?
Stat_headcrabbed has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Kwiboo>
warpme: noticed I got a PHY -19 issue a day or two ago on rock-2a, works with generic u-boot on e20c (motorcomm) and possible sige1 (rtl8211f), will run some more test on rock-2a to see if the phy just needs to be reset before linux
ldevulder has quit [Ping timeout: 244 seconds]
psydroid has quit [Ping timeout: 252 seconds]
<linkmauve>
robmur01, I’m not talking about any cooling device, but about sensors. In the rk3588 there are three sensors, one for the four Cortex-A55, and one for each cluster of two Cortex-A76, and the kernel will downclock these clusters based on their temperature.
<linkmauve>
Being able to display them instead of N/A, and if possible without hacks, would be useful I think.
Stat_headcrabbed has quit [Quit: Stat_headcrabbed]
<robmur01>
linkmauve: I know, I was just agreeing that the fact that some sensor->zone->cooling map->cooling device->CPU association might exist still does not tell you anything meaningful
<robmur01>
you can only really rely on the sensor itself to tell you what it is, i.e. the hwmon name/labels
<linkmauve>
The issue with the names is that you can’t derive the association in any meaningful generic way from userspace, without parsing the dtb yourself.
<robmur01>
that's what I mean, there is no such association that can be relied on
<robmur01>
if the sensor calls itself "CPU_BIG", all you can do is print "CPU_BIG" and hope that the user understands what that might be
<robmur01>
yeah htop might have special cases for Intel/AMD where the sensor/CPU topology is sufficiently standard per vendor to assume an association, but that can't generalise
<linkmauve>
Even on SoCs with a single sensor for all the cores, we can’t have any link that it indeed covers those.
<linkmauve>
And not like the NVMe or the GPU or something else.
<linkmauve>
And trying to extract meaning from the sensor’s name sounds like it’ll be prone to breakage.
<robmur01>
AFAICS on the Xeon box to hand, there's an identifiable "coretemp" hwmon device exposing sensors labelled "Core n", so it's pretty easy to guess
<robmur01>
so at best htop would have to have more per-SoC special cases...
<linkmauve>
This isn’t only about htop, but every other similar tool where it makes sense to have an approximative temp per part of the SoC.
<linkmauve>
CPU cores, but also GPU (cores?), SSDs, and every other part.
<linkmauve>
robmur01, ugh…
psydroid has joined #linux-rockchip
<robmur01>
right, the status quo is that the tools all have to know, which is a hard problem in general
<robmur01>
the trouble is that it's easy to look at a load of Intel platforms, see that they are all very similar, replace "know" with "assume" and declare it an easy problem because everyone knows everything is x86
<linkmauve>
This is about ACPI and not about x86, isn’t it? We could standardise something in device tree/sysfs and it would be kind of the same.
<robmur01>
it's not even ACPI, AFAICS Intel and AMD are each doing their own thing, it's just that they're doing it consistently across all their products
<robmur01>
meanwhile both my AArch64 and x86 boxes show an "nvme" hwmon device the same way, so that's fine, similarly the "amdgpu" one from the PCIe card
<robmur01>
although again, AMD/NVIDIA/Intel GPUs vs. SoC mess will be the same story as for CPUs
<CounterPillow>
thankfully on Arm once we all stop eating glue and huffing party balloons we can just go through the DTs and add whatever scheme we came up with, like how the device form factor thing happened.
<maz>
that, and world peace.
<CounterPillow>
I'm afraid your binding for world peace will need another revision, it should describe the world and not the peace
<robmur01>
war { status = "disabled"; );
vagrantc has joined #linux-rockchip
ungeskriptet has quit [Ping timeout: 260 seconds]
ungeskriptet has joined #linux-rockchip
System_Error has quit [Ping timeout: 264 seconds]
System_Error has joined #linux-rockchip
raster has quit [Quit: Gettin' stinky!]
stikonas has joined #linux-rockchip
<linkmauve>
robmur01, weird, even on latest htop master with this per-SoC list, the temperatures are still left as N/A.
ungeskriptet_ has joined #linux-rockchip
ungeskriptet has quit [Ping timeout: 272 seconds]
ungeskriptet_ is now known as ungeskriptet
franoosh has quit [Remote host closed the connection]