Hi, On Fri, Aug 28, 2026 at 9:04 PM Bastian Blank <[email protected]> wrote: > > Control: retitle -1 riscv64: Boot failure due to incorrect memory map > Control: tags -1 moreinfo > > On Wed, Aug 26, 2026 at 11:30:00PM +0800, Han Gao wrote: > > The RISC-V kernel has also encountered an issue similar to bug #963033. > > Similar, yes, but not related to what you claim. > > > The boot process consists of coreboot(ACPI)/LinuxBoot kexec loading the > > Debian kernel. > > As I don't know which package provides linuxboot and no such package > exists in Debian: please re-assign this bug yourself.
This is the boot firmware that directly launches the debian kernel; coreboot and LinuxBoot are the firmware itself. > > > [ 0.000000] efi: Getting UEFI parameters from /chosen in DT: > > [ 0.000000] efi: System Table : 0x00000000900108a8 > > [ 0.000000] efi: MemMap Address : 0x000000008cb3f068 > > [ 0.000000] efi: MemMap Size : 0x0000000000000370 > > [ 0.000000] efi: MemMap Desc. Size : 0x0000000000000028 > > [ 0.000000] efi: MemMap Desc. Version : 0x0000000000000001 > > You claim you boot via coreboot(ACPI) and linuxboot/kexec. But the > kernel finds a device tree, and a populated one. But this device tree > includes EFI information, but at least incomplete EFI information. > > > [ 0.000000] efi: Can't find property 'linux,uefi-secure-boot' in DT! > > This line means that the EFI stub did not run. So you boot with EFI and > without EFI at the same time. https://salsa.debian.org/kernel-team/linux/-/blob/debian/latest/debian/patches/features/all/lockdown/arm64-add-kernel-config-option-to-lock-down-when.patch?ref_type=heads The addition of the `linux,uefi-secure-boot` node check here has caused the FDT functionality to malfunction; no relevant documentation could be found for this `linux,uefi-secure-boot` node. refer: https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/chosen.yaml https://github.com/torvalds/linux/blob/master/Documentation/arch/arm/uefi.rst > > > [ 0.000000] __memblock_reserve: [0x0000000084200000-0x00000000865fffff] > > nid=-1 flags=0 paging_init+0xf8/0x6d0 > > [ 0.000000] INITRD: 0x1ff6d9f000+0x009a1000 is not a memory region - > > disabling initrd > > Even your initrd is located in memory that does not exist in the > provided memory map in the device tree. > > > [ 0.000000] __memblock_reserve: [0x0000001ff6d9f000-0x0000001ff773f79e] > > nid=-1 flags=0 early_init_fdt_scan_reserved_mem+0xe0/0x110 > > [ 0.000000] __memblock_reserve: [0x000000207dd5b000-0x000000207dd5b37d] > > nid=-1 flags=0 paging_init+0x23c/0x6d0 > > [ 0.000000] cma: Size (0x0000000006000000) of region at > > 0x0000000000000000 exceeds limit (0x0000000000000000) > > [ 0.000000] cma: Failed to reserve 96 MiB > > [ 0.000000] memblock_phys_alloc_range: 2097152 bytes align=0x1000 > > from=0x0000000000000000 max_addr=0x0000000000000000 paging_init+0x3fc/0x6d0 > > [ 0.000000] ------------[ cut here ]------------ > > [ 0.000000] kernel BUG at arch/riscv/mm/init.c:1224! > > [ 0.000000] Kernel BUG [#1] > > And here we failed two times (first CMA, then kfence) to get any usable > memory. I believe the issue here is caused by linux,uefi-secure-boot. Thanks, Han > > I don't see where this is a problem in the kernel. The boot loader > needs to provide memory information and fails. > > Bastian > > -- > The sooner our happiness together begins, the longer it will last. > -- Miramanee, "The Paradise Syndrome", stardate 4842.6
