From owner-freebsd-arm@freebsd.org Fri Feb 28 11:03:43 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 981892603A3 for ; Fri, 28 Feb 2020 11:03:43 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out.migadu.com (out.migadu.com [91.121.223.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.migadu.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48TRVQ0KlHz4b7f for ; Fri, 28 Feb 2020 11:03:41 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: (Migadu outbound); Fri, 28 Feb 2020 11:03:39 +0000 Received: from [127.0.0.1] ([185.211.158.135]) by out.migadu.com (Haraka/2.8.16) with ESMTPSA id ACA356B2-6295-490A-9C07-FDA24EE4696A.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 verify=FAIL); Fri, 28 Feb 2020 11:03:35 +0000 Date: Fri, 28 Feb 2020 11:03:33 +0000 (UTC) From: Greg V To: bob prohaska Cc: freebsd-arm@freebsd.org Message-ID: In-Reply-To: <20200228010924.GA87999@www.zefox.net> References: <11951E01-EC13-4FBB-938A-AEB5700C4281@yahoo.com> <20200226052045.GA79939@www.zefox.net> <04e8e290e5d7bb810f76ece4ff33d6e1006e63cd.camel@freebsd.org> <280455B5-E201-494F-A4EB-2426A12B7E2C@googlemail.com> <20200226235908.GD22189@lonesome.com> <5AD91C8A-F4A2-4C53-9D03-CB83EDAC9C0A@gromit.dlib.vt.edu> <20200228010924.GA87999@www.zefox.net> Subject: Re: Points to ponder Re: Showstoppers for RPI3 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Correlation-ID: DKIM-Signature: v=1; a=rsa-sha256; bh=OHple6/k9qqy54T4SpmcGsCtyJcx4vm/uJ1kdyNTQkA=; c=relaxed/simple; d=unrelenting.technology; h=from:subject:date:to; s=default; b=V9INgkvBCLxW1o/LZb/pbUTZkTG3hh0NhDVV0jb7kSLlPtudPARrqEse273fQQ6TT7wBrPJ4aqxZTwGEhX7+o2tvIsBE5aaj/DwJeRyJ+0e9A2yGISRePjpsTGV4ny525htg0iWufkIzC6A8hlM+BAOAvfxnyONURsybe/L+04s= X-Rspamd-Queue-Id: 48TRVQ0KlHz4b7f X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unrelenting.technology header.s=default header.b=V9INgkvB; dmarc=pass (policy=none) header.from=unrelenting.technology; spf=pass (mx1.freebsd.org: domain of greg@unrelenting.technology designates 91.121.223.63 as permitted sender) smtp.mailfrom=greg@unrelenting.technology X-Spamd-Result: default: False [-4.34 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[unrelenting.technology:s=default]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:91.121.223.63]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-1.84)[ip: (-9.79), ipnet: 91.121.0.0/16(-1.47), asn: 16276(2.06), country: FR(0.00)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[unrelenting.technology:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[63.223.121.91.list.dnswl.org : 127.0.10.0]; DMARC_POLICY_ALLOW(-0.50)[unrelenting.technology,none]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_NOT_FQDN(0.50)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16276, ipnet:91.121.0.0/16, country:FR]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 11:03:43 -0000 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 :)