| Message ID | 20190118111820.71349-1-anup.patel@wdc.com |
|---|---|
| Headers | show |
| Series | SiFive FU540 Support | expand |
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? 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. Thanks, Lukas
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. > 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 >
> -----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: 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. > > > 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
Hi Anup, On Mon, Jan 21, 2019 at 12:04 PM Anup Patel <Anup.Patel@wdc.com> 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: > 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. Has the OpenSBI project be started somewhere? Regards, Bin
> -----Original Message----- > From: Bin Meng [mailto:bmeng.cn@gmail.com] > Sent: Monday, January 21, 2019 11:44 AM > To: Anup Patel <Anup.Patel@wdc.com> > Cc: Atish Patra <Atish.Patra@wdc.com>; Auer, Lukas > <lukas.auer@aisec.fraunhofer.de>; sjg@chromium.org; > rick@andestech.com; joe.hershberger@ni.com; > yamada.masahiro@socionext.com; 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 > > Hi Anup, > > On Mon, Jan 21, 2019 at 12:04 PM Anup Patel <Anup.Patel@wdc.com> > 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: > > 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. > > Has the OpenSBI project be started somewhere? Yes, it exist on Github under https://github.com/riscv Currently, OpenSBI is at-par with BBL in-terms of SBI implementation but it is extensible and supports lot more boards/targets namely: 1. QEMU virt machine 2. QEMU sifive_u machine 3. SiFive FU540 Unleashed board 4. Kendryte K210 board We are almost there and just need some more time for finishing touches. We will be making is Public very soon (few more days) so stay tuned. Of course, we will need help from everyone to make OpenSBI better after all it be a community driver open-source project. There is SBI extensions spec under discussion which will be added in OpenSBI once it is frozen. All of us will be present at up-coming FOSDEM19 to talk about SBI extensions, OpenSBI project, and other stuff. Best Regards, Anup Patel
Hi Anup, On Mon, Jan 21, 2019 at 2:41 PM Anup Patel <Anup.Patel@wdc.com> wrote: > > > > > -----Original Message----- > > From: Bin Meng [mailto:bmeng.cn@gmail.com] > > Sent: Monday, January 21, 2019 11:44 AM > > To: Anup Patel <Anup.Patel@wdc.com> > > Cc: Atish Patra <Atish.Patra@wdc.com>; Auer, Lukas > > <lukas.auer@aisec.fraunhofer.de>; sjg@chromium.org; > > rick@andestech.com; joe.hershberger@ni.com; > > yamada.masahiro@socionext.com; 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 > > > > Hi Anup, > > > > On Mon, Jan 21, 2019 at 12:04 PM Anup Patel <Anup.Patel@wdc.com> > > 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: > > > 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. > > > > Has the OpenSBI project be started somewhere? > > Yes, it exist on Github under https://github.com/riscv > I did not find the project under https://github.com/riscv. Maybe it is an internal one at present? > Currently, OpenSBI is at-par with BBL in-terms of SBI implementation > but it is extensible and supports lot more boards/targets namely: > 1. QEMU virt machine > 2. QEMU sifive_u machine > 3. SiFive FU540 Unleashed board > 4. Kendryte K210 board > > We are almost there and just need some more time for finishing > touches. We will be making is Public very soon (few more days) > so stay tuned. > > Of course, we will need help from everyone to make OpenSBI > better after all it be a community driver open-source project. > > There is SBI extensions spec under discussion which will be > added in OpenSBI once it is frozen. > I've recently posted an question regarding "mhartid" access from S-mode in the RISC-V ISA ML [1]. If we cannot fix the issue from the architecture level, then we may have to consider adding "mhartid" emulation in the SBI. I will copy you guys on that email thread. > All of us will be present at up-coming FOSDEM19 to talk about > SBI extensions, OpenSBI project, and other stuff. > [1] https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/13afxTuYIcc Regards, Bin
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: > 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
> -----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: > > 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
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: > > > 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
On Tue, 22 Jan 2019, Auer, Lukas wrote: > 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. It should be possible to link the OpenSBI library with U-boot, then allow U-boot to use SBI services itself, and to expose the SBI services to whatever it boots. So the OpenSBI boot firmware wouldn't be used, but the underlying library code would be. That simplifies the boot flow, since the (separate) OpenSBI firmware would no longer be needed. > 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) There are other boot flows that are common on ARM platforms: - Boot ROM -> SPL -> U-boot -> Linux - Boot ROM -> SPL -> U-boot -> (SBI implementation / TEE) -> Linux It would be good if we could avoid prejudicing against any of these boot flows. - Paul
On Sat, 2019-02-02 at 09:06 -0800, Paul Walmsley wrote: > On Tue, 22 Jan 2019, Auer, Lukas wrote: > > > 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. > > It should be possible to link the OpenSBI library with U-boot, then > allow > U-boot to use SBI services itself, and to expose the SBI services to > whatever it boots. So the OpenSBI boot firmware wouldn't be used, > but the > underlying library code would be. That simplifies the boot flow, > since > the (separate) OpenSBI firmware would no longer be needed. > Yes, that would also work. I am not at all against integrating the OpenSBI library into U-Boot. Having a separate SBI implementation instead of a shared one (OpenSBI) is what I think does not make sense. Thanks, Lukas > > 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) > > There are other boot flows that are common on ARM platforms: > > - Boot ROM -> SPL -> U-boot -> Linux > - Boot ROM -> SPL -> U-boot -> (SBI implementation / TEE) -> Linux > > It would be good if we could avoid prejudicing against any of these > boot > flows. > > > - Paul
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. Changes since v1: - Re-ordered SoB in patches with multiple SoB - Simplified board_get_usable_ram_top() added by PATCH3 Anup Patel (7): riscv: Rename cpu/qemu to cpu/generic riscv: Add asm/dma-mapping.h for DMA mappings riscv: generic: Ensure that U-Boot runs within 4GB for 64bit systems net: macb: Fix clk API usage for RISC-V systems clk: Add SiFive FU540 PRCI clock driver clk: Add fixed-factor clock driver riscv: Add SiFive FU540 board support Atish Patra (4): net: macb: Fix GEM hardware detection drivers: serial_sifive: Fix baud rate calculation drivers: serial_sifive: Skip baudrate config if no input clock cpu: Bind timer driver for boot hart arch/riscv/Kconfig | 6 +- arch/riscv/cpu/{qemu => generic}/Kconfig | 2 +- arch/riscv/cpu/{qemu => generic}/Makefile | 0 arch/riscv/cpu/{qemu => generic}/cpu.c | 0 arch/riscv/cpu/generic/dram.c | 37 ++ arch/riscv/cpu/qemu/dram.c | 17 - arch/riscv/include/asm/dma-mapping.h | 38 ++ board/emulation/qemu-riscv/Kconfig | 4 +- .../qemu-riscv => sifive/fu540}/Kconfig | 36 +- board/sifive/fu540/MAINTAINERS | 9 + board/sifive/fu540/Makefile | 5 + board/sifive/fu540/fu540.c | 17 + configs/sifive_fu540_defconfig | 11 + drivers/clk/Kconfig | 1 + drivers/clk/Makefile | 5 +- drivers/clk/clk_fixed_factor.c | 74 +++ drivers/clk/sifive/Kconfig | 19 + drivers/clk/sifive/Makefile | 5 + .../clk/sifive/analogbits-wrpll-cln28hpc.h | 101 +++ drivers/clk/sifive/fu540-prci.c | 604 ++++++++++++++++++ drivers/clk/sifive/wrpll-cln28hpc.c | 390 +++++++++++ drivers/cpu/riscv_cpu.c | 7 +- drivers/net/macb.c | 6 +- drivers/serial/serial_sifive.c | 60 +- include/configs/sifive-fu540.h | 43 ++ include/dt-bindings/clk/sifive-fu540-prci.h | 29 + 26 files changed, 1465 insertions(+), 61 deletions(-) rename arch/riscv/cpu/{qemu => generic}/Kconfig (91%) rename arch/riscv/cpu/{qemu => generic}/Makefile (100%) rename arch/riscv/cpu/{qemu => generic}/cpu.c (100%) create mode 100644 arch/riscv/cpu/generic/dram.c delete mode 100644 arch/riscv/cpu/qemu/dram.c create mode 100644 arch/riscv/include/asm/dma-mapping.h copy board/{emulation/qemu-riscv => sifive/fu540}/Kconfig (57%) create mode 100644 board/sifive/fu540/MAINTAINERS create mode 100644 board/sifive/fu540/Makefile create mode 100644 board/sifive/fu540/fu540.c create mode 100644 configs/sifive_fu540_defconfig create mode 100644 drivers/clk/clk_fixed_factor.c create mode 100644 drivers/clk/sifive/Kconfig create mode 100644 drivers/clk/sifive/Makefile create mode 100644 drivers/clk/sifive/analogbits-wrpll-cln28hpc.h create mode 100644 drivers/clk/sifive/fu540-prci.c create mode 100644 drivers/clk/sifive/wrpll-cln28hpc.c create mode 100644 include/configs/sifive-fu540.h create mode 100644 include/dt-bindings/clk/sifive-fu540-prci.h