I don't have UART adapter, so anything outside HDMI is not shown. I don't know if it helps: FreeBSD has the EXACT behaviour on OrangePi Plus2E
NetBSD Problem Report #60069
From www%netbsd.org@localhost Tue Mar 10 09:18:43 2026 Return-Path: <www%netbsd.org@localhost> 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) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.netbsd.org", Issuer "R12" (not verified)) by mollari.NetBSD.org (Postfix) with ESMTPS id 6A2A01A9239 for <gnats-bugs%gnats.NetBSD.org@localhost>; Tue, 10 Mar 2026 09:18:43 +0000 (UTC) Message-Id: <20260310091841.D3C3B1A923A%mollari.NetBSD.org@localhost> Date: Tue, 10 Mar 2026 09:18:41 +0000 (UTC) From: netbsd%harakirimail.com@localhost Reply-To: netbsd%harakirimail.com@localhost To: gnats-bugs%NetBSD.org@localhost Subject: NetBSD non booting on H3 Allwinner X-Send-Pr-Version: www-1.0 X-From4GNATS: "netbsd%harakirimail.com@localhost via gnats" <gnats-admin%NetBSD.org@localhost> >Number: 60069 >Category: port-arm32 >Synopsis: NetBSD non booting on H3 Allwinner >Confidential: no >Severity: critical >Priority: high >Responsible: port-arm32-maintainer >State: feedback >Class: sw-bug >Submitter-Id: net >Arrival-Date: Tue Mar 10 09:20:00 +0000 2026 >Closed-Date: >Last-Modified: Wed Mar 11 12:15: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. >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: From: Martin Husemann <martin%duskware.de@localhost> To: gnats-bugs%netbsd.org@localhost Cc: Subject: Re: port-arm32/60069: NetBSD non booting on H3 Allwinner Date: Tue, 10 Mar 2026 10:27:18 +0100 On Tue, Mar 10, 2026 at 09:20:01AM +0000, netbsd%harakirimail.com@localhost via gnats wrote: > OS versions tested: NetBSD 10.0, 10.1, 11.0 (current). current != 11.0 (or RC2), did you actually test -current? Martin State-Changed-From-To: open->feedback State-Changed-By: skrll%NetBSD.org@localhost State-Changed-When: Wed, 11 Mar 2026 12:13:31 +0000 State-Changed-Why: Question asked 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. >Unformatted:
|
|
(Contact us) $NetBSD: query-full-pr,v 1.47 2022/09/11 19:34:41 kim Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2026 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.