On Mon, Jun 28, 2021 at 2:24 PM Heinrich Schuchardt <xypron.g...@gmx.de> wrote: > > > +cc Ard Biesheuvel <a...@kernel.org> > > Ard, please see question for you below. > > On 6/27/21 11:01 PM, Heinrich Schuchardt wrote: > > On 6/26/21 8:07 PM, Andreas Schwab wrote: > >> On Jun 03 2021, Nikita Ermakov wrote: > >> > >>> This series contains patches to add support for LoadFile2 protocol to > >>> load > >>> initrd on EFI systems. Also it contains patches to load Linux kernel > >>> with EFI > >>> stub on riscv platforms and unites arm and riscv codes together into > >>> common > >>> loader code for EFI systems. > >> > >> That doesn't work with a CD image. When I try to run > >> http://download.opensuse.org/ports/riscv/tumbleweed/iso/openSUSE-Tumbleweed-NET-riscv64-Media.iso > >> > >> with qemu, the initrd fails to load. > > > > Please, indicate how you built u-boot.bin. > > > >> > >> $ qemu-system-riscv64 -M virt -nographic -serial mon:stdio -smp 4 -m > >> 8g -kernel u-boot.bin -drive > >> format=raw,if=virtio,media=cdrom,file=openSUSE-Tumbleweed-NET-riscv64-Media.iso > >> > > > > This command results in an error > > > > qemu-system-riscv64: warning: > > No -bios option specified. Not loading a firmware. > > > > Please, provide a repo with the GRUB code you have been compiling. > > > >> > >> OpenSBI v0.9 > >> ____ _____ ____ _____ > >> / __ \ / ____| _ \_ _| > >> | | | |_ __ ___ _ __ | (___ | |_) || | > >> | | | | '_ \ / _ \ '_ \ \___ \| _ < | | > >> | |__| | |_) | __/ | | |____) | |_) || |_ > >> \____/| .__/ \___|_| |_|_____/|____/_____| > >> | | > >> |_| > >> > >> Platform Name : riscv-virtio,qemu > >> Platform Features : timer,mfdeleg > >> Platform HART Count : 4 > >> Firmware Base : 0x80000000 > >> Firmware Size : 124 KB > >> Runtime SBI Version : 0.2 > >> > >> Domain0 Name : root > >> Domain0 Boot HART : 1 > >> Domain0 HARTs : 0*,1*,2*,3* > >> Domain0 Region00 : 0x0000000080000000-0x000000008001ffff () > >> Domain0 Region01 : 0x0000000000000000-0xffffffffffffffff (R,W,X) > >> Domain0 Next Address : 0x0000000080200000 > >> Domain0 Next Arg1 : 0x00000000bf000000 > >> Domain0 Next Mode : S-mode > >> Domain0 SysReset : yes > >> > >> Boot HART ID : 1 > >> Boot HART Domain : root > >> Boot HART ISA : rv64imafdcsu > >> Boot HART Features : scounteren,mcounteren,time > >> Boot HART PMP Count : 16 > >> Boot HART PMP Granularity : 4 > >> Boot HART PMP Address Bits: 54 > >> Boot HART MHPM Count : 0 > >> Boot HART MHPM Count : 0 > >> Boot HART MIDELEG : 0x0000000000000222 > >> Boot HART MEDELEG : 0x000000000000b109 > >> > >> > >> U-Boot 2021.04 (Jun 09 2021 - 00:00:00 +0000) > >> > >> CPU: rv64imafdcsu > >> Model: riscv-virtio,qemu > >> DRAM: 8 GiB > >> In: uart@10000000 > >> Out: uart@10000000 > >> Err: uart@10000000 > >> Net: No ethernet found. > >> Hit any key to stop autoboot: 0 > >> > >> Device 0: 1af4 VirtIO Block Device > >> Type: Hard Disk > >> Capacity: 225.7 MB = 0.2 GB (462376 x 512) > >> ... is now current device > >> ** Invalid partition 3 ** > >> ** Invalid partition 4 ** > >> ** Invalid partition 2 ** > >> Scanning virtio 0:1... > >> ** Unable to read file / ** > >> Failed to load '/' > >> libfdt fdt_check_header(): FDT_ERR_BADMAGIC > >> Scanning disk virtio-blk#8... > >> Found 2 disks > >> No EFI system partition > >> BootOrder not defined > >> EFI boot manager: Cannot load any image > >> Found EFI removable media binary efi/boot/bootriscv64.efi > > > > When I press 'e' in GRUB I see: > > > > setparams 'Installation' > > set gfxpayload=keep > > echo 'Loading kernel ...' > > linux /boot/riscv64/linux splash=silent > > echo 'Loading > > initial ramdisk ...' initrd > > /boot/riscv64/initrd > > > > With debug=all I get as output: > > > > kern/verifiers.c:88: file: /boot/riscv64/initrd type: 131076 > > loader/efi/linux.c:368: LoadFile2 initrd loading protocol installed > > > > With a bit of debugging enabled in U-Boot: > > > > EFI: Call: image_obj->entry(image_handle, &systab) > > EFI: Entry efi_open_protocol(00000000ff751310, > > EFI_LOADED_IMAGE_PROTOCOL_GUID, 00000000ff73a6e0, 00000000ff750050, > > 0000000000000000, 0x1) > > EFI: Exit: efi_open_protocol: 0 > > EFI stub: Booting Linux Kernel... > > EFI: Entry efi_locate_handle_ext(2, > > EFI_GRAPHICS_OUTPUT_PROTOCOL_GUID, 0000000000000000, 00000000ff73a740, > > 0000000000000000) > > EFI: Exit: efi_locate_handle_ext: 14 > > EFI: Entry efi_locate_protocol(EFI_TPM2_GUID, 0000000000000000, > > 00000000ff73a648) > > EFI: Exit: efi_locate_protocol: 14 > > EFI stub: Using DTB from configuration table > > EFI: Entry efi_locate_device_path(EFI_LOAD_FILE2_PROTOCOL_GUID, > > 00000000ff73a648, 00000000ff73a668) > > EFI: Call: efi_locate_handle_buffer(BY_PROTOCOL, protocol, > > NULL, &no_handles, &handles) > > EFI: Entry efi_locate_handle_buffer(2, > > EFI_LOAD_FILE2_PROTOCOL_GUID, 0000000000000000, 00000000ff73a5d8, > > 00000000ff73a5d0) > > EFI: Exit: efi_locate_handle_buffer: 0 > > EFI: 0 returned by efi_locate_handle_buffer(BY_PROTOCOL, > > protocol, NULL, &no_handles, &handles) > > EFI: Exit: efi_locate_device_path: 0 > > EFI: Entry efi_open_protocol(00000000ff74c8b0, > > EFI_LOAD_FILE2_PROTOCOL_GUID, 00000000ff73a650, 00000000ff750050, > > 0000000000000000, 0x1) > > EFI: Exit: efi_open_protocol: 0 > > EFI: Exit: efi_open_protocol: 0 > > EFI: Entry efi_allocate_pages_ext(AllocateMaxAddress, > > EfiLoaderData, 0xc024, 00000000ff73a618) > > EFI: Exit: efi_allocate_pages_ext: 9 (EFI_OUT_OF_RESOURCES) > > > > EFI stub: ERROR: Failed to load initrd! > > > > The LOAD_FILE2 protocol was successfully opened on the handle ff74c8b0 > > where it was installed by GRUB. > > > > *Allocating memory for the initrd fails.* > > > > 0xC024 pages are requested below 0x901fffff. > > > > This is the memory map when the call is executed: > > > > Type Start End Attributes > > ================ ================ ================ ========== > > BOOT DATA 0000000100000000-0000000280000000 WB > > LOADER DATA 00000000fff62000-0000000100000000 WB > > RUNTIME CODE 00000000fff61000-00000000fff62000 WB|RT > > LOADER DATA 00000000fe73f000-00000000fff61000 WB > > BOOT DATA 00000000fe73d000-00000000fe73f000 WB > > RESERVED 00000000fe73c000-00000000fe73d000 WB > > BOOT DATA 00000000fe73a000-00000000fe73c000 WB > > RESERVED 00000000fe739000-00000000fe73a000 WB > > RUNTIME DATA 00000000fe735000-00000000fe739000 WB|RT > > BOOT DATA 00000000fe734000-00000000fe735000 WB > > RUNTIME DATA 00000000fe730000-00000000fe734000 WB|RT > > BOOT DATA 00000000fe72f000-00000000fe730000 WB > > RESERVED 00000000fe728000-00000000fe72f000 WB > > LOADER CODE 00000000fe4aa000-00000000fe728000 WB > > LOADER DATA 00000000fe4a9000-00000000fe4aa000 WB > > BOOT DATA 00000000fe4a8000-00000000fe4a9000 WB > > RESERVED 00000000fe4a6000-00000000fe4a8000 WB > > LOADER DATA 00000000fe4a3000-00000000fe4a6000 WB > > LOADER CODE 00000000deb8d000-00000000fe4a3000 WB > > LOADER DATA 00000000dd620000-00000000deb8d000 WB > > LOADER CODE 00000000dbfc3000-00000000dd620000 WB > > BOOT DATA 00000000dbfc2000-00000000dbfc3000 WB > > CONVENTIONAL 0000000087f05000-00000000dbfc2000 WB > > ACPI RECLAIM MEM 0000000087efb000-0000000087f05000 WB > > CONVENTIONAL 000000008185d000-0000000087efb000 WB > > LOADER DATA 0000000080200000-000000008185d000 WB > > CONVENTIONAL 0000000080040000-0000000080200000 WB > > BOOT DATA 0000000080000000-0000000080040000 WB > > > > 0x901fffff - 0x1000 * 0xC024 = 0x841DBFFF > > > > So U-Boot is correct in indicating that the memory is not available at > > the required low address. > > > > In Linux efi_load_initrd() is called with parameter hard_limit being the > > 'minimum size of allocated memory'. But this parameter is passed to
The function comment header should be updated to reflect the correct usage. No ? > > efi_load_initrd_dev_path() as 'upper limit for the initrd memory > > allocation' and further to efi_allocate_pages() as 'the address that the > > last allocated memory page shall not exceed'. > > > > @Ard > > Why does Linux require allocating the memory below 0x901fffff which is > > the value of 'minimum size of allocated memory'? I think initrd can be > > allocated anywhere in memory even above 4GiB. > > That should be fine. I think this bug was present during initial porting but never got exposed because I never used such a big initrd. Thanks for providing the fix. > > Best regards > > > > Heinrich > > > >> 2584576 bytes read in 3 ms (821.6 MiB/s) > >> libfdt fdt_check_header(): FDT_ERR_BADMAGIC > >> Booting /efi\boot\bootriscv64.efi > >> Welcome to GRUB! > >> > >> Please press 't' to show the boot menu on this console > >> error: ../../grub-core/video/video.c:761:no suitable video mode found. > >> > >> > >> openSUSE Tumbleweed > >> > >> > >> ┌────────────────────────────────────────────────────────────────────────────┐ > >> > >> │ Boot from Hard > >> Disk │ > >> > >> │*Installation > >> │ > >> │ > >> Upgrade > >> │ > >> │ More > >> ... │ > >> > >> │ > >> │ > >> > >> │ > >> │ > >> > >> │ > >> │ > >> > >> │ > >> │ > >> > >> │ > >> │ > >> > >> │ > >> │ > >> > >> │ > >> │ > >> > >> │ > >> │ > >> > >> │ > >> │ > >> > >> └────────────────────────────────────────────────────────────────────────────┘ > >> > >> > >> Use the ▲ and ▼ keys to select which entry is highlighted. > >> Press enter to boot the selected OS, `e' to edit the commands > >> before booting or `c' for a command-line. > >> > >> Loading kernel ... > >> Loading initial ramdisk ... > >> EFI stub: Booting Linux Kernel... > >> EFI stub: Using DTB from configuration table > >> EFI stub: ERROR: Failed to load initrd! > >> EFI stub: Exiting boot services and installing virtual address map... > >> > > > > > > > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel -- Regards, Atish _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
