On Tue, 2019-01-22 at 12:31 +0000, Anup Patel wrote:
-----Original Message----- From: Auer, Lukas [mailto:lukas.auer@aisec.fraunhofer.de] Sent: Tuesday, January 22, 2019 5:21 PM To: sjg@chromium.org; bmeng.cn@gmail.com; rick@andestech.com; Anup Patel Anup.Patel@wdc.com; joe.hershberger@ni.com; yamada.masahiro@socionext.com; Atish Patra Atish.Patra@wdc.com Cc: paul.walmsley@sifive.com; palmer@sifive.com; hch@infradead.org; u- boot@lists.denx.de; agraf@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@wdc.com] Sent: Monday, January 21, 2019 7:07 AM To: Auer, Lukas lukas.auer@aisec.fraunhofer.de; sjg@chromium.org; bmeng.cn@gmail.com; rick@andestech.com; Anup Patel Anup.Patel@wdc.com; joe.hershberger@ni.com; yamada.masahiro@socionext.com Cc: paul.walmsley@sifive.com; palmer@sifive.com; hch@infradead.org; u- boot@lists.denx.de; agraf@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:
- 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:
- 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