Hi, Ard, On Tue, Sep 20, 2022 at 4:04 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > On Tue, 20 Sept 2022 at 03:45, Huacai Chen <chenhuacai@xxxxxxxxxx> wrote: > > > > Hi, Ard, > > > ... > > I'm very sorry, after an offline discussion with my colleagues, > > non-EFI DT boot is still needed (very sadly, we want to drop non-EFI > > firmware but we can't do that). However, for non-EFI DT boot we will > > use the same parameter passing method (a0=efi boot flag, a1=cmdline, > > a2=systemtable), firmware will generate a simple systemtable only for > > DT. In this way all boot methods share the same logic, and also make > > kexec easy to implement. > > > > OK, that should work. So I suppose you create a EFI system table along > with EFI configuration tables for DT, SMBIOS, etc? In this case, I > suggest you omit the MEMMAP config table that I am adding here, so > that there is no ambiguity between the EFI provided memory map and the > one provided by DT. > > I think that should be a clean way to implement this. OK, thanks. I have merged efi-cleanups-for-v6.1-v2 to https://github.com/loongson/linux/commits/loongarch-next. It seems everything work well except kexec. Huacai > > > So, let's make a0 the real "efi boot flag" and let it control > > EFI_BOOT, for efistub, we can just pass "true" unconditionally > > (whether support efi_novamap is not as important as the efi boot flag > > for us, as you said, efi_novamap is just for broken firmware). > > Indeed. So as before, I will just set efi_novamap to false. You can > still use noefi or efi=noruntime to turn off the EFI runtime pieces if > needed (e.g., PREEMPT_RT tends to disable those by default to preserve > their bounded worst case latency)
