> -----Original Message----- > From: Auer, Lukas [mailto:lukas.a...@aisec.fraunhofer.de] > Sent: Tuesday, January 22, 2019 5:21 PM > To: s...@chromium.org; bmeng...@gmail.com; r...@andestech.com; Anup > Patel <anup.pa...@wdc.com>; joe.hershber...@ni.com; > yamada.masah...@socionext.com; Atish Patra <atish.pa...@wdc.com> > Cc: paul.walms...@sifive.com; pal...@sifive.com; h...@infradead.org; u- > b...@lists.denx.de; ag...@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.pa...@wdc.com] > > > Sent: Monday, January 21, 2019 7:07 AM > > > To: Auer, Lukas <lukas.a...@aisec.fraunhofer.de>; s...@chromium.org; > > > bmeng...@gmail.com; r...@andestech.com; Anup Patel > > > <anup.pa...@wdc.com>; joe.hershber...@ni.com; > > > yamada.masah...@socionext.com > > > Cc: paul.walms...@sifive.com; pal...@sifive.com; h...@infradead.org; > > > u- > > > b...@lists.denx.de; ag...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
