On Sun, Jul 05, 2020 at 09:32:47PM -0700, 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? > As Mike Larkin pointed in https://marc.info/?l=openbsd-misc&m=160377179930502&w=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 0x40000 for 376KB Region 3: type 2 at 0x9e000 for 392KB Region 4: type 1 at 0x100000 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 0x100000000 for 6291456KB Region 14: type 2 at 0x10000000 for 34116KB Region 15: type 2 at 0x6ec00000 for 282624KB Region 16: type 2 at 0xd0000000 for 16384KB Region 17: type 2 at 0xd3709000 for 4KB Region 18: type 2 at 0xe0000000 for 262144KB Region 19: type 2 at 0xfe042000 for 12KB Region 20: type 2 at 0xfe900000 for 12KB Region 21: type 2 at 0xfec00000 for 4KB Region 22: type 2 at 0xfed01000 for 4KB Region 23: type 2 at 0xfee00000 for 4KB Region 24: type 2 at 0xff000000 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 0x100000000, 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