From sprhawk at gmail.com  Wed Aug 17 08:39:27 2022
From: sprhawk at gmail.com (Y. HB)
Date: Wed, 17 Aug 2022 16:39:27 +0800
Subject: How can I run RTEMS kernel from SDRAM on TMDX570LC43 HDK?
Message-ID: <CADBJ=yEWd7P5kqbX2ErT4qwBQgYgvRSF_KVr4bXKU6fYM7vU0w@mail.gmail.com>

Hello,

About two weeks ago, I worked in running RTEMS (5.1) on TMS570LC43
Launchxl, and it booted and print via uart.

But when I tried to build CFS on RTEMS, it failed due to not enough memory,
so I bought a TMDX570LC43 HDK with 8MB sdram on it.

As indicated in https://devel.rtems.org/wiki/TBR/BSP/Tms570, due to Flash
has limited erase cycles, it is recommended to run program in SDRAM during
debug and tests.

I have seen SDRAM_SCI_configuration, there is no special code to jump to
RTEMS startup code. In the main(), it is merly setup SCI and EMIF, then
forever loop.

So if I want to run RTEMS in SDRAM after initialization after HALCoGen, how
should I start it ? use some GDB command or write a jump/branch instruction
before "forever loop" in main()?

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20220817/1a385ab1/attachment.htm>

From sprhawk at gmail.com  Wed Aug 17 08:47:50 2022
From: sprhawk at gmail.com (Y. HB)
Date: Wed, 17 Aug 2022 16:47:50 +0800
Subject: How can I run RTEMS kernel from SDRAM on TMDX570LC43 HDK?
In-Reply-To: <CADBJ=yEWd7P5kqbX2ErT4qwBQgYgvRSF_KVr4bXKU6fYM7vU0w@mail.gmail.com>
References: <CADBJ=yEWd7P5kqbX2ErT4qwBQgYgvRSF_KVr4bXKU6fYM7vU0w@mail.gmail.com>
Message-ID: <CADBJ=yFGG-TzSaVE-x7GS05xgoGxfPGR+OB7xhe2EydEuNDS6A@mail.gmail.com>

Is it as easy as "set $pc=0xYYYYYY; continue"  in GDB console ?

On Wed, Aug 17, 2022 at 4:39 PM Y. HB <sprhawk at gmail.com> wrote:

> Hello,
>
> About two weeks ago, I worked in running RTEMS (5.1) on TMS570LC43
> Launchxl, and it booted and print via uart.
>
> But when I tried to build CFS on RTEMS, it failed due to not enough
> memory, so I bought a TMDX570LC43 HDK with 8MB sdram on it.
>
> As indicated in https://devel.rtems.org/wiki/TBR/BSP/Tms570, due to Flash
> has limited erase cycles, it is recommended to run program in SDRAM during
> debug and tests.
>
> I have seen SDRAM_SCI_configuration, there is no special code to jump to
> RTEMS startup code. In the main(), it is merly setup SCI and EMIF, then
> forever loop.
>
> So if I want to run RTEMS in SDRAM after initialization after HALCoGen,
> how should I start it ? use some GDB command or write a jump/branch
> instruction before "forever loop" in main()?
>
> Thanks
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20220817/99066e36/attachment.htm>

From sprhawk at gmail.com  Mon Aug 22 08:36:24 2022
From: sprhawk at gmail.com (Y. HB)
Date: Mon, 22 Aug 2022 16:36:24 +0800
Subject: Failed to start RTEMS on tms570lc4357 loaded from SDRAM
Message-ID: <CADBJ=yH_7SpiyYOUgT5c+UCu+VDna47xf8nSOiXvfDvsJOmFbA@mail.gmail.com>

Hello,

I'm still working on bringing RTEMS on tms570lc43x. Although I can start
RTEMS from tms570 flash, but to minimize flash erase cycles, I want to load
RTEMS from SDRAM like said in RTEMS wiki.

