Hi,
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
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
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
bios0: HARDKERNEL ODROID-H2
...
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,
Sven
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;
EFI_PHYSICAL_ADDRESS
- addr = 0x10000000ULL; /* Below 256MB */
+ addr = 0x1000000;
- status = EFI_CALL(BS->AllocatePages, AllocateMaxAddress,
EfiLoaderData,
+ status = EFI_CALL(BS->AllocatePages, AllocateAddress,
EfiLoaderData,
EFI_SIZE_TO_PAGES(KERN_LOADSPACE_SIZE), &addr);
if (status != EFI_SUCCESS)
panic("BS->AllocatePages()");
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?
Thanks,
Kastus
