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

Padmarao.Begari at microchip.com Padmarao.Begari at microchip.com
Tue Aug 30 04:31:27 UTC 2022


On Mon, 2022-08-29 at 16:18 -0500, Joel Sherrill wrote:
On Fri, Aug 26, 2022 at 6:37 AM <Padmarao.Begari at microchip.com<mailto: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.


Hi Joel,

Thank you, trying to implement same with the boot HARTID.

Regards
Padmarao

--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<mailto: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<mailto: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<mailto:users at rtems.org>
> > > > http://lists.rtems.org/mailman/listinfo/users
> > _______________________________________________
> > users mailing list
> > users at rtems.org<mailto:users at rtems.org>
> > http://lists.rtems.org/mailman/listinfo/users
_______________________________________________
users mailing list
users at rtems.org<mailto: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/20220830/b3ea07e0/attachment-0001.htm>


More information about the users mailing list