On Fri, Aug 26, 2022 at 6:37 AM <padmarao.beg...@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.beg...@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.beg...@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@rtems.org > > > > > http://lists.rtems.org/mailman/listinfo/users > > > _______________________________________________ > > > users mailing list > > > users@rtems.org > > > http://lists.rtems.org/mailman/listinfo/users > _______________________________________________ > users mailing list > users@rtems.org > http://lists.rtems.org/mailman/listinfo/users >
_______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
