From: via <qemu-devel@nongnu.org>
To: <anup@brainfault.org>
Cc: <alistair23@gmail.com>, <bmeng.cn@gmail.com>,
<Alistair.Francis@wdc.com>, <kbastian@mail.uni-paderborn.de>,
<palmerdabbelt@google.com>, <sagark@eecs.berkeley.edu>,
<qemu-devel@nongnu.org>, <qemu-riscv@nongnu.org>,
<peter.maydell@linaro.org>, <alistair@alistair23.me>,
<qemu-block@nongnu.org>, <jasowang@redhat.com>,
<bin.meng@windriver.com>, <pbonzini@redhat.com>,
<palmer@dabbelt.com>, <qemu-arm@nongnu.org>,
<marcandre.lureau@redhat.com>, <edgar.iglesias@gmail.com>,
<philmd@redhat.com>
Subject: Re: [PATCH 00/18] hw/riscv: Add Microchip PolarFire SoC Icicle Kit board support
Date: Tue, 18 Aug 2020 13:09:52 +0000 [thread overview]
Message-ID: <1f17cc4c-83f8-a024-ebef-79e28fab9a32@microchip.com> (raw)
In-Reply-To: <CAAhSdy32owLO0KytyYsg-zH6JyyfNfGofa4vanqTFJLntPq0=g@mail.gmail.com>
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.
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?
Regards,
Cyril.
next prev parent reply other threads:[~2020-08-18 13:11 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
2020-08-18 13:09 ` via [this message]
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=1f17cc4c-83f8-a024-ebef-79e28fab9a32@microchip.com \
--to=qemu-devel@nongnu.org \
--cc=Alistair.Francis@wdc.com \
--cc=Cyril.Jean@microchip.com \
--cc=alistair23@gmail.com \
--cc=alistair@alistair23.me \
--cc=anup@brainfault.org \
--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-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).