04:12 <CounterPillow> warpme___: I've experimentally hacked in the device tree stuff for it on my side for hantro and discovered that it's slower than software decoding.

04:12 <CounterPillow> might be a clock issue

09:55 <CounterPillow> warpme___: also if you're Piotr on the mailing list, the -517 errno is EPROBE_DEFER so I think it's missing something it depends on in the device tree maybe?

10:52 <warpme___> CounterPillow: yes: I'm Piotr from mailinglist :-). Indeed - missing dependency in DT was my first idea. I looked on ml for patches adding thermal support for rk356x to be sure i not missed something. looks ok for me. My wip DT is based on Quartz64 DT. I assume Quartz64 has working ok tsadc/thermal so currently i have 3 hypothesis: 1\my x96-x6 box has different clocks/resets setup compared to Quartz64 - so i need to

10:52 <warpme___> reflect this is DT; 2\something is missing in my kernel config; 3\my 5.16 kernel is still missing some patches which i'm not aware of.

10:53 <CounterPillow> thermal sensors work fine on a 5.16 kernel on my Quartz64 so it shouldn't be hypothesis number 3

10:57 <CounterPillow> Make sure the tsadc node in you dts has status = "okay"; I guess

11:16 <warpme___> CounterPillow: yes. i think i have it: https://pastebin.com/pLiZJUqB

12:38 <robmur01> phh: yup, that sounds about right for downstream firmware blobs - IIRC it's hard-coded in the downstream Android U-Boot to simply remove that range from the DT memory node altogether. The RAM gets firewalled off for the Secure world so blows up if Linux so much as sniffs at it

12:42 <robmur01> mainline U-Boot should now be smart enough to carve out a reservation if it knowingly loads an OP-TEE image itself, but of course the crusty old downstream blobs don't work that way

13:08 <phh> robmur01: ok thanks for the information. I'll dig into that, I'm not sure which TEE does glodroid use currently

13:39 <mort> hey, so I'm using the rockchip kernel, and I have a Fibocom NL678

13:39 <mort> https://github.com/rockchip-linux/kernel/search?q=fibocom I can see that the rockchip kernel mentions that NL678 (the vendor/device tuple matches the IDs I see in lsusb, 2cb7:0104)

13:39 <mort> but I don't understand which driver is supposed to support it

13:40 <mort> https://github.com/torvalds/linux/search?q=fibocom in upstream, it's mentioned in qmi_wwan.c, but it's only mentioned in option.c in the rockchip kernel

13:48 <robmur01> mort: "Option" is the name of the driver - https://github.com/rockchip-linux/kernel/blob/develop-4.4/drivers/usb/serial/Kconfig#L625

13:48 <mort> huh

13:49 <mort> does the "option" driver make a wwan0 interface and everything too?

13:49 <mort> because that's what I thought qmi_wwan was needed for

13:51 <mort> and I'm running a kernel with the option driver, with the fibocom modem connected, and I can see it with lsusb, and interact with it using mmcli, but have no wwan0 interface

13:52 <robmur01> No idea, I can only contribute the top tip of looking at the Makefile to see what controls compiling a particular file, then tracking it back through Kconfig to a particular driver :)

14:04 <mort> fair, but quite a few devices have cell modems :p

14:04 <mort> not like I'm hooking this device up to a phone line haha

21:20 <Belgin[m]> Hello! For rk3288 (more specifically, a c100p veyron minnie chromebook), what address does the bootrom load the second stage bootloader at?

21:21 <Belgin[m]> From what I understand, it's not relevant whether it gets loaded from spi, emmc, sdcard, or usb.

21:22 <Belgin[m]> I looked online for a few days, but I could only find a basic datasheet with not much info.