04:29 <Spirit532> A question for the rockchip people: I'm designing a devboard with the RV1106, and I want to use an AP6212 for WiFi+BT. The AP6212 requires a 32k clock on the LPO pin, which I'm assuming the UART0_RX_M0/CLK_32K/CLK_REFOUT/RTC_CLK0/GPIO0_A0_z pin can output. Am I correct in this assumption? If so, how can I tell it to do that in linux?

04:30 <Spirit532> I do have an RK818-3 PMIC on board that I'm trying to bully into generating the right rails for the RV1106. It's not designed to, the sequence is all wrong and the defaults are not right, so in the case that it ends up cooking the chip, I'd rather not use its integrated RTC output. Especially because the RV1106 RTC consumes around ~1uA, and the

04:30 <Spirit532> RK818-3 is over 10uA for the same peripheral.

07:56 <Kwiboo> qschulz: good to know there is other similar issues ;-)

08:01 <Kwiboo> ianh: the gmac driver is already merged in u-boot, was merged for one of the 2024.01-rcX tags if I remember correctly, if mainline u-boot is built with a device tree for your board linux would probably work without ethernet phy issue

08:06 <Kwiboo> qschulz: I will try to send out a rk3399 series to sync DT and among other things enable spl fit signature check later today, not fully sure how to handle puma, due to different fit payload offsets it has different tpl+spl size limit, 224 kb for entire idbloader.img

08:08 <Kwiboo> for now I just skipped enable spl fit signature, see https://github.com/Kwiboo/u-boot-rockchip/commits/rk3399-2024.07-wip for work-in-progress patches, final series will have small adjustments to defconfigs

08:51 <qschulz> Kwiboo: ianh: https://lore.kernel.org/netdev/20231201142453.324697-1-heiko@sntech.de/

09:00 <wens> I wonder if it makes sense to enable OF_LIBFDT_OVERLAY in U-boot for the whole platform

09:01 <qschulz> wens: what's the context for this thought :) ?

09:02 <wens> me sometimes randomly applying overlays for whatever fun stuff I have connected

09:02 <wens> I used to have one of my boards running a GPS module over UART with PPS timing signals

09:03 <wens> recently I have multiple sensors and a small SPI OLED display telling me the temp, humidity, CO2 concentration, etc.

12:05 <qschulz> has anyone managed to get VDPU381 on RK3588 to decode VP9 on downstream kernel?

16:36 <crossdev> Which kernel module / kernel config option should I use for CPU temperature sensing on Orange Pi 5?

16:44 <crossdev> How about hardware spec sheet of that board beyond the basic info, is it available somewhere?

16:44 <jakllsch> is there a schematic?

16:45 <jakllsch> apparentyl

16:48 <jakllsch> i'm guessing you'd need the driver for whatever on-die temperature sensors there are

16:48 <jakllsch> doesn't look like there's a external temperature sensor in my quick reading of the schematic

17:16 <crossdev> That seems to be correct. Is there a way to find out what on-die sensor there might be? The schematic you speak of, could you please share a link?

17:17 <crossdev> I tried compiling in everything in Device Drivers -> Hardware monitoring support but still nothing shows up

17:20 <ianh> anybody got any advice on how to debug a kernel panic happening in a tasklet / softirq? the stack trace is completely opaque - just IRQ / softirq routines from top to bottom, and the link reg is just in tasklet_action_common

17:20 <ianh> like the useful info would be what function pointer is in the tasklet struct...hmm

17:32 <ianh> crossdev: tsadc is in the dts for rk3588s afaict, rk driver should be built if you build with CONFIG_ROCKCHIP_THERMAL - it registers a hwmon device in sysfs - should at least be able to get the temp that way, but not sure what u need

19:15 <crossdev> ianh: so something should should show up in /sys/class/hwmon as I figure, but no: I only get the nvme temperature

19:19 <ianh> dang. anything in /sys/class/thermal?

19:21 <crossdev> nope

22:18 <ianh> crossdev: pretty weird if you're running on mainline. i just fired up the orangepi5 on my desk running 6.7.x and all hwmon devices are showing up correctly / showing up when running sensors. if you're running the orangepi-supplied image then that may be the issue as it's built against the Rockchip 5.10 BSP and who knows how much board support is actually in there.

22:21 <ianh> crossdev: my recommendation would be to build or grab an Armbian image. it's easy and will give you a well-supported u-boot, kernel, etc.