[U-Boot] [PATCH v2 00/11] SiFive FU540 Support

Tue Jan 22 22:35:58 UTC 2019

On Tue, 2019-01-22 at 12:31 +0000, Anup Patel wrote:
> > -----Original Message-----
> > From: Auer, Lukas [mailto:lukas.auer at aisec.fraunhofer.de]
> > Sent: Tuesday, January 22, 2019 5:21 PM
> > To: sjg at chromium.org; bmeng.cn at gmail.com; rick at andestech.com; Anup
> > Patel <Anup.Patel at wdc.com>; joe.hershberger at ni.com;
> > yamada.masahiro at socionext.com; Atish Patra <Atish.Patra at wdc.com>
> > Cc: paul.walmsley at sifive.com; palmer at sifive.com; hch at infradead.org;
> > u-
> > boot at lists.denx.de; agraf at suse.de
> > Subject: Re: [PATCH v2 00/11] SiFive FU540 Support
> > 
> > On Mon, 2019-01-21 at 04:04 +0000, Anup Patel wrote:
> > > > -----Original Message-----
> > > > From: Atish Patra [mailto:atish.patra at wdc.com]
> > > > Sent: Monday, January 21, 2019 7:07 AM
> > > > To: Auer, Lukas <lukas.auer at aisec.fraunhofer.de>; 
> > > > sjg at chromium.org;
> > > > bmeng.cn at gmail.com; rick at andestech.com; Anup Patel
> > > > <Anup.Patel at wdc.com>; joe.hershberger at ni.com;
> > > > yamada.masahiro at socionext.com
> > > > Cc: paul.walmsley at sifive.com; palmer at sifive.com; 
> > > > hch at infradead.org;
> > > > u-
> > > > boot at lists.denx.de; agraf at suse.de
> > > > Subject: Re: [PATCH v2 00/11] SiFive FU540 Support
> > > > 
> > > > On 1/20/19 12:34 PM, Auer, Lukas wrote:
> > > > > Hi Anup,
> > > > > 
> > > > > On Fri, 2019-01-18 at 11:18 +0000, Anup Patel wrote:
> > > > > > This patchset adds SiFive Freedom Unleashed (FU540) support
> > > > > > to
> > > > > > RISC-V U-Boot.
> > > > > > 
> > > > > > The patches are based upon latest RISC-V U-Boot tree
> > > > > > (git://git.denx.de/u-boot-riscv.git) at commit id
> > > > > > 91882c472d8c0aef4db699d3f2de55bf43d4ae4b
> > > > > > 
> > > > > > All drivers namely: SiFive PRCI, SiFive Serial, and Cadance
> > > > > > MACB
> > > > > > Ethernet work fine on actual SiFive Unleashed board and
> > > > > > QEMU
> > > > > > sifive_u machine.
> > > > > > 
> > > > > 
> > > > > Thanks for working on this! Are you also planning on adding
> > > > > the
> > > > > features of the FSBL to U-Boot to remove it from the boot
> > > > > flow?
> > > > > 
> > > > 
> > > > That would also mean that adding M-mode capability in U-boot.
> > > > As of
> > > > now the expected boot flow is
> > > > 
> > > > ZSBL->FSBL------->BBL/OpenSBI--------->U-boot-------------
> > > > >Linux
> > > > (M mode from ROM)  (M mode from DRAM)  (S Mode from DRAM)  (S
> > Mode
> > > > from
> > > > DRAM)
> > > > 
> > > > This is not the mandated boot flow but running the last stage
> > > > boot
> > > > loader from S-mode gives flexibility in virtualization in
> > > > future.
> > > 
> > > To elaborate more on what Atish already mentioned, our rationale
> > > behind
> > > ZSBL->FSBL->BBL/OpenSBI->U-Boot(or Any other general bootloader)
> > > is
> > > as follows:
> > > 1. We don't want to replicate FSBL code (DRAM and other system-
> > > level
> > > init)
> > > in general purpose bootloaders (U-Boot, UEFI/Tianocore, etc) 2.
> > > We
> > > don't want to replicate SBI runtime implementation in general
> > > purpose
> > > bootloaders (U-Boot, UEFI/Tianocore, etc) 3. We want to use
> > > general
> > > purpose bootloader (U-Boot, UEFI/Tianocore,
> > > etc)
> > > inside Guest/VM (S-mode)
> > > 
> > > Of course, above boot flow is not mandatory. There could be RISC-
> > > V
> > > systems where prior booting stages (such as ZSBL and FSBL) don't
> > > exist
> > > so users have following options:
> > > 1. Run U-Boot in M-mode for such RISC-V systems and link to
> > > OpenSBI
> > > static library for SBI runtime services 2. Run U-Boot in S-mode
> > > but do
> > > most system-level initialization (including DRAM init) in OpenSBI
> > > firmware. In other words, use following booting
> > > flow:
> > > OpenSBI (M-mode) -> U-Boot (S-mode)
> > > 
> > > For point1 above, we will first try it with U-Boot M-mode on QEMU
> > > Virt
> > > machine.
> > > 
> > 
> > Thank you for the explanation, Anup and Atish!
> > I am actually less concerned about adding DRAM initialization into
> > U-Boot (but that would be nice to have) and more about having a
> > better
> > separation of tasks. At the moment, bootloader tasks are included
> > in
> > both the FSBL (device trees) and BBL (disable the monitor hart).
> > While
> > the current implementation works fine, it will get complicated as
> > soon
> > as we have more boards (and importantly, more complicated boards)
> > using
> > these chips. At this point, the manufacturer will have at least two
> > board specific software components to update, the FSBL and U-Boot.
> > This
> > is unneeded complexity, I think.
> > For the same reason, I agree with you that it does not make sense
> > to
> > implement the SBI in U-Boot. OpenSBI is better suited to handle
> > this.
> > 
> > A boot flow that could be used in this case is the following.
> > 
> > ZSBL -> U-Boot SPL (M-mode) -> OpenSBI -> U-Boot proper (S-mode)
> 
> In this boot flow we have U-Boot SPL in-place of FSBL. At very high-
> level
> it is very similar to the boot flow we mentioned.
> 
> If we use more generic names to describe the boot flow then it would
> be:
> ROM (on-chip ROM, M-mode) -> LOADER (on-chip SRAM, M-mode) -> RUNTIME
> (DRAM, M-mode) -> BOOTLOADER (DRAM, S-mode)

That's true, the boot flow is more or less the same. The big difference
is that we have one less software project that must be tested and
maintained. :)

> 
> I agree that ROM, LOADER, and RUNTIME will be mostly board specific
> But BOOTLOADER can be more generic such that it can run on multiple
> Boards.
> 
> For example:
> All drivers for SiFive FU540 in U-Boot are DT-based. If we enable
> these
> drivers for QEMU RISC-V board then we have unified U-Boot image which
> works on QEMU virt machine, QEMU sifive_u machine, and SiFive FU540
> board. We have tried this ourselves and this actually works.
> 
> We can certainly have a generic RISC-V board support in U-Boot where
> enabled drivers are DT-based. With this generic RISC-V board support
> we can aim for unified U-Boot images which works on multiple boards.
> 
> Regards,
> Anup

I do agree that a generic bootloader would be a very good thing to have
and I think we should try to keep everything reasonably generic.
However, I also think that we will likely need some degree of board-
specific configuration, which can probably be limited to the device
trees and U-Boot config.

Thanks,
Lukas