I started a flashed program generated by HalCoGen, and loaded the program
to SDRAM by gdb.

However, when I load program by gdb, and run from 0x80000000(start address
of SDRAM), the code run though start.S, to bsp_start_hook_1, which runs
bsp_start_copy_sections() and bsp_start_clear_bss(), then it runs into
exception.

During Steps, I see the LR register is not set to a valid address
(lr=0x4d18, at the end of work_begin label inside bsp_start_memcpy,
apparently it is not a SDRAM address).

Can anyone give me some hints on how to debug it?

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20220822/e6f25dab/attachment.htm>

From Padmarao.Begari at microchip.com  Wed Aug 24 07:13:56 2022
From: Padmarao.Begari at microchip.com (Padmarao.Begari at microchip.com)
Date: Wed, 24 Aug 2022 07:13:56 +0000
Subject: Want to add RISC-V-based PolarFire SoC support to RTEMS
Message-ID: <b822fa936ccb42b23441d7ec9946f2c804f56330.camel@microchip.com>

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

From peter at awsmtek.com  Wed Aug 24 08:45:17 2022
From: peter at awsmtek.com (=?UTF-8?B?0J/QtdGC0YAg0JHQvtGA0LjRgdC10L3QutC+?=)
Date: Wed, 24 Aug 2022 15:45:17 +0700
Subject: Want to add RISC-V-based PolarFire SoC support to RTEMS
In-Reply-To: <b822fa936ccb42b23441d7ec9946f2c804f56330.camel@microchip.com>
References: <b822fa936ccb42b23441d7ec9946f2c804f56330.camel@microchip.com>
Message-ID: <CANkSPCVTzOoMK_Smn-RpTH_G2urr5cLTbKGMx08JYvqLMG4SPQ@mail.gmail.com>

Wow, I thought I will do it alone soon.
Also interested

Best regards.
Peter Borisenko
Awesome Technologies, Ltd.
http://awsmtek.com
hardware at awsmtek.com
+66826684211


On Wed, Aug 24, 2022 at 2:14 PM <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20220824/97b88953/attachment.htm>

From Padmarao.Begari at microchip.com  Thu Aug 25 05:07:59 2022
From: Padmarao.Begari at microchip.com (Padmarao.Begari at microchip.com)
Date: Thu, 25 Aug 2022 05:07:59 +0000
Subject: Want to add RISC-V-based PolarFire SoC support to RTEMS
In-Reply-To: <CA+wsVCCk9vOig4zFp=L_aiAGyMpgAqYvsvv42UGjM-WWST0sTg@mail.gmail.com>
References: <b822fa936ccb42b23441d7ec9946f2c804f56330.camel@microchip.com>
 <CA+wsVCCk9vOig4zFp=L_aiAGyMpgAqYvsvv42UGjM-WWST0sTg@mail.gmail.com>
Message-ID: <4fb03b527b199fc04dc35cb19f70f5fdf6b1493f.camel@microchip.com>

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

From joel at rtems.org  Thu Aug 25 12:42:00 2022
From: joel at rtems.org (Joel Sherrill)
Date: Thu, 25 Aug 2022 07:42:00 -0500
Subject: Want to add RISC-V-based PolarFire SoC support to RTEMS
In-Reply-To: <4fb03b527b199fc04dc35cb19f70f5fdf6b1493f.camel@microchip.com>
References: <b822fa936ccb42b23441d7ec9946f2c804f56330.camel@microchip.com>
 <CA+wsVCCk9vOig4zFp=L_aiAGyMpgAqYvsvv42UGjM-WWST0sTg@mail.gmail.com>
 <4fb03b527b199fc04dc35cb19f70f5fdf6b1493f.camel@microchip.com>
Message-ID: <CAF9ehCVjrB5UP1qSwuOvh0roOzWX0Mo7NDuuDnXFnhcAQxGY_g@mail.gmail.com>

