On Tue, Aug 18, 2020 at 1:23 AM <cyril.j...@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-de...@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 <a...@brainfault.org> wrote: > >>>> On Fri, Aug 14, 2020 at 10:12 PM Bin Meng <bmeng...@gmail.com> wrote: > >>>>> From: Bin Meng <bin.m...@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
