On Mon, 28 Feb 2022 at 09:38, Huacai Chen <chenhuacai@xxxxxxxxx> wrote: > > Hi, Ard, > > On Mon, Feb 28, 2022 at 4:09 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > > > On Mon, 28 Feb 2022 at 07:34, Huacai Chen <chenhuacai@xxxxxxxxx> wrote: > > > > > > Hi, Ard and Greg, > > > > > > On Mon, Feb 28, 2022 at 12:40 AM Greg Kroah-Hartman > > > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > On Sun, Feb 27, 2022 at 03:14:30PM +0100, Ard Biesheuvel wrote: > > > > > (add Greg and ACPI maintainers) > > > > > > > > > > On Sat, 26 Feb 2022 at 12:11, Huacai Chen <chenhuacai@xxxxxxxxxxx> wrote: > > > > > > > > > > > > This patch adds basic boot, setup and reset routines for LoongArch. > > > > > > LoongArch uses UEFI-based firmware. The firmware uses ACPI and DMI/ > > > > > > SMBIOS to pass configuration information to the Linux kernel (in elf > > > > > > format). > > > > > > > > > > > > Now the boot information passed to kernel is like this: > > > > > > 1, kernel get 3 register values (a0, a1 and a2) from bootloader. > > > > > > 2, a0 is "argc", a1 is "argv", so "kernel cmdline" comes from a0/a1. > > > > > > 3, a2 is "environ", which is a pointer to "struct bootparamsinterface". > > > > > > 4, "struct bootparamsinterface" include a "systemtable" pointer, whose > > > > > > type is "efi_system_table_t". Most configuration information, include > > > > > > ACPI tables and SMBIOS tables, come from here. > > > > > > > > > > > > Cc: Ard Biesheuvel <ardb@xxxxxxxxxx> > > > > > > Cc: linux-efi@xxxxxxxxxxxxxxx > > > > > > Signed-off-by: Huacai Chen <chenhuacai@xxxxxxxxxxx> > > > > > > --- > > > > > > arch/loongarch/include/asm/acenv.h | 17 + > > > > > > arch/loongarch/include/asm/acpi.h | 38 ++ > > > > > > arch/loongarch/include/asm/boot_param.h | 97 +++++ > > > > > > arch/loongarch/include/asm/bootinfo.h | 33 ++ > > > > > > arch/loongarch/include/asm/dmi.h | 24 ++ > > > > > > arch/loongarch/include/asm/efi.h | 33 ++ > > > > > > arch/loongarch/include/asm/fw.h | 18 + > > > > > > arch/loongarch/include/asm/reboot.h | 10 + > > > > > > arch/loongarch/include/asm/setup.h | 21 + > > > > > > arch/loongarch/kernel/acpi.c | 338 ++++++++++++++++ > > > > > > arch/loongarch/kernel/cacheinfo.c | 122 ++++++ > > > > > > arch/loongarch/kernel/cmdline.c | 31 ++ > > > > > > arch/loongarch/kernel/cpu-probe.c | 305 +++++++++++++++ > > > > > > arch/loongarch/kernel/efi.c | 208 ++++++++++ > > > > > > arch/loongarch/kernel/env.c | 176 +++++++++ > > > > > > arch/loongarch/kernel/head.S | 72 ++++ > > > > > > arch/loongarch/kernel/mem.c | 89 +++++ > > > > > > arch/loongarch/kernel/reset.c | 90 +++++ > > > > > > arch/loongarch/kernel/setup.c | 495 ++++++++++++++++++++++++ > > > > > > arch/loongarch/kernel/time.c | 220 +++++++++++ > > > > > > arch/loongarch/kernel/topology.c | 13 + > > > > > > 21 files changed, 2450 insertions(+) > > > > > > > > > > As I pointed out in response to an earlier revision of this code, I > > > > > don't think we should merge this until we decide on some ground rules > > > > > regarding the support level of this architecture in the UEFI and ACPI > > > > > subsystems. > > > > > > > > > > The problem is that loongarch does not exist in the ACPI or UEFI > > > > > specifications at all, and as I understand it, the firmware > > > > > implementations themselves do not implement UEFI or ACPI entirely, > > > > > they simply present data structures in memory that look similar enough > > > > > for the Linux UEFI and ACPI code to boot the OS. > > > > > > > > Why isn't this in the ACPI/UEFI specs? Is it a lack of access to the > > > > spec groups by the comapny making these devices, or something else? > > > We have tried our best to make LoongArch parts be in ACPI and UEFI SPECs. > > > > > > ECR for adding LoongArch support in ACPI: > > > https://mantis.uefi.org/mantis/view.php?id=2203 > > > > > > ECR for adding LoongArch support in ACPI (version update): > > > https://mantis.uefi.org/mantis/view.php?id=2268 > > > > > > ECR for adding LoongArch support in UEFI: > > > https://mantis.uefi.org/mantis/view.php?id=2313 > > > > > > ACPI changes of LoongArch have been approved in the last year, but the > > > new version of ACPI SPEC hasn't been made public yet. And UEFI changes > > > of LoongArch are under review now. > > > > > > Is it a must that the kernel code be merged after all SPECs are > > > public? If not, I think we can provide some snapshots (If it is legal, > > > I'm not sure) of mantis.uefi.org to prove the above. > > > > > > > Thanks for the links, those with access will be able to review, > > although it would of course be preferable if this was open access. > > > > In any case, if UEFI and ACPI support is going to be ratified in the > > respective specifications, we are in a much better place to support > > this in Linux going forward. > > > > However, that still doesn't mean you should be using the internal API > > used between the EFI stub and the core kernel as a boot interface. > > Instead, you should implement LoongArch support into the EFI stub, and > > build the kernel as a PE/COFF image that can boot from EFI directly, > > from UEFI compliant firmware (u-boot or EDK2 are the most common > > examples) that exposes all the UEFI stuff that the EFI stub relies on. > We have implemented EFISTUB, but not in this first series: > https://github.com/loongson/linux/commit/d415a8e57e4d248e239958f2f18b45ea7a5fec2c > We want to add efistub support in the next series after new UEFI SPEC released. > > > > > RISC-V is a useful reference for the changes needed - this is the most > > recent addition to the EFI stub, and avoids some legacy stuff that new > > architectures have no need for. > We still want to support the raw elf kernel (RISC-V also does), > because LoongArch also has MCU and SoC and we want to support FDT (I > think this is reasonable, because RISC-V also supports raw elf). > That is fine. So perhaps the best course of action is to omit the UEFI/ACPI parts entirely for now, and focus on the DT/embedded use case. Once all the spec pieces are in place, the UEFI + ACPI changes can be presented as a single coherent set. -- Ard.
