Re: Porting to my custom 030 board

Le lun. 17 févr. 2025 à 13:52, Lawrence Manning <[email protected]> a écrit :
> My board: github.com/aslak3/maxi030
> I have a fairly workable Linux port forthis board

And it's a very nice board too. I have looked at your design when
thinking about my own, though I'm going in a completely different
direction by using *only* a FPGA for everything non-CPU (including
memory, and maybe some extra coprocessors when using an '030).

> [snip stuff I would like to know as well but haven't got around it so I can't help]

> One particular area of interest is the structure of the X server and whether it can (without a complete rewrite) leverage bitblit hardware on top of a basic framebuffer.
> This is possible in Linux kernel console land but frustratingly the fb X server can’t leverage it. I recon I could get a passable GUI experience out of such a setup.

That I can help with, having done all of that (and still annoyed that
FB acceleration was dropped in Linux, I had done the pm3fb one many
years ago).
I have added support for my own FPGA-based video device in my SBusFPGA
[1] device. It does help a lot with the user experience!
It's not particularly hard for the console, I ended up doing it two
different ways (once for some custom "vector" engine, then using a
much simpler design where a micro-coded VexRiscV core does the job
[5], which is the current version [2]).
For X11 it's a bit more of a mess, as depending on what your
accelerator can do you could accelerate using EXA (old-school X11
acceleration) or XRender (an extension to do more sophisticated
operations). I ended up doing both, as basic EXA acceleration isn't
quite enough for "modern" X11 software. IIRC, the EXA stuff would be
the accel function without "Composite" in the name [3], those with
"Composite" are for EXA [4]. You also need the X11 and NetBSD driver
to sort of "work together" so that X11 has access to the hardware
appropriately. In my case it's not 100% obvious, as the console run in
8-bits indexed color (for speed), while X11 runs in 24-bits TrueColor
(as all the "modern" software expects that...).

I was on a SPARCstation so it was natural for me, but I will say the
NetBSD support for the Sun cg3 (8-bits color, no acceleration), Sun
cg6 (8-bits color, accelerated in console and 8-bits X11) and Sun cg14
(a.k.a. SX, 8-bits in console, 24-bits in X11, using a built-in vector
accelerator) are good examples to look at. It's SBus so the kernel is
aware of the hardware through the PROM, which you might need to
change, but other than that one of them should be similar to what you
want to achieve, and they all have good console and X11 support.

Cordially,

Romain

[1] <https://github.com/MelkhiorVintageComputing/SBusFPGA>
[2] <https://github.com/MelkhiorVintageComputing/SBusFPGA/blob/main/NetBSD/9.0/usr/src/sys/dev/sbus/goblin.c>,
search for 'ACCEL'
[3] <https://github.com/MelkhiorVintageComputing/SBusFPGA/blob/f4c5c0e5b72f8991af55432149b596efb855f2ac/NetBSD/9.0/usr/xsrc/external/mit/xf86-video-goblin/dist/src/goblin_accel.c#L59-L67>
[4] <https://github.com/MelkhiorVintageComputing/SBusFPGA/blob/f4c5c0e5b72f8991af55432149b596efb855f2ac/NetBSD/9.0/usr/xsrc/external/mit/xf86-video-goblin/dist/src/goblin_accel.c#L69-L71>
[5] <https://github.com/MelkhiorVintageComputing/VintageBusFPGA_Common/blob/main/blit_goblin.c>,
the code is a bit weird as it uses custom RISC-V instructions for
double-width load/store and some Xrender-specific maths

-- 
Romain Dolbeau