snapshot boot fails with error "entry point at 0x1001000"

[Kastus Shchuka]

Hi,

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 suspect I am hitting the same problem as in
https://marc.info/?l=openbsd-misc&m=159325874410286&w=2.

Disk is partitioned with GPT, and system boots through EFI.

There were other reports about BOOTX86.EFI supposedely causing this problem,
as in https://marc.info/?l=openbsd-misc&m=159147446008114&w=2.

I tried to boot snapshot kernel on 6.7-release system to make use of older BOOTX86.EFI,
but it stopped at the same line "entry point at 0x1001000"

I could be wrong, but I doubt that efi is the problem. It seems that kernel size is.

If kernel is smaller than 20MB, it boots. If it is larger, it doesn't.

Are there any other solutions than compiling a custom smaller kernel?

I cannot produce dmesg from snapshot, but here is dmesg from 6.7-release:

OpenBSD 6.7 (GENERIC.MP) #2: Thu Jun  4 09:55:08 MDT 2020
    [hidden email]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8201129984 (7821MB)
avail mem = 7939952640 (7572MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x6d946000 (18 entries)
bios0: vendor American Megatrends Inc. version "P1.30" date 05/04/2018
bios0: ASRock J4105M
acpi0 at bios0: ACPI 6.1
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP FPDT FIDT MCFG DBG2 DBGP HPET LPIT APIC NPKT SSDT SSDT SSDT AAFT SSDT SSDT SSDT SSDT SSDT UEFI BGRT WDAT WSMT
acpi0: wakeup devices SIO1(S3) PS2K(S4) PS2M(S4) UAR1(S4) UAR2(S4) HDAS(S3) XHC_(S4) XDCI(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimcfg0 at acpi0
acpimcfg0: addr 0xe0000000, bus 0-255
acpihpet0 at acpi0: 19200000 Hz
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Celeron(R) J4105 CPU @ 1.50GHz, 1496.53 MHz, 06-7a-01
cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu0: 4MB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 19MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.2.4.2.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Celeron(R) J4105 CPU @ 1.50GHz, 1495.86 MHz, 06-7a-01
cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu1: 4MB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Celeron(R) J4105 CPU @ 1.50GHz, 1495.87 MHz, 06-7a-01
cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu2: 4MB 64b/line 16-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Celeron(R) J4105 CPU @ 1.50GHz, 1495.86 MHz, 06-7a-01
cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu3: 4MB 64b/line 16-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec00000, version 20, 120 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (RP03)
acpiprt2 at acpi0: bus 2 (RP04)
acpiprt3 at acpi0: bus 3 (RP05)
acpiprt4 at acpi0: bus 4 (RP06)
acpiec0 at acpi0: not present
acpipwrres0 at acpi0: DRST
acpipwrres1 at acpi0: DRST
acpipwrres2 at acpi0: DRST
acpipwrres3 at acpi0: DRST
acpipwrres4 at acpi0: DRST
acpipwrres5 at acpi0: DRST
acpipwrres6 at acpi0: WRST
acpicpu0 at acpi0: C3(10@150 mwait.1@0x60), C2(10@50 mwait.1@0x21), C1(1000@1 mwait.1@0x1), PSS
acpicpu1 at acpi0: C3(10@150 mwait.1@0x60), C2(10@50 mwait.1@0x21), C1(1000@1 mwait.1@0x1), PSS
acpicpu2 at acpi0: C3(10@150 mwait.1@0x60), C2(10@50 mwait.1@0x21), C1(1000@1 mwait.1@0x1), PSS
acpicpu3 at acpi0: C3(10@150 mwait.1@0x60), C2(10@50 mwait.1@0x21), C1(1000@1 mwait.1@0x1), PSS
acpipwrres7 at acpi0: FN00, resource for FAN0
acpitz0 at acpi0: critical temperature is 95 degC
acpipci0 at acpi0 PCI0: 0x00000000 0x00000011 0x00000001
acpicmos0 at acpi0
acpibtn0 at acpi0: PWRB
glkgpio0 at acpi0: GPO1 uid 1 addr 0xd0c40000/0xcef irq 14, 80 pins
glkgpio1 at acpi0: GPO0 uid 2 addr 0xd0c50000/0xaff irq 14, 80 pins
glkgpio2 at acpi0: GPO2 uid 3 addr 0xd0c90000/0x7bf irq 15, 20 pins
glkgpio3 at acpi0: GPO3 uid 4 addr 0xd0c80000/0x82f irq 14, 35 pins
"INT33A1" at acpi0 not configured
"INT3400" at acpi0 not configured
"INT3406" at acpi0 not configured
"INT3404" at acpi0 not configured
"INT3403" at acpi0 not configured
"INT3407" at acpi0 not configured
"INT3403" at acpi0 not configured
"INT3403" at acpi0 not configured
"INT3403" at acpi0 not configured
"INT3403" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD1F
cpu0: Enhanced SpeedStep 1496 MHz: speeds: 1501, 1500, 1400, 1300, 1200, 1100, 1000, 900, 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Gemini Lake Host" rev 0x03
"Intel Gemini Lake DPTF" rev 0x03 at pci0 dev 0 function 1 not configured
inteldrm0 at pci0 dev 2 function 0 "Intel UHD Graphics 600" rev 0x03
drm0 at inteldrm0
inteldrm0: msi, GEMINILAKE, gen 9
azalia0 at pci0 dev 14 function 0 "Intel Gemini Lake HD Audio" rev 0x03: msi
azalia0: codecs: Realtek/0x0887, Intel/0x280d, using Realtek/0x0887
audio0 at azalia0
vendor "Intel", unknown product 0x319a (class communications subclass miscellaneous, rev 0x03) at pci0 dev 15 function 0 not configured
ahci0 at pci0 dev 18 function 0 "Intel Gemini Lake AHCI" rev 0x03: msi, AHCI 1.3.1
ahci0: port 0: 6.0Gb/s
ahci0: port 1: 6.0Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0: <ATA, CT250MX500SSD1, M3CR> naa.500a0751e2971823
sd0: 238475MB, 512 bytes/sector, 488397168 sectors, thin
sd1 at scsibus1 targ 1 lun 0: <ATA, CT250MX500SSD1, M3CR> naa.500a0751e29f524a
sd1: 238475MB, 512 bytes/sector, 488397168 sectors, thin
ppb0 at pci0 dev 19 function 0 "Intel Gemini Lake PCIE" rev 0xf3: msi
pci1 at ppb0 bus 1
ahci1 at pci1 dev 0 function 0 vendor "Marvell", unknown product 0x9215 rev 0x11: msi, AHCI 1.0
ahci1: port busy after first PMP probe FIS
ahci1: port busy after first PMP probe FIS
ahci1: port 0: 1.5Gb/s
ahci1: port busy after first PMP probe FIS
ahci1: port busy after first PMP probe FIS
ahci1: port 2: 6.0Gb/s
ahci1: port busy after first PMP probe FIS
ahci1: port busy after first PMP probe FIS
ahci1: port 3: 6.0Gb/s
scsibus2 at ahci1: 32 targets
cd0 at scsibus2 targ 0 lun 0: <TSSTcorp, CDRWDVD TS-H493B, D200> removable
sd2 at scsibus2 targ 2 lun 0: <ATA, ST1000NM0011, SN02> naa.5000c5003533ac60
sd2: 953869MB, 512 bytes/sector, 1953525168 sectors
sd3 at scsibus2 targ 3 lun 0: <ATA, ST1000NM0011, SN02> naa.5000c5003533d206
sd3: 953869MB, 512 bytes/sector, 1953525168 sectors
ppb1 at pci0 dev 19 function 1 "Intel Gemini Lake PCIE" rev 0xf3: msi
pci2 at ppb1 bus 2
ppb2 at pci0 dev 19 function 2 "Intel Gemini Lake PCIE" rev 0xf3: msi
pci3 at ppb2 bus 3
re0 at pci3 dev 0 function 0 "Realtek 8168" rev 0x0c: RTL8168G/8111G (0x4c00), msi, address a8:a1:59:02:f6:5e
rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0
ppb3 at pci0 dev 19 function 3 "Intel Gemini Lake PCIE" rev 0xf3: msi
pci4 at ppb3 bus 4
xhci0 at pci0 dev 21 function 0 "Intel Gemini Lake xHCI" rev 0x03: msi, xHCI 1.0
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 addr 1
pcib0 at pci0 dev 31 function 0 "Intel Gemini Lake LPC" rev 0x03
"Intel Gemini Lake SMBus" rev 0x03 at pci0 dev 31 function 1 not configured
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard
pms0 at pckbc0 (aux slot)
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
vmm0 at mainbus0: VMX/EPT (using slow L1TF mitigation)
efifb at mainbus0 not configured
uhub1 at uhub0 port 7 configuration 1 interface 0 "Genesys Logic USB2.0 Hub" rev 2.00/88.32 addr 2
vscsi0 at root
scsibus3 at vscsi0: 256 targets
softraid0 at root
scsibus4 at softraid0: 256 targets
root on sd1a (ba86fe19f0932737.a) swap on sd1b dump on sd1b
[drm] GuC: No firmware known for this platform!
[drm] HuC: No firmware known for this platform!
inteldrm0: 1280x1024, 32bpp
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0
wsdisplay0: screen 1-5 added (std, vt100 emulation)

Thanks,

Kastus

[Kastus Shchuka]

On Sat, Jul 04, 2020 at 11:09:54AM +0000, Michael Baehr wrote:

> Kastus Shchuka <[hidden email]> 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

[Sven Wolf-3]

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 <[hidden email]> 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
>

[ari.openbsd]

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
[hidden email]:/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 <[hidden email]> 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
>>
>

[Kastus Shchuka]

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 <[hidden email]> 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