01:13 <naoki> macromorgan: now I can use rk3568_bl31_v1.36.elf. thank you so much!

07:59 <pinchartl> naoki: was the issue just the order of entries in the .its ?

08:03 <naoki> pinchartl: what I did is surely just changing the order of entries, but I cannot explain technical detail about it...

14:45 <macromorgan> glad to hear it works, but man I can't wait for mainline A-TF to be ready...

14:45 <macromorgan> on that note, anyone hear anything about support in A-TF (or U-Boot proper) for the 3588?

14:46 <macromorgan> I have a Radxa Rock Pi 5B that I want to get on mainline everything. The only downside is it's a device meant to be used for (personal) work, so I might have to press it into duty sooner than later and without as much room to tinker.

14:47 <macromorgan> I have a Raspberry Pi 4 that I use for compiling natively for ARM and running ARM VMs... the Rock Pi 5B is going to take over for that once I get the rest of the parts in.

14:48 <CounterPillow> heard nothing on that front yet, but mainline kernel is coming along well thanks to sre's work

14:49 <macromorgan> cool

14:50 <macromorgan> I see no movement at all in U-Boot and dread the idea of kicking things off for the RK3588. Have you tried EDK2 on it?

14:50 <CounterPillow> I haven't, I just know it exists as part of the SDK

14:50 <CounterPillow> but I'd imagine rockchip EDK2 is gonna be a bit like rockchip u-boot in that it won't be the be all and end all of codebases, especially considering the EDK2 windows-like code style

15:17 <warpme> CounterPillow: i saw your's good post on ArchLinuxARM forum (topic: Is ArchlinuxARM project still alive? Or just build failures?). Q is very valid!. Do you know what happens there? i.e. i still see install sudo breaks pacman by missing lib crypto-1.1 effectively killing system. i see issue was reported on eos forums 22/12/2022 and still seems to be not resolved. Effectively this start mean to me that "is dead" is not Q. Is

15:17 <warpme> rather observation....

15:23 <robmur01> it's certainly annoying that linux-aarch64 is still stuck on a version with the USB bug that prevents my RK3399 from booting...

15:23 <robmur01> (yeah, I did at least rebuild a fixed package for that, and I could equally build my own newer kernels, but I'm lazy :P)

15:25 <warpme> robmur01: sorry for spam: this may help maybe (for you as user of course): https://github.com/warpme/miniarch

15:26 <robmur01> "but Robin, if you're lazy, why do you stubbornly continue to use one of the most awkward do-everything-manually distros?"

15:26 <robmur01> I make no sense :)

15:26 <warpme> :-)

15:27 <CounterPillow> warpme: hopefully we'll get an official arch linux port for arm64 some day

15:27 <robmur01> For now I suspect logic would point in the direction of Manjaro, if one were logical

15:27 <warpme> robmur01: this is Arch Way

15:40 <mps> robmur01: what board is your rk3399

15:43 <robmur01> mps: NanoPC-T4 - IIRC that bug didn't affect boards that override dr-mode to "host", but this is one of the few that leave it set to "otg"

15:44 <mps> robmur01: is that u-boot problem

15:44 <robmur01> no, kernel driver bug

15:45 <mps> ah, ok. I thought it is in u-boot

15:45 <mps> on gru-kevin I can boot from usb-c ssd fine

15:47 <robmur01> this one: https://lore.kernel.org/linux-rockchip/4f398e4c-973b-7843-2f75-27324d109277@linaro.org/

15:48 <robmur01> the broken "fix" also affected stable between (I think) 5.19.5 and 5.19.8 - Arch is on 5.19.7 :(

15:48 <mps> so old

15:50 <mps> but all kernel versions after 5.1 worked for me on gru-kevin which rk3399

15:50 <mps> for long I used usb-c as rootfs

15:50 <mps> usb-c ssd*

16:21 <robmur01> well, yeah, gru DTs force the port into host mode like I said, hence why broken otg wasn't noticed more widely

16:26 <mps> yes, boot from otg is not used often