Re: [PATCH 00/18] hw/riscv: Add Microchip PolarFire SoC Icicle Kit board support

From: Bin Meng <bmeng.cn@gmail.com>
To: Anup Patel <anup@brainfault.org>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"Alistair Francis" <alistair@alistair23.me>,
	Cyril.Jean@microchip.com,
	"open list:RISC-V" <qemu-riscv@nongnu.org>,
	"Sagar Karandikar" <sagark@eecs.berkeley.edu>,
	"Bin Meng" <bin.meng@windriver.com>,
	"Bastian Koppelmann" <kbastian@mail.uni-paderborn.de>,
	"Jason Wang" <jasowang@redhat.com>,
	"Palmer Dabbelt" <palmerdabbelt@google.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	qemu-arm <qemu-arm@nongnu.org>,
	"Alistair Francis" <Alistair.Francis@wdc.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Alistair Francis" <alistair23@gmail.com>,
	qemu-block@nongnu.org,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>,
	"Palmer Dabbelt" <palmer@dabbelt.com>
Subject: Re: [PATCH 00/18] hw/riscv: Add Microchip PolarFire SoC Icicle Kit board support
Date: Wed, 19 Aug 2020 09:34:03 +0800	[thread overview]
Message-ID: <CAEUhbmUWcTxv70yuLMXwniGXB6zkadcpB4YTq=8F9UcXRK72+g@mail.gmail.com> (raw)
In-Reply-To: <CAAhSdy1MTvjfpHZEAs2YVHXdPBaEMQxUNdP_yc7br0C2p9kfng@mail.gmail.com>

On Tue, Aug 18, 2020 at 9:55 PM Anup Patel <anup@brainfault.org> wrote:
>
> On Tue, Aug 18, 2020 at 6:39 PM <Cyril.Jean@microchip.com> wrote:
> >
> > On 8/18/20 7:17 AM, Anup Patel wrote:
> > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > >
> > > On Tue, Aug 18, 2020 at 1:23 AM <Cyril.Jean@microchip.com> wrote:
> > >> On 8/17/20 8:28 PM, Alistair Francis wrote:
> > >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > >>>
> > >>> On Mon, Aug 17, 2020 at 11:12 AM via <qemu-devel@nongnu.org> wrote:
> > >>>> Hi Anup,
> > >>>>
> > >>>> On 8/17/20 11:30 AM, Bin Meng wrote:
> > >>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > >>>>>
> > >>>>> Hi Anup,
> > >>>>>
> > >>>>> On Sat, Aug 15, 2020 at 1:44 AM Anup Patel <anup@brainfault.org> wrote:
> > >>>>>> On Fri, Aug 14, 2020 at 10:12 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > >>>>>>> From: Bin Meng <bin.meng@windriver.com>
> > >>>>>>>
> > >>>>>>> This adds support for Microchip PolarFire SoC Icicle Kit board.
> > >>>>>>> The Icicle Kit board integrates a PolarFire SoC, with one SiFive's
> > >>>>>>> E51 plus four U54 cores and many on-chip peripherals and an FPGA.
> > >>>>>> Nice Work !!! This is very helpful.
> > >>>>> Thanks!
> > >>>>>
> > >>>>>> The Microchip HSS is quite convoluted. It has:
> > >>>>>> 1. DDR Init
> > >>>>>> 2. Boot device support
> > >>>>>> 3. SBI support using OpenSBI as library
> > >>>>>> 4. Simple TEE support
> > >>>>>>
> > >>>>>> I think point 1) and 2) above should be part of U-Boot SPL.
> > >>>>>> The point 3) can be OpenSBI FW_DYNAMIC.
> > >>>>>>
> > >>>>>> Lastly,for point 4), we are working on a new OpenSBI feature using
> > >>>>>> which we can run independent Secure OS and Non-Secure OS using
> > >>>>>> U-Boot_SPL+OpenSBI (for both SiFive Unleashed and Microchip
> > >>>>>> PolarFire).
> > >>>>>>
> > >>>>>> Do you have plans for adding U-Boot SPL support for this board ??
> > >>>>> + Cyril Jean from Microchip
> > >>>>>
> > >>>>> I will have to leave this question to Cyril to comment.
> > >>>>>
> > >>>> I currently do not have a plan to support U-Boot SPL. The idea of the
> > >>>> HSS is to contain all the silicon specific initialization and
> > >>>> configuration code within the HSS before jumping to U-Boot S-mode. I
> > >>>> would rather keep all this within the HSS for the time being. I would
> > >>>> wait until we reach production silicon before attempting to move this to
> > >>>> U-Boot SPL as the HSS is likely to contain some opaque silicon related
> > >>>> changes for another while.
> > >>> That is unfortunate, a lot of work has gone into making the boot flow
> > >>> simple and easy to use.
> > >>>
> > >>> QEMU now includes OpenSBI by default to make it easy for users to boot
> > >>> Linux. The Icicle Kit board is now the most difficult QEMU board to
> > >>> boot Linux on. Not to mention it makes it hard to impossible to
> > >>> support it in standard tool flows such as meta-riscv.
> > >>>
> > >>> Alistair
> > >> If it is such a problem we can add a U-Boot SPL stage and the HSS can be
> > >> treated as standard SoC ROM code.
> > > It's not mandatory for U-Boot SPL to have stable DRAM calibration settings
> > > from the start itself. The initial U-Boot SPL support for most
> > > platforms (accross
> > > architectures) usually include basic working DRAM calibration settings which
> > > is later on updated with separate patches. Also, we don't need all U-Boot
> > > drivers to be upstreamed in one-go as this can be done in phases.
> > >
> > > The advantage we have with PolarFire SoC Icicle board is that we already
> > > have a U-Boot S-mode. and we believe the OpenSBI generic platform will
> > > work fine for PolarFire SoC Icicle board so the only thing missing right now
> > > is the U-Boot SPL support for OpenSource boot-flow.
> > >
> > > It will certainly accelerate open-source development if we have boot-flow
> > > U-Boot_SPL => OpenSBI (FW_DYNAMIC) => U-Boot_S-mode working
> > > on PolarFire SoC Icicle board. Initially, we just need DRAM, SD/eMMC,
> > > and Serial port support for U-Boot SPL and U-Boot S-mode. Later on,
> > > more patches can add ethernet and other booting device drivers to U-Boot.
> > >
> > > Regarding security services of HSS, we are working on a OpenSBI
> > > feature which will allow HSS security services to run as independent
> > > binary in M-mode (not linked to OpenSBI) and OpenSBI FW_DYNAMIC
> > > will be a separate binary acting as a secure monitor.
> > >
> > > Regards,
> > > Anup
> >
> > What I have in mind is that the external memory will be up and running
> > by the time we get to U-Boot SPL. In the case of PolarFire SoC the ROM
> > code equivalent brings up the DDR memory interface so we do not need to
> > worry about this as part of U-Boot.
>
> Keeping DRAM configuration as part of a separate ROM booting stage prior
> to the U-Boot SPL sounds good to me. This will lead to following boot-flow:
>
> ROM/HSS (M-mode) => U-Boot SPL (M-mode) => OpenSBI (M-mode) => U-Boot S-mode

