Re: freebsd-update and arm64.aarch64 (rpi4)

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