11:55 <amazingfate> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/firmware/arm_scmi/base.c?h=next-20220503&id=3b0041f6e10e5bdbb646d98172be43e88734ed62 this commit caused rk3568 failed to get clk from scmi

11:56 <CounterPillow> ok, so that validates robmur01's theory that this is the firmware being buggy

11:56 <CounterPillow> but the Linux kernel getting more strict about it

11:57 <CounterPillow> here's an interesting question: why does the code even care if the protocol response size is wrong? It's clearly able to get the real size anyway.

12:00 <amazingfate> arm-scmi firmware:scmi: Malformed reply - real_sz:8 calc_sz:4, t->rx.len is 12, sizeof(u32) is 4, loop_num_ret is 3

12:01 <amazingfate> here is the log I printed

12:02 <CounterPillow> remove the ret = -EPROTO; break; and it should boot I think

12:03 <amazingfate> yes, I commented it and cpu and gpu can get clk now

12:08 <CounterPillow> rockchip should fix the bug in their firmware or let us fix the bug by publishing the source but Linux should still be tolerant of the wrongly implemented protocol here I think

12:11 <amazingfate> Distros like armbian can patch the kernel since we have found the root cause. And then wait for a firmware update

12:19 <CounterPillow> which version of rkbin is this?

12:19 <CounterPillow> or whatever their ATF blob is called

12:19 <macc24> bl31?

12:19 <CounterPillow> yeah

12:28 <amazingfate> I use this version: https://github.com/JeffyCN/rockchip_mirrors/blob/rkbin/bin/rk35/rk3568_bl31_v1.32.elf

12:28 <macc24> try compiling it yourself from upstream if it's available

12:29 <amazingfate> it should be a close source binary

12:29 <CounterPillow> macc24: it's not yet

12:29 <CounterPillow> they plan to open-source it eventually but they keep delaying it

12:30 <macc24> classic rockchip

12:30 <CounterPillow> Eh, they had a stressful development cycle for rk3588

13:01 <macc24> is there any way to support multiple devices with same soc using one sd card with u-boot on sd card? each device has a "hardware id" info connected to an adc channel and dtb files aren't compatible?

13:16 <robmur01> in principle I guess it ought to be feasible to pack a U-Boot FIT image with multiple DTBs and implement a mechanism for selecting between them

13:17 <macc24> are there any examples?

13:19 <robmur01> no idea, sorry, just a general observation on the nature of FIT

13:21 <macc24> hmm "board_fit_config_name_mach"

13:48 <robmur01> oh, so MULTI_DTB_FIT is a thing already, neat! :)