On 6/3/22 18:02, Arnd Bergmann wrote:
On Fri, Jun 3, 2022 at 11:27 AM WANG Xuerui <kernel@xxxxxxxxxx> wrote:
On 6/3/22 15:20, Huacai Chen wrote:
Add basic boot, setup and reset routines for LoongArch. Now, LoongArch
machines use UEFI-based firmware. The firmware passes configuration
information to the kernel via ACPI and DMI/SMBIOS.
Currently an existing interface between the kernel and the bootloader
is implemented. Kernel gets 2 values from the bootloader, passed in
registers a0 and a1; a0 is an "EFI boot flag" distinguishing UEFI and
non-UEFI firmware, while a1 is a pointer to an FDT with systable,
memmap, cmdline and initrd information.
The standard UEFI boot protocol (EFISTUB) will be added later.
Cc: linux-efi@xxxxxxxxxxxxxxx
Cc: Ard Biesheuvel <ardb@xxxxxxxxxx>
Reviewed-by: WANG Xuerui <git@xxxxxxxxxx>
Reviewed-by: Jiaxun Yang <jiaxun.yang@xxxxxxxxxxx>
Co-developed-by: Yun Liu <liuyun@xxxxxxxxxxx>
Signed-off-by: Yun Liu <liuyun@xxxxxxxxxxx>
Signed-off-by: Huacai Chen <chenhuacai@xxxxxxxxxxx>
Would you please look at this patch, which has all the arch-independent
changes backed out, and Ack if it is fit for mainlining?
I communicated a little with Huacai about the approach for supporting
alternative boot protocols down the road, and we agreed to carry the
respective changes downstream. And if needs truly arise for modifying
common EFI logic, we can do so in a non-rushed manner later.
For the current status of the code, apparently it just accepts the
standard efistub-shape FDT pointer from (whatever booting the image),
and everything onwards are fully using the common code without
modification as you can see from the diffstat. I rebased my BPI support
patch on top of this (basically translating Loongson BPI data structures
into the expected FDT form), and can confirm the boot can progress to
the same point as before -- indeed the SVAM changes etc. are not
necessary for a working system, and the code remains working.
I'm a bit lost here: Does this mean the v15 version is back to the old
pre-efistub interface and allows booting with existing firmware, or
is it now left out completely? I still see a kernel_entry() function
in head.S, and I see references to loongson_sysconf, but I don't
see if that is what gets passed in from the bootloader.
It's not the same interface as in some of the very early revisions; the
earlier versions relied on "struct bootparamsinterface" or BPI, while
it's the same FDT-based interface to initialize EFI from, as in
arch/arm64 and arch/riscv I believe. No Loongson-specific things remain now.
I really want to make sure that without the EFI stub, there is no
other way to boot the kernel that would have to get maintained
in the long run.
Yeah this is the case right now. No LoongArch bootloader that I know of
can prepare the EFI stub-shaped FDT that the current code expects, and I
don't know of any future Loongson plan to do that either (Loongson's
previous in-house efforts all looked something different). So it's
pretty safe to say the current code wouldn't get frozen once mainlined.
Arnd
