Date: Fri, 28 Feb 2020 11:03:33 +0000 (UTC) From: Greg V <greg@unrelenting.technology> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org Subject: Re: Points to ponder Re: Showstoppers for RPI3 Message-ID: <d8acedc8-8acd-4e7b-a2c9-7c3f1d7cf4d3@localhost> In-Reply-To: <20200228010924.GA87999@www.zefox.net> References: <11951E01-EC13-4FBB-938A-AEB5700C4281@yahoo.com> <CACNAnaEiv5NZZz%2BxfETkhSZ-zbjZ3Ya6z7pyteheP4zj3EK1Gg@mail.gmail.com> <20200226052045.GA79939@www.zefox.net> <E866B6BE-7948-4412-82EF-999A2F8C0DF9@googlemail.com> <04e8e290e5d7bb810f76ece4ff33d6e1006e63cd.camel@freebsd.org> <280455B5-E201-494F-A4EB-2426A12B7E2C@googlemail.com> <20200226235908.GD22189@lonesome.com> <F4EB9ED4-017D-4CDC-A927-035E1C595CD4@googlemail.com> <A13BFE46-0D14-465D-9139-CB208616AF80@kronometrix.org> <5AD91C8A-F4A2-4C53-9D03-CB83EDAC9C0A@gromit.dlib.vt.edu> <20200228010924.GA87999@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 hobbyis= t/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 i= t, fix any bugs exposed by new HW (e.g. for Ampere eMAG we needed to save o= ne more register when calling EFI services, and to read more ACPI parameter= s of the PCIe controller), add quirks as required (e.g. Arm N1 SDP dev syst= em shipped with busted PCIe which required a semi custom driver). Just mayb= e 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 co= ntrollers are either standard (XHCI, SDHCI) or reused between most of them = (Synopsys DesignWare for SD, USB2, Ethernet), and all the board support cod= e is is some wrappers around that, plus power/clock management per SoC vend= or. 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* t= here was a custom Broadcom thing, including (WTF) a custom interrupt contro= ller instead of the ARM GIC. That was expensive to support. Pretty much nob= ody 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 firmwar= e that presents it as an ACPI system with fully generic descriptions for th= e basic stuff and even USB 3 (XHCI). This is basically already supported fo= r free. Of course that's not Full=E2=84=A2 support but it's enough for a se= rver, for an arm64 build/test box.. Speaking of which, I just got a Pi4 in the mail. I'll try it out soon. Migh= t 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 embed= ded GPUs is quite a challenge. Well, it's not something very clever, but so= mething 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 to= p 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 dis= play output driver for allwinner from scratch, on top of a different port o= f 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 cr= appy unaccelerated graphics via EFI framebuffer or a display-only driver). = I think that's good enough for a non-mainstream OS :)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d8acedc8-8acd-4e7b-a2c9-7c3f1d7cf4d3>