13:23 <mriesch> punit: could this clock be related to a certain PCLK_XPCS? just stumbled over this clock, the driver in barebox requires it for some reason while the linux driver does not seem to consider it at all

13:52 <tlwoerner> my rock64 board struggles to boot, but i suspect it's probably just my board, but i thought i'd throw it out there in case anyone else was seeing somthing similar

13:52 <tlwoerner> it often gets stuck right after probing the sdmmc

13:53 <tlwoerner> but if i reset it often enough it usually succeeds

13:53 <tlwoerner> i've tried 2 different power supplies (5V3A and 5V4A) and i've tried 2 different uSD cards

13:53 <tlwoerner> it *feels* like older kernels are more likely to succeed whereas i've never successfully booted a 5.14.y kernel (for example)

13:55 <tlwoerner> https://paste.ee/p/djs3v

14:10 <diederik> tlwoerner: what os and kernel are you using? I have no problem with my rock64 running Debian (sid) and a slightly modified 5.14 kernel (Debian's 5.14 is in experimental)

14:26 <tlwoerner> diederik: i'm using yocto for my builds, i'm working off their master branch and have been trying a bunch of different kernels based on linux-yocto, stable, and linus' tree

14:26 <tlwoerner> if debian is carrying any patches specifically for the rock64, or rockchip, i'd be interested in applying them to my build to see if anything changes

14:33 <diederik> I found one 3 y/o patch for firefly, so that doesn't seem relevant

14:35 <diederik> But the kernel config can be relevant. https://salsa.debian.org/kernel-team/linux/-/merge_requests/384 was recently merged improving things for rock64 on debian

14:42 <robmur01> tlwoerner: I think that one's easy...

14:42 <robmur01> [ 0.612233] Waiting for root device /dev/mmcblk1p7...

14:42 <robmur01> [ 0.650598] mmcblk0: p1 p2 p3 p4 p5 p6 p7

14:43 <robmur01> the kernel's gonna be waiting forever for that partition to appear on the wifi adapter ;)

14:44 <tlwoerner> but i then hit the reset button and it works

14:44 <tlwoerner> robmur01: wifi adapter?

14:44 <tlwoerner> diederik: thanks! i'm looking at my config now

14:44 <robmur01> I bet because the MMC device happen to probe in the other order

14:45 <tlwoerner> ah blk1

14:45 <robmur01> well, whatever's on mmc1 - I assume it's an SDIO wifi chip

14:45 <tlwoerner> ah, i think that's the emmc

14:46 <tlwoerner> as opposed to the sdmmc i want to use

14:46 <tlwoerner> robmur01: thanks! i hadn't noticed

14:46 <robmur01> oh, quite possibly - I forget what's what on Rock64 since I don't have one

14:47 <robmur01> anyway, there *has* been an upheaval in MMC ordering relatively recently, but there should now also be DT aliases to re-stabilise it per-board

14:49 <robmur01> possibly those are missing for Rock64, or you just haven't updated your DTB because hey they're supposed to be stable and you shouldn't need to :(

14:49 <robmur01> (DTBS should be stable, that is, not probe order)

14:50 <robmur01> either way, GPT and "root=UUID=..." FTW!

14:52 <diederik> +1 on checking dtb.

14:52 <punit> mriesch: I didn't find any reference to pclk_xpcs in the rk3399 manual. The only reference in linux seems to be for rk3568

14:53 <diederik> tlwoerner: https://github.com/LibreELEC/LibreELEC.tv/tree/master/projects/Rockchip is worth a look. I used that to improve things on Debian

15:01 <tlwoerner> robmur01: nice! that would explain why i can't get a recent kernel to boot

15:02 <tlwoerner> diederik: thanks for the LibreELCE pointer, i'll take a look