Points to ponder Re: Showstoppers for RPI3

[Greg V]

Feb 28, 2020 4:09:43 AM bob prohaska :

> In a thread entitled "how to get freebsd on a new board?" it's
> suggested that a port of FreeBSD to a new platform would cost
> $20-50K, presumably with manufacturer support. Let's suppose
> it'll cost $100K if the manufacturer won't help.

It's funny to hear massive cost estimates for something that's been hobbyist/volunteer work a lot of the time :)

"New platform" is a very abstract term, isn't it?

The most hardcore kind of new platform is when there's a new ISA like RISC-V..

For new arm64 SBSA/SBBR standard hardware, it's just like with amd64: try it, fix any bugs exposed by new HW (e.g. for Ampere eMAG we needed to save one more register when calling EFI services, and to read more ACPI parameters of the PCIe controller), add quirks as required (e.g. Arm N1 SDP dev system shipped with busted PCIe which required a semi custom driver). Just maybe a bit more bugs because the platform is younger.

For embedded arm boards, there's a lot of variety in how much weird custom stuff there is on each SoC. With Allwinner, Rockchip, Amlogic etc., most controllers are either standard (XHCI, SDHCI) or reused between most of them (Synopsys DesignWare for SD, USB2, Ethernet), and all the board support code is is some wrappers around that, plus power/clock management per SoC vendor. Nobody has paid for this kind of support for e.g. Rockchip on FreeBSD.

The Raspberry Pi 3 and older were a big outlier: pretty much *everything* there was a custom Broadcom thing, including (WTF) a custom interrupt controller instead of the ARM GIC. That was expensive to support. Pretty much nobody wants to write drivers for obscure interrupt controllers and stuff.

Now with the Pi 4, it's a much more sensible SoC, and there is UEFI firmware that presents it as an ACPI system with fully generic descriptions for the basic stuff and even USB 3 (XHCI). This is basically already supported for free. Of course that's not Full™ support but it's enough for a server, for an arm64 build/test box..

Speaking of which, I just got a Pi4 in the mail. I'll try it out soon. Might look into porting NetBSD's Ethernet driver or something.

> Better explanation is at http://www.zefox.net/~fbsd/showstoppers

> GUI support appears to hinge on VideoCore

Linux has all the graphics drivers, we just port them. But supporting embedded GPUs is quite a challenge. Well, it's not something very clever, but something very very tedious. For PCIe devices, we have glue in LinuxKPI, but for FDT, I'm not sure we even *could* implement the Linux API for FDT on top of ours. So you could manually convert the drivers to our API, but that's way too much of boring work.

Also, manu@ went in an.. interesting direction with this: writing a new display output driver for allwinner from scratch, on top of a different port of the KMS/DRM layer than the one we use for desktop. That kinda complicates things I guess.

So right now we only have proper graphics on PCIe GPUs from AMD and Intel, and systems that can't use these cards can only be headless (or run with crappy unaccelerated graphics via EFI framebuffer or a display-only driver). I think that's good enough for a non-mainstream OS :)