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 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.
