On Thu, Sep 22, 2022 at 9:52 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > On Thu, 22 Sept 2022 at 15:19, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > > > On Thu, 22 Sept 2022 at 15:18, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > > > > > On Thu, 22 Sept 2022 at 15:12, Huacai Chen <chenhuacai@xxxxxxxxxx> wrote: > > > > > > > > On Thu, Sep 22, 2022 at 9:10 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > > > > > > > > > On Thu, 22 Sept 2022 at 15:09, Huacai Chen <chenhuacai@xxxxxxxxxx> wrote: > > > > > > > > > > > > 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? > > > > > > > > > > > > > > > > No GRUB loads the initrd and creates a DT with a /chosen node to > > > > > record the initrd base and size. > > > > Without this series, efistub also fails at > > > > efi_bs_call(locate_device_path, &lf2_proto_guid, &dp, &handle), but > > > > initrd works well, this makes me puzzled. > > > > > > > > > > That is because you don't have DTB support in the core kernel yet right? > > > > Never mind - what exact commit are you testing this with? > > OK, so the existing code only does > > early_init_dt_scan(fdt_ptr); > early_init_fdt_reserve_self(); > efi_system_table = efi_get_fdt_params(&data); > > so it never parses the /chosen node, and therefore does not discover the initrd. > > I suppose you may have been running with the loongson-2k patches? > > But actually, this describes exactly the problem that I am addressing > with this series: you have been inadvertently relying on DT hardware > support for initrd functionality ... Yes, the correct way is to update our grub. But for kexec, seems initrd over cmdline is the only way because we don't know how to handle systemtable and don't know how to work together with both ACPI/DT systems after efistub refactoring. Huacai
