Re: port-arm32/60069: NetBSD non booting on H3 Allwinner

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

The following reply was made to PR port-arm32/60069; it has been noted by GNATS.

From: Nick Hudson <nick.hudson%gmx.co.uk@localhost>
To: gnats-bugs%netbsd.org@localhost, port-arm32-maintainer%netbsd.org@localhost,
 gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Cc: 
Subject: Re: port-arm32/60069: NetBSD non booting on H3 Allwinner
Date: Wed, 11 Mar 2026 12:12:44 +0000

 On 10/03/2026 09:20, netbsd%harakirimail.com@localhost via gnats wrote:
 >> Number:         60069
 >> Category:       port-arm32
 >> Synopsis:       NetBSD non booting on H3 Allwinner
 >> Confidential:   no
 >> Severity:       critical
 >> Priority:       high
 >> Responsible:    port-arm32-maintainer
 >> State:          open
 >> Class:          sw-bug
 >> Submitter-Id:   net
 >> Arrival-Date:   Tue Mar 10 09:20:00 +0000 2026
 >> Originator:     NetBSD reporter
 >> Release:
 >> Organization:
 >> Environment:
 >> Description:
 > Description:
 > There is a significant regression in bootarm.efi starting from NetBSD 10.x and persisting in 11.0 when booting on Allwinner H3 SoC (specifically tested on OrangePi Plus 2E). The boot process hangs indefinitely immediately after the EFI loader stage.
 >
 > Symptoms:
 > The last message visible on the screen is:
 > EHCI unable to shut down host controller (or similar EFI handoff messages).
 > After this point, the system becomes unresponsive. No kernel green text appears, and there is no output on the serial console (TTL).
 >
 > Confirmed Workaround:
 > Replacing the bootarm.efi file from NetBSD 10/11 with the version from NetBSD 9.x allows the system to boot perfectly into a NetBSD 11 kernel. This confirms that the issue is strictly related to the EFI loader's memory mapping or FDT handoff logic introduced in the newer versions, and not a kernel or U-Boot regression.
 >
 > Environment:
 >
 > Hardware: OrangePi Plus 2E (Allwinner H3, 2GB RAM).
 >
 > Firmware: U-Boot (tested with both older and 2024/2025 mainline versions).
 >
 > OS versions tested: NetBSD 10.0, 10.1, 11.0 (current).
 >
 > Architecture: earmv7hf (evbarm).
 >
 > Attempted Troubleshooting (without success):
 >
 > Updated U-Boot to the latest version.
 >
 > Disabled EHCI/USB via userconf in boot.cfg.
 >
 > Disabled genfb via userconf.
 >
 > Manually loaded DTB using the dtb command in the loader.
 >
 > Set fdt_high=0xffffffff in U-Boot to prevent FDT relocation.
 >
 > Tried boot -n to disable KASLR.
 >
 > Conclusion:
 > The new bootarm.efi seems to have an incompatibility with the EFI memory map or the way it handles the transition to the kernel on this specific 32-bit ARM SoC. The fact that the 9.x loader works as a drop-in replacement suggests a regression in the sys/stand/efiboot logic regarding memory allocation or EFI GOP/FDT injection.
 
 If you have serial console does adding
 
 options EARLYCONS=sunxi, CONSADDR=0x01c28000
 
 options VERBOSE_INIT_ARM
 
 to the kernel you're trying to boot with modern bootarm.efi show anything?
 
 I think I got the correct EARLYCONS/CONSADDR for your board.