If we want to keep the HSS, meaning that DDR memory is already
initialized, then there is no need to create an additional step of
U-Boot SPL phase, because there is no size limitation any more.

Right now, the boot workflow on PolarFire is:

HSS + OpenSBI (as a library) (M-mode) => U-Boot S-mode

It's just not the canonical way because of the HSS and OpenSBI as a library.

A canonical way should be:

U-Boot SPL (M-mode) => OpenSBI dynamic (M-mode) => U-Boot S-mode

So we should be aiming to replace HSS with U-Boot SPL.

>
> >
> > Sounds to me the component that needs to be upstreamed next is the eMMC
> > support so that it can be used as part of U-Boot SPL. Correct?
>
> Maybe as a PHASE1 patch series for PolarFire U-Boot support can
> target the following:
> 1. Minimal U-Boot board support for PolarFire IcIcle Board with
> single defconfig to build both U-Boot SPL and U-Boot S-mode
> 2. Serial port driver (probably re-use existing driver)
> 3. SD and eMMC driver
>
> Supporting SD booting is highly desirable for PHASE1. At least,
> U-Boot SPL, OpenSBI, U-Boot S-mode, and Linux should come
> as separate images from SD card. The ROM/HSS can reside and
> boot from on-board flash/eMMC.
>
> Above is my suggestion based on experience with SiFive Unleashed.
>
> The general idea behind OpenSource boot-flow is to have each
> booting stage as a separate binary so that users can selectively
> upgrade a particular booting stage without re-compiling/re-flashing
> other booting stages.
>
> Various distros and yocto already support building most of the above
> booting stages (U-Boot, OpenSBI, Linux, etc) so we can reuse a lot
> of existing work. Eventually, I am confident we will endup moving
> more stuff from ROM/HSS to U-Boot SPL for ease in maintenance.

Regards,
Bin