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)
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