On Thu, Aug 25, 2022, 12:08 AM <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.
>

You are on a path to create a BSP variant. Share entire files via build
system. Set conditional variables for small things. For larger things just
pick different files.


> Will remove platform-dependent #ifdefs in startup code, is it Ok to
> add CPU dependent #ifdefs?


Where? Usually if they are small sections of code, it's ok in a BSP

Just balance amount shared versus just swapping the file, refactoring a
helper method which can be swapped at the file level, etc

>
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20220825/acdca6e2/attachment.htm>

From Padmarao.Begari at microchip.com  Fri Aug 26 11:37:26 2022
From: Padmarao.Begari at microchip.com (Padmarao.Begari at microchip.com)
Date: Fri, 26 Aug 2022 11:37:26 +0000
Subject: Want to add RISC-V-based PolarFire SoC support to RTEMS
In-Reply-To: <CA+wsVCD7QEkqN=TRkb7=nZkThjZ5VNi3FqWW4tkCRpryGibb9Q@mail.gmail.com>
References: <b822fa936ccb42b23441d7ec9946f2c804f56330.camel@microchip.com>
 <CA+wsVCCk9vOig4zFp=L_aiAGyMpgAqYvsvv42UGjM-WWST0sTg@mail.gmail.com>
 <4fb03b527b199fc04dc35cb19f70f5fdf6b1493f.camel@microchip.com>
 <CA+wsVCD7QEkqN=TRkb7=nZkThjZ5VNi3FqWW4tkCRpryGibb9Q@mail.gmail.com>
Message-ID: <b1366f5e1c11fa14b68dbb921a98965479a2948b.camel@microchip.com>

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.

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

From sebastian.huber at embedded-brains.de  Mon Aug 29 07:30:23 2022
From: sebastian.huber at embedded-brains.de (Sebastian Huber)
Date: Mon, 29 Aug 2022 09:30:23 +0200
Subject: Want to add RISC-V-based PolarFire SoC support to RTEMS
In-Reply-To: <b1366f5e1c11fa14b68dbb921a98965479a2948b.camel@microchip.com>
References: <b822fa936ccb42b23441d7ec9946f2c804f56330.camel@microchip.com>
 <CA+wsVCCk9vOig4zFp=L_aiAGyMpgAqYvsvv42UGjM-WWST0sTg@mail.gmail.com>
 <4fb03b527b199fc04dc35cb19f70f5fdf6b1493f.camel@microchip.com>
 <CA+wsVCD7QEkqN=TRkb7=nZkThjZ5VNi3FqWW4tkCRpryGibb9Q@mail.gmail.com>
 <b1366f5e1c11fa14b68dbb921a98965479a2948b.camel@microchip.com>
Message-ID: <03899b1b-6033-36c4-1c7d-49897f64ae28@embedded-brains.de>

Hello Padmarao,

On 26/08/2022 13:37, Padmarao.Begari at microchip.com wrote:
> 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.

the numbers returned by

static inline uint32_t _CPU_SMP_Get_current_processor( void )
{
   unsigned long mhartid;

   __asm__ volatile (
     ".option push\n"
     ".option arch, +zicsr\n"
     "csrr %0, mhartid\n"
     ".option pop" :
     "=&r" ( mhartid )
   );

   return (uint32_t) mhartid;
}

must be in the range 0, ..., CPU count - 1. For your chip you need 
something like

static inline uint32_t _CPU_SMP_Get_current_processor( void )
{
   unsigned long mhartid;

   __asm__ volatile (
     ".option push\n"
     ".option arch, +zicsr\n"
     "csrr %0, mhartid\n"
     ".option pop" :
     "=&r" ( mhartid )
   );

   return (uint32_t) mhartid + RISCV_MHARTID_OFFSET;
}

The RISCV_MHARTID_OFFSET could be a new CPU option which has 
BSP-dependent default values. It would be the first CPU option in RTEMS 
with BSP-dependent default values.

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht M?nchen
Registernummer: HRB 157899
Vertretungsberechtigte Gesch?ftsf?hrer: Peter Rasmussen, Thomas D?rfler
Unsere Datenschutzerkl?rung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

From Padmarao.Begari at microchip.com  Mon Aug 29 08:51:19 2022
From: Padmarao.Begari at microchip.com (Padmarao.Begari at microchip.com)
Date: Mon, 29 Aug 2022 08:51:19 +0000
Subject: Want to add RISC-V-based PolarFire SoC support to RTEMS
In-Reply-To: <03899b1b-6033-36c4-1c7d-49897f64ae28@embedded-brains.de>
References: <b822fa936ccb42b23441d7ec9946f2c804f56330.camel@microchip.com>
 <CA+wsVCCk9vOig4zFp=L_aiAGyMpgAqYvsvv42UGjM-WWST0sTg@mail.gmail.com>
 <4fb03b527b199fc04dc35cb19f70f5fdf6b1493f.camel@microchip.com>
 <CA+wsVCD7QEkqN=TRkb7=nZkThjZ5VNi3FqWW4tkCRpryGibb9Q@mail.gmail.com>
 <b1366f5e1c11fa14b68dbb921a98965479a2948b.camel@microchip.com>
 <03899b1b-6033-36c4-1c7d-49897f64ae28@embedded-brains.de>
Message-ID: <0f86aa96fbc69b2d7485901fadb40d4fe60cdebe.camel@microchip.com>

Hi Sebastian,

Agree with You,


>    return (uint32_t) mhartid - RISCV_MHARTID_OFFSET;


Want to add "*_MHARTID_OFFSET" a new option in cpu
with "optboothartid.yml".

which name can we choose for this, below are options:

1. "RTEMS_BOOT_HARTID"
2. "RTEMS_RISCV_BOOT_HARTID"
3. "RISCV_MHARTID_OFFSET"
4. "RTEMS_RISCV_MHARTID_OFFSET"

Regards
Padmarao
On Mon, 2022-08-29 at 09:30 +0200, Sebastian Huber wrote:
> 
> Hello Padmarao,
> 
> On 26/08/2022 13:37, Padmarao.Begari at microchip.com wrote:
> > 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.
> 
> the numbers returned by
> 
> static inline uint32_t _CPU_SMP_Get_current_processor( void )
> {
>    unsigned long mhartid;
> 
>    __asm__ volatile (
>      ".option push\n"
>      ".option arch, +zicsr\n"
>      "csrr %0, mhartid\n"
>      ".option pop" :
>      "=&r" ( mhartid )
>    );
> 
>    return (uint32_t) mhartid;
> }
> 
> must be in the range 0, ..., CPU count - 1. For your chip you need
> something like
> 
> static inline uint32_t _CPU_SMP_Get_current_processor( void )
> {
>    unsigned long mhartid;
> 
>    __asm__ volatile (
>      ".option push\n"
>      ".option arch, +zicsr\n"
>      "csrr %0, mhartid\n"
>      ".option pop" :
>      "=&r" ( mhartid )
>    );
> 
>    return (uint32_t) mhartid + RISCV_MHARTID_OFFSET;
> }
> 
> The RISCV_MHARTID_OFFSET could be a new CPU option which has
> BSP-dependent default values. It would be the first CPU option in
> RTEMS
> with BSP-dependent default values.
> 
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.huber at embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
> 
> Registergericht: Amtsgericht M?nchen
> Registernummer: HRB 157899
> Vertretungsberechtigte Gesch?ftsf?hrer: Peter Rasmussen, Thomas
> D?rfler
> Unsere Datenschutzerkl?rung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/

