00:09 <macromorgan> hanetzer: https://anbernic.com/collections/new-arrival/products/anbernic-rg503

00:09 <macromorgan> BSPs suck so the sooner we can use mainline the better

00:10 <hanetzer> yooo, that's pretty dope.

00:10 <hanetzer> and yes. BSPs suck.

00:10 <hanetzer> t. struggling with bsp bullshit from 3.10 :D

00:22 <hanetzer> its hard enough getting stuff working even with a fully open source stack

00:40 <CounterPillow> 5.19-rc + your own dts should Just Werk™

00:40 <CounterPillow> actually you might also need the ARM SCMI patch to get it to find clocks

00:41 <pnill> Does mainline support LCD/LVDS on most rockchip? that's my limiting factor using mainline for some allwinner boards I have.

00:42 <CounterPillow> Oh hmmm, good point, DSI support is still not working on mainline for the rk3566

00:48 <macromorgan> that's not great to hear :-(

00:48 <macromorgan> as I'm dealing with a DSI panel (with SPI commands)

00:50 <macromorgan> do you know how A-TF integrates with that branch of U-Boot? it looks like using a BL31.elf doesn't work (as it doesn't get appended to the u-boot.itb properly), possibly because of some of the image build commands changed?

00:55 <hanetzer> CounterPillow: heh. my current project involves 5.19-rc, my own dts, a patched sata phy driver, and two of my own drivers :P

00:56 <CounterPillow> macromorgan: you'll want bl31.bin, not .elf afaik

00:58 <macromorgan> have to resort to what's in the Rockchip rkbin though right, since it's not open yet?

00:58 <macromorgan> using rk3568_bl31_v1.24.elf

00:59 <CounterPillow> oh hmmm let me check

01:00 <CounterPillow> pgwipeout uses 1.28 https://gitlab.com/pgwipeout/quartz64_ci/-/blob/main/.gitlab-ci.yml#L77

01:03 <macromorgan> hmm... okay

01:04 <macromorgan> I will mess with those and see what happens :-)

01:05 <vagrantc> /18/21

01:09 <macromorgan> that did the job, thanks

04:58 <mriesch> is the anbernic rg503 schematic available by chance?

06:56 <macc24> hanetzer: i'm working on it too

06:56 <macc24> mriesch: no.

07:34 <mriesch> macc24: shame. but thanks anyway!

10:03 <hanetzer> macc24: hmm?

10:33 <LinuxHackerman> macromorgan: looks like a neat device, how are the ergonomics?

13:10 <macc24> hanetzer: i mean, i'm working on the mainline kernel port for rg503 with macromorgan

13:17 <macromorgan> LinuxHackerman: You know, I don't know. I have yet to play a game on it as I have mostly experimented with U-Boot and the devicetree thus far.

13:17 <LinuxHackerman> hehe

13:17 <macromorgan> for that matter... I think I've played maybe 1 game on my Odroid Go Advance while I've spent countless hours working on the kernel and bootloader (proud to say it can run 100% mainline once the battery driver gets approved)

13:18 <macc24> macromorgan: sometimes there's more fun in hacking on something than using it

13:18 <macromorgan> true

13:18 <LinuxHackerman> nice work!

13:19 <LinuxHackerman> and yeah same, though if I don't even have a use for the device at the end of the day...

13:19 <LinuxHackerman> (not that I actually hack on the kernel's code much, in spite of what my nick suggests...)

13:21 <macc24> anything i do in userspace is to lead by example

13:21 <macc24> or to show-off

13:58 <hanetzer> macc24: ahh nice :)

15:23 <mriesch> macc24: macromorgan: do you know already how the display is connected on this device? mipi dsi?

15:24 <macc24> mriesch: dsi

15:24 <mriesch> macc24: i see, thx

15:24 <macc24> the panel has support for commands both on mipi interface and on spi

15:24 <macc24> and fucking rockchip chose spi...

15:25 <macc24> (the board was designed by rk)

15:25 <macc24> also guess what

15:25 <mriesch> ok.. is anyone aware of any rockchip hardware that actually uses the rgb output for lcd?

15:25 <macc24> they wired it backwards and now we have to bitbang spi

15:25 <macc24> macromorgan can tell more info about that

15:26 <mriesch> macc24: oh dear :-/

15:27 <robmur01> I have an old RK3288 box that uses the RGB interface to drive an encoder for composite output

15:28 <robmur01> not tried it with mainline since it's the weirdo RK1000 and I'd have to port the whole set of crusty BSP drivers (they did it as an MFD for some reason)

15:30 <mriesch> mfd for a display output? and i thought i have seen everything...

15:36 <robmur01> because everyone would want to use an A/V codec chip for just audio without having to load a driver for the video part, right? O_o

15:46 <macromorgan> it's hard to say without a schematic, but yes it appears the SPI is wired backwards... which seems odd to say the least...

16:17 <macc24> robmur01: well i can kinda see why would they mfd that

16:18 <macc24> but i'm also a shitty kernel developer and not a good one xD

16:34 <robmur01> would you also MFD an HDMI driver to have independent audio, video, DDC and CEC drivers? :P

16:45 <CounterPillow> I thought the rk3328 composite video output was its own DRM driver

16:45 <CounterPillow> oh, rk3288

16:45 <CounterPillow> misread, nevermind me

16:57 <robmur01> yeah, I keep meaning to play with 3328's built-in composite output since that driver is so trivial

16:57 <robmur01> and come to think of it, I do actually have some 3.5mm TRRS splitters now :D