On Tue, 2019-01-22 at 12:31 +0000, Anup Patel wrote: > > -----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)
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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
