RE: [sw-dev] SBI extension proposal v2

[Anup Patel <Anup.Patel@wdc.com>]

> -----Original Message-----
> From: linux-riscv [mailto:linux-riscv-bounces@lists.infradead.org] On Behalf
> Of Paul Walmsley
> Sent: Thursday, February 7, 2019 9:27 AM
> To: ron minnich <rminnich@gmail.com>
> Cc: mark.rutland@arm.com; Christoph Hellwig <hch@infradead.org>;
> Damien Le Moal <Damien.LeMoal@wdc.com>; Olof Johansson
> <olof.johansson@gmail.com>; alankao@andestech.com;
> abner.chang@hpe.com; Luís Marques <luismarques@lowrisc.org>; Anup
> Patel <anup@brainfault.org>; Palmer Dabbelt <palmer@sifive.com>;
> Alexander Graf <agraf@suse.de>; zong@andestech.com; Atish Patra
> <Atish.Patra@wdc.com>; sw-dev@groups.riscv.org; Paul Walmsley
> <paul.walmsley@sifive.com>; Benjamin Herrenschmidt
> <benh@kernel.crashing.org>; mick@ics.forth.gr; Alistair Francis
> <Alistair.Francis@wdc.com>; Luke Kenneth Casson Leighton <lkcl@lkcl.net>;
> linux-riscv@lists.infradead.org; Andrew Waterman <andrew@sifive.com>
> Subject: Re: [sw-dev] SBI extension proposal v2
> 
> On Tue, 5 Feb 2019, ron minnich wrote:
> 
> > While I respect the tremendous amount of work the OpenSBI authors have
> > done, I agree with Benjamin and Luis.
> 
> There are a few key points that seem to be getting lost in this
> discussion:
> 
> 1. OpenSBI is a sample implementation of the SBI interface, and is not the SBI
> standard itself
> 
> 2. It is optional to implement the SBI, and it's likely that only certain types of
> platforms will do so
> 
> 3. OpenSBI, from my point of view, consists of two distinct components:
> 	a. libraries that can be used as reference implementations by
> 	   other early boot firmware; and
> 	b. sample early boot firmware that replaces riscv-pk

I would like to clarify that reference firmwares provided by OpenSBI
only provide RUNTIME services (i.e. handle SBI calls and M-mode traps)
so they are not early boot firmware.

The OpenSBI reference firmwares are not suitable to be used as ROM
firmware (e.g. ZSBL) or LOADER (e.g. FSBL) firmware. They are only
RUNTIME firmwares designed to replace BBL (riscv-pk).

Further, it is not mandatory to use OpenSBI reference firmwares as-is
and HW vendors can always create their own RUNTIME firmware (probably
link it to OpenSBI library).

> 
> As far as I can tell, as long as the platform specification standards are written
> correctly, there's no conflict between SBI-based platforms and SBI-less
> platforms.
> 
> > There is a further issue that occurred to me doing their excellent
> > FOSDEM talk, which is that nowhere in this has any kind of verified
> > boot scenario been discussed, and if you don't get that thinking in
> > from the start it is very hard to wedge it in later.
> 
> Verified boot seems almost completely orthogonal to OpenSBI's library
> implementation (3a, above).  U-boot, or Grub, or Coreboot, could reuse the
> OpenSBI libraries, but not the OpenSBI early boot firmware.  Then those
> other bootloaders can implement whatever verified/trusted/secure boot
> approach that they wish.
> 
> As 3b mentions above, the OpenSBI repository also contains sample early
> boot firmware.  That part of OpenSBI would clearly need to be modified to
> support some sort of verified boot.  However, no one to my knowledge is
> proposing to make the OpenSBI sample early boot firmware a RISC-V
> standard.  That part of OpenSBL is just a sample first-stage bootloader
> implementation - the same way that U-boot SPL or Coreboot romstage are
> sample first-stage bootloader implementations.
> 
> ...
> 
> I personally am excited to finally be able to use U-boot's rich commandline
> interface and device drivers without needing to have riscv-pk (aka BBL)
> involved.  Those who are not doing active RISC-V Linux development may not
> be aware that the use of riscv-pk made it very difficult to use upstream-
> focused Linux DT data.  Even though I might have slightly different
> preferences for the current boot flow, their work removes a major obstacle
> from RISC-V Linux upstream development, and is a big step forward.
> 
> 

Regards,
Anup

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv