port-arm/60905: evbarm needs something like a machdep.bootmethod sysctl

["martin%NetBSD.org@localhost via gnats" <gnats-admin%NetBSD.org@localhost>]

>Number:         60905
>Category:       port-arm
>Synopsis:       evbarm needs something like a machdep.bootmethod sysctl
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-arm-maintainer
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Mon Oct 19 11:55:00 +0000 2026
>Originator:     Martin Husemann
>Release:        NetBSD 11.99.9
>Organization:
The NetBSD Foundation, Inc.
>Environment:
System: NetBSD h-pulse.aprisoft.de 11.99.9 NetBSD 11.99.9 (GENERIC64) #579: Thu Oct 15 10:21:48 CEST 2026 martin%seven-days-to-the-wolves.aprisoft.de@localhost:/work/src/sys/arch/evbarm/compile/GENERIC64 evbarm
Architecture: aarch64
Machine: evbarm
>Description:

When installing on an evbarm system, the installer has trouble telling which
of the half a dozen available boot methods the system it runs on will use
to boot the installed system.

On other architectures this is a lot simpler (one arch = one bootmethod)
and probably the most complex example already is x86 with two boot methods
(BIOS and UEFI). On x86 this is easy to tell, there is a sysctl for it:

machdep.bootmethod = UEFI

For evbarm we so far support three methods:

 - 32 bit Raspberry PI related machines

 - "FDT boot" via u-boot on various non-FDT'ized evbarmv5 and evbarmv6
   SoCs

 - ACPI boot for everything else.

So far this was relatively easy to tell apart, as sysctl hw.model either
contained a specific substring for the 32bit RPis, or was "netbsd,generic-acpi"
for ACPI boots, and everything else had to be "FDT boot".

However, this does not work anymore (or never really did):
aarch64 boards can be booted via EFI but no ACPI and use FDT instead:

https://mail-index.netbsd.org/port-arm/2026/10/19/msg009694.html

or via Tow-Boot leading to:

https://gnats.netbsd.org/60872

(hw.model = pine64,pinebook-pro)

We need to be able to tell all these cases apart (and ideally document them
and their special boot setup requirements somewhware).

The installer needs to know if a plain ELF kernel is used (or a *.ub or
other image type) and whether to create a ESP boot partition and populate
it.

I would have suggested to #ifndef _LP64 the two non-ACPI cases, but apparently
there is work going on to fully support FDT-only boots on aarch64. I also
have been told that full FDT is required to get drmkms code working on
evbarm.

So please:
 - create a sysctl that tells us whether we booted via bootaa64.efi
   (or the 32bit equivalent)
 - create a list of wiered boot methods and hw.model strings
   or a special new sysctl that names the boot method and create a
   table of such methods with (minimal) setup instructions

I don't understand "non-ACPI" or "FTD-boot" for aarch64, do the go
via bootaa64.efi too but just pass FDT and no ACPI? Maybe in that
case we need a sysctl telling us if the FDT is present, and another
that tells us about ACPI availability.

I would also expect either ACPI tables being available for GPU stuff
or an official ACPI-way to pass full or partial FDT through.


>How-To-Repeat:
s/a

>Fix:
n/a