Date: Fri, 28 Feb 2020 15:30:26 +0100 From: =?utf-8?Q?Klaus_K=C3=BCchemann?= <maciphone2@googlemail.com> To: Greg V <greg@unrelenting.technology>, freebsd-arm@freebsd.org Subject: Re: Points to ponder Re: Showstoppers for RPI3 Message-ID: <AE5915B6-659A-4089-A3C5-5C96B10F122C@googlemail.com> In-Reply-To: <d8acedc8-8acd-4e7b-a2c9-7c3f1d7cf4d3@localhost> 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> <d8acedc8-8acd-4e7b-a2c9-7c3f1d7cf4d3@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
> Am 28.02.2020 um 12:03 schrieb Greg V <greg@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=E2=80=99t find the time to = work more on it,=20 A bit tricky to format the uSD-card... afaik a loader is needed. See you in the Wiki when time comes=E2=80=A6 > 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=E2=80=A6... > 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=20 In e.g. OpenBSD than most people know, some NEtBSD-drivers come from = OpenBSD and vice versa=E2=80=A6 And there=E2=80=99s u-boot. But as you described very nice: It all goes into the right direction here: More open mind to look around what=E2=80=99s already available and could = be adopted or extended=20 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 :) =E2=80=A6, I just got a Pi4 in the = mail=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6. Non mainstream OS ? =E2=80=A6. impertinence :-) lol (=E2=80=A6 just = kidding) You will be amazed when you plug your rpi4 to HDMI: it works=E2=80=A6 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=20 Best Regards Klaus=20 > 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@unrelenting.technology>: >=20 >=20 > It's funny to hear massive cost estimates for something that's been = hobbyist/volunteer work a lot of the time :) >=20 > "New platform" is a very abstract term, isn't it? >=20 > The most hardcore kind of new platform is when there's a new ISA like = RISC-V.. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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=E2=84=A2 = support but it's enough for a server, for an arm64 build/test box.. >=20 > 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. >=20 >> Better explanation is at http://www.zefox.net/~fbsd/showstoppers >=20 >> GUI support appears to hinge on VideoCore >=20 > 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. >=20 > 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. >=20 > 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 = :) >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AE5915B6-659A-4089-A3C5-5C96B10F122C>