10:02 <xdarklight> chewitt: too bad :/

10:42 <chewitt> is the "5f6c6d61ffffffff" value = 50ºC or was that just a lucky guess?

10:44 <xdarklight> it was a lucky guess unfortunately :/

10:46 <xdarklight> chewitt: hmm, another random guess: can you enable the SAR ADC node (&saradc) on your board like it's done here: https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi (note: you may have to copy the vddio_ao18 over as well)?

10:47 <xdarklight> maybe Linux is disabling the ADC clock and now u-boot (who uses the ADC to read the temperature) gets only garbage

14:36 <chewitt> xdarklight: I'll have a play once kids are in bed, thanks

14:58 <chewitt> HUB:~ # cat /sys/class/hwmon/hwmon0/temp1_input

14:58 <chewitt> 50000

14:58 <chewitt> so that's a beer I owe you :)

15:01 <chewitt> the next item on my list is figuring out why these boxes can't see the cpu serial

15:01 <chewitt> on all the GXL devices I have "cat /sys/bus/platform/devices/firmware\:secure-monitor/serial" shows the serial

15:02 <chewitt> on these two GXBB device I see "cat: read error: Invalid argument"

15:02 <chewitt> as most Android boxes don't have MAC addresses set, I'm using a simple systemd service to create a persistent MAC from the CPU serial

15:03 <chewitt> but this isn't possible on these boxes

15:03 <chewitt> and I'm not sure if this is something specific to these two (WeTek Hub/Play 2) or all GXBB devices

16:04 <xdarklight> chewitt: sweet :)

16:04 <xdarklight> chewitt: are you running mainline or -next ?

16:05 <chewitt> mainline

16:06 <chewitt> as much as the bleeding edge can be interesting.. it's also hard work

16:07 <chewitt> i'll test without last night's patch later .. if it's just the missing saradc node etc. I'll send a patch to add it to the wetek dtsi

16:07 <xdarklight> ah, Jerome added the correct clock for the efuse driver

16:07 <xdarklight> and you're missing the serial from the secure-monitor

16:08 <xdarklight> so these probably aren't related

16:11 <xdarklight> but maybe it's one of these: https://github.com/torvalds/linux/commit/d6ee1e7e9004d3d246cdfa14196989e0a9466c16 (just another random guess...)

17:34 <xdarklight> narmstrong: I'm upstreaming IRQ support for the IP101GR PHY currently. do you still have your GXBB NEXBOX A95X - and if you do: could you test IRQ support (assuming the PHY IRQ is routed to GPIOZ_15 like on all other GXBB boards) if I send a patch for that?

18:35 <narmstrong> xdarklight: I can have a look tomorrow, they may be in our lab already

20:14 <ndufresne> Make the cerbero cache relocatable was much simpler then I anticipated, https://gitlab.freedesktop.org/ndufresne/cerbero/commit/8a24881a307bd909029721ef6f191d550a613a8b

21:29 <xdarklight> narmstrong: for testing on the GXBB Nexbox A95X you need: 1) IP101GR PHY interrupt patches from https://patchwork.ozlabs.org/cover/999574/ 2) .dts patch which enables the interrupt for that box: https://paste.kde.org/pysqfpndj

21:30 <xdarklight> cat /proc/interrupts should show that you're *not* getting a flood of interrupts on GPIOZ_15. if you remove the "icplus,select-interrupt;" or apply the .dts-patch without the PHY driver patches then you'll probably see a flood of interrupts