linux-efi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Atish Patra <Atish.Patra@wdc.com>
To: "palmer@dabbelt.com" <palmer@dabbelt.com>
Cc: "alexios.zavras@intel.com" <alexios.zavras@intel.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"mchehab+samsung@kernel.org" <mchehab+samsung@kernel.org>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"michal.simek@xilinx.com" <michal.simek@xilinx.com>,
	"linux@armlinux.org.uk" <linux@armlinux.org.uk>,
	"abner.chang@hpe.com" <abner.chang@hpe.com>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"daniel.schaefer@hpe.com" <daniel.schaefer@hpe.com>,
	Anup Patel <Anup.Patel@wdc.com>,
	"kstewart@linuxfoundation.org" <kstewart@linuxfoundation.org>,
	"aou@eecs.berkeley.edu" <aou@eecs.berkeley.edu>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"rppt@linux.ibm.com" <rppt@linux.ibm.com>,
	"bp@suse.de" <bp@suse.de>,
	"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
	"greentime.hu@sifive.com" <greentime.hu@sifive.com>,
	"keescook@chromium.org" <keescook@chromium.org>,
	"agraf@csgraf.de" <agraf@csgraf.de>,
	"will@kernel.org" <will@kernel.org>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"mingo@kernel.org" <mingo@kernel.org>,
	"allison@lohutok.net" <allison@lohutok.net>,
	"han_mao@c-sky.com" <han_mao@c-sky.com>,
	"paul.walmsley@sifive.com" <paul.walmsley@sifive.com>,
	"ardb@kernel.org" <ardb@kernel.org>,
	"linus.walleij@linaro.org" <linus.walleij@linaro.org>,
	"leif@nuviainc.com" <leif@nuviainc.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>
Subject: Re: [RFC PATCH 0/5] Add UEFI support for RISC-V
Date: Thu, 27 Feb 2020 02:09:09 +0000	[thread overview]
Message-ID: <7659f4c0970fac6113c290b0f3a4889bf6504cfd.camel@wdc.com> (raw)
In-Reply-To: <mhng-2fe6e2a0-9291-4810-b42c-af69b8dbaa06@palmerdabbelt-glaptop1>

