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
