lkml.org 
[lkml]   [2022]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectSteps forward for the LoongArch UEFI bringup patch? (was: Re: [PATCH V14 11/24] LoongArch: Add boot and setup routines)
    From
    Hi Ard,

    Sorry for sounding particularly rushed and I really don't like rushing
    things either, but as explained in the previous reply [1], what we want
    to do is mainly to get the arch/loongarch into mainline first,
    stabilizing an ABI surface already under heavy testing for many months;
    plus Huacai has removed the questioned kernel version string, and the
    Loongson-specific "boardinfo" sysfs file that doesn't really belong to
    /sys/firmware/efi.

    So, would you please clarify and explain how Huacai and I could best
    proceed to hopefully get the *rest* of the port readied for a (late)
    merge window PR? Otherwise much of userspace development would have to
    shift target once more, and many Linux distros would have to carry and
    rebase this big patchset for another 2 months which is real churn.

    If some more background is necessary, let me explain a bit more about
    the LoongArch boot protocol peculiarities...

    For one thing, the standard EFI stub boot flow is a recent development,
    and has not shipped yet; all currently existing LoongArch systems
    actually implement the previous Loongson-specific boot protocol based on
    "struct bootparamsinterface", or BPI for short, that was carried over
    from the MIPS era. Systems with BPI firmware provide full EFI services
    too, but all pointers in BPI structs are virtual addresses, and the
    memory maps are not provided in the same way as their new firmware. In
    addition to that, all BPI systems launch Linux via a special GRUB2 that
    can only boot ELF files (so cannot chainload an EFI stub), and it's
    unclear whether directly booting an EFI stub would work, so the EFI stub
    logic is not invoked at all but SVAM still have to be executed somehow
    to ensure sanity. All of this means the SVAM oddity will eventually get
    in, regardless of whether we take it out now or not, if the BPI support
    is to be mainlined in the future.

    For another thing, it seems Loongson really wanted to support the "PMON"
    use case that wouldn't provide full EFI services but sharing some logic
    with UEFI boot. PMON is one of the MIPS firmware varieties that Loongson
    has supported back in the days, and they seem to have ported it to
    LoongArch as well.

    For this, I don't know if Huacai should really just leave those
    modification in the downstream fork to keep the upstream Linux clean of
    such hacks, because to some degree dealing with such notoriety is life,
    it seems to me. I think at this point Huacai would cooperate and tweak
    the patch to get rid of the SVAM and other nonstandard bits as much as
    possible, and I'll help him where necessary too.


    [1]:
    https://lore.kernel.org/all/47b559c0-b1e8-e800-0491-2431e2083dad@xen0n.name/

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