On Sat, 17 Sept 2022 at 09:59, Huacai Chen <chenhuacai@xxxxxxxxxx> wrote: > > Hi, Ard, > > On Sat, Sep 17, 2022 at 2:37 AM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > > > Hello, > > > > One of the things I didn't quite like was that LoongArch now uses > > libfdt only because our EFI stub code depends on it. I would like to > > fix this. > > > > I have pushed a branch here that implements this. Unfortunately, it > > doesn't proceed beyond > > > > and I need some help debugging the error. > > > > EFI stub: Booting Linux Kernel... > > EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path > > EFI stub: Exiting boot services ... > > > > https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/commit/?h=efi-cleanups-for-v6.1 > > > > The idea is to pass the EFI system table pointer and the command line > > pointer directly. In previous patches, the initrd and memmap code is > > updated so it exposes the information via configuration tables that > > the generic code can parse. > > > > Any help is greatly appreciated. > I'm sorry but I suggest keeping the current light FDT approach. Of > course the upstream LoongArch kernel uses UEFI+ACPI, but it only > supports high-end systems (Loongson-3A/3C CPU with LS7A chipset). In > fact, low-end systems (Loongson-2K CPU in SoC) support is already on > the way and target for 6.2, which uses FDT in order to share a number > of existing drivers. Using the current approach can share lots of boot > code for both high-end and low-end systems, and doesn't break boot > again. > Ah fair enough. I didn't realize you were planning on using FDT as a platform description. I may still propose some enhancements that clean up the way we use FDT in the EFI stub, but omitting it entirely is not going to be a priority then. Thanks, Ard.
