13:20 <kallisti5> hey! A whole panfrost channel

13:21 <kallisti5> just opened this trying to run Fedora 32 on my Tinkerboard (RK3288) https://bugzilla.kernel.org/show_bug.cgi?id=208331

13:55 <robmur01> yikes, so we abort the driver probe due to an error, but somehow end up in the IRQ handler trying to service imaginary job faults :/

13:56 <robmur01> you don't have CONFIG_DEBUG_SHIRQ enabled by any chance?

13:57 <kallisti5> robmur01: nah.. just the stock fedora 32 kernel.

13:57 <kallisti5> let me check the config though

13:58 <robmur01> (if you just want stuff to work, then focus on why devfreq fails in the first place - you might be missing the config for the governor)

13:58 <kallisti5> CONFIG_DEBUG_SHIRQ=y

13:59 <robmur01> however it's not good that we can go that badly wrong in a failure path... I'll have to try breaking devfreq on my RK3288 box to see if I can repro

13:59 <kallisti5> looks like this kernel has that enabled

14:00 <kallisti5> robmur01: you know if upstream u-boot should have framebuffer on the RK3288 / Tinkerboard? Not getting any video at all on this board

14:01 <robmur01> aha, so it may be partly our fault for not having a sufficiently robust IRQ handler, but it's also partly Fedora's fault for leaving debug options enabled in shipping kernels :P

14:01 <kallisti5> mmhm :-)

14:02 <kallisti5> also! while i'm her and have someone in the know around. I wanna broadcast my annoyance about SOC's and the 10,000 different ways they boot.

14:02 <kallisti5> </spam>

14:02 <robmur01> U-boot display seems OK on my box using the Firefly config; IIRC the Tinker config is rather different, so might not have it enabled

14:03 <kallisti5> robmur01: that makes sense. I'm a little bummed about the Tinkerboard. Only real images it supports are the ones Asus provides... never had much luck outside of Asus's Debian images.

14:04 <robmur01> meh, desktop PCs only seem nicer because the motherboard vendors write all this low-level crap for you ;)

14:04 <kallisti5> lol. I'm converting Haiku to boot from u-boot -> EFI on arm.

14:05 <kallisti5> mostly because I *really* miss bios services

14:05 <kallisti5> also, parsing fdt and shipping a bunch of "baby SOC uart + fb drivers" in our bootloader with native u-boot is bugging me

14:06 <alyssa-> "baby SOC uart" heh

14:07 <robmur01> there's a partial port of EDK2 for RK3399 knocking about, much of that could probably be recycled for a RK3288 port if you're feeling brave :P

14:07 <kallisti5> I'm having trouble just getting our arm EFI bootloader going under edk2 in qemu-system-arm lol

14:07 <kallisti5> it boots... kind of. Then edk2 implodes

14:08 <kallisti5> btw.. we wrote a "generic arm image provisioner" in rust. It's like fedora's arm-image-installer... but better and less horrible

14:09 <kallisti5> https://github.com/haiku/rune pretty much give it an SOC, and it will plop down u-boot, etc binaries where they're needed based on a json manifest

14:09 <alyssa-> kallisti5: wait so you're porting panfrost to Haiku? :o

14:10 <kallisti5> alyssa-: i'm porting Haiku to "arm"

14:10 <alyssa-> ah, well :)

14:10 <kallisti5> been working on it for a while. pretty much originally we did the u-boot -> kernel.ub dance. but like I said above... we're collecting too much FDT + drivers in our bootloader

14:11 <kallisti5> so.. trying to just "pass fdt" through EFI bootloader to kernel.. then use "real drivers"

14:11 <alyssa-> why fb in the bootloader at all?

14:12 <kallisti5> our bootloader does a lot.. you can toggle boot flags, blacklist software packages, blacklist drivers

14:12 <alyssa-> Hmm

14:12 <kallisti5> it'll run in serial, but what fun is that.

14:13 <alyssa-> that's rather uncommon on arm I think

14:13 <kallisti5> keep in mind Haiku != Linux

14:13 <kallisti5> We're special

14:13 <alyssa-> I know :)

14:13 <kallisti5> :-) I have to clairify sometimes :P

14:13 <kallisti5> https://github.com/haiku/rune/blob/master/docs/HaikuMMCLayout.png is my arm layout plans on booting

14:14 <alyssa-> The other approach that comes to mind is running that bootloader as userspace in another Haiku kernel (I know Linux->Linux booting is a thing in coreboot, don't know if that makes sense for haiku)

14:14 <alyssa-> using the 'real' drivers

14:15 <kallisti5> ideally we'll use u-boot's efi services. That should give us access to everything u-boot has

14:15 <kallisti5> *ALSO* u-boot's now-a-days come with a fdt built in

14:15 <kallisti5> so we can just "steal" u-boot's built-in fdt

14:15 <alyssa-> sure

14:16 <kallisti5> our bootloader is more like grub.. It has filesystem drivers, etc. So it's kind of the "lowest hanging fruit"

14:17 <kallisti5> once we get into it... stuff gets easier

14:17 <robmur01> give it another 10 years and U-Boot will probably have reinvented real OF completely :P

14:17 <kallisti5> lol

14:18 <kallisti5> le-sigh. Guess I should toss the Tinkerboard to the side and stick to things that everyone supports like the Pi

14:20 <alyssa-> noooo :-(

14:21 <alyssa-> ;P

14:21 <kallisti5> alyssa-: lol.. this isn't a Haiku project, was just trying to get Fedora running on the Tinkerboard for an iot-car-computer-thing

14:22 <kallisti5> aarch64 is nicer anyway :-D

14:23 <robmur01> hmm, AFAICS U-Boot's Tinker configs appear to have all the same display-related options as the one I'm using :/

14:24 <kallisti5> weeird

14:24 <alyssa-> https://marcin.juszkiewicz.com.pl/2020/06/22/installing-fedora-on-rockpro64/

14:25 <kallisti5> oh.. hmm. disable panfrost

14:25 <kallisti5> i can try that

14:28 <kallisti5> ok.. monitor turned on and off with that kernel option

14:29 <kallisti5> err. bootlooping shortly after panfrost

14:29 <kallisti5> https://pastebin.com/Q2auEXzP

14:30 <kallisti5> definitely looks like that helps. just realized it isn't disabling panfrost, but doing something else.

14:31 <kallisti5> (minus the bootloop)t

14:44 <robmur01> crapping out in early userspace can be caused by insufficient power - my box does that if I forget to switch on the PSU and it's pulling power from a USB port instead

14:45 <robmur01> and firing up the GPU is highly likely to spike the current draw a bit

14:55 <kallisti5> robmur01: ewtrfwfra

14:56 <kallisti5> whoops. sorry. Power went out and lost network for a sec :-)

14:56 <kallisti5> robmur01: good point. On a pretty beefy usb supply, but this cable might be a bit long.

14:59 <kallisti5> robmur01: hey! Good call. slightly shorter cable and i'm online

17:47 <jgmdev> Hi everyone, I want to test the panfrost driver on the Odroid C4 and Odroid N2 so I compiled mesa from git with panfrost dri enabled, set the environment variable PAN_MESA_DEBUG=bifrost and added panfrost to /etc/modules-load.d/panfrost.conf also I'm using linux kernel 5.7.2. But es2_info and glxinfo show that mesa is using llvmpipe so no acceleration :( Is something else I need to install in order to test panfrost on these devices?

17:49 <jgmdev> ah, and just in case I'm using ArchLinuxARM

18:20 <xdarklight> jgmdev: these GPUs are not yet white-listed on kernel side (drivers/gpu/drm/panfrost/panfrost_drv.c)

18:23 <xdarklight> jgmdev: you need at least https://patches.linaro.org/patch/187792/ and https://patches.linaro.org/patch/187793/ - potentially more. then with the Odroid-N2 you may still be having issues as there's some (AFAIK) Amlogic G52 special issue

18:27 <jgmdev> I see, so for testing the kernel branch mentioned on collabora blog post comment https://gitlab.freedesktop.org/tomeu/linux/-/commits/panfrost-odroid-n2/ would do the trick? I will check those patches, thanks for the guideance!

22:06 <chrisf> slowly working through getting an odroid-go2 usable for panfrost dev... built kernel from tomeu's branch, now messing around trying to build a working uInitrd for it

22:08 <chrisf> are there notes somewhere on how to set this up? im very familiar with the mesa side once i get to it, but not quite there yet

23:20 <icecream95> kallisti5: You are probably missing the governor_simpleondemand module from your initramfs

23:25 <icecream95> The workaround alyssa pointed to is just delaying loading panfrost until the root filesystem is mounted and the ondemand module can be loaded from disk