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

From: Bin Meng <bmeng.cn@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2 00/11] SiFive FU540 Support
Date: Mon, 21 Jan 2019 14:14:18 +0800	[thread overview]
Message-ID: <CAEUhbmWYD=WFRmzqA8xGJbWwR5E-ecdHJrkdA4fVXFzD8L=1aA@mail.gmail.com> (raw)
In-Reply-To: <BYAPR04MB53033E5CADC20AA6C6CB349A8D9F0@BYAPR04MB5303.namprd04.prod.outlook.com>

Hi Anup,

On Mon, Jan 21, 2019 at 12:04 PM Anup Patel <Anup.Patel@wdc.com> 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@aisec.fraunhofer.de>; sjg at chromium.org;
> > bmeng.cn at gmail.com; rick at andestech.com; Anup Patel
> > <Anup.Patel@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.

Has the OpenSBI project be started somewhere?

Regards,
Bin