From owner-freebsd-arm@freebsd.org Tue Dec 3 14:43:53 2019 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 AF7191B1186; Tue, 3 Dec 2019 14:43:53 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f42.google.com (mail-io1-f42.google.com [209.85.166.42]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47S4Vc4g7dz4S9c; Tue, 3 Dec 2019 14:43:52 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f42.google.com with SMTP id i11so3912565ioi.12; Tue, 03 Dec 2019 06:43:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=nhJJR1dcj3svzazRtkC3TJd/7MXuKrkgT6Z4BKRPdas=; b=Onys3Oe3ay+uLWi59QYsjcM0ZeCMC0eeRuqR41+X6xACARZVQZ5epW6iih9+fZkBvL JsG3E5FTt9084oTdM9D79iS/AdAuPmeho6dPXwf5+M6WpZaJr7gQFimA74QqDyWHo5JI vTdq52wws/H22AgDzWrJE8h5Dx4KwQkYNKIiWg8IGEefHeLC9s+6TropNSANbwe1nlfa 13lQ7T/tG15IRY2rY8Y70rTYLW5R6lKgGCCuE9hSdunSNEvRA6HLE7fHaZPtpkQzoXJJ 0Rxnhx4QJwwYzDB9+OxiOz950kRw8/cdIve6RepanV79llyzwJnTWiJI0zL8zKWMexGf moJQ== X-Gm-Message-State: APjAAAX93ldOF9NiRw7cFqK0RCJxGe+07Ms54Mvk+zGg+4iL8ABDMhp3 ugim4y8UV08eU5AAy9KdJbDFD2YMIEnFw+U2B3oAGoyz X-Google-Smtp-Source: APXvYqwOAleyx3rY/N/HoF9TiqGaMHcuM49r1yxE7Bsx4oetLXWaiyZTul+GGwH4dr0YaAuopX7i9vpfZhMo5eK6OIs= X-Received: by 2002:a6b:3b06:: with SMTP id i6mr2424311ioa.185.1575384230466; Tue, 03 Dec 2019 06:43:50 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ed Maste Date: Tue, 3 Dec 2019 05:57:18 -0500 Message-ID: Subject: arm64 as Tier 1 for FreeBSD 13 To: freebsd-arch , freebsd-arm Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 47S4Vc4g7dz4S9c X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.42 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-4.20 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-2.20)[ip: (-5.84), ipnet: 209.85.128.0/17(-3.15), asn: 15169(-1.94), country: US(-0.05)]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[42.166.85.209.list.dnswl.org : 127.0.5.0]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[42.166.85.209.rep.mailspike.net : 127.0.0.17]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] 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: Tue, 03 Dec 2019 14:43:53 -0000 The FreeBSD core team recently modernized and updated the Platform Tier documentation, available at https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/archs.html. I believe that arm64 as a platform is close to being Tier 1 and would like to determine what's still needed to get there. Many of the Tier 1 guarantees are already provided on arm64. and I won't copy them here. I've provided my comments on what I see as the gaps between the Tier 1 attributes and arm64's current state, and am very interested in hearing about anything I've missed. > Binary updates and source patches for Security Advisories and Errata > Notices will be provided for supported releases. We don't do this today, but have the ability to do so for arm64 server platforms. (Due to its design, freebsd-update does not work particularly well on devices with slow root filesystems such as SD cards.) > Changes to userland ABIs will generally include compatibility shims to > ensure correct operation of binaries compiled against any stable branch > where the platform is Tier 1. These shims might not be enabled in the > default install. If compatibility shims are not provided for an ABI > change, the lack of shims will be clearly documented in the release > notes. In the past we've used the fact that a platform is no Tier 1 to make ABI-breaking changes, like switching time_t from 32 to 64 bits. I see no issue guaranteeing we will not do that on arm64. > Changes to certain portions of the kernel ABI will include compatibility > shims to ensure correct operation of kernel modules compiled against the > oldest supported release on the branch. Note that not all parts of the > kernel ABI are protected. No concern here either - in practice I believe most of the issues that could arise here will be machine-independent and need to be addressed for all platforms. > Official binary packages for third party software will be provided by the > ports team. For embedded architectures, these packages may be cross-built > from a different architecture. We do this today, although on somewhat slow and unstable hardware. I expect faster arm64 package build machines to be added in the near future. > New features which are not inherently platform-specific will be fully > functional on all Tier 1 architectures. This introduces some additional commitments on those developing new features, but in practice I believe we already generally expect new functionality to work on arm64. > Tier 1 platforms should be fully documented. Basic operations will be > documented in the FreeBSD Handbook. Some Handbook updates are warranted for arm64, although this is true for existing Tier-1 architectures as well (e.g. documenting amd64 BIOS booting but not UEFI). > Build and test automation support either in the FreeBSD.org cluster or > some other location easily available for all developers. Embedded > platforms may substitute an emulator available in the FreeBSD.org cluster > for actual hardware. We build FreeBSD/arm64 in CI and smoke test on physical hardware today. More is needed (including adding a capable ref machine to the cluster) but I don't see any significant issues here. > Developers should be able to build packages on commonly available, > non-embedded Tier 1 systems. This can mean either native builds if > non-embedded systems are commonly available for the platform in question, > or it can mean cross-builds hosted on some other Tier 1 architecture. This is somewhat of a challenge today - there aren't many arm64 platforms readily available in a configuration most suited to developer use, such as a 4- or 8-core system with 16GB of RAM and SATA- or NVMe-connected storage. Smaller systems (e.g. Pine64) are readily available but not quite capable enough; larger systems (e.g. Marvell ThunderX and Ampere eMAG) are out of reach for typical developer use. User-mode QEMU cross-builds are a possibility, but this item is one that should resolve over time as new platforms become available.