lkml.org 
[lkml]   [2022]   [Jun]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH V15 11/24] LoongArch: Add boot and setup routines
    On Fri, Jun 3, 2022 at 11:27 AM WANG Xuerui <kernel@xen0n.name> wrote:
    > On 6/3/22 15:20, Huacai Chen wrote:
    > > Add basic boot, setup and reset routines for LoongArch. Now, LoongArch
    > > machines use UEFI-based firmware. The firmware passes configuration
    > > information to the kernel via ACPI and DMI/SMBIOS.
    > >
    > > Currently an existing interface between the kernel and the bootloader
    > > is implemented. Kernel gets 2 values from the bootloader, passed in
    > > registers a0 and a1; a0 is an "EFI boot flag" distinguishing UEFI and
    > > non-UEFI firmware, while a1 is a pointer to an FDT with systable,
    > > memmap, cmdline and initrd information.
    > >
    > > The standard UEFI boot protocol (EFISTUB) will be added later.
    > >
    > > Cc: linux-efi@vger.kernel.org
    > > Cc: Ard Biesheuvel <ardb@kernel.org>
    > > Reviewed-by: WANG Xuerui <git@xen0n.name>
    > > Reviewed-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
    > > Co-developed-by: Yun Liu <liuyun@loongson.cn>
    > > Signed-off-by: Yun Liu <liuyun@loongson.cn>
    > > Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    >
    > Would you please look at this patch, which has all the arch-independent
    > changes backed out, and Ack if it is fit for mainlining?
    >
    > I communicated a little with Huacai about the approach for supporting
    > alternative boot protocols down the road, and we agreed to carry the
    > respective changes downstream. And if needs truly arise for modifying
    > common EFI logic, we can do so in a non-rushed manner later.
    >
    > For the current status of the code, apparently it just accepts the
    > standard efistub-shape FDT pointer from (whatever booting the image),
    > and everything onwards are fully using the common code without
    > modification as you can see from the diffstat. I rebased my BPI support
    > patch on top of this (basically translating Loongson BPI data structures
    > into the expected FDT form), and can confirm the boot can progress to
    > the same point as before -- indeed the SVAM changes etc. are not
    > necessary for a working system, and the code remains working.

    I'm a bit lost here: Does this mean the v15 version is back to the old
    pre-efistub interface and allows booting with existing firmware, or
    is it now left out completely? I still see a kernel_entry() function
    in head.S, and I see references to loongson_sysconf, but I don't
    see if that is what gets passed in from the bootloader.

    I really want to make sure that without the EFI stub, there is no
    other way to boot the kernel that would have to get maintained
    in the long run.

    Arnd

    \
     
     \ /
      Last update: 2022-06-03 12:04    [W:3.977 / U:0.216 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site