In my case replacing bootx64.efi with new one compiled with aforementioned patch took off.

ODROID-H2 could boot kernel from latest snapshot.

Part of dmesg:

boot> boot bsd
booting hd0a:bsd: 14464328+3175440+344096+0+872448 [963989+128+1137408+860372]=0x14d15f0
entry point at 0x1001000
[ using 2962928 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
        The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2020 OpenBSD. All rights reserved. https://www.OpenBSD.org

OpenBSD 6.7-current (GENERIC.MP) #336: Tue Jul  7 22:27:36 MDT 2020
real mem = 8385654784 (7997MB)
avail mem = 8116477952 (7740MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x79856000 (60 entries)
bios0: vendor American Megatrends Inc. version "5.13" date 04/27/2020


thanks Kastus

On 07.07.2020 20:55, Sven Wolf wrote:
Hi guys,

with the patch the kernel loads and doesn't stop at "entry point at 0x1001000". But the kernel stops with a "Stopped at gfx_v9_0_wait_reg_mem+0x307: int $3"

So for my machine the patch is the right direction but not the solution :( I've tried the boot with the current snapshot kernel.

Thanks and best regards,

On 7/6/20 6:32 AM, Kastus Shchuka wrote:
On Sat, Jul 04, 2020 at 11:09:54AM +0000, Michael Baehr wrote:
Kastus Shchuka <open...@tprfct.net> wrote:
“I installed 2020-07-03 snapshot on ASRock J4105M system and I am not able to boot it.
Boot stops at the line

entry point at 0x1001000

If I try bsd.rd kernel, it boots just fine. After this failure with snapshot I
installed 6.7-release, and it boots without any issues.”

I've experienced something similar, including the sensitivity to kernel size. As best I can observe, the EFI bootloader is being handed a different block of RAM than where the kernel is actually loaded (which is at a fixed address defined in boot.c). Which block of memory gets returned, and whether boot fails, seems to be dependent on the particular UEFI ROM/chipset. In my case, debugging over serial, I observe a page fault while the kernel is still being loaded into RAM.
“Are there any other solutions than compiling a custom smaller kernel?”

Patching efiboot.c as follows and recompiling bootia32/bootx64 resolved it for me:
--- a/sys/arch/amd64/stand/efiboot/efiboot.c
+++ b/sys/arch/amd64/stand/efiboot/efiboot.c
@@ -303,9 +303,9 @@ efi_memprobe(void)
         bios_memmap_t   *bm;
         EFI_STATUS       status;
-                        addr = 0x10000000ULL;  /* Below 256MB */
+                        addr = 0x1000000;
  -       status = EFI_CALL(BS->AllocatePages, AllocateMaxAddress, EfiLoaderData, +       status = EFI_CALL(BS->AllocatePages, AllocateAddress, EfiLoaderData,
         if (status != EFI_SUCCESS)
Let me know if that helps. I can't guarantee that this is actually what is causing your issue but it worked for me.

I tried this patch and was able to boot kernel from snapshot 2007-07-03 with recompiled BOOTX64.EFI. It fixes the problem with EFI memory mapping on ASRock J4105M motherboard.

I wonder what would it take for the patch to be accepted in -current?



Reply via email to