From Jens.Schweikhardt at tesat.de  Mon Aug 29 11:59:56 2022
From: Jens.Schweikhardt at tesat.de (Schweikhardt, Jens (TSPCE6-TL5))
Date: Mon, 29 Aug 2022 11:59:56 +0000
Subject: Unknown task ID "Hefg" seen in thread_switch hook
Message-ID: <d743cfe057394b468cfafe47b22d34b4@BK99MAIL02.bk.local>

hello, world

I?m chasing an observation I can?t explain in RTEMS 5.1 for risc-v on a rocketchip.
The application starts about 10 tasks, none of which with a rtems_build_name(?H?, ?e?, ?f?, ?g?).
We also use the thread_switch extension and record the ID of the next task to be
executed, saving heir->Object.name.name_u32 in a non-volatile place.
This works and usually shows known task IDs, until it doesn?t.
I?ve grepped the RTEMS sources for uses of build_name and don?t see any that use Hefg in any way, shape or form.
Now I?m stumped.
Does this name ring a bell for you? Does RTEMS use ?internal? tasks that we don?t see?
How could the thread_switch hook see such a name?
My only theory at the moment is that a wild pointer messed with the thread object.

Thanks for any insights!
Regards, Jens

________________________________

Tesat-Spacecom GmbH & Co. KG
Sitz: Backnang; Registergericht: Amtsgericht Stuttgart HRA 270977
Persoenlich haftender Gesellschafter: Tesat-Spacecom Geschaeftsfuehrungs GmbH;
Sitz: Backnang; Registergericht: Amtsgericht Stuttgart HRB 271658;
Geschaeftsfuehrung: Thomas Reinartz, Kerstin Basche, Ralph Schmid

[banner]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20220829/f84ed20a/attachment-0001.htm>

From sebastian.huber at embedded-brains.de  Mon Aug 29 12:15:55 2022
From: sebastian.huber at embedded-brains.de (Sebastian Huber)
Date: Mon, 29 Aug 2022 14:15:55 +0200
Subject: Unknown task ID "Hefg" seen in thread_switch hook
In-Reply-To: <d743cfe057394b468cfafe47b22d34b4@BK99MAIL02.bk.local>
References: <d743cfe057394b468cfafe47b22d34b4@BK99MAIL02.bk.local>
Message-ID: <55657492-f35b-6e27-97ae-1dd058a4bdae@embedded-brains.de>



On 29/08/2022 13:59, Schweikhardt, Jens (TSPCE6-TL5) wrote:
> Does this name ring a bell for you? 

No.

> Does RTEMS use ?internal? tasks that 
> we don?t see?

Yes, idle tasks for example.

> 
> How could the thread_switch hook see such a name?

It is in the thread control block. You can inspect the other members to 
figure out which task it is.

> 
> My only theory at the moment is that a wild pointer messed with the 
> thread object.

I would set a write break point to the name member in the thread control 
block to figure out the origin of this name.

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht M?nchen
Registernummer: HRB 157899
Vertretungsberechtigte Gesch?ftsf?hrer: Peter Rasmussen, Thomas D?rfler
Unsere Datenschutzerkl?rung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

From joel at rtems.org  Mon Aug 29 21:18:40 2022
From: joel at rtems.org (Joel Sherrill)
Date: Mon, 29 Aug 2022 16:18:40 -0500
Subject: Want to add RISC-V-based PolarFire SoC support to RTEMS
In-Reply-To: <b1366f5e1c11fa14b68dbb921a98965479a2948b.camel@microchip.com>
References: <b822fa936ccb42b23441d7ec9946f2c804f56330.camel@microchip.com>
 <CA+wsVCCk9vOig4zFp=L_aiAGyMpgAqYvsvv42UGjM-WWST0sTg@mail.gmail.com>
 <4fb03b527b199fc04dc35cb19f70f5fdf6b1493f.camel@microchip.com>
 <CA+wsVCD7QEkqN=TRkb7=nZkThjZ5VNi3FqWW4tkCRpryGibb9Q@mail.gmail.com>
 <b1366f5e1c11fa14b68dbb921a98965479a2948b.camel@microchip.com>
