10:44 <kilobyte_ch> Hello, I'm trying to get OpenGL working on a Rockchip PX30. I have tried the branch develop-4.4 and develop-5.10 from https://github.com/rockchip-linux/kernel. Unfortunately, I get errors about missing rockchip_dri.so files. Any idea what could cause this? https://paste.debian.net/1279391/

11:05 <robmur01> kilobyte_ch: for the BSP kernel, you're going to want the userspace libmali blobs from the BSP as well; to use Mesa with Panfrost you'd want a newer upstream kernel

11:07 <kilobyte_ch> robmur01: Do you know where I get the BSP compatible libmali?

11:10 <robmur01> Sadly the repo on the official Github account disappeared, but it seems the under-the-counter mirror is still here: https://github.com/JeffyCN/mirrors/tree/libmali

11:12 <kilobyte_ch> Ok, thanks. Will try to build that one.

11:17 <kilobyte_ch> robmur01: Interestingly I have a libmali-bifrost-g31-g2p0-x11_1.9-1_arm64.deb on the system. It is also installed. I guess that should be the correct libmali?

11:22 <robmur01> yeah, probably... maybe something's wonky with hooking it up as libGL? rockchip_dri.so would be the Mesa kmsro backend, so if anyone's got as far looking for that then it certainly implies something is amiss

11:23 <kilobyte_ch> Can I check mesa itself somehow?

11:28 <Tenkawa> kilobyte_ch: what physical unit are you working on?

11:29 <kilobyte_ch> Tenkawa: Rockchip PX30 EVB Board

11:32 <robmur01> I'm not 100% sure, but I would suspect that you probably don't want any trace of mesa installed at all (no idea how mesa coexists with vendor drivers on x86, but I'm confident libmali wouldn't expect to share libGL duties with anything else)

11:36 <kilobyte_ch> robmur01: hmm, ok. So I need mesa or mali depending on my HW? I think I installes mesa packages at some point on this thing.. Maybe thats the root cause for my issues.

11:36 <Tenkawa> kilobyte_ch: you running mainline or vendor still? I found this merge that may impact it some a while back if you are running mainline (not 100% sure since they are a bit vague on hardware model specifcs)

11:36 <Tenkawa> https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwjBhPO3it7-AhWUFjQIHanHC84QFnoECAwQAQ&url=https%3A%2F%2Flore.kernel.org%2Fall%2F20211230151428.1a49b1bf%40windsurf%2FT%2F&usg=AOvVaw1RGakeuuEenN0HDKFtUJzs

11:37 <Tenkawa> sorry wromg link

11:37 <Tenkawa> no.. right link.. just ugly header

11:39 <Tenkawa> but not sure if that will solve mesa vs mali dilemma

11:39 <kilobyte_ch> I'm on the vendor kernel

11:39 <Tenkawa> Oh ok.

11:42 <robmur01> the hardware itself (Mali-G31) is well-supported by mesa/panfrost these days, it's just that you'd need to backport an impractically large amount of newer DRM subsystem changes to use it on top of the BSP kernel

11:43 <Tenkawa> robmur01: sounds like exactly what we have been going through with the RK3588

11:43 <Tenkawa> (for mainline)

11:44 <robmur01> yeah, it's pretty much a case of going full BSP or full upstream, there's no real mix-and-match possibilities between kernel and userspace

11:44 <Tenkawa> yep

16:46 <Tartarus> Hey all, does anyone know of a known-good commit in upstream arm-trusted-firmware for rk3399 ? I'm trying to sort out where my own problems may reside and it'd be good to have some known good revisions

16:50 <CounterPillow> Hard to say because upstream tf-a also doesn't build at all depending on your toolchain version due to complete incompetence and idiocy that lead them to enable --fatal-warnings

16:52 <Tartarus> Oh fun

16:52 <Tartarus> I can grab older gcc's off kernel.org if there's a known good commit that's not happy with 12 or 11

16:52 <CounterPillow> I mean you can also just remove --fatal-warnings from the Makefile

16:52 <CounterPillow> which is a patch I submitted and they ignored

16:52 <Tartarus> Ah

16:53 <Tartarus> Well, part of my issue is that while I have an older Armbian image for rockpro64-rk3399 that does work, current Debian images give me no output, nor did current Armbian, nor do my own tf-a + u-boot

16:54 <Tartarus> So I was hoping to grab known good commits, build, see if that works or not

16:54 <Tartarus> and the tf-a hash in that old armbian image isn't upstream

16:55 <CounterPillow> I installed Debian on a rockpro64 not too long ago, are you sure it's not a problem with how you're writing u-boot?

16:59 <Tartarus> .. The thing where you complain and then see the problem? Yeah, me, now. That uSD card I was trying seems to be crap, grabbed a different one and current Armbian is showing up

17:00 <CounterPillow> Classic :D

17:05 <Tartarus> And then yup, my build also boots

17:23 <Tenkawa> Tartarus: which Armbian image are you using?

17:24 <Tenkawa> I want to go look at our build list

17:28 <Tartarus> Tenkawa: Note that it was user-error, reflashing to another card resolved it, but Armbian_23.02.1_Rockpro64_bullseye_current_5.15.96.img

17:32 <Tenkawa> Nod. I wonder how the Bookworm builds are running (I have my own custom build on my Rockpro64)

22:34 <Kwiboo> paulk: regarding your pbp suspend/resume issue, could be related to an issue in u-boot, are you are running spl from emmc? issue is related to loading part of tf-a into sram when sdhci sdma is enabled

22:36 <Kwiboo> will shortly post a series that should disable emmc dma use in spl for rk3399 and rk3588

22:37 <Tenkawa> Kwiboo: any theories on why that would impact Towboot running from SPI?

22:38 <Kwiboo> recommend building u-boot with CONFIG_SPL_FIT_SIGNATURE=y, that should run checksum test after loading atf/uboot into memory

22:38 <Tenkawa> Ah..

22:39 <Kwiboo> I just got "Bad hash value for 'hash' hash node in 'atf-2' image node" on my rockpro64 after having CONFIG_MMC_SDHCI_SDMA=y

22:39 <Kwiboo> could be same issue loading atf-2 from spi into sram

22:39 <Tenkawa> I'll check my builds and see what its set to

22:41 <Kwiboo> after https://patchwork.ozlabs.org/project/uboot/patch/20230422012309.402799-2-jonas@kwiboo.se/ it should be possible to use u-boot,spl-sfc-no-dma to disable dma in spl (using this method for rk35xx)

22:48 <Tenkawa> Yeah.. not set on our build

22:48 <Tenkawa> ./sources/u-boot/.config:# CONFIG_SPL_FIT_SIGNATURE is not set

22:48 <Tenkawa> I'll add that in and update it

22:49 <Tenkawa> Thanks for the info

22:57 <Kwiboo> https://github.com/Kwiboo/u-boot-rockchip/commit/d1fab7cce75d4f8d81a0b005a3a731332601e42f should fix loading from emmc

22:58 <Kwiboo> looking closer rk3399 do not use the sfc driver, but could still be similar issue loading the pmu code into sram, will test some spi booting from my rockpro64