Steps forward for the LoongArch UEFI bringup patch? (was: Re: [PATCH V14 11/24] LoongArch: Add boot and setup routines)

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

 



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@xxxxxxxxxx/




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux