Re: misc/59151: efiboot hangs on new motherboard

["Taylor R Campbell via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR misc/59151; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: Paul Ripke <stix%stix.id.au@localhost>
Cc: RVP <rvp%SDF.ORG@localhost>,
	netbsd-bugs%NetBSD.org@localhost, gnats-bugs%NetBSD.org@localhost
Subject: Re: misc/59151: efiboot hangs on new motherboard
Date: Thu, 21 May 2026 12:35:37 +0000

 > Date: Fri, 7 Mar 2025 21:56:28 +1100
 > From: Paul Ripke <stix%stix.id.au@localhost>
 >=20
 > On Fri, Mar 07, 2025 at 10:25:01AM +0000, RVP via gnats wrote:
 > >  On Fri, 7 Mar 2025, stix%stix.id.au@localhost wrote:
 > > =20
 > >  >> Fix:
 > >  > I suspect that this firmware implements memory protection on the efi=
 boot
 > >  > image. I also assume that the variables written to as defined in the=
  asm
 > >  > are read-only, generating an exception, resulting in a silent hang.
 > >  >
 > > =20
 > >  Yeah, I think this makes sense. Can you see if the patch below also fi=
 xes
 > >  this issue?
 > > =20
 > >  ```
 > >  diff -urN a/src/sys/arch/i386/stand/efiboot/bootx64/startprog64.S b/sr=
 c/sys/arch/i386/stand/efiboot/bootx64/startprog64.S
 > >  --- a/sys/arch/i386/stand/efiboot/bootx64/startprog64.S	2023-06-24 05:=
 31:04.000000000 +0000
 > >  +++ b/sys/arch/i386/stand/efiboot/bootx64/startprog64.S	2025-03-07 10:=
 11:13.394064579 +0000
 > >  @@ -65,6 +65,7 @@
 > >    #define	CODE_SEGMENT	0x08
 > >    #define	DATA_SEGMENT	0x10
 > > =20
 > >  +	.data
 > >    	.align	16
 > >    	.globl _C_LABEL(startprog64)
 > >    _C_LABEL(startprog64):
 > >  ```
 >=20
 > Interesting... when I saw what the code was doing, I decided to clean it
 > up - afaict, there's no need for writable symbols in the asm.
 >=20
 > Anyway, I expected your very simple patch to work - but it doesn't!
 > I get what looks to be the same hang. I've removed all my debug prints
 > else I'd confirm if it was hanging at the same point, but it is a pretty
 > safe assumption it is.
 
 Did you also apply the same change to add `.data' to multiboot64.S?
 
 Because efi_md_init writes to both startprog64 and multiboot64,
 unconditionally, even if the bootloader will only use one or the other
 later on:
 
      43 void
      44 efi_md_init(void)
      45 {
 ...
      57 	startprog64 =3D (void *)addr;
 ...
      67 	multiboot64 =3D (void *)addr;
 
 https://nxr.NetBSD.org/xref/src/sys/arch/i386/stand/efiboot/bootx64/efiboot=
 x64.c?r=3D1.6#43
 
 If so, that would explain the mystery of the difference between those
 two patches.