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

[Anup Patel]

> -----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)

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