On Wed, 2020-02-26 at 15:46 -0800, Palmer Dabbelt wrote:
> On Tue, 25 Feb 2020 17:10:32 PST (-0800), Atish Patra wrote:
> > This series adds UEFI support for RISC-V. Currently, only boot time
> > services have been added. Runtime services will be added in a
> > separate
> > series. This series depends on some core EFI patches
> > present in current in efi-next and following other patches.
> > 
> > U-Boot: Adds the boot hartid under chosen node.
> > https://lists.denx.de/pipermail/u-boot/2020-February/401227.html
> > 
> > Linux kernel: SBI v0.2 and HSM extension support. This series is a
> > mandatory
> > pre-requisite for UEFI support as only single core can boot EFI
> > stub and
> > Linux via UEFI. All other cores are brought up using SBI HSM
> > extension.
> > http://lists.infradead.org/pipermail/linux-riscv/2020-February/008513.html
> > 
> > OpenSBI: master (commit: ge3f69fc1e934)
> > 
> > Patch 1 just moves arm-stub code to a generic code so that it can
> > be used
> > across different architecture.
> > 
> > Patch 3 adds fixmap bindings so that CONFIG_EFI can be compiled and
> > we do not
> > have create separate config to enable boot time services.
> > As runtime services are not enabled at this time, full generic
> > early ioremap
> > support is also not added in this series.
> > 
> > Patch 4 and 5 adds the PE/COFF header and EFI stub code support for
> > RISC-V
> > respectively.
> > 
> > The patches can also be found in following git repo.
> > 
> > https://github.com/atishp04/linux/tree/wip_uefi_riscv
> > 
> > The patches have been verified on Qemu using bootefi command in U-
> > Boot.
> > Here is a boot log.
> > 
> > Atish Patra (5):
> > efi: Move arm-stub to a common file
> > include: pe.h: Add RISC-V related PE definition
> > RISC-V: Define fixmap bindings for generic early ioremap support
> > RISC-V: Add PE/COFF header for EFI stub
> > RISC-V: Add EFI stub support.
> > 
> > arch/arm/Kconfig                              |   2 +-
> > arch/arm64/Kconfig                            |   2 +-
> > arch/riscv/Kconfig                            |  21 +++
> > arch/riscv/Makefile                           |   1 +
> > arch/riscv/configs/defconfig                  |   1 +
> > arch/riscv/include/asm/Kbuild                 |   2 +-
> > arch/riscv/include/asm/fixmap.h               |  21 ++-
> > arch/riscv/include/asm/io.h                   |   1 +
> > arch/riscv/include/asm/sections.h             |  13 ++
> > arch/riscv/kernel/Makefile                    |   4 +
> > arch/riscv/kernel/efi-header.S                | 107 ++++++++++++++
> > arch/riscv/kernel/head.S                      |  15 ++
> > arch/riscv/kernel/image-vars.h                |  52 +++++++
> > arch/riscv/kernel/vmlinux.lds.S               |  27 +++-
> > drivers/firmware/efi/Kconfig                  |   6 +-
> > drivers/firmware/efi/libstub/Makefile         |  20 ++-
> > .../efi/libstub/{arm-stub.c => efi-stub.c}    |   7 +-
> > drivers/firmware/efi/libstub/riscv-stub.c     | 135
> > ++++++++++++++++++
> > include/linux/pe.h                            |   3 +
> > 19 files changed, 420 insertions(+), 20 deletions(-)
> > create mode 100644 arch/riscv/include/asm/sections.h
> > create mode 100644 arch/riscv/kernel/efi-header.S
> > create mode 100644 arch/riscv/kernel/image-vars.h
> > rename drivers/firmware/efi/libstub/{arm-stub.c => efi-stub.c}
> > (98%)
> > create mode 100644 drivers/firmware/efi/libstub/riscv-stub.c
> 
> I'm in favor of adding EFI support, and I'd rather have it sooner
> than later so
> we don't paint ourselves into a corner.  I'm not sure what happened
> to the
> RISC-V EFI spec process, though, which would be my only worry here
> (also I
> haven't looked at the code :)).  Do we have enough of a spec through
> the EFI
> process that this is all kosher on their end?
> 
The RISC-V platform is already merged in UEFI spec. The latest UEFI
spec can be found here.

https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_A_Feb14.pdf

Section 2.3.7: RISC-V Platforms

There are some modification required in the current spec. For example:

The current spec assumes that UEFI will execute in M mode only and
should perform handoff control to OS in M-mode as well. This is not
entirely correct as we can do this in S-mode as well.

We are in the process of creating an ECR so that next release will have
the correct information.

> Given that this definately isn't for these RCs, I'm going to leave it
> in my
> review queue.  It might be best to get the "move stuff to generic"
> work merged
> on its own, as then we can carry less diff around.
> 
> 

Yup. It's definitely not rc material. Given that RISC-V specific
section is already merged in UEFI spec, can we aim for 5.7 merge window? 

> Thanks!

-- 
Regards,
Atish

      reply	other threads:[~2020-02-27  2:09 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-26  1:10 [RFC PATCH 0/5] Add UEFI support for RISC-V Atish Patra
2020-02-26  1:10 ` [RFC PATCH 1/5] efi: Move arm-stub to a common file Atish Patra
2020-02-26  7:04   ` Ard Biesheuvel
2020-02-27  1:16     ` Atish Patra
2020-02-26  1:10 ` [RFC PATCH 2/5] include: pe.h: Add RISC-V related PE definition Atish Patra
2020-02-26  7:06   ` Ard Biesheuvel
2020-02-27  0:53     ` Atish Patra
2020-02-26  1:10 ` [RFC PATCH 3/5] RISC-V: Define fixmap bindings for generic early ioremap support Atish Patra
2020-02-26  7:08   ` Ard Biesheuvel
2020-02-27 19:58     ` Atish Patra
2020-02-27 20:00       ` Ard Biesheuvel
2020-02-26  1:10 ` [RFC PATCH 4/5] RISC-V: Add PE/COFF header for EFI stub Atish Patra
2020-02-26  7:14   ` Ard Biesheuvel
2020-02-27  1:29     ` Atish Patra
2020-02-27  7:44       ` Ard Biesheuvel
2020-02-26  1:10 ` [RFC PATCH 5/5] RISC-V: Add EFI stub support Atish Patra
2020-02-26  7:28   ` Ard Biesheuvel
2020-02-27 19:53     ` Atish Patra
2020-02-27 19:59       ` Ard Biesheuvel
2020-02-28  1:05         ` Atish Patra
2020-02-28  6:57           ` Ard Biesheuvel
2020-03-10  7:08             ` Atish Patra
2020-03-10  7:38               ` Anup Patel
2020-03-10 13:18               ` Ard Biesheuvel
2020-02-26 23:46 ` [RFC PATCH 0/5] Add UEFI support for RISC-V Palmer Dabbelt
2020-02-27  2:09   ` Atish Patra [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7659f4c0970fac6113c290b0f3a4889bf6504cfd.camel@wdc.com \
    --to=atish.patra@wdc.com \
    --cc=Anup.Patel@wdc.com \
    --cc=abner.chang@hpe.com \
    --cc=agraf@csgraf.de \
    --cc=akpm@linux-foundation.org \
    --cc=alexios.zavras@intel.com \
    --cc=allison@lohutok.net \
    --cc=aou@eecs.berkeley.edu \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=bp@suse.de \
    --cc=catalin.marinas@arm.com \
    --cc=daniel.schaefer@hpe.com \
    --cc=greentime.hu@sifive.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=han_mao@c-sky.com \
    --cc=keescook@chromium.org \
    --cc=kstewart@linuxfoundation.org \
    --cc=leif@nuviainc.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux@armlinux.org.uk \
    --cc=mchehab+samsung@kernel.org \
    --cc=michal.simek@xilinx.com \
    --cc=mingo@kernel.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=pbonzini@redhat.com \
    --cc=rppt@linux.ibm.com \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).