Re: [PATCH V6 09/22] LoongArch: Add boot and setup routines

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Linux Kernel]     [Kernel Newbies]     [x86 Platform Driver]     [Netdev]     [Linux Wireless]     [Netfilter]     [Bugtraq]     [Linux Filesystems]     [Yosemite Discussion]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux