grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 0/7] Add LoadFile2 and riscv Linux loader


From: Atish Patra
Subject: Re: [PATCH v2 0/7] Add LoadFile2 and riscv Linux loader
Date: Fri, 2 Jul 2021 11:48:17 -0700

On Wed, Jun 30, 2021 at 12:26 AM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Tue, 29 Jun 2021 at 21:13, Atish Patra <atishp@atishpatra.org> wrote:
> >
> > On Mon, Jun 28, 2021 at 2:24 PM Heinrich Schuchardt <xypron.glpk@gmx.de> 
> > wrote:
> > >
> > >
> > > +cc Ard Biesheuvel <ardb@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 ?
> >
>
> Agreed. The allocation limits are physical upper bounds, not sizes.
>

I will send the patch.

> > > > 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.
> >
>
> I don't know about RISC-V in particular, but in general, there are
> limits to where the initrd can be loaded, depending on how the
> architecture organizes its linear mapping of DRAM. If no such
> limitation exists for RISC-V, the code should be updated accordingly.

I am not aware of any such limitation for RISC-V as long as the initrd
is placed somewhere that
doesn't overwrite fdt or kernel image. I believe the U-boot/EDK2 will
take care of that during allocation itself.

I will cross-check anyways in case I missed something.
-- 
Regards,
Atish



reply via email to

[Prev in Thread] Current Thread [Next in Thread]