Message-ID: <CAF9ehCXdLaO-aM2jOigCMWLJvF+aL014+vuGFZZm21w7M04dEQ@mail.gmail.com>

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>

From Padmarao.Begari at microchip.com  Tue Aug 30 04:31:27 2022
From: Padmarao.Begari at microchip.com (Padmarao.Begari at microchip.com)
Date: Tue, 30 Aug 2022 04:31:27 +0000
Subject: Want to add RISC-V-based PolarFire SoC support to RTEMS
In-Reply-To: <CAF9ehCXdLaO-aM2jOigCMWLJvF+aL014+vuGFZZm21w7M04dEQ@mail.gmail.com>
References: <b822fa936ccb42b23441d7ec9946f2c804f56330.camel@microchip.com>
 <CA+wsVCCk9vOig4zFp=L_aiAGyMpgAqYvsvv42UGjM-WWST0sTg@mail.gmail.com>
 <4fb03b527b199fc04dc35cb19f70f5fdf6b1493f.camel@microchip.com>
 <CA+wsVCD7QEkqN=TRkb7=nZkThjZ5VNi3FqWW4tkCRpryGibb9Q@mail.gmail.com>
 <b1366f5e1c11fa14b68dbb921a98965479a2948b.camel@microchip.com>
 <CAF9ehCXdLaO-aM2jOigCMWLJvF+aL014+vuGFZZm21w7M04dEQ@mail.gmail.com>
Message-ID: <c31338d23b4edc2b477a0b12f57e699abab18ea0.camel@microchip.com>

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>

From scott at zemericks.com  Wed Aug 31 01:37:23 2022
From: scott at zemericks.com (Scott Zemerick)
Date: Tue, 30 Aug 2022 21:37:23 -0400
Subject: libgcrypt and rtems?
Message-ID: <CADw5qGW8jJ7m3b9n6sDLDFVyFcJi9FZQ3YF6NigLybxXobxkdw@mail.gmail.com>

Hello!  I am interested if anyone has utilized libgcrypt (
https://github.com/gpg/libgcrypt) with rtems?  And as a followup question,
if not libgcrypt, what crypto library are you using successfully?  We ask
because we want to utilize our CryptoLib (
https://github.com/nasa/CryptoLib/wiki) on rtems.  Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20220830/b9d13b26/attachment.htm>

From chrisj at rtems.org  Wed Aug 31 02:23:32 2022
From: chrisj at rtems.org (Chris Johns)
Date: Wed, 31 Aug 2022 12:23:32 +1000
Subject: libgcrypt and rtems?
In-Reply-To: <CADw5qGW8jJ7m3b9n6sDLDFVyFcJi9FZQ3YF6NigLybxXobxkdw@mail.gmail.com>
References: <CADw5qGW8jJ7m3b9n6sDLDFVyFcJi9FZQ3YF6NigLybxXobxkdw@mail.gmail.com>
Message-ID: <c615aa45-8bda-2e77-b367-48fbfc605df9@rtems.org>

On 31/8/2022 11:37 am, Scott Zemerick wrote:
> Hello!? I am interested if anyone has utilized libgcrypt
> (https://github.com/gpg/libgcrypt <https://github.com/gpg/libgcrypt>) with
> rtems?? And as a followup question, if not libgcrypt, what crypto library are
> you using successfully?? We ask because we want to utilize our CryptoLib
> (https://github.com/nasa/CryptoLib/wiki
> <https://github.com/nasa/CryptoLib/wiki>) on rtems.? Thanks!

We have https://git.rtems.org/rtems/tree/cpukit/libcrypt. In libbsd openssl can
be used. I have ported the crypto code from this https://tinyssh.org/.

The GNU library looks to be GPL or LGPL with some 3 clause BSD files and so we
will not include it.

Chris