From: Anup Patel <anup@brainfault.org>
To: Cyril.Jean@microchip.com
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
"Alistair Francis" <alistair@alistair23.me>,
"open list:RISC-V" <qemu-riscv@nongnu.org>,
qemu-block@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@nongnu.org,
"Alistair Francis" <Alistair.Francis@wdc.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Alistair Francis" <alistair23@gmail.com>,
"Bin Meng" <bmeng.cn@gmail.com>,
"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: Tue, 18 Aug 2020 11:47:15 +0530 [thread overview]
Message-ID: <CAAhSdy32owLO0KytyYsg-zH6JyyfNfGofa4vanqTFJLntPq0=g@mail.gmail.com> (raw)
In-Reply-To: <d3f61c2c-a489-887e-0143-4d9a1e66e6f2@microchip.com>
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
next prev parent reply other threads:[~2020-08-18 6:18 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-14 16:40 [PATCH 00/18] hw/riscv: Add Microchip PolarFire SoC Icicle Kit board support Bin Meng
2020-08-14 16:40 ` [PATCH 01/18] target/riscv: cpu: Add a new 'resetvec' property Bin Meng
2020-08-17 17:49 ` Alistair Francis
2020-08-14 16:40 ` [PATCH 02/18] hw/riscv: hart: " Bin Meng
2020-08-17 17:49 ` Alistair Francis
2020-08-14 16:40 ` [PATCH 03/18] target/riscv: cpu: Set reset vector based on the configured property value Bin Meng
2020-08-17 17:52 ` Alistair Francis
2020-08-14 16:40 ` [PATCH 04/18] hw/riscv: Initial support for Microchip PolarFire SoC Icicle Kit board Bin Meng
2020-08-17 19:39 ` Alistair Francis
2020-08-14 16:40 ` [PATCH 05/18] hw/char: Add Microchip PolarFire SoC MMUART emulation Bin Meng
2020-08-17 20:51 ` Alistair Francis
2020-08-14 16:40 ` [PATCH 06/18] hw/riscv: microchip_pfsoc: Connect 5 MMUARTs Bin Meng
2020-08-17 21:06 ` Alistair Francis
2020-08-14 16:40 ` [PATCH 07/18] hw/sd: sd: Fix incorrect populated function switch status data structure Bin Meng
2020-08-15 7:58 ` Philippe Mathieu-Daudé
2020-08-18 16:30 ` Sai Pavan Boddu
2020-08-21 10:09 ` Sai Pavan Boddu
2020-08-21 10:08 ` Bin Meng
2020-08-24 4:13 ` Sai Pavan Boddu
2020-08-14 16:40 ` [PATCH 08/18] hw/sd: sd: Correctly set the high capacity bit Bin Meng
2020-08-15 8:38 ` Philippe Mathieu-Daudé
2020-08-16 8:54 ` Bin Meng
2020-08-14 16:40 ` [PATCH 09/18] hw/sd: sdhci: Make sdhci_poweron_reset() internal visible Bin Meng
2020-08-15 7:51 ` Philippe Mathieu-Daudé
2020-08-16 8:50 ` Bin Meng
2020-08-16 11:06 ` Philippe Mathieu-Daudé
2020-08-14 16:40 ` [PATCH 10/18] hw/sd: Add Cadence SDHCI emulation Bin Meng
2020-08-15 8:51 ` Philippe Mathieu-Daudé
2020-08-14 16:40 ` [PATCH 11/18] hw/riscv: microchip_pfsoc: Connect a Cadence SDHCI controller and an SD card Bin Meng
2020-08-15 8:55 ` Philippe Mathieu-Daudé
2020-08-14 16:40 ` [PATCH 12/18] hw/dma: Add Microchip PolarFire Soc DMA controller emulation Bin Meng
2020-08-14 16:40 ` [PATCH 13/18] hw/riscv: microchip_pfsoc: Connect a DMA controller Bin Meng
2020-08-15 9:00 ` Philippe Mathieu-Daudé
2020-08-16 8:57 ` Bin Meng
2020-08-16 11:08 ` Philippe Mathieu-Daudé
2020-08-14 16:40 ` [PATCH 14/18] hw/net: cadence_gem: Add a new 'phy-addr' property Bin Meng
2020-08-15 9:06 ` Philippe Mathieu-Daudé
2020-08-16 8:29 ` Bin Meng
2020-08-16 11:14 ` Philippe Mathieu-Daudé
2020-08-16 12:08 ` Nathan Rossi
2020-08-16 13:42 ` Bin Meng
2020-08-16 16:31 ` Philippe Mathieu-Daudé
2020-08-14 16:40 ` [PATCH 15/18] hw/riscv: microchip_pfsoc: Connect 2 Cadence GEMs Bin Meng
2020-08-21 18:46 ` Alistair Francis
2020-08-14 16:40 ` [PATCH 16/18] hw/riscv: microchip_pfsoc: Hook GPIO controllers Bin Meng
2020-08-21 18:47 ` Alistair Francis
2020-08-14 16:40 ` [PATCH 17/18] hw/riscv: clint: Avoid using hard-coded timebase frequency Bin Meng
2020-08-25 18:33 ` Alistair Francis
2020-08-14 16:40 ` [PATCH 18/18] hw/riscv: microchip_pfsoc: Document the software used for testing Bin Meng
2020-08-21 18:51 ` Alistair Francis
2020-08-14 17:44 ` [PATCH 00/18] hw/riscv: Add Microchip PolarFire SoC Icicle Kit board support Anup Patel
2020-08-17 10:30 ` Bin Meng
2020-08-17 15:44 ` via
2020-08-17 19:28 ` Alistair Francis
2020-08-17 19:53 ` via
2020-08-18 6:17 ` Anup Patel [this message]
2020-08-18 13:09 ` via
2020-08-18 13:55 ` Anup Patel
2020-08-19 1:34 ` Bin Meng
2020-08-19 10:13 ` via
2020-08-21 18:23 ` Alistair Francis
2020-08-14 18:10 ` no-reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAAhSdy32owLO0KytyYsg-zH6JyyfNfGofa4vanqTFJLntPq0=g@mail.gmail.com' \
--to=anup@brainfault.org \
--cc=Alistair.Francis@wdc.com \
--cc=Cyril.Jean@microchip.com \
--cc=alistair23@gmail.com \
--cc=alistair@alistair23.me \
--cc=bin.meng@windriver.com \
--cc=bmeng.cn@gmail.com \
--cc=edgar.iglesias@gmail.com \
--cc=jasowang@redhat.com \
--cc=kbastian@mail.uni-paderborn.de \
--cc=marcandre.lureau@redhat.com \
--cc=palmer@dabbelt.com \
--cc=palmerdabbelt@google.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@redhat.com \
--cc=qemu-arm@nongnu.org \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-riscv@nongnu.org \
--cc=sagark@eecs.berkeley.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).