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

[Auer, Lukas]

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)

Thanks,
Lukas

> > > I was able to run U-Boot and boot Linux successfully on a SiFive
> > > HiFive Unleashed board with this patch series. I had to make one
> > > more
> > > change, because U-Boot was not able to find a serial driver and
> > > paniced as a result.
> > > 
> > > I fixed this by making the serial driver available pre-
> > > relocation. For
> > > this, the soc compatible has to be added to cpu/generic/cpu.c and
> > > the
> > > serial driver must have the DM_FLAG_PRE_RELOC flag set.
> > > 
> > > Another way would be to add a "stdout-path" property to the
> > > chosen
> > > node of the device tree.
> > > 
> > 
> > Currently, we modified the DT to add stdout-path in prior stage
> > boot loader.
> > 
> > Regards,
> > Atish
> > > Thanks,
> > > Lukas
> > > 
> Regards,
> Anup