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 |
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 |
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 > |
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 >> > |
In reply to this post by 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? > 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 |
Free forum by Nabble | Edit this page |