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

[Cyril.Jean]

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.