lkml.org 
[lkml]   [2022]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH V6 09/22] LoongArch: Add boot and setup routines
On Mon, 28 Feb 2022 at 09:38, Huacai Chen <chenhuacai@gmail.com> wrote:
>
> Hi, Ard,
>
> On Mon, Feb 28, 2022 at 4:09 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > On Mon, 28 Feb 2022 at 07:34, Huacai Chen <chenhuacai@gmail.com> wrote:
> > >
> > > Hi, Ard and Greg,
> > >
> > > On Mon, Feb 28, 2022 at 12:40 AM Greg Kroah-Hartman
> > > <gregkh@linuxfoundation.org> 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@loongson.cn> 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@kernel.org>
> > > > > > Cc: linux-efi@vger.kernel.org
> > > > > > Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
> > > > > > ---
> > > > > > 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.

\
 
 \ /
  Last update: 2022-02-28 09:52    [W:0.167 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site