Date: Sat, 15 Jan 2022 04:16:08 -0800 From: Mark Millard <marklmi@yahoo.com> To: tech-lists <tech-lists@zyxst.net> Cc: freebsd-arm@freebsd.org Subject: Re: freebsd-update and arm64.aarch64 (rpi4) Message-ID: <27ED08A4-C263-4D33-B5C3-A5B6B1834C15@yahoo.com> In-Reply-To: <YeKbZeefLFJ0Oc0X@ceres.zyxst.net> References: <12B2BE2B-07F2-4DB4-9D9D-20FDAF6C717E.ref@yahoo.com> <12B2BE2B-07F2-4DB4-9D9D-20FDAF6C717E@yahoo.com> <YeKbZeefLFJ0Oc0X@ceres.zyxst.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello. On 2022-Jan-15, at 02:01, tech-lists <tech-lists@zyxst.net> wrote: > On Fri, Jan 14, 2022 at 10:31:10PM -0800, Mark Millard wrote: > >> Looks documented to me. But one has to find and follow >> the definitions/reference-material. >> >> There are places that reference having "binary security >> and errata updates to FreeBSD" or such wording that do >> not mention the tool(s) used for such. But . . . > > [snip] > >> (Admittedly, https://www.freebsd.org/releases/13.0R/installation/ >> makes no mention of arm64/aarch64 but mentions only i386 and >> amd64. But there is material elsewhere that indicates arm64/aarch64 >> has such as of 13.0-RELEASE+, given its Tier 1 status for >> 13.0-RELEASE+, see later below.) > > This illustrates the point I'm trying to make. It can be inferred > from the overall tier1 status, but given the sheer number of boards > on this arch it would be best I think if, rather than an inference, > the supported boards (for freebsd-update) were listed explicitly, > in order to provide clarity. This should be obvious and easy to find. Given the "sheer number of boards" they will never be generally explicitly tested with freebsd-update over time and listed individually as the official ones that will have freebsd-update kept working "for sure". (Any more than there has been an explicit list for amd64 or i386.) I think part of the answer is probably something more like: Supported are boards with (working) UEFI/ACPI firmware, supporting what ACPI supports. (Over simplified, but I expect you get the idea.) (The RPi*'s with https://github.com/pftf/RPi4 materials not counting.) The boards that get explicit snapshots and release builds are probably only ones the beyond-UEFI/ACPI ones that might be explicitly listed as kept-working-with-freebsd-update, subject to changes in that what boards have such builds at any time. But even for those, U-Boot, RPi* firmware, etc. would likely not be updated by freebsd-update. (This is like freebsd-update not updating UEFI/ACPI firmware either.) It is also the case that some of those boards have no one claiming to be actively supporting the boards if/when things break for them. They keep working as they have been so long as special (significant) effort is not required to undo breakage. It is less obvious what would happen if a significant breakage taking significant effort happened. (In some respects, my response is driven by what I read into your request for what purposes it might serve --and sticking to that presumed context. I may well also have guessed wrong in various other respects and folks actually involved may well correct my guesses.) > [snip] > >> One thing that I've not seen explicit material for, that was >> referenced in Ed's announcement, is: >> >> QUOTE >> We will also be suggesting one or more low-cost reference >> platforms for FreeBSD/arm64. >> END QUOTE >> >> I've no clue where to find such suggestions. > > neither do I! I also expect that something like, say, a HoneyComb based system might count as "low-cost" here. (There is no general agreement on what "low-cost" identifies.) Small Board Computers are probably not what is being referenced by the terminology. Given the lack of an active supporter, no RPi*'s are likely to be listed even if some SBC's are referenced. === Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?27ED08A4-C263-4D33-B5C3-A5B6B1834C15>