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.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-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 <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
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.
