Re: snapshot boot fails with error "entry point at 0x1001000"
Hi all, For the record, Mark Kettenis' patch below fixed the boot stuck problem on my Intel NUC Kit NUC7PJYH mini server, see the following email thread: https://marc.info/?l=openbsd-misc=160391516603159 Thanks a lot for this. Cheers. Fabian > Hi Mark, > > on my Lenovo V130 the patch works. Now I'm able to boot the current > kernel again, without the need to remove the radeon and amdgpu driver > (https://marc.info/?l=openbsd-misc=159276382718317=2) > > Thanks and best regards, > Sven > > On 10/27/20 1:40 PM, Mark Kettenis wrote: > > Hi Kastus, > > > > Please don't have technical discussions on misc@; some developers, > > like me, only read it sporadically. The tech@ list is a much better > > place. > > > > The problem with your approach is that you allocate memory at a fixed > > address, and we can't be sure that memory is available. We may have > > to extend the amount of memory we allocate such that larger kernels > > fit. The diff below bumps it from 32MB to 64MB. Does this work for > > you? > > > > > > Index: arch/amd64/stand/efiboot/efiboot.c > > === > > RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/efiboot.c,v > > retrieving revision 1.35 > > diff -u -p -r1.35 efiboot.c > > --- arch/amd64/stand/efiboot/efiboot.c 22 Mar 2020 14:59:11 - > > 1.35 > > +++ arch/amd64/stand/efiboot/efiboot.c 27 Oct 2020 12:36:45 - > > @@ -39,7 +39,7 @@ > > #include "eficall.h" > > #include "run_i386.h" > > > > -#defineKERN_LOADSPACE_SIZE (32 * 1024 * 1024) > > +#defineKERN_LOADSPACE_SIZE (64 * 1024 * 1024) > > > > EFI_SYSTEM_TABLE *ST; > > EFI_BOOT_SERVICES *BS;
Re: snapshot boot fails with error "entry point at 0x1001000"
Hi Mark, on my Lenovo V130 the patch works. Now I'm able to boot the current kernel again, without the need to remove the radeon and amdgpu driver (https://marc.info/?l=openbsd-misc=159276382718317=2) Thanks and best regards, Sven On 10/27/20 1:40 PM, Mark Kettenis wrote: Hi Kastus, Please don't have technical discussions on misc@; some developers, like me, only read it sporadically. The tech@ list is a much better place. The problem with your approach is that you allocate memory at a fixed address, and we can't be sure that memory is available. We may have to extend the amount of memory we allocate such that larger kernels fit. The diff below bumps it from 32MB to 64MB. Does this work for you? Index: arch/amd64/stand/efiboot/efiboot.c === RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/efiboot.c,v retrieving revision 1.35 diff -u -p -r1.35 efiboot.c --- arch/amd64/stand/efiboot/efiboot.c 22 Mar 2020 14:59:11 - 1.35 +++ arch/amd64/stand/efiboot/efiboot.c 27 Oct 2020 12:36:45 - @@ -39,7 +39,7 @@ #include "eficall.h" #include "run_i386.h" -#define KERN_LOADSPACE_SIZE (32 * 1024 * 1024) +#defineKERN_LOADSPACE_SIZE (64 * 1024 * 1024) EFI_SYSTEM_TABLE *ST; EFI_BOOT_SERVICES *BS;
Re: snapshot boot fails with error "entry point at 0x1001000"
Hi Kastus, Please don't have technical discussions on misc@; some developers, like me, only read it sporadically. The tech@ list is a much better place. The problem with your approach is that you allocate memory at a fixed address, and we can't be sure that memory is available. We may have to extend the amount of memory we allocate such that larger kernels fit. The diff below bumps it from 32MB to 64MB. Does this work for you? Index: arch/amd64/stand/efiboot/efiboot.c === RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/efiboot.c,v retrieving revision 1.35 diff -u -p -r1.35 efiboot.c --- arch/amd64/stand/efiboot/efiboot.c 22 Mar 2020 14:59:11 - 1.35 +++ arch/amd64/stand/efiboot/efiboot.c 27 Oct 2020 12:36:45 - @@ -39,7 +39,7 @@ #include "eficall.h" #include "run_i386.h" -#defineKERN_LOADSPACE_SIZE (32 * 1024 * 1024) +#defineKERN_LOADSPACE_SIZE (64 * 1024 * 1024) EFI_SYSTEM_TABLE *ST; EFI_BOOT_SERVICES *BS;
Re: snapshot boot fails with error "entry point at 0x1001000"
On Sun, Jul 05, 2020 at 09:32:47PM -0700, Kastus Shchuka wrote: > On Sat, Jul 04, 2020 at 11:09:54AM +, Michael Baehr wrote: > > Kastus Shchuka 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 = 0x1000ULL; /* Below 256MB */ > > +addr = 0x100; > > > > - status = EFI_CALL(BS->AllocatePages, AllocateMaxAddress, > > EfiLoaderData, > > + status = EFI_CALL(BS->AllocatePages, AllocateAddress, EfiLoaderData, > > EFI_SIZE_TO_PAGES(KERN_LOADSPACE_SIZE), ); > > 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? > As Mike Larkin pointed in https://marc.info/?l=openbsd-misc=160377179930502=2, "mach mem" output may shed some light on the problem. So, for the ASRock J4105M motherboard, the output is this: >> OpenBSD/amd64 BOOTX64 3.50 boot> mach mem Region 0: type 1 at 0x0 for 248KB Region 1: type 2 at 0x3e000 for 8KB Region 2: type 1 at 0x4 for 376KB Region 3: type 2 at 0x9e000 for 392KB Region 4: type 1 at 0x10 for 261120KB Region 5: type 1 at 0x12151000 for 1454584KB Region 6: type 2 at 0x6adcf000 for 41480KB Region 7: type 1 at 0x6d651000 for 324KB Region 8: type 4 at 0x6d6a2000 for 160KB Region 9: type 2 at 0x6d6ca000 for 3916KB Region 10: type 1 at 0x6da9d000 for 10388KB Region 11: type 2 at 0x6e4c2000 for 688KB Region 12: type 1 at 0x6e56e000 for 6728KB Region 13: type 1 at 0x1 for 6291456KB Region 14: type 2 at 0x1000 for 34116KB Region 15: type 2 at 0x6ec0 for 282624KB Region 16: type 2 at 0xd000 for 16384KB Region 17: type 2 at 0xd3709000 for 4KB Region 18: type 2 at 0xe000 for 262144KB Region 19: type 2 at 0xfe042000 for 12KB Region 20: type 2 at 0xfe90 for 12KB Region 21: type 2 at 0xfec0 for 4KB Region 22: type 2 at 0xfed01000 for 4KB Region 23: type 2 at 0xfee0 for 4KB Region 24: type 2 at 0xff00 for 16384KB Low ram: 1024KB High ram: 295236KB With the patch, kernel is loaded in region 14 and it fits there. Without patch, memory is allocated down from 0x1, and large kernel overlaps with something and fails to boot. There were reports on -misc that the patch does not help on some systems. I wonder what can be tried differently to make it work on all systems? Thanks, Kastus
Re: snapshot boot fails with error "entry point at 0x1001000"
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 +, Michael Baehr wrote: Kastus Shchuka 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 = 0x1000ULL; /* Below 256MB */ + addr = 0x100; - status = EFI_CALL(BS->AllocatePages, AllocateMaxAddress, EfiLoaderData, + status = EFI_CALL(BS->AllocatePages, AllocateAddress, EfiLoaderData, EFI_SIZE_TO_PAGES(KERN_LOADSPACE_SIZE), ); 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
Re: snapshot boot fails with error "entry point at 0x1001000"
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 +, Michael Baehr wrote: Kastus Shchuka 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 = 0x1000ULL; /* Below 256MB */ +addr = 0x100; - status = EFI_CALL(BS->AllocatePages, AllocateMaxAddress, EfiLoaderData, + status = EFI_CALL(BS->AllocatePages, AllocateAddress, EfiLoaderData, EFI_SIZE_TO_PAGES(KERN_LOADSPACE_SIZE), ); 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
Re: snapshot boot fails with error "entry point at 0x1001000"
On Sat, Jul 04, 2020 at 11:09:54AM +, Michael Baehr wrote: > Kastus Shchuka 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 = 0x1000ULL; /* Below 256MB */ > +addr = 0x100; > > - status = EFI_CALL(BS->AllocatePages, AllocateMaxAddress, > EfiLoaderData, > + status = EFI_CALL(BS->AllocatePages, AllocateAddress, EfiLoaderData, > EFI_SIZE_TO_PAGES(KERN_LOADSPACE_SIZE), ); > 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