On Thu, Sep 22, 2022 at 8:50 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > On Thu, 22 Sept 2022 at 14:08, Huacai Chen <chenhuacai@xxxxxxxxxx> wrote: > > > > Hi, Ard, > > > > On Thu, Sep 22, 2022 at 4:59 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > > > > > On Thu, 22 Sept 2022 at 09:42, Huacai Chen <chenhuacai@xxxxxxxxxx> wrote: > > > > > > > > On Thu, Sep 22, 2022 at 3:25 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > > > > > > > > > On Thu, 22 Sept 2022 at 09:22, Huacai Chen <chenhuacai@xxxxxxxxxx> wrote: > > > > > > > > > > > > On Thu, Sep 22, 2022 at 3:13 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > > > > > > > > > > > > > On Thu, 22 Sept 2022 at 04:15, Huacai Chen <chenhuacai@xxxxxxxxxx> wrote: > > > > > > > > > > > > > > > > On Wed, Sep 21, 2022 at 4:15 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > > > > > > > > > > > > > > > > > On Wed, 21 Sept 2022 at 06:02, Huacai Chen <chenhuacai@xxxxxxxxxx> wrote: > > > > > > > > > > > > > > > > > > > > Acked-by: Huacai Chen <chenhuacai@xxxxxxxxxxx> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thank you Huacai > > > > > > > > > > > > > > > > > > I have created a separate tag with these patches applied onto the > > > > > > > > > first loongarch efi enablement patch (see below) > > > > > > > > > > > > > > > > > > I would prefer to keep the loongarch trees separate for the next merge > > > > > > > > > window, but if needed to avoid massive conflicts, you could merge the > > > > > > > > > tag into the loongarch tree and rebase your changes on top. But please > > > > > > > > > take care not to rebase those patches themselves: the commit SHAs need > > > > > > > > > to remain the same. > > > > > > > > > > > > > > > > > > However, if the conflicts are only minor, you can just explain in your > > > > > > > > > PR to Linus what the resolution should look like. > > > > > > > > > > > > > > > > > > The tag can be found here: > > > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git/tag/?h=efi-loongarch-for-v6.1-2 > > > > > > > > > > > > > > > > > > I have merged this into the EFI tree as well and pushed it out; it > > > > > > > > > should appear in -next tomorrow. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > b093dc55ba9a efi/loongarch: libstub: remove dependency on flattened DT > > > > > > > > > 102faf0747c2 efi: libstub: install boot-time memory map as config table > > > > > > > > > 7318926e7bc9 efi: libstub: remove DT dependency from generic stub > > > > > > > > > 7cb6671e3caa efi: libstub: unify initrd loading between architectures > > > > > > > > > > > > > > I will have to respin the initrd patch, unfortunately, as it breaks > > > > > > > x86. So the signed tag will be updated, and the SHAs above will change > > > > > > > as well. > > > > > > Emm, initrd is also broken on LoongArch, the core kernel gets an > > > > > > EFI_INVALID_TABLE_ADDR address. > > > > > > > > > > > > > > > > OK, I will investigate. This was working fine before so I'm not sure > > > > > what happened there. > > > > > > > > > > > I cannot reproduce this. Can you reproduce it with qemu? If so, can > > > you share your command line and .config etc? > > In qemu we also OK, but on a real machine efistub fails at > > efi_bs_call(locate_device_path, &lf2_proto_guid, &dp, &handle), maybe > > our UEFI BIOS has some problems? On a real machine we use grub and > > there is no "initrd" command in UEFI shell. > > > > Ah ok, so i guess your GRUB lacks the LoadFile2 patches? > > https://lists.gnu.org/archive/html/grub-devel/2022-09/msg00057.html Maybe it is a GRUB problem (I'll discuss with GRUB team), but why without this series the GRUB can load initrd? Because in the old way UEFI BIOS fill initrd information to FDT? Huacai > > Those have been blocked in review for almost 2 years. I cc'ed you on > the latest version. Without those patches, GRUB will generate a DT to > pass the initrd information. > > I understand this is annoying right now, but I strongly suggest to > implement only a single method of loading the INITRD for EFI boot - it > is much easier to reason about when things like secure boot and > measured boot become relevant on your architecture. > > In any case, you can build your UEFI shell with the following dynamic > command from EDK2: > > OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.inf > > This add a 'initrd' command to the UEFI shell > > (it will also work for bare metal platforms not only for virtual machines) > > > If this is a deal breaker for you, one workaround we might consider is > to parse /chosen/linux,initrd-* in the LoongArch stub (but nothing > else) if locating the LoadFile2 protocol fails and a DTB exists in the > config table array. I'd prefer to avoid that if we can, but at least > the initrd is always visible to the stub, for measurement etc.
