On Mon, 19 Sept 2022 at 08:06, Huacai Chen <chenhuacai@xxxxxxxxxx> wrote: > > Hi, Ard, > > On Mon, Sep 19, 2022 at 1:15 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > > > On Mon, 19 Sept 2022 at 03:58, Huacai Chen <chenhuacai@xxxxxxxxxx> wrote: > > > > > > Hi, Ard, > > > > > > I think the parameters passed to the core kernel need to be discussed. > > > The old way (so-called old world): > > > a0=argc, a1=argv, a1=bpi > > > > > > The current way (so-called new world): > > > a0=efi boot flag, a1=fdt pointer > > > > > > The new way (in this patchset): > > > a0=efi boot flag, a1=systemtable, a2=cmdline > > > > > > I prefer to use the current way, there are 3 reasons: > > > 1, both acpi system and dt system can use the same parameters passing method; > > > > DT systems will use this too. The distinction is between EFI boot and > > non-EFI boot. We *really* should keep these separate, given the > > experience on ARM, where other projects invent ways to pass those > > values to the kernel without going through the stub. > In the last patch I see: > + void *fdt_ptr = early_memremap_ro(fw_arg1, SZ_64K); > + > + early_init_dt_scan(fdt_ptr); > + early_init_fdt_reserve_self(); > + > clear_bit(EFI_BOOT, &efi.flags); > So I suppose for the DT system that means a0=efi boot flag, a1=fdt > pointer, a2=cmdline? Then it is not exactly the same as the ACPI > system, but similar. > No, for non-EFI DT boot, the command line is passed via the DT, so a0=0x0 (non-efi), a1=DT, a2=0x0 Do you intend to support non-EFI DT boot by the way? So a2 != 0x0 means old world a0 != 0x0 means EFI boot, a1 is the command line a0 == 0x0 means !EFI boot, a1 is the DT > > > > > 2, arm64, riscv and loongarch can use similar logics (light FDT); > > > > No need to repeat a mistake. I intend to fix RISC-V next. > > > > > 3, out-of-tree patches can make compatibility with the old world > > > easier by just judging whether a2 is zero. > > > > > > > The whole point of this series is that the EFI stub should not be > > touching the DT at all. In other words, there is no DT pointer, so the > > current method needs to be revised. > > > > What we might do is > > > > a0=systemtable, a1=cmdline > > > > as any non-zero value is treated as logic true. That way, your logic > > to test a2 is zero will still work. > I think the efi boot flag is still needed, even boot from efistub. > Because if boot with "efi=novamap", the efi runtime should be > disabled. Then we need efi_enabled(EFI_BOOT) to be false in > efi_init(). > I don't think it makes sense to allow efi=novamap on LoongArch, given that we cannot make use of the runtime services that way. So in my code, efi_novamap is set to false unconditionally.
