NetBSD Problem Report #60905

From martin@h-pulse.aprisoft.de  Mon Oct 19 11:50:48 2026
Return-Path: <martin@h-pulse.aprisoft.de>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits)
	 client-signature RSA-PSS (2048 bits))
	(Client CN "mail.netbsd.org", Issuer "YR1" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id DD6621A923B
	for <gnats-bugs@gnats.NetBSD.org>; Mon, 19 Oct 2026 11:50:47 +0000 (UTC)
Message-Id: <20261019115044.06DD5E1FFFF@mail.duskware.de>
Date: Mon, 19 Oct 2026 13:50:38 +0200 (CEST)
From: martin@NetBSD.org
Reply-To: martin@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: evbarm needs something like a machdep.bootmethod sysctl
X-Send-Pr-Version: 3.95
X-From4GNATS: "martin@NetBSD.org via gnats" <gnats-admin@NetBSD.org>

>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:/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

Home	PR Database Search