Want to add RISC-V-based PolarFire SoC support to RTEMS

[Joel Sherrill]

On Fri, Aug 26, 2022 at 6:37 AM <Padmarao.Begari at microchip.com> wrote:

> Hi Hesham,
>
> The boot HARTID configurable is Ok but I am thinking about SMP.
>
> The PolarFire SoC has 4 U54's with hartid 1,2,3,4 but the SMP
> starts with cpu number '0' to MAX cpu number then the PolarFire
> SoC U54's hartid number should become 0,1,2,3 to run the SMP.
>

Yeah. I think the BSP is going to be responsible for mapping things
so RTEMS can ask for 0..n-1 but the BSP interacts with 1..n. If that
can be done via changing the base number to 0 without messing
anything up, that would be the simplest I think.

--joel


> Regards
> Padmarao
>
> On Thu, 2022-08-25 at 10:05 +0100, Hesham Almatary wrote:
> >
> > Hello Padmarao,
> >
> > I wonder if we can make the boot HARTID configuragle in RTEMS for
> > RISC-V. Something like introducing a new option (e.g.,
> > optboothartid.yml) in the generic RISC-V BSP.
> >
> > On Thu, 25 Aug 2022 at 06:08, <Padmarao.Begari at microchip.com> wrote:
> > > Hi Hesham,
> > >
> > > The generic RISC-V BSP is working on the PolarFire SoC without SMP
> > > but
> > > doesn't work with SMP because it expects first HARTID  should be
> > > '0', t
> > > he PolarFire SoC SMP starts with HARTID '1'(U54) because the HARTID
> > > '0'(E51) reserved for first state booatloader. When the RTEMS is
> > > executing on the PolarFire SoC it reads hartid number with "HARTID-
> > > 1" so that the SMP can start from hartid '0'.
> > >
> > > i.e reason I have added seperate BSP for the PolarFire SoC.
> > >
> > > Yes, there is a lot of code duplication and will try to re-use the
> > > existing code for the PolarFire SoC with modification.
> > >
> > > Will remove platform-dependent #ifdefs in startup code, is it Ok to
> > > add CPU dependent #ifdefs?
> > >
> > > Regards
> > > Padmarao
> > >
> > > On Wed, 2022-08-24 at 11:00 +0100, Hesham Almatary wrote:
> > > > Hello Padmarao,
> > > >
> > > > It would be great to have support for running RTEMS on PolarFire.
> > > >
> > > > I had a quick look at the code. There is a lot of code
> > > > duplications
> > > > already. The generic RISC-V BSP already has SMP, CLINT, PLIC, and
> > > > 16550 support. Why can't this code be shared (i.e., if you use
> > > > the
> > > > riscv/riscv BSP and just provide your FDT)?
> > > >
> > > > I'd also try to avoid introducing platform-dependent #ifdefs in
> > > > shared
> > > > code (e.g., start.S).
> > > >
> > > > Cheers,
> > > > Hesham
> > > >
> > > > On Wed, 24 Aug 2022 at 08:14, <Padmarao.Begari at microchip.com>
> > > > wrote:
> > > > > Hi,
> > > > >
> > > > > I want to add a new BSP for RISC-V-based Microchip PolarFire
> > > > > SoC(MPFS)
> > > > > to RTEMS.
> > > > >
> > > > > The PolarFire SoC is the 4x 64-bit RISC-V U54 cores and a 64-
> > > > > bit
> > > > > RISC-
> > > > > V
> > > > > E51 monitor core SoC from Microchip.
> > > > >
> > > > > The new BSP is added for the U54 cores not for E51 because the
> > > > > E51
> > > > > moniter core is resreved for first stage bootloader (Hart
> > > > > Software
> > > > > Services).
> > > > >
> > > > > This BSP supports below components:
> > > > >
> > > > >     4 CPU Cores (U54)
> > > > >     Interrupt controller (PLIC)
> > > > >     Timer (CLINT)
> > > > >     UART (mmuart, 16550-compatible)
> > > > >
> > > > > We have already done some work on this and tested but not with
> > > > > latest
> > > > > RTEMS source(8th March, 2022 commit) and want to send patches
> > > > > with
> > > > > latest source.
> > > > >
> > > > > https://github.com/polarfire-soc/rtems/tree/mpfs-rtems
> > > > >
> > > > > Regards
> > > > > Padmarao
> > > > > _______________________________________________
> > > > > users mailing list
> > > > > users at rtems.org
> > > > > http://lists.rtems.org/mailman/listinfo/users
> > > _______________________________________________
> > > users mailing list
> > > users at rtems.org
> > > http://lists.rtems.org/mailman/listinfo/users
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20220829/6705d1f1/attachment.htm>