Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
MIME-Version: 1.0
References: <20220603072053.35005-1-chenhuacai@loongson.cn>
 <20220603072053.35005-12-chenhuacai@loongson.cn> <4213df91-c762-ae56-f08d-8c925759fa63@xen0n.name>
In-Reply-To: <4213df91-c762-ae56-f08d-8c925759fa63@xen0n.name>
From:   Arnd Bergmann <arnd@arndb.de>
Date:   Fri, 3 Jun 2022 12:02:00 +0200
Message-ID: <CAK8P3a2mW7KmgxqWsaf76Q4V++B+0e6bH=tb4w4cA0XkZYuSLA@mail.gmail.com>
Subject: Re: [PATCH V15 11/24] LoongArch: Add boot and setup routines
To:     WANG Xuerui <kernel@xen0n.name>
Cc:     Ard Biesheuvel <ardb@kernel.org>,
        Huacai Chen <chenhuacai@loongson.cn>,
        Arnd Bergmann <arnd@arndb.de>,
        Andy Lutomirski <luto@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Peter Zijlstra <peterz@infradead.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        David Airlie <airlied@linux.ie>,
        Jonathan Corbet <corbet@lwn.net>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        linux-arch <linux-arch@vger.kernel.org>,
        "open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Xuefeng Li <lixuefeng@loongson.cn>,
        Yanteng Si <siyanteng@loongson.cn>,
        Huacai Chen <chenhuacai@gmail.com>,
        Guo Ren <guoren@kernel.org>,
        Jiaxun Yang <jiaxun.yang@flygoat.com>,
        Stephen Rothwell <sfr@canb.auug.org.au>,
        linux-efi <linux-efi@vger.kernel.org>,
        WANG Xuerui <git@xen0n.name>, Yun Liu <liuyun@loongson.cn>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, Jun 3, 2022 at 11:27 AM WANG Xuerui <kernel@xen0n.name> 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@vger.kernel.org
> > Cc: Ard Biesheuvel <ardb@kernel.org>
> > Reviewed-by: WANG Xuerui <git@xen0n.name>
> > Reviewed-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
> > Co-developed-by: Yun Liu <liuyun@loongson.cn>
> > Signed-off-by: Yun Liu <liuyun@loongson.cn>
> > Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
>
> 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.

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.

        Arnd