Points to ponder Re: Showstoppers for RPI3

[Klaus Küchemann]

> Am 28.02.2020 um 12:03 schrieb Greg V <greg at unrelenting.technology>:
> It's funny to hear massive cost estimates for something that's been hobbyist/volunteer work a lot of the time :)
Hi Greg, ol`hobbyist , (.. just kidding ),

I am very happy to hear that things and approaches are moving in the right direction.
good description you give here, thanks.
> Greg V
> The most hardcore kind of new platform is when there's a new ISA like RISC-V..

I have an HFunleashed available, but didn’t find the time to work more on it, 
A bit tricky to format the uSD-card...
 afaik a loader is needed. See you in the Wiki when time comes…
> Greg V
> Nobody has paid for this kind of support for e.g. Rockchip on FreeBSD.

impertinence that nobody pays  for it ;-)

> Greg V
> Pretty much nobody wants to write drivers for obscure interrupt controllers and stuff…...
> 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.
Yep, there is much more support for brcm-hw available 
In e.g. OpenBSD than most people know, some NEtBSD-drivers come from OpenBSD and vice versa…
And there’s u-boot.
But as you described very nice:
It all goes into the right direction here:
More open mind to look around what’s already available and could be adopted or extended 
Instead of reinventing the wheel.


> Greg V  ...(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 :) …, I just got a Pi4 in the mail………….
Non mainstream OS ? …. impertinence  :-) lol (… just kidding)
You will be amazed when you plug your rpi4 to HDMI: it works…
While you will ask yourself where to plug your keyboard/mouse ..
 but no problem for hobbyists : just take your soldering iron an plug a PS/2 Auxiliary Port ;-). Ha Ha 

Best Regards
Klaus 





> 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.

> Am 28.02.2020 um 12:03 schrieb Greg V <greg at unrelenting.technology>:
> 
> 
> 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 :)
> 
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"