Re: [PATCH] docs/user: add docs for riscv/kendrytek210 BSP variant

[Padmarao.Begari]

Hi Alan,

> On Wed, 2023-03-29 at 10:32 -0400, Alan Cudmore wrote:
> 
> This patch adds the documentation for building and running RTEMS on
> the Kendryte K210 RISC-V SoC. The generic riscv introducion
> was re-arranged to list the multilib variants then the specific
> hardware targets. In addition a couple of errors were fixed for
> the generic QEMU commands.
> 
> Closes #4876
> ---
>  user/bsps/bsps-riscv.rst | 105 ++---
> --
>  1 file changed, 92 insertions(+), 13 deletions(-)
> 
> diff --git a/user/bsps/bsps-riscv.rst b/user/bsps/bsps-riscv.rst
> index 41f369f..14055d0 100644
> --- a/user/bsps/bsps-riscv.rst
> +++ b/user/bsps/bsps-riscv.rst
> @@ -8,7 +8,7 @@ riscv (RISC-V)
>  riscv
>  =
> 
> -This BSP offers 12 variants:
> +**This BSP offers 10 variants, each corresponding to a GCC
> multilib:**
> 
>  * rv32i
> 
> @@ -30,23 +30,22 @@ This BSP offers 12 variants:
> 
>  * rv64imafdc
> 
> -* frdme310arty
> -
> -* mpfs64imafdc
> -
> -Each rv* variant corresponds to a GCC multilib.  A particular
> variant reflects an
> -ISA with ABI and code model choice. All rv64 BSPs have medany code
> model by
> +Each variant reflects an ISA with ABI and code model choice. All
> rv64 BSPs have medany code model by
>  default, while rv32 BSPs are medlow. The reason is that RV32 medlow
> can access
>  the entire 32-bit address space, while RV64 medlow can only access
> addresses
>  below 0x8000. With RV64 medany, it's possible to perform
> accesses above
> -0x8000.
> +0x8000. The BSP must be started im machine mode.
I think, it is "in machine mode" not "im" 
> +
> +The reference platform for the rv* variants is the QEMU `virt`
> machine.
> +
> +**The BSP also provides the following 3 variants for specific
> hardware targets:**
> 
> -The BSP must be started im machine mode.
> +* frdme310arty - The reference platform for this variant is the Arty
> FPGA board with the Sifive Freedom E310 reference design.
> 
> -The reference platform for this BSP is the QEMU `virt` machine.
> +* mpfs64imafdc - The reference platform for this variant is the
> Microchip PolarFire SoC Icicle Kit.
> +
> +* kendrytek210 - The reference platform for this variant is the
> Kendryte K210 SoC on the Sipeed MAiX Bit or MAiXDuino board.
> 
> -The reference platform for the mpfs64imafdc BSP variant is the
> Microchip
> -PolarFire SoC Icicle Kit.
> 
>  Build Configuration Options
>  ---
> @@ -90,6 +89,9 @@ configuration INI file. The ``waf`` defaults can be
> used to inspect the values.
>   The maximum number of NS16550 devices supported by the console
> driver (2
>   by default).
> 
> +``RISCV_ENABLE_SIFIVE_UART_SUPPORT``
> + Enable the Sifive console UART (disabled by default)
> +
>  ``RISCV_RAM_REGION_BEGIN``
>   The begin of the RAM region for linker command file (default is
> 0x8000).
> 
> @@ -104,6 +106,10 @@ configuration INI file. The ``waf`` defaults can
> be used to inspect the values.
>   Enables support Microchip PolarFire SoC if defined to a non-
> zero
>   value, otherwise it is disabled (disabled by default).
> 
> +``RISCV_ENABLE_KENDRYTE_K210_SUPPORT``
> + Enables support for the Kendtryte K210 SoC if defined to a non-
> zero
> + value, otherwise it is disabled (disabled by default).
> +
>  ``RISCV_BOOT_HARTID``
>   The boot hartid (processor number) of risc-v cpu by default 0.
> 
> @@ -131,7 +137,7 @@ The console driver supports devices compatible to
> 
>  * "ns16750" (see ``RISCV_CONSOLE_MAX_NS16550_DEVICES`` BSP option).
> 
> -* "sifive,uart0" (see ``RISCV_ENABLE_FRDME310ARTY_SUPPORT`` BSP
> option).
> +* "sifive,uart0" (see ``RISCV_ENABLE_SIFIVE_UART_SUPPORT`` BSP
> option). This console driver is used by the frdme310arty and
> kendrytek210 BSP variants.
> 
>  They are initialized according to the device tree.  The console
> driver does not
>  configure the pins or peripheral clocks.  The console device is
> selected
> @@ -145,11 +151,13 @@ and spike machines. For instance, to run the
> ``rv64imafdc`` BSP with the
>  following "config.ini" file.
> 
>  .. code-block:: none
> +
>  [riscv/rv64imafdc]
> 
>  Run the following QEMU command.
> 
>  .. code-block:: shell
> +
>  $ qemu-system-riscv64 -M virt -nographic -bios $RTEMS_EXE
>  $ qemu-system-riscv64 -M spike -nographic -bios $RTEMS_EXE
> 
> @@ -160,11 +168,13 @@ For instance, to run the ``rv64imafdc`` BSP
> with the following
>  "config.ini" file.
> 
>  .. code-block:: none
> +
>  [riscv/rv64imafdc]
> 
>  Run the following Spike command.
> 
>  .. code-block:: shell
> +
>  $ spike --isa=rv64imafdc $RTEMS_EXE
> 
>  Unlike QEMU, Spike supports enabling/disabling a subset of the
> imafdc extensions
> @@ -277,6 +287,75 @@ Serial terminal UART1 displays the SMP example
> messages
> 
>  *** END OF TEST SMP 1 ***
> 
> +Kendryte K210
> +-
> +
> +The Kendryte K210 SoC is a dual core 64-bit RISC-V SoC with an AI
> NPU,
> +built in SRAM, and a variety 

Re: [PATCH 1/3] bsps/riscv: Make SMP start more robust

[Padmarao.Begari]

> On Thu, 2023-03-16 at 09:59 +0100, Sebastian Huber wrote:
> 
> In SMP configurations, check that we run on a configured
> processor.  If not,
> then there is not much what can be done since we do not have a stack
> available
> for this processor.  Just loop forever in this case.  Do this in
> assemlby to
> ensure that no stack memory is used.

I have tested it on the Microchip PolarFire SoC Icicle Kit and working
fine.

Regards
Padmarao
> ---
>  bsps/riscv/riscv/start/bspsmp.c |  5 +
>  bsps/riscv/shared/start/start.S | 16 ++--
>  2 files changed, 15 insertions(+), 6 deletions(-)
> 
> diff --git a/bsps/riscv/riscv/start/bspsmp.c
> b/bsps/riscv/riscv/start/bspsmp.c
> index 91f4f7b96a..ce5792f5b8 100644
> --- a/bsps/riscv/riscv/start/bspsmp.c
> +++ b/bsps/riscv/riscv/start/bspsmp.c
> @@ -36,10 +36,7 @@ void
> bsp_start_on_secondary_processor(Per_CPU_Control *cpu_self)
> 
>cpu_index_self = _Per_CPU_Get_index(cpu_self);
> 
> -  if (
> -cpu_index_self < rtems_configuration_get_maximum_processors()
> -  && _SMP_Should_start_processor(cpu_index_self)
> -  ) {
> +  if (_SMP_Should_start_processor(cpu_index_self)) {
>  set_csr(mie, MIP_MSIP | MIP_MEIP);
>  _SMP_Start_multitasking_on_secondary_processor(cpu_self);
>} else {
> diff --git a/bsps/riscv/shared/start/start.S
> b/bsps/riscv/shared/start/start.S
> index 34e1839ca1..42e4348cd0 100644
> --- a/bsps/riscv/shared/start/start.S
> +++ b/bsps/riscv/shared/start/start.S
> @@ -66,8 +66,17 @@ SYM(_start):
> LADDR   sp, _ISR_Stack_area_begin
> LADDR   t2, _ISR_Stack_size
> csrrs0, mhartid
> -   li  t3, RISCV_BOOT_HARTID
> -   sub s0, s0, t3
> +   li  t3, RISCV_BOOT_HARTID
> +   sub s0, s0, t3
> +
> +   /*
> +* Check that this is a configured processor.  If not, then
> there is
> +* not much what can be done since we do not have a stack
> available for
> +* this processor.  Just loop forever in this case.
> +*/
> +   LREGt3, _SMP_Processor_configured_maximum
> +   bgeus0, t3, .Lwfi
> +
> LADDR   t0, _Per_CPU_Information
> sllit1, s0, PER_CPU_CONTROL_SIZE_LOG2
> add s1, t0, t1
> @@ -100,6 +109,9 @@ SYM(_start):
> tailboot_card
> 
>  #ifdef RTEMS_SMP
> +.Lwfi:
> +   wfi
> +   j   .Lwfi
> 
>  .Lstart_on_secondary_processor:
> 
> --
> 2.35.3
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 0/3] bsps/riscv: Add kendrytek210 riscv BSP variant

[Padmarao.Begari]

I have tested it on the renode.io simulator and working fine.

Regards
Padmarao
> On Wed, 2023-03-15 at 22:04 -0400, Alan Cudmore wrote:
> 
> Version 2 patch updates: Separated the device tree source and encoded
> device tree blob into a separate patch, added the license text to
> k210.h, eliminated whitespace warnings, and eliminated dead code in
> the conditional compilation structure for the core_get_frequency
> function in start/bspstart.c.
> 
> This patch set adds the riscv/kendrytek210 BSP variant to support the
> Kendryte K210 Dual Core RISC-V SoC. The BSP runs on the renode.io
> simulator, the Sipeed MAiX BiT and MAiXDuino boards, and would likely
> run on other boards. RTEMS binaries can be flashed to the boards
> using
> the kflash python utility available through the pip command.
> Currently
> the BSP supports the console UART which is shared with the
> frdme310arty,
> an interrupt controller, and timer. The included device tree source
> just covers a minimal set of peripherals. The device tree can be
> expanded as additional device support is addded.
> Manufacturer, board links, and other information can be found in
> ticket #4876.
> 
> Documentation that describes how to build and run the BSP on the
> boards and simulator has been prepared and will be submitted after
> the bsp
> is merged.
> 
> The full testsuite has not been run on this BSP, but I run a
> subset of the of testsuite on the renode.io robot test framework.
> 
> Alan Cudmore (3):
>   bsps/riscv: add device tree source and device tree blob header for
> k210 bsp variant
>   bsps/riscv: add riscv/kendrytek210 BSP variant source changes
>   spec: add riscv kendrytek210 variant build options
> 
>  bsps/riscv/riscv/config/kendrytek210.cfg  |   9 +
>  bsps/riscv/riscv/console/console-config.c |  10 +-
>  bsps/riscv/riscv/console/fe310-uart.c |   2 +-
>  bsps/riscv/riscv/dts/kendryte-k210.dts| 216 
>  bsps/riscv/riscv/include/bsp.h|   4 +
>  bsps/riscv/riscv/include/bsp/k210.h   | 105 ++
>  .../riscv/include/bsp/kendryte-k210-dtb.h | 315
> ++
>  bsps/riscv/riscv/include/bsp/riscv.h  |   4 +
>  bsps/riscv/riscv/start/bspstart.c |  43 +++
>  spec/build/bsps/optdtb.yml|   4 +-
>  spec/build/bsps/optdtbheaderpath.yml  |   2 +
>  spec/build/bsps/optfdtuboot.yml   |   3 +
>  spec/build/bsps/riscv/optramsize.yml  |   2 +
>  spec/build/bsps/riscv/riscv/abi.yml   |   1 +
>  .../bsps/riscv/riscv/bspkendrtyek210.yml  |  19 ++
>  spec/build/bsps/riscv/riscv/grp.yml   |   4 +
>  spec/build/bsps/riscv/riscv/obj.yml   |   1 +
>  .../bsps/riscv/riscv/optkendrytek210.yml  |  18 +
>  spec/build/bsps/riscv/riscv/optns16550max.yml |   4 +-
>  spec/build/bsps/riscv/riscv/optsifiveuart.yml |  20 ++
>  spec/build/cpukit/optsmp.yml  |   1 +
>  21 files changed, 779 insertions(+), 8 deletions(-)
>  create mode 100644 bsps/riscv/riscv/config/kendrytek210.cfg
>  create mode 100644 bsps/riscv/riscv/dts/kendryte-k210.dts
>  create mode 100644 bsps/riscv/riscv/include/bsp/k210.h
>  create mode 100644 bsps/riscv/riscv/include/bsp/kendryte-k210-dtb.h
>  create mode 100644 spec/build/bsps/riscv/riscv/bspkendrtyek210.yml
>  create mode 100644 spec/build/bsps/riscv/riscv/optkendrytek210.yml
>  create mode 100644 spec/build/bsps/riscv/riscv/optsifiveuart.yml
> 
> --
> 2.25.1
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsps/riscv: Clear interrupt complete before disable

[Padmarao.Begari]

> On Tue, 2023-03-14 at 13:37 +0100, Sebastian Huber wrote:
> 
> On 14.03.23 13:31, padmarao.beg...@microchip.com wrote:
> > Hi Sebastian,
> > 
> > > On Mon, 2023-03-06 at 14:11 +0100, Sebastian Huber wrote:
> > > 
> > > 
> > > On 06.03.23 13:00,padmarao.beg...@microchip.com  wrote:
> > > > > On Mon, 2023-03-06 at 11:19 +0100, Sebastian Huber wrote:
> > > > > 
> > > > > On 06.03.23 10:24,padmarao.beg...@microchip.com   wrote:
> > > > > > Hi Sebastian,
> > > > > > 
> > > > > > > On Mon, 2023-03-06 at 09:41 +0100, Sebastian Huber wrote:
> > > > > > > 
> > > > > > > On 06.03.23 09:37,padmarao.beg...@microchip.com   wrote:
> > > > > > > > > Is
> > > > > > > > > the claim complete message ignored if the interrupt
> > > > > > > > > is
> > > > > > > > > disabled?
> > > > > > > > > 
> > > > > > > > Yes.
> > > > > > > Is this an intended and documented behaviour of the PLIC?
> > > > > > Not documented
> > > > > Is this a common PLIC behaviour or just the case for the
> > > > > MicroChip
> > > > > implementation?
> > > > > 
> > > > It's a common PLIC behaviour.
> > > It is not implemented in the Qemu PLIC emulation:
> > > 
> > > https://github.com/qemu/qemu/blob/master/hw/intc/sifive_plic.c#L242
> > > 
> > > Where do I see this behaviour in a PLIC implementation, for
> > > example:
> > > 
> > > https://github.com/lowRISC/opentitan/tree/master/hw/ip_templates/rv_plic
> > > 
> > > That the interrupt completion depends on the interrupt
> > > enable/disable
> > > status is quite unusual.
> > > 
> > https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc#8-interrupt-completion
> > The interrupt is completed only when the interrupt is enabled but
> > not
> > when disabled.
> > 
> > Can we clear the interrupt before calling the interrupt handler?
> > like
> > below
> > https://github.com/RTEMS/rtems/blob/master/bsps/riscv/riscv/irq/irq.c#L90
> > 
> >  while ((interrupt_index = plic_hart_regs->claim_complete) !=
> > 0) {
> > + plic_hart_regs->claim_complete = interrupt_index;
> >bsp_interrupt_handler_dispatch(
> >  RISCV_INTERRUPT_VECTOR_EXTERNAL(interrupt_index)
> >);
> > 
> > -  plic_hart_regs->claim_complete = interrupt_index;
> > 
> > Also refer
> > https://github.com/psherman42/Demonstrating-MTVEC/blob/main/start.s#L307
> 
> At some point I would like to enable support for nested interrupts. I
> guess in this case it is important that you complete the interrupt
> after
> processing.
> 
The Exception(trap) handler is called when an interrupt occurs and the
global interrupt(mie) is disabled automatically at the top-most
level–the MIE bit in mstatus and re-enabled after return from machine
interrupt instruction "mret".

I think, we will not get any other interrupt while servicing the
interrupt handler, we can use the interrupt complete before processing.

Regards
Padmarao

> Ideally, we would return a status in the interrupt handlers to
> support
> things like the PLIC, however, this would be an API change affecting
> all
> existing interrupt handlers. This is not an option from my side.
> 
> I would add new BSP interrupt controller methods specifically for the
> interrupt server. By default, they do nothing. For the PLIC they do
> the
> enable and complete once the server task did process the interrupt.
> 
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@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/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsps/riscv: Clear interrupt complete before disable

[Padmarao.Begari]

Hi Sebastian,

>On Mon, 2023-03-06 at 14:11 +0100, Sebastian Huber wrote:
> 
> 
> On 06.03.23 13:00, padmarao.beg...@microchip.com wrote:
> > > On Mon, 2023-03-06 at 11:19 +0100, Sebastian Huber wrote:
> > > 
> > > On 06.03.23 10:24,padmarao.beg...@microchip.com  wrote:
> > > > Hi Sebastian,
> > > > 
> > > > > On Mon, 2023-03-06 at 09:41 +0100, Sebastian Huber wrote:
> > > > > 
> > > > > On 06.03.23 09:37,padmarao.beg...@microchip.com  wrote:
> > > > > > > Is
> > > > > > > the claim complete message ignored if the interrupt is
> > > > > > > disabled?
> > > > > > > 
> > > > > > Yes.
> > > > > Is this an intended and documented behaviour of the PLIC?
> > > > Not documented
> > > Is this a common PLIC behaviour or just the case for the
> > > MicroChip
> > > implementation?
> > > 
> > It's a common PLIC behaviour.
> 
> It is not implemented in the Qemu PLIC emulation:
> 
> https://github.com/qemu/qemu/blob/master/hw/intc/sifive_plic.c#L242
> 
> Where do I see this behaviour in a PLIC implementation, for example:
> 
> https://github.com/lowRISC/opentitan/tree/master/hw/ip_templates/rv_plic
> 
> That the interrupt completion depends on the interrupt enable/disable
> status is quite unusual.
> 

https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc#8-interrupt-completion
The interrupt is completed only when the interrupt is enabled but not
when disabled.

Can we clear the interrupt before calling the interrupt handler? like
below
https://github.com/RTEMS/rtems/blob/master/bsps/riscv/riscv/irq/irq.c#L90

while ((interrupt_index = plic_hart_regs->claim_complete) != 0) {
+ plic_hart_regs->claim_complete = interrupt_index;
  bsp_interrupt_handler_dispatch(
RISCV_INTERRUPT_VECTOR_EXTERNAL(interrupt_index)
  );

-  plic_hart_regs->claim_complete = interrupt_index;

Also refer 
https://github.com/psherman42/Demonstrating-MTVEC/blob/main/start.s#L307

Regards
Padmarao

> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@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/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsps/riscv: Clear interrupt complete before disable

[Padmarao.Begari]

> On Mon, 2023-03-06 at 14:11 +0100, Sebastian Huber wrote:
> 
> On 06.03.23 13:00, padmarao.beg...@microchip.com wrote:
> > > On Mon, 2023-03-06 at 11:19 +0100, Sebastian Huber wrote:
> > > 
> > > On 06.03.23 10:24,padmarao.beg...@microchip.com  wrote:
> > > > Hi Sebastian,
> > > > 
> > > > > On Mon, 2023-03-06 at 09:41 +0100, Sebastian Huber wrote:
> > > > > 
> > > > > On 06.03.23 09:37,padmarao.beg...@microchip.com  wrote:
> > > > > > > Is
> > > > > > > the claim complete message ignored if the interrupt is
> > > > > > > disabled?
> > > > > > > 
> > > > > > Yes.
> > > > > Is this an intended and documented behaviour of the PLIC?
> > > > Not documented
> > > Is this a common PLIC behaviour or just the case for the
> > > MicroChip
> > > implementation?
> > > 
> > It's a common PLIC behaviour.
> 
> It is not implemented in the Qemu PLIC emulation:
> 
> https://github.com/qemu/qemu/blob/master/hw/intc/sifive_plic.c#L242
> 
> Where do I see this behaviour in a PLIC implementation, for example:
> 
> https://github.com/lowRISC/opentitan/tree/master/hw/ip_templates/rv_plic
> 
> That the interrupt completion depends on the interrupt enable/disable
> status is quite unusual.
> 

I will look into above links, mean while you can check the implemention
of external interrupt service in the PolarFire SoC with same the siFive
PLIC core.

https://github.com/polarfire-soc/hart-software-services/blob/master/baremetal/polarfire-soc-bare-metal-library/src/platform/mpfs_hal/common/mss_mtrap.c#L623

Regards
Padmarao
  
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@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/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsps/riscv: Clear interrupt complete before disable

[Padmarao.Begari]

> On Mon, 2023-03-06 at 11:19 +0100, Sebastian Huber wrote:
> 
> On 06.03.23 10:24, padmarao.beg...@microchip.com wrote:
> > Hi Sebastian,
> > 
> > > On Mon, 2023-03-06 at 09:41 +0100, Sebastian Huber wrote:
> > > 
> > > On 06.03.23 09:37, padmarao.beg...@microchip.com wrote:
> > > > > Is
> > > > > the claim complete message ignored if the interrupt is
> > > > > disabled?
> > > > > 
> > > > Yes.
> > > 
> > > Is this an intended and documented behaviour of the PLIC?
> > 
> > Not documented
> 
> Is this a common PLIC behaviour or just the case for the MicroChip
> implementation?
> 

It's a common PLIC behaviour.

Regards
Padmarao

> > >   This is a
> > > hardware bug from my point of view. If we really need a software
> > > workround just for the PLIC to work with the interrupt server,
> > > then
> > > we
> > > should add a new function for this and keep the interrupt disable
> > > as
> > > is.
> > 
> > Ok
> 
> You could for example add a bsp_interrupt_vector_server_disable()
> which
> defaults to bsp_interrupt_vector_disable().
> 
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@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/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsps/riscv: Clear interrupt complete before disable

[Padmarao.Begari]

Hi Sebastian,

> On Mon, 2023-03-06 at 09:41 +0100, Sebastian Huber wrote:
> 
> On 06.03.23 09:37, padmarao.beg...@microchip.com wrote:
> > > Is
> > > the claim complete message ignored if the interrupt is disabled?
> > > 
> > Yes.
> 
> Is this an intended and documented behaviour of the PLIC?

Not documented
>  This is a
> hardware bug from my point of view. If we really need a software
> workround just for the PLIC to work with the interrupt server, then
> we
> should add a new function for this and keep the interrupt disable as
> is.

Ok

Regards
Padmarao
> 
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@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/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsps/riscv: Clear interrupt complete before disable

[Padmarao.Begari]

Hi Sebastian,

> On Mon, 2023-03-06 at 08:01 +0100, Sebastian Huber wrote:
> 
> Hello Padmarao,
> 
> On 03.03.23 15:55, padmarao.beg...@microchip.com wrote:
> > > On Thu, 2023-03-02 at 15:18 +0100, Sebastian Huber wrote:
> > > 
> > > 
> > > On 27.02.23 16:51, Padmarao Begari wrote:
> > > > The interrupt complete should clear with the interrupt
> > > > number before disabling the interrupt in the PLIC to
> > > > get the next interrupt.
> > > Which problem does this patch address?
> > > 
> > The problem occurs when the interrupt register(enabled) in the
> > RTEMS-
> > LIBBSD drivers and want to serve the interrupt subroutine in the
> > RTEMS.
> > 
> > Example : CGEM driver
> > 
> > When the application running to test the CGEM driver with RTEMS +
> > RTEMS-LIBBSD, The interrupt is occurred while transmiting the
> > ethernet
> > pocket, the RTEMS is received the interrupt but not served with the
> > register interrupt subroutine instead it disable the interrupt and
> > set
> > the "RTEMS_EVENT_SYSTEM_SERVER", while completing the ISR it is
> > clearing the interrupt complete register but there is no effect and
> > the
> > next transmit pocket intereupt is not occurred because the
> > interrupt is
> > disabled before the interrupt complete clear.
> > 
> > RISC-V interrupt stacktrace
> > **
> > _RISCV_Exception_handler()
> > _RISCV_Interrupt_dispatch()
> > bsp_interrupt_handler_dispatch_unchecked()
> > bsp_interrupt_dispatch_entries()
> >   ( *entry->handler )( entry->arg ); ->
> > bsp_interrupt_server_trigger()
> > bsp_interrupt_server_trigger()
> > bsp_interrupt_is_valid_vector()
> > bsp_interrupt_vector_disable()
> > rtems_event_system_send()
> > *
> 
> The claim complete register is written after the interrupt handler
> dispatch:
> 
>  while ((interrupt_index = plic_hart_regs->claim_complete) != 0)
> {
>bsp_interrupt_handler_dispatch(
>  RISCV_INTERRUPT_VECTOR_EXTERNAL(interrupt_index)
>);
> 
>plic_hart_regs->claim_complete = interrupt_index;
> 
> If you write to the claim complete register also in the interrupt
> disable function, then this write is done twice.
> 
Yes but no impact on second write.
> The interrupt disable function may be used in other contexts as well
> so
> doing a write to the claim complete register may have unexpected side
> effects.
> 
> We should first figure out why the current implementation which works
> with several other interrupt controllers doesn't work with the PLIC. 

Current Implemtation is working fine for UART, Timer because the ISR is
installed at the RTEMS source and when the interrupt is occured it is
going to call the ISR and clear the interrupt complete but not disable
the interrupt.

> Is
> the claim complete message ignored if the interrupt is disabled?
> 

Yes.


Regards
Padmarao

> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@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/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsps/riscv: Clear interrupt complete before disable

[Padmarao.Begari]

Hi Sebastian,

> On Thu, 2023-03-02 at 15:18 +0100, Sebastian Huber wrote:
> 
> 
> On 27.02.23 16:51, Padmarao Begari wrote:
> > The interrupt complete should clear with the interrupt
> > number before disabling the interrupt in the PLIC to
> > get the next interrupt.
> 
> Which problem does this patch address?
> 

The problem occurs when the interrupt register(enabled) in the RTEMS-
LIBBSD drivers and want to serve the interrupt subroutine in the RTEMS.

Example : CGEM driver

When the application running to test the CGEM driver with RTEMS +
RTEMS-LIBBSD, The interrupt is occurred while transmiting the ethernet
pocket, the RTEMS is received the interrupt but not served with the
register interrupt subroutine instead it disable the interrupt and set
the "RTEMS_EVENT_SYSTEM_SERVER", while completing the ISR it is
clearing the interrupt complete register but there is no effect and the
next transmit pocket intereupt is not occurred because the interrupt is
disabled before the interrupt complete clear.

RISC-V interrupt stacktrace
**
_RISCV_Exception_handler()
_RISCV_Interrupt_dispatch()
bsp_interrupt_handler_dispatch_unchecked()
bsp_interrupt_dispatch_entries()
 ( *entry->handler )( entry->arg ); -> bsp_interrupt_server_trigger()
bsp_interrupt_server_trigger()
bsp_interrupt_is_valid_vector()
bsp_interrupt_vector_disable()
rtems_event_system_send()
*

Regards
Padmarao 

--
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@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/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-libbsd 3/3] freebsd/cgem: Add weak symbol for riscv

[Padmarao.Begari]

Hi will,

> On Wed, 2023-03-01 at 08:27 -0600, Will wrote:
>   
> This functionality is ideally implemented in a platform-specific
> system level control register (SLCR) driver similar to ZynqMP and
> Versal. You could also just leave it as-is since the default does
> exactly the same thing. This patch should be dropped unless you're
> going to define an implementation that will actually set the
> reference clock.
> 
Ok, will drop this patch.

Regards
Padmarao
> On Tue, Feb 28, 2023 at 11:57 PM Padmarao Begari <
> padmarao.beg...@microchip.com> wrote:
> > Add __weak_symbol instead of __weak_reference for the
> > cgem_set_ref_clk() function for riscv build.
> > ---
> >  freebsd/sys/dev/cadence/if_cgem.c | 7 +++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/freebsd/sys/dev/cadence/if_cgem.c
> > b/freebsd/sys/dev/cadence/if_cgem.c
> > index 363a9717..a12f7b43 100644
> > --- a/freebsd/sys/dev/cadence/if_cgem.c
> > +++ b/freebsd/sys/dev/cadence/if_cgem.c
> > @@ -1764,6 +1764,12 @@ cgem_miibus_linkchg(device_t dev)
> >   * Overridable weak symbol cgem_set_ref_clk().  This allows
> > platforms to
> >   * provide a function to set the cgem's reference clock.
> >   */
> > +#ifdef __riscv
> > +__weak_symbol int cgem_set_ref_clk(int unit, int frequency)
> > +{
> > +   return 0;
> > +}
> > +#else
> >  static int __used
> >  cgem_default_set_ref_clk(int unit, int frequency)
> >  {
> > @@ -1771,6 +1777,7 @@ cgem_default_set_ref_clk(int unit, int
> > frequency)
> > return 0;
> >  }
> >  __weak_reference(cgem_default_set_ref_clk, cgem_set_ref_clk);
> > +#endif /* __riscv */
> > 
> >  /* Call to set reference clock and network config bits according
> > to media. */
> >  static void
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-libbsd 2/3] freebsd/cgem: Read clock frequency from device tree

[Padmarao.Begari]

Hi will,

> On Wed, 2023-03-01 at 08:20 -0600, Will wrote:
>   
> On Tue, Feb 28, 2023 at 11:57 PM Padmarao Begari <
> padmarao.beg...@microchip.com> wrote:
> > Read the clock frequency from the device tree and use it to
> > calculate the mdc clock divider for the MII bus if not found
> > then use default clock divider.
> > ---
> >  freebsd/sys/dev/cadence/if_cgem.c | 39
> > ---
> >  1 file changed, 36 insertions(+), 3 deletions(-)
> > 
> > diff --git a/freebsd/sys/dev/cadence/if_cgem.c
> > b/freebsd/sys/dev/cadence/if_cgem.c
> > index 2888a085..363a9717 100644
> > --- a/freebsd/sys/dev/cadence/if_cgem.c
> > +++ b/freebsd/sys/dev/cadence/if_cgem.c
> > @@ -135,6 +135,7 @@ struct cgem_softc {
> > uint32_tnet_cfg_shadow;
> > int neednullqs;
> > int phy_contype;
> > +   uint32_tpclk_rate;
> >  #endif /* __rtems__ */
> > int ref_clk_num;
> >  #ifndef __rtems__
> > @@ -1238,6 +1239,27 @@ cgem_get_phyaddr(phandle_t node, int
> > *phy_addr)
> > return (0);
> >  }
> > 
> > +static uint32_t cgem_mdc_clk_div(struct cgem_softc *sc)
> > +{
> > +   uint32_t config;
> > +   uint32_t pclk_hz = sc->pclk_rate;
> > +
> > +   if (pclk_hz <= 2000)
> > +   config = CGEM_NET_CFG_MDC_CLK_DIV_8;
> > +   else if (pclk_hz <= 4000)
> > +   config = CGEM_NET_CFG_MDC_CLK_DIV_16;
> > +   else if (pclk_hz <= 8000)
> > +   config = CGEM_NET_CFG_MDC_CLK_DIV_32;
> > +   else if (pclk_hz <= 12000)
> > +   config = CGEM_NET_CFG_MDC_CLK_DIV_48;
> > +   else if (pclk_hz <= 16000)
> > +   config = CGEM_NET_CFG_MDC_CLK_DIV_64;
> > +   else
> > +   config = CGEM_NET_CFG_MDC_CLK_DIV_96;
> > +
> > +   return config;
> > +}
> > +
> > 
> 
> Enclose this in a #ifdef __rtems__ guard. I think the suggested style
> is to always use braces {} with if/else, even if it's a single line.
>  
Ok, will update

Regards
Padmarao
> >  /* Reset hardware. */
> >  static void
> >  cgem_reset(struct cgem_softc *sc)
> > @@ -1279,12 +1301,16 @@ cgem_reset(struct cgem_softc *sc)
> > sc->net_cfg_shadow = CGEM_NET_CFG_DBUS_WIDTH_32;
> > }
> > 
> > +   if (sc->pclk_rate != 0) {
> > +   sc->net_cfg_shadow |= cgem_mdc_clk_div(sc);
> > +   } else {
> >  #ifdef CGEM64
> > -   sc->net_cfg_shadow |= CGEM_NET_CFG_MDC_CLK_DIV_48;
> > +   sc->net_cfg_shadow |= CGEM_NET_CFG_MDC_CLK_DIV_48;
> >  #else
> > -   sc->net_cfg_shadow |= CGEM_NET_CFG_MDC_CLK_DIV_64;
> > +   sc->net_cfg_shadow |= CGEM_NET_CFG_MDC_CLK_DIV_64;
> >  #endif
> > -   WR4(sc, CGEM_NET_CFG, sc->net_cfg_shadow);
> > +   WR4(sc, CGEM_NET_CFG, sc->net_cfg_shadow);
> > +   }
> >  #endif /* __rtems__ */
> > 
> > sc->net_ctl_shadow = CGEM_NET_CTRL_MGMT_PORT_EN;
> > @@ -2038,6 +2064,13 @@ cgem_attach(device_t dev)
> >  #endif /* __rtems__ */
> > /* Get reference clock number and base divider from fdt. */
> > node = ofw_bus_get_node(dev);
> > +#ifdef __rtems__
> > +   if (OF_getencprop(node, "clock-frequency", ,
> > sizeof(cell)) > 0)
> > +   sc->pclk_rate = cell;
> > +   else
> > +   sc->pclk_rate = 0;
> > +#endif /* __rtems__ */
> > +
> > sc->ref_clk_num = 0;
> > if (OF_getprop(node, "ref-clock-num", , sizeof(cell))
> > > 0)
> > sc->ref_clk_num = fdt32_to_cpu(cell);
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-libbsd 1/3] freebsd/cgem: Add phy address to read it from device tree

[Padmarao.Begari]

Hi Will,

Thanks for review comments.

> On Wed, 2023-03-01 at 08:10 -0600, Will wrote:
>   
> On Tue, Feb 28, 2023 at 11:57 PM Padmarao Begari <
> padmarao.beg...@microchip.com> wrote:
> > Read the phy address from the device tree and use it to
> > find the phy device if not found then search in the
> > range of 0 to 31.
> > ---
> >  freebsd/sys/dev/cadence/if_cgem.c | 41
> > ---
> >  1 file changed, 37 insertions(+), 4 deletions(-)
> > 
> > diff --git a/freebsd/sys/dev/cadence/if_cgem.c
> > b/freebsd/sys/dev/cadence/if_cgem.c
> > index 689c3611..2888a085 100644
> > --- a/freebsd/sys/dev/cadence/if_cgem.c
> > +++ b/freebsd/sys/dev/cadence/if_cgem.c
> > @@ -1217,6 +1217,27 @@ cgem_intr(void *arg)
> > CGEM_UNLOCK(sc);
> >  }
> > 
> > +static int
> > +cgem_get_phyaddr(phandle_t node, int *phy_addr)
> > +{
> > +   phandle_t phy_node;
> > +   pcell_t phy_handle, phy_reg;
> > +
> > +   if (OF_getencprop(node, "phy-handle", (void *)_handle,
> > +   sizeof(phy_handle)) <= 0)
> > +   return (ENXIO);
> > +
> > +   phy_node = OF_node_from_xref(phy_handle);
> > +
> > +   if (OF_getencprop(phy_node, "reg", (void *)_reg,
> > +   sizeof(phy_reg)) <= 0)
> > +   return (ENXIO);
> > +
> > +   *phy_addr = phy_reg;
> > +
> > +   return (0);
> > +}
> > +
> > 
> 
> All changes should be gated behind #ifdef __rtems__, even if they're
> backports from upstream.
> 
Ok, will update
>  
> >  /* Reset hardware. */
> >  static void
> >  cgem_reset(struct cgem_softc *sc)
> > @@ -2003,6 +2024,7 @@ cgem_attach(device_t dev)
> > pcell_t cell;
> > int rid, err;
> > u_char eaddr[ETHER_ADDR_LEN];
> > +   int phy_addr;
> > 
> 
> Same here.
>  
> > sc->dev = dev;
> > CGEM_LOCK_INIT(sc);
> > @@ -2091,10 +2113,21 @@ cgem_attach(device_t dev)
> > cgem_reset(sc);
> > CGEM_UNLOCK(sc);
> > 
> > -   /* Attach phy to mii bus. */
> > -   err = mii_attach(dev, >miibus, ifp,
> > -cgem_ifmedia_upd, cgem_ifmedia_sts,
> > -BMSR_DEFCAPMASK, MII_PHY_ANY,
> > MII_OFFSET_ANY, 0);
> > +   err = cgem_get_phyaddr(node, _addr);
> > +   if (err == 0) {
> > +   /* Attach phy to mii bus. */
> > +   err = mii_attach(dev, >miibus, ifp,
> > +cgem_ifmedia_upd,
> > cgem_ifmedia_sts,
> > +BMSR_DEFCAPMASK, phy_addr,
> > MII_OFFSET_ANY, 0);
> > +   }
> > +
> > +   if (err) {
> > +   /* Attach phy to mii bus. */
> > +   err = mii_attach(dev, >miibus, ifp,
> > +cgem_ifmedia_upd,
> > cgem_ifmedia_sts,
> > +BMSR_DEFCAPMASK, MII_PHY_ANY,
> > MII_OFFSET_ANY, 0);
> > +   }
> > +
> > 
> 
> Same here. Also, a simpler implementation would be to have
> cgem_get_phyaddr return the PHY address or MII_PHY_ANY on error and
> fold that all into the declaration. That would leave the declaration
> as:
> #ifdef __rtems__
>int phy_addr = cgem_get_phyaddr(node);
> #endif
> 
> and the change here as:
>/* Attach phy to mii bus. */
>err = mii_attach(dev, >miibus, ifp,
> cgem_ifmedia_upd, cgem_ifmedia_sts,
> #ifdef __rtems__
> BMSR_DEFCAPMASK, phy_addr, MII_OFFSET_ANY,
> 0);
> #else /* __rtems__ */
> BMSR_DEFCAPMASK, MII_PHY_ANY, MII_OFFSET_ANY,
> 0);
> #endif /* __rtems__ */
> 

Ok sure, will update

Regards
Padmarao
> > if (err) {
> > device_printf(dev, "attaching PHYs failed\n");
> > cgem_detach(dev);
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

bsps/riscv: interrupt not occurred

[Padmarao.Begari]

Hi,

While testing the Candence GEM driver of RTEMS-FreeBSD with the RTEMS
on the PolarFire SoC Icicle Kit found one issue.

Issue:The Interrupt is disabled before clearing the interrupt complete
in the PLIC because of this the same interrupt is not occurred next
time.

Resolved: Clear the Interrupt complete in the PLIC before disable the
interrupt. 

Updated the bsp_interrupt_vector_disable() function like below then the
cgem driver is working fine with the RTEMS. 

@Sebastian Huber - Can I send the patch for this?

---
rtems_status_code bsp_interrupt_vector_disable(rtems_vector_number
vector)
{
  bsp_interrupt_assert(bsp_interrupt_is_valid_vector(vector));

  if (RISCV_INTERRUPT_VECTOR_IS_EXTERNAL(vector)) {
uint32_t interrupt_index;
volatile uint32_t *enable;
uint32_t group;
uint32_t bit;
rtems_interrupt_lock_context lock_context;
volatile RISCV_PLIC_hart_regs *plic_hart_regs;

interrupt_index = RISCV_INTERRUPT_VECTOR_EXTERNAL_TO_INDEX(vector);
enable = riscv_plic_irq_to_cpu[interrupt_index - 1];
group = interrupt_index / 32;
bit = UINT32_C(1) << (interrupt_index % 32);

rtems_interrupt_lock_acquire(_plic_lock, _context);

#ifdef RTEMS_SMP
  uint32_t cpu_max;
  uint32_t cpu_index;

  cpu_max = _SMP_Get_processor_maximum();

  for (cpu_index = 0; cpu_index < cpu_max; ++cpu_index) {
Per_CPU_Control *cpu;

cpu = _Per_CPU_Get_by_index(cpu_index);
enable = cpu->cpu_per_cpu.plic_m_ie;
plic_hart_regs = cpu->cpu_per_cpu.plic_hart_regs;
   
plic_hart_regs->claim_complete = interrupt_index;

if (enable != NULL) {
  enable[group] &= ~bit;
}
  }
#else
  Per_CPU_Control *cpu;

  cpu = _Per_CPU_Get_by_index(0);
  enable = cpu->cpu_per_cpu.plic_m_ie;
  plic_hart_regs = cpu->cpu_per_cpu.plic_hart_regs;
  plic_hart_regs->claim_complete = interrupt_index;
  if (enable != NULL) {
enable[group] &= ~bit;
  }
#endif

rtems_interrupt_lock_release(_plic_lock, _context);
return RTEMS_SUCCESSFUL;
  }

  if (vector == RISCV_INTERRUPT_VECTOR_TIMER) {
clear_csr(mie, MIP_MTIP);
return RTEMS_SUCCESSFUL;
  }

  _Assert(vector == RISCV_INTERRUPT_VECTOR_SOFTWARE);
  clear_csr(mie, MIP_MSIP);
  return RTEMS_SUCCESSFUL;
} 


Regards
Padmarao
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: bsps/riscv: interrupt number mismatch

[Padmarao.Begari]

> On Mon, 2022-11-21 at 11:20 +0100, Sebastian Huber wrote:
> 
> On 21/11/2022 11:17, padmarao.beg...@microchip.com wrote:
> > > To which number would you map the software and timer interrupts?
> > > 
> > The Software and Timer interrupts(numbers 0 & 1) are mapped by
> > the Machine cause register (mcause) and enabled by the CLINT but
> > not by
> > the PLIC.
> 
> Yes, this is the problem. We need an interrupt vector number for all
> interrupts (PLIC and CLINT).
> 

Fixed, by adding 2 with interrupt number in the bsp_fdt_map_intr()
function.

uint32_t bsp_fdt_map_intr(const uint32_t *intr, size_t icells)
{
  (void) icells;
  return intr[0] + 2;
}


Regards
Padmarao 
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@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/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: bsps/riscv: interrupt number mismatch

[Padmarao.Begari]

Hi Sebastian,

> On Mon, 2022-11-21 at 10:53 +0100, Sebastian Huber wrote:
> 
> On 21/11/2022 10:50, padmarao.beg...@microchip.com wrote:
> > The interrupt number(vector) mention in the device tree node is
> > working
> > when the driver is used the RISCV_INTERRUPT_VECTOR_EXTERNAL() and
> > later
> > called the RISCV_INTERRUPT_VECTOR_EXTERNAL_TO_INDEX() in the RTEMS
> > but
> > the interrupt number is decreased by 2 when registering the
> > interrupt
> > from the RTEMS-LIBBSD driver(ex: Cadence GEM). The RTEMS-LIBBSD
> > doesn't
> > call the RISCV_INTERRUPT_VECTOR_EXTERNAL() but called the
> > RISCV_INTERRU
> > PT_VECTOR_EXTERNAL_TO_INDEX() for interrupt enable.
> > 
> > In "bsps/riscv/riscv/include/bsp/irq.h"
> > 
> > #define RISCV_INTERRUPT_VECTOR_EXTERNAL(x) ((x) + 2)
> > 
> > #define RISCV_INTERRUPT_VECTOR_IS_EXTERNAL(x) ((x) >= 2)
> > 
> > #define RISCV_INTERRUPT_VECTOR_EXTERNAL_TO_INDEX(x) ((x) - 2)
> > 
> > Can we create a config file for non-external interrupt vector index
> > instead of '2'?
> > 
> > like '2' for RISC-V GENERIC and '0' for PolarFire SoC.
> 
> To which number would you map the software and timer interrupts?
> 

The Software and Timer interrupts(numbers 0 & 1) are mapped by
the Machine cause register (mcause) and enabled by the CLINT but not by
the PLIC.
 
> Can't this off by two problem be fixed by bsp_fdt_map_intr()?

will check this option.

Regards
Padmarao

> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@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/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

bsps/riscv: interrupt number mismatch

[Padmarao.Begari]

Hi,

The interrupt number(vector) mention in the device tree node is working
when the driver is used the RISCV_INTERRUPT_VECTOR_EXTERNAL() and later
called the RISCV_INTERRUPT_VECTOR_EXTERNAL_TO_INDEX() in the RTEMS but
the interrupt number is decreased by 2 when registering the interrupt
from the RTEMS-LIBBSD driver(ex: Cadence GEM). The RTEMS-LIBBSD doesn't
call the RISCV_INTERRUPT_VECTOR_EXTERNAL() but called the RISCV_INTERRU
PT_VECTOR_EXTERNAL_TO_INDEX() for interrupt enable.

In "bsps/riscv/riscv/include/bsp/irq.h"

#define RISCV_INTERRUPT_VECTOR_EXTERNAL(x) ((x) + 2)

#define RISCV_INTERRUPT_VECTOR_IS_EXTERNAL(x) ((x) >= 2)

#define RISCV_INTERRUPT_VECTOR_EXTERNAL_TO_INDEX(x) ((x) - 2) 

Can we create a config file for non-external interrupt vector index
instead of '2'?

like '2' for RISC-V GENERIC and '0' for PolarFire SoC.

Regards
Padmarao
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] zynqmp: Add support for the CFC-400X

[Padmarao.Begari]

Hi Kinsey,

> On Thu, 2022-11-10 at 07:55 -0600, Kinsey Moore wrote:
> 
> Hi Padmarao,
> More compatibles can be added later if necessary to both the device
> tree in RTEMS and the driver in RTEMS-LibBSD, but I don't see the
> need for either at the moment since the ethernet portion of the
> device tree is intended to be used with RTEMS-LibBSD directly. As far
> as the driver in 6-freebsd-12 is concerned, all compatibles are
> currently equivalent and it already supports "cdns,macb" if a BSP
> chooses to use that compatible. This may change when we upgrade to
> the FreeBSD 13 code since the driver has gained more advanced support
> for differentiating among compatibles and hardware quirks, but the
> list of supported compatibles will only expand.
> 

Ok, Makes sense to me.

Regards
Padmarao
> Kinsey
> 
> On Thu, Nov 10, 2022 at 6:50 AM 
> wrote:
> > Hi Kinsey,
> > 
> > The ethernet compatible "cdns,gem" is mentioned in the device tree,
> > even I used same for PolarFire SoC BSP but later realised that
> > common
> > compatible for the candence GEM is "cdns,macb" used in U-Boot and
> > Linux.
> > 
> > Can we go with compatible "cdns,gem"? or will we update with
> > "cdns,macb" later?  
> > 
> > Regards
> > Padmarao
> > > +   ethernet@ff0b {
> > > +   compatible = "cdns,gem";
> > > +   status = "okay";
> > > +   interrupt-parent = <0x01>;
> > > +   interrupts = <0x00 0x39 0x04>;
> > > +   reg = <0x00 0xff0b 0x00 0x1000>;
> > > +   phy-mode = "sgmii";
> > > +   };
> > 
> > 
> > > On Tue, 2022-11-08 at 15:56 -0600, Kinsey Moore wrote:
> > > 
> > > This adds a BSP variant for the ZynqMP BSP family to support the
> > > Innoflight CFC-400X platform. To properly support the CFC-400X,
> > > device
> > > trees were added to the ZynqMP platform due to both the optional
> > > management interface as well as alternate physical configuration
> > of
> > > the
> > > ethernet interfaces.
> > > ---
> > >  bsps/aarch64/xilinx-zynqmp/console/console.c  | 163
> > > +-
> > >  bsps/aarch64/xilinx-zynqmp/fdt/bsp_fdt.c  |  51 ++
> > >  bsps/aarch64/xilinx-zynqmp/fdt/cfc400x.dts| 110 
> > >  bsps/aarch64/xilinx-zynqmp/fdt/cfc400x_dtb.c  | 124
> > +
> > >  bsps/aarch64/xilinx-zynqmp/fdt/zynqmp.dts |  94 ++
> > >  bsps/aarch64/xilinx-zynqmp/fdt/zynqmp_dtb.c   |  97 +++
> > >  bsps/aarch64/xilinx-zynqmp/include/bsp.h  |  15 ++
> > >  .../aarch64/xilinx-zynqmp/start/bspstartmmu.c |   4 +
> > >  .../aarch64/xilinx-zynqmp/bspcfc400xlp64.yml  |  21 +++
> > >  .../aarch64/xilinx-zynqmp/bspqemuilp32.yml|   2 +
> > >  .../aarch64/xilinx-zynqmp/bspqemulp64.yml |   2 +
> > >  .../aarch64/xilinx-zynqmp/bspzu3egilp32.yml   |   2 +
> > >  .../aarch64/xilinx-zynqmp/bspzu3eglp64.yml|   2 +
> > >  spec/build/bsps/aarch64/xilinx-zynqmp/obj.yml |   1 +
> > >  .../aarch64/xilinx-zynqmp/objfdtcfc400x.yml   |  14 ++
> > >  .../aarch64/xilinx-zynqmp/objfdtzynqmp.yml|  14 ++
> > >  .../bsps/aarch64/xilinx-zynqmp/optloadoff.yml |   1 +
> > >  .../bsps/aarch64/xilinx-zynqmp/optramori.yml  |   1 +
> > >  spec/build/cpukit/optsmp.yml  |   1 +
> > >  19 files changed, 718 insertions(+), 1 deletion(-)
> > >  create mode 100644 bsps/aarch64/xilinx-zynqmp/fdt/bsp_fdt.c
> > >  create mode 100644 bsps/aarch64/xilinx-zynqmp/fdt/cfc400x.dts
> > >  create mode 100644 bsps/aarch64/xilinx-zynqmp/fdt/cfc400x_dtb.c
> > >  create mode 100644 bsps/aarch64/xilinx-zynqmp/fdt/zynqmp.dts
> > >  create mode 100644 bsps/aarch64/xilinx-zynqmp/fdt/zynqmp_dtb.c
> > >  create mode 100644 spec/build/bsps/aarch64/xilinx-
> > > zynqmp/bspcfc400xlp64.yml
> > >  create mode 100644 spec/build/bsps/aarch64/xilinx-
> > > zynqmp/objfdtcfc400x.yml
> > >  create mode 100644 spec/build/bsps/aarch64/xilinx-
> > > zynqmp/objfdtzynqmp.yml
> > > 
> > > diff --git a/bsps/aarch64/xilinx-zynqmp/console/console.c
> > > b/bsps/aarch64/xilinx-zynqmp/console/console.c
> > > index d1948f1a0c..d546db8535 100644
> > > --- a/bsps/aarch64/xilinx-zynqmp/console/console.c
> > > +++ b/bsps/aarch64/xilinx-zynqmp/console/console.c
> > > @@ -9,7 +9,7 @@
> > >   */
> > > 
> > >  /*
> > > - * Copyright (C) 2020 On-Line Applications Research Corporation
> > > (OAR)
> > > + * Copyright (C) 2022 On-Line Applications Research Corporation
> > > (OAR)
> > >   * Written by Kinsey Moore 
> > >   *
> > >   * Redistribution and use in source and binary forms, with or
> > > without
> > > @@ -36,13 +36,165 @@
> > > 
> > >  #include 
> > >  #include 
> > > +#include 
> > > +#include 
> > >  #include 
> > > 
> > > +#include 
> > > +#include 
> > >  #include 
> > > +
> > >  #include 
> > > 
> > >  #include 
> > > 
> > > +#include 
> > > +
> > > +uint32_t mgmt_uart_reg_shift = 0;
> > > +static uint8_t get_register(uintptr_t addr, uint8_t i)
> > > +{
> > > +  volatile uint8_t *reg 

Re: [PATCH v2] zynqmp: Add support for the CFC-400X

[Padmarao.Begari]

Hi Kinsey,

The ethernet compatible "cdns,gem" is mentioned in the device tree,
even I used same for PolarFire SoC BSP but later realised that common
compatible for the candence GEM is "cdns,macb" used in U-Boot and
Linux.

Can we go with compatible "cdns,gem"? or will we update with
"cdns,macb" later?  

Regards
Padmarao
> +   ethernet@ff0b {
> +   compatible = "cdns,gem";
> +   status = "okay";
> +   interrupt-parent = <0x01>;
> +   interrupts = <0x00 0x39 0x04>;
> +   reg = <0x00 0xff0b 0x00 0x1000>;
> +   phy-mode = "sgmii";
> +   };


> On Tue, 2022-11-08 at 15:56 -0600, Kinsey Moore wrote:
> 
> This adds a BSP variant for the ZynqMP BSP family to support the
> Innoflight CFC-400X platform. To properly support the CFC-400X,
> device
> trees were added to the ZynqMP platform due to both the optional
> management interface as well as alternate physical configuration of
> the
> ethernet interfaces.
> ---
>  bsps/aarch64/xilinx-zynqmp/console/console.c  | 163
> +-
>  bsps/aarch64/xilinx-zynqmp/fdt/bsp_fdt.c  |  51 ++
>  bsps/aarch64/xilinx-zynqmp/fdt/cfc400x.dts| 110 
>  bsps/aarch64/xilinx-zynqmp/fdt/cfc400x_dtb.c  | 124 +
>  bsps/aarch64/xilinx-zynqmp/fdt/zynqmp.dts |  94 ++
>  bsps/aarch64/xilinx-zynqmp/fdt/zynqmp_dtb.c   |  97 +++
>  bsps/aarch64/xilinx-zynqmp/include/bsp.h  |  15 ++
>  .../aarch64/xilinx-zynqmp/start/bspstartmmu.c |   4 +
>  .../aarch64/xilinx-zynqmp/bspcfc400xlp64.yml  |  21 +++
>  .../aarch64/xilinx-zynqmp/bspqemuilp32.yml|   2 +
>  .../aarch64/xilinx-zynqmp/bspqemulp64.yml |   2 +
>  .../aarch64/xilinx-zynqmp/bspzu3egilp32.yml   |   2 +
>  .../aarch64/xilinx-zynqmp/bspzu3eglp64.yml|   2 +
>  spec/build/bsps/aarch64/xilinx-zynqmp/obj.yml |   1 +
>  .../aarch64/xilinx-zynqmp/objfdtcfc400x.yml   |  14 ++
>  .../aarch64/xilinx-zynqmp/objfdtzynqmp.yml|  14 ++
>  .../bsps/aarch64/xilinx-zynqmp/optloadoff.yml |   1 +
>  .../bsps/aarch64/xilinx-zynqmp/optramori.yml  |   1 +
>  spec/build/cpukit/optsmp.yml  |   1 +
>  19 files changed, 718 insertions(+), 1 deletion(-)
>  create mode 100644 bsps/aarch64/xilinx-zynqmp/fdt/bsp_fdt.c
>  create mode 100644 bsps/aarch64/xilinx-zynqmp/fdt/cfc400x.dts
>  create mode 100644 bsps/aarch64/xilinx-zynqmp/fdt/cfc400x_dtb.c
>  create mode 100644 bsps/aarch64/xilinx-zynqmp/fdt/zynqmp.dts
>  create mode 100644 bsps/aarch64/xilinx-zynqmp/fdt/zynqmp_dtb.c
>  create mode 100644 spec/build/bsps/aarch64/xilinx-
> zynqmp/bspcfc400xlp64.yml
>  create mode 100644 spec/build/bsps/aarch64/xilinx-
> zynqmp/objfdtcfc400x.yml
>  create mode 100644 spec/build/bsps/aarch64/xilinx-
> zynqmp/objfdtzynqmp.yml
> 
> diff --git a/bsps/aarch64/xilinx-zynqmp/console/console.c
> b/bsps/aarch64/xilinx-zynqmp/console/console.c
> index d1948f1a0c..d546db8535 100644
> --- a/bsps/aarch64/xilinx-zynqmp/console/console.c
> +++ b/bsps/aarch64/xilinx-zynqmp/console/console.c
> @@ -9,7 +9,7 @@
>   */
> 
>  /*
> - * Copyright (C) 2020 On-Line Applications Research Corporation
> (OAR)
> + * Copyright (C) 2022 On-Line Applications Research Corporation
> (OAR)
>   * Written by Kinsey Moore 
>   *
>   * Redistribution and use in source and binary forms, with or
> without
> @@ -36,13 +36,165 @@
> 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
> 
> +#include 
> +#include 
>  #include 
> +
>  #include 
> 
>  #include 
> 
> +#include 
> +
> +uint32_t mgmt_uart_reg_shift = 0;
> +static uint8_t get_register(uintptr_t addr, uint8_t i)
> +{
> +  volatile uint8_t *reg = (uint8_t *) addr;
> +
> +  i <<= mgmt_uart_reg_shift;
> +  return reg [i];
> +}
> +
> +static void set_register(uintptr_t addr, uint8_t i, uint8_t val)
> +{
> +  volatile uint8_t *reg = (uint8_t *) addr;
> +
> +  i <<= mgmt_uart_reg_shift;
> +  reg [i] = val;
> +}
> +
> +static ns16550_context zynqmp_mgmt_uart_context = {
> +  .base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER("Management UART
> 0"),
> +  .get_reg = get_register,
> +  .set_reg = set_register,
> +  .port = 0,
> +  .irq = 0,
> +  .clock = 0,
> +  .initial_baud = 0,
> +};
> +
> +__attribute__ ((weak)) void
> zynqmp_configure_management_console(rtems_termios_device_context
> *base)
> +{
> +  /* This SLIP-encoded watchdog command sets timeouts to 0x
> seconds. */
> +  const char mgmt_watchdog_cmd[] =
> +"\xc0\xda\x00\x00\xff\xff\xff\xff\xff\x00\xff\xff\xff\xffM#\xc0"
> ;
> +
> +  /* Send the system watchdog configuration command */
> +  for (int i = 0; i < sizeof(mgmt_watchdog_cmd); i++) {
> +ns16550_polled_putchar(base, mgmt_watchdog_cmd[i]);
> +  }
> +}
> +
> +static void zynqmp_management_console_init(void)
> +{
> +  /* Find the management console in the device tree */
> +  rtems_fdt_handle fdt_handle;
> +  const uint32_t *prop;
> +  uint32_t outprop[4];
> +  int proplen;
> +  int 

Re: bsp/riscv: Store/AMO address misaligned trap occured

[Padmarao.Begari]

Hi Sebastian,

> On Fri, 2022-11-04 at 14:03 +0100, Sebastian Huber wrote:
> On 04/11/2022 10:49, Sebastian Huber wrote:
> > On 04/11/2022 10:44, padmarao.beg...@microchip.com wrote:
> > > Hi Sebastian,
> > > 
> > > > On Fri, 2022-11-04 at 08:07 +0100, Sebastian Huber wrote:
> > > > 
> > > > On 03/11/2022 06:40,padmarao.beg...@microchip.com  wrote:
> > > > > > On Wed, 2022-11-02 at 09:58 -0600, Gedare Bloom wrote:
> > > > > > 
> > > > > > t0 contains the address of .Lsecondary_processor_go
> > > > > > 
> > > > > > start.S has:
> > > > > > ```asm
> > > > > > #if __riscv_xlen == 32
> > > > > > .align  2
> > > > > > #elif __riscv_xlen == 64
> > > > > > .align  3
> > > > > > #endif
> > > > > > 
> > > > > > .Lsecondary_processor_go:
> > > > > > ```
> > > > > > Can you confirm the value of __riscv_xlen is properly
> > > > > > defined to
> > > > > > 64
> > > > > > for the PolarFire?
> > > > > > 
> > > > > No, the value of __riscv_xlen is showing 32(config.log)
> > > > > instead of
> > > > > 64
> > > > > for PolarFire SoC and other 64-bit RISCV BSPs.
> > > > This is a compiler built-in define.  It doesn't matter what is
> > > > in the
> > > > config.log. What matters is that the compiler is invoked with
> > > > the
> > > > right
> > > > options. In my build this looks all right.
> > > > 
> > > > What is the value of t0 in
> > > > 
> > > > amoswap.w zero, zero, 0(t0)
> > > > 
> > > > ?
> > > > 
> > > The "t0" value is 0x1000ae
> > 
> > Ok, is this the address of .Lsecondary_processor_go?
> > 
> > It is a value > 4GiB. I am not sure how such a value is loaded
> > through
> > la or lla.
> 
> It seems that the .align directive is broken in the assembler. I
> checked
> in b4ffaa7cdcce4fedb857f6b8342301f8dde65c78 as a workaround. Could
> you
> please test this commit?
> 

I have tested it and working fine.

Regards
Padmarao
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@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/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: bsp/riscv: Store/AMO address misaligned trap occured

[Padmarao.Begari]

Hi Sebastian,

> On Fri, 2022-11-04 at 08:07 +0100, Sebastian Huber wrote:
> 
> On 03/11/2022 06:40, padmarao.beg...@microchip.com wrote:
> > > On Wed, 2022-11-02 at 09:58 -0600, Gedare Bloom wrote:
> > > 
> > > t0 contains the address of .Lsecondary_processor_go
> > > 
> > > start.S has:
> > > ```asm
> > > #if __riscv_xlen == 32
> > >.align  2
> > > #elif __riscv_xlen == 64
> > >.align  3
> > > #endif
> > > 
> > > .Lsecondary_processor_go:
> > > ```
> > > Can you confirm the value of __riscv_xlen is properly defined to
> > > 64
> > > for the PolarFire?
> > > 
> > No, the value of __riscv_xlen is showing 32(config.log) instead of
> > 64
> > for PolarFire SoC and other 64-bit RISCV BSPs.
> 
> This is a compiler built-in define.  It doesn't matter what is in the
> config.log. What matters is that the compiler is invoked with the
> right
> options. In my build this looks all right.
> 
> What is the value of t0 in
> 
> amoswap.w zero, zero, 0(t0)
> 
> ?
> 
The "t0" value is 0x1000ae

> Does it help to revert the commit?
> 
Yes, removed ".option norelax" from start.S and it's working fine.

Regards
Padmarao 
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@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/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: bsp/riscv: Store/AMO address misaligned trap occured

[Padmarao.Begari]

> On Thu, 2022-11-03 at 05:40 +, padmarao.beg...@microchip.com
wrote:
> Hi Gedare,
> > On Wed, 2022-11-02 at 09:58 -0600, Gedare Bloom wrote:
> > 
> > t0 contains the address of .Lsecondary_processor_go
> > 
> > start.S has:
> > ```asm
> > #if __riscv_xlen == 32
> >   .align  2
> > #elif __riscv_xlen == 64
> >   .align  3
> > #endif
> > 
> > .Lsecondary_processor_go:
> > ```
> > Can you confirm the value of __riscv_xlen is properly defined to 64
> > for the PolarFire?
> > 
> No, the value of __riscv_xlen is showing 32(config.log) instead of 64
> for PolarFire SoC and other 64-bit RISCV BSPs.
> 
Ignore previous one "the value of __riscv_xlen is showing
32(config.log)"

The __riscv_xlen is 64 for PolarFire SoC, have seen while executing the
rtems on the board.
 
> Regards
> Padmarao
> > On Wed, Nov 2, 2022 at 12:40 AM 
> > wrote:
> > > Hi Sebastian,
> > > 
> > > The "Store/AMO address misaligned" trap occured in the "start.S"
> > >  at "amoswap.w zero, zero, 0(t0)" while testing the sample
> > >  application with the latest RTEMS master for RISC-V on
> > > the Microchip PolarFire SoC.
> > > 
> > > The trap occured after this  89ba2a98/rtems latest commit for
> > > riscv
> > > (bsps/riscv: Workaround for sporadic linker issues).
> > > 
> > > Regards
> > > Padmarao
> > > ___
> > > devel mailing list
> > > devel@rtems.org
> > > http://lists.rtems.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: bsp/riscv: Store/AMO address misaligned trap occured

[Padmarao.Begari]

Hi Gedare,
> On Wed, 2022-11-02 at 09:58 -0600, Gedare Bloom wrote:
> 
> t0 contains the address of .Lsecondary_processor_go
> 
> start.S has:
> ```asm
> #if __riscv_xlen == 32
>   .align  2
> #elif __riscv_xlen == 64
>   .align  3
> #endif
> 
> .Lsecondary_processor_go:
> ```
> Can you confirm the value of __riscv_xlen is properly defined to 64
> for the PolarFire?
> 
No, the value of __riscv_xlen is showing 32(config.log) instead of 64
for PolarFire SoC and other 64-bit RISCV BSPs.

Regards
Padmarao
> 
> On Wed, Nov 2, 2022 at 12:40 AM 
> wrote:
> > Hi Sebastian,
> > 
> > The "Store/AMO address misaligned" trap occured in the "start.S"
> >  at "amoswap.w zero, zero, 0(t0)" while testing the sample
> >  application with the latest RTEMS master for RISC-V on
> > the Microchip PolarFire SoC.
> > 
> > The trap occured after this  89ba2a98/rtems latest commit for riscv
> > (bsps/riscv: Workaround for sporadic linker issues).
> > 
> > Regards
> > Padmarao
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

bsp/riscv: Store/AMO address misaligned trap occured

[Padmarao.Begari]

Hi Sebastian,

The "Store/AMO address misaligned" trap occured in the "start.S"
 at "amoswap.w zero, zero, 0(t0)" while testing the sample
 application with the latest RTEMS master for RISC-V on
the Microchip PolarFire SoC.

The trap occured after this  
89ba2a98/rtems
 latest commit for riscv
(bsps/riscv: Workaround for sporadic linker issues).

Regards
Padmarao
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH rtems-docs v2] user/bsps: Update riscv for PolarFire SoC

[Padmarao.Begari]

Hi,

The Patch v1 was reviewed by Alan, update few comments, and submitted Patch v2.
 https://lists.rtems.org/pipermail/devel/2022-October/073469.html - Patch v1

https://lists.rtems.org/pipermail/devel/2022-October/073528.html - Patch v2

Can you please review or merge it to rtems-docs git?

Regards
Padmarao
-Original Message-
From: Padmarao Begari  
Sent: Monday, October 10, 2022 12:25 PM
To: devel@rtems.org
Cc: Cyril Jean - M31571 ; Padmarao Begari - I30397 

Subject: [PATCH rtems-docs v2] user/bsps: Update riscv for PolarFire SoC

Update the riscv documentation for the Microchip PolarFire SoC BSP variant 
including information about SMP test procedure for the Microchip PolarFire 
Icicle Kit.
---
 user/bsps/bsps-riscv.rst | 126 ++-
 1 file changed, 125 insertions(+), 1 deletion(-)

diff --git a/user/bsps/bsps-riscv.rst b/user/bsps/bsps-riscv.rst index 
5faa87b..48e7ee7 100644
--- a/user/bsps/bsps-riscv.rst
+++ b/user/bsps/bsps-riscv.rst
@@ -8,7 +8,7 @@ riscv (RISC-V)
 riscv
 =
 
-This BSP offers 13 variants:
+This BSP offers 15 variants:
 
 * rv32i
 
@@ -38,6 +38,8 @@ This BSP offers 13 variants:
 
 * frdme310arty
 
+* mpfs64imafdc
+
 Each variant corresponds to a GCC multilib.  A particular variant reflects an  
ISA with ABI and code model choice.
 
@@ -47,6 +49,9 @@ be started im machine mode.
 
 The reference platform for this BSP is the Qemu `virt` machine.
 
+The reference platform for the mpfs64imafdc BSP variant is the 
+Microchip PolarFire SoC Icicle Kit.
+
 Build Configuration Options
 ---
 
@@ -68,6 +73,13 @@ configuration INI file. The ``waf`` defaults can be used to 
inspect the values.
 ``BSP_FDT_BLOB_SIZE_MAX``
 The maximum size of the device tree blob in bytes (default is 65536).
 
+``BSP_DTB_IS_SUPPORTED``
+If defined to a non-zero value, then the device tree blob is embedded in
+the BSP.
+
+``BSP_DTB_HEADER_PATH``
+The path to the header file containing the device tree blob.
+
 ``BSP_CONSOLE_BAUD``
 The default baud for console driver devices (default 115200).
 
@@ -94,6 +106,13 @@ configuration INI file. The ``waf`` defaults can be used to 
inspect the values.
  Enables support sifive Freedom E310 Arty board if defined to a non-zero
  value,otherwise it is disabled (disabled by default)
 
+``RISCV_ENABLE_MPFS_SUPPORT``
+ Enables support Microchip PolarFire SoC if defined to a non-zero
+ value, otherwise it is disabled (disabled by default).
+
+``RISCV_BOOT_HARTID``
+ The boot hartid (processor number) of risc-v cpu by default 0.
+
 Interrupt Controller
 
 
@@ -124,6 +143,111 @@ They are initialized according to the device tree.  The 
console driver does not  configure the pins or peripheral clocks.  The console 
device is selected  according to the device tree "/chosen/stdout-path" property 
value.
 
+Microchip PolarFire SoC
+---
+
+The PolarFire SoC is the 4x 64-bit RISC-V U54 cores and a 64-bit RISC-V
+E51 monitor core SoC from the Microchip.
+
+The ``mpfs64imafdc`` BSP variant supports the U54 cores but not the E51 
+because the E51 monitor core is reserved for the first stage bootloader 
+(Hart Software Services). In order to boot from the first U54 core, 
+``RISCV_BOOT_HARTID`` is set to 1 by default.
+
+The device tree blob is embedded in the ``mpfs64imafdc`` BSP variant by 
+default with the ``BSP_DTB_IS_SUPPORTED`` enabled and the DTB header 
+path ``BSP_DTB_HEADER_PATH`` is set to bsp/mpfs-dtb.h.
+
+**SMP test procedure for the Microchip PolarFire Icicle Kit:**
+
+The "config.ini" file.
+
+.. code-block:: none
+
+[riscv/mpfs64imafdc]
+BUILD_TESTS = True
+RTEMS_POSIX_API=True
+RTEMS_SMP = True
+BSP_START_COPY_FDT_FROM_U_BOOT=False
+BSP_VERBOSE_FATAL_EXTENSION = False
+
+Build RTEMS.
+
+.. code-block:: shell
+
+$ ./waf configure --prefix=$HOME/rtems-start/rtems/6
+$ ./waf
+
+Convert .exe to .elf file.
+
+.. code-block:: shell
+
+$ riscv-rtems6-objcopy 
+ build/riscv/mpfs64imafdc/testsuites/smptests/smp01.exe 
+ build/riscv/mpfs64imafdc/testsuites/smptests/smp01.elf
+
+Generate a payload for the `smp01.elf` using the `hss-payload-generator 
`_.
+
+* Copy `smp01.elf` file to the HSS/tools/hss-payload-generator/test directory.
+
+* Go to hss-payload-generator source directory.
+
+.. code-block:: shell
+
+$ cd hart-software-services/tools/hss-payload-generator
+
+* Edit test/uboot.yaml file for the hart entry points and correct name 
+of the
+  binary file.
+
+.. code-block:: none
+
+set-name: 'PolarFire-SoC-HSS::RTEMS'
+hart-entry-points: {u54_1: '0x10', u54_2: '0x10', u54_3: 
'0x10', u54_4: '0x10'}
+payloads:
+ test/smp01.elf: {exec-addr: '0x10', owner-hart: u54_1, 
+ secondary-hart: u54_2, secondary-hart: u54_3, secondary-hart: u54_4, 
+ 

rtems-libbsd support RISC-V or not

[Padmarao.Begari]

Hi,

Is the rtems-libbsd support the risc-v architecture BSP or not?

Because I am trying to use existing FreeBSD ethernet and mmc driver for 
Microchip PolarFore SoC(RTEMS RISC-V BSP variant).

Regards
Padmarao
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Visibility of RISCV_BOOT_HARTID

[Padmarao.Begari]

> On Thu, 2022-10-13 at 06:27 +0200, Sebastian Huber wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know the content is safe
> 
> On 12/10/2022 16:36, Joel Sherrill wrote:
> > Hi
> > 
> > I was looking at the bsp default settings for sparc/leon3 to show
> > someone and noticed this which is out of place.
> > 
> > # boot hartid (processor number) of risc-v cpu (default 0)
> > RISCV_BOOT_HARTID = 0
> > 
> > I looked around and see it is an architecture specific ini setting
> > but
> > placed in a directory with architecture independent settings. We
> > don't
> > appear to have any other examples of a cpukit option that is
> > architecture specific. So it is lumped in with all the architecture
> > independent ini settings.
> 
> This was easy to fix:
> 
> https://git.rtems.org/rtems/commit/?id=97fce5120c08180a86301b03e61d0a06db5f8b9b
> 
Oh... I didn't see it and tried different way.
> > We had long discussions about presenting these options with better
> > names, documentation, etc as part of the waf transition. Seems
> > unfortunate to have this show up in all configurations.
> > 
> > Any thoughts on how to clean this up?
> 
> It would be nice if more developers could invest some time to learn
> how
> the build system works.

Yes.. need to learn more about the build system.

Regards
Padmarao
> 
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@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/
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Visibility of RISCV_BOOT_HARTID

[Padmarao.Begari]

Hi Joel,

We can do like below to remove visibility of RISCV_BOOT_HARTID from
other architecture configurations and only visible to RISC-V.

Changes in spec/build/cpukits

1. Remove "optboothartid" build-dependency from "cpuotps"
2. Add the "cpuriscvhartid" to generate the "hartid.h" using "optbootha
rtid
"
3. Link "cpuriscvhartid" build-dependency in "cpuriscv"
4. Include "hartid.h" in "cpukit/score/cpu/riscv/include/rtems/score/ri
scv.h" 

I have modified the RTEMS source like below
**
cpukit/score/cpu/riscv/include/rtems/score/riscv.h |  2 ++
 spec/build/cpukit/cpuopts.yml  |  2 --
 spec/build/cpukit/cpuriscv.yml |  4 +++-
 spec/build/cpukit/cpuriscvhartid.yml   | 13 +
 4 files changed, 18 insertions(+), 3 deletions(-)
 create mode 100644 spec/build/cpukit/cpuriscvhartid.yml

diff --git a/cpukit/score/cpu/riscv/include/rtems/score/riscv.h
b/cpukit/score/cpu/riscv/include/rtems/score/riscv.h
index f770578715..3e0169981b 100644
--- a/cpukit/score/cpu/riscv/include/rtems/score/riscv.h
+++ b/cpukit/score/cpu/riscv/include/rtems/score/riscv.h
@@ -36,6 +36,8 @@
 #ifndef _RTEMS_SCORE_RISCV_H
 #define _RTEMS_SCORE_RISCV_H
 
+#include 
+
 #ifdef __cplusplus
 extern "C" {
 #endif
diff --git a/spec/build/cpukit/cpuopts.yml
b/spec/build/cpukit/cpuopts.yml
index dcfca62d05..86cc7f676a 100644
--- a/spec/build/cpukit/cpuopts.yml
+++ b/spec/build/cpukit/cpuopts.yml
@@ -33,8 +33,6 @@ links:
   uid: optinstall
 - role: build-dependency
   uid: optada
-- role: build-dependency
-  uid: optboothartid
 - role: build-dependency
   uid: optbuildlabel
 - role: build-dependency
diff --git a/spec/build/cpukit/cpuriscv.yml
b/spec/build/cpukit/cpuriscv.yml
index 2671c5c5f0..c8365e550a 100644
--- a/spec/build/cpukit/cpuriscv.yml
+++ b/spec/build/cpukit/cpuriscv.yml
@@ -24,7 +24,9 @@ install:
   - cpukit/score/cpu/riscv/include/rtems/score/cpuimpl.h
   - cpukit/score/cpu/riscv/include/rtems/score/riscv-utility.h
   - cpukit/score/cpu/riscv/include/rtems/score/riscv.h
-links: []
+links:
+- role: build-dependency
+  uid: cpuriscvhartid
 source:
 - cpukit/score/cpu/riscv/cpu.c
 - cpukit/score/cpu/riscv/riscv-context-initialize.c
diff --git a/spec/build/cpukit/cpuriscvhartid.yml
b/spec/build/cpukit/cpuriscvhartid.yml
new file mode 100644
index 00..60f22bd3bd
--- /dev/null
+++ b/spec/build/cpukit/cpuriscvhartid.yml
@@ -0,0 +1,13 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+build-type: config-header
+copyrights:
+- Copyright (C) 2020 embedded brains GmbH (
http://www.embedded-brains.de)
+enabled-by: true
+guard: _RTEMS_SCORE_HARTID_H
+include-headers: []
+install-path: ${BSP_INCLUDEDIR}/rtems/score
+links:
+- role: build-dependency
+  uid: optboothartid
+target: cpukit/include/rtems/score/hartid.h
+type: build
\ No newline at end of file
-- 
2.25.1

***

Regards
Padmarao

On Wed, 2022-10-12 at 09:36 -0500, Joel Sherrill wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know the content is safe
> Hi
> 
> I was looking at the bsp default settings for sparc/leon3 to show
> someone and noticed this which is out of place. 
> 
> # boot hartid (processor number) of risc-v cpu (default 0)
> RISCV_BOOT_HARTID = 0
> 
> I looked around and see it is an architecture specific ini setting
> but placed in a directory with architecture independent settings. We
> don't appear to have any other examples of a cpukit option that is
> architecture specific. So it is lumped in with all the architecture
> independent ini settings.
> 
> We had long discussions about presenting these options with better
> names, documentation, etc as part of the waf transition. Seems
> unfortunate to have this show up in all configurations.
> 
> Any thoughts on how to clean this up?
> 
> Thanks.
> 
> --joel
> 
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-docs] user/bsps: Update riscv for PolarFire SoC

[Padmarao.Begari]

Hi Alan,

Thank you for review.
I will update same in Patch v2.

Regards
Padmarao

From: Alan Cudmore 
Sent: Wednesday, October 5, 2022 7:52 PM
To: Padmarao Begari - I30397 
Cc: devel@rtems.org ; Cyril Jean - M31571 

Subject: Re: [PATCH rtems-docs] user/bsps: Update riscv for PolarFire SoC

Hi Padmarao,
The docs look good to me. I have a couple of minor comments inline.
I'm really glad to see this BSP in RTEMS.
Thanks,
Alan

On Wed, Sep 28, 2022 at 4:07 PM Padmarao Begari 
mailto:padmarao.beg...@microchip.com>> wrote:
Update the riscv documentation for the Microchip PolarFire SoC
BSP variant including information about SMP test procedure
for the Microchip PolarFire Icicle Kit.
---
 user/bsps/bsps-riscv.rst | 114 ++-
 1 file changed, 113 insertions(+), 1 deletion(-)

diff --git a/user/bsps/bsps-riscv.rst b/user/bsps/bsps-riscv.rst
index 5faa87b..be65a68 100644
--- a/user/bsps/bsps-riscv.rst
+++ b/user/bsps/bsps-riscv.rst
@@ -8,7 +8,7 @@ riscv (RISC-V)
 riscv
 =

-This BSP offers 13 variants:
+This BSP offers 15 variants:

 * rv32i

@@ -38,6 +38,8 @@ This BSP offers 13 variants:

 * frdme310arty

+* mpfs64imafdc
+
 Each variant corresponds to a GCC multilib.  A particular variant reflects an
 ISA with ABI and code model choice.

@@ -47,6 +49,9 @@ be started im machine mode.

 The reference platform for this BSP is the Qemu `virt` machine.

+The reference platform for the mpfs64imafdc BSP variant is the Microchip
+PolarFire SoC Icicle Kit.
+
 Build Configuration Options
 ---

@@ -94,6 +99,13 @@ configuration INI file. The ``waf`` defaults can be used to 
inspect the values.
  Enables support sifive Freedom E310 Arty board if defined to a non-zero
  value,otherwise it is disabled (disabled by default)

+``RISCV_ENABLE_MPFS_SUPPORT``
+ Enables support Microchip PolarFire SoC if defined to a non-zero
+ value, otherwise it is disabled (disabled by default).
+
+``RISCV_BOOT_HARTID``
+ The boot hartid (processor number) of risc-v cpu by default 0.
+
 Interrupt Controller
 

@@ -124,6 +136,106 @@ They are initialized according to the device tree.  The 
console driver does not
 configure the pins or peripheral clocks.  The console device is selected
 according to the device tree "/chosen/stdout-path" property value.

+Microchip PolarFire SoC
+---
+
+The PolarFire SoC is the 4x 64-bit RISC-V U54 cores and a 64-bit RISC-V
+E51 monitor core SoC from the Microchip.
+
+The ``mpfs64imafdc`` BSP variant supports the U54 cores not the E51 because
+the E51 monitor core is reserved for first stage bootloader
+(Hart Software Services) and default ``RISCV_BOOT_HARTID`` is 1.
I would suggest "... BSP variant supports the U54 cores but not the E51 because 
the E51 monitor core is reserved for the first stage bootloader (Hart Software 
Services). In order to boot from the first U54 core, ``RISCV_BOOT_HARTID`` is 
set to 1 by default.
+
+**SMP test procedure for the Microchip PolarFire Icicle Kit:**
+
+The "config.ini" file.
+
+.. code-block:: none
+
+[riscv/mpfs64imafdc]
+BUILD_TESTS = True
+RTEMS_POSIX_API=True
+RTEMS_SMP = True
+BSP_START_COPY_FDT_FROM_U_BOOT=False
+BSP_VERBOSE_FATAL_EXTENSION = False
+
+Build RTEMS.
+
+.. code-block:: shell
+
+$ ./waf configure --prefix=$HOME/rtems-start/rtems/6
+$ ./waf
+
+Convert .exe to .elf file.
+
+.. code-block:: shell
+
+$ riscv-rtems6-objcopy 
build/riscv/mpfs64imafdc/testsuites/smptests/smp01.exe 
build/riscv/mpfs64imafdc/testsuites/smptests/smp01.elf
I believe the .exe file is already .elf, so the file can be renamed or used as 
is. Probably OK to leave this since it makes it clear that the elf file format 
is needed for the next step.

Also, is it worth mentioning that the DTB is embedded in the BSP rather than 
loaded from the eMMC/SD card?
+
+Generate a payload for the `smp01.elf` using the `hss-payload-generator 
`_.
+
+* Copy `smp01.elf` file to the HSS/tools/hss-payload-generator/test directory.
+
+* Go to hss-payload-generator source directory.
+
+.. code-block:: shell
+
+$ cd hart-software-services/tools/hss-payload-generator
+
+* Edit test/uboot.yaml file for the hart entry points and correct name of the
+  binary file.
+
+.. code-block:: none
+
+set-name: 'PolarFire-SoC-HSS::RTEMS'
+hart-entry-points: {u54_1: '0x10', u54_2: '0x10', u54_3: 
'0x10', u54_4: '0x10'}
+payloads:
+ test/smp01.elf: {exec-addr: '0x10', owner-hart: u54_1, 
secondary-hart: u54_2, secondary-hart: u54_3, secondary-hart: u54_4, priv-mode: 
prv_m, skip-opensbi: true}
+
+* Generate payload
+
+.. code-block:: shell
+
+$ ./hss-payload-generator -c test/uboot.yaml payload.bin
+
+Once the payload binary is generated, it should be copied to the eMMC/SD.
+
+`FPGA 

Re: [PATCH] bsps: Improve riscv console FDT parsing

[Padmarao.Begari]

Hi Alan,

I tested this patch and it is working fine on the PolarFire SoC Icicle
Kit.

Thanks & Regards
Padmarao

> On Thu, 2022-09-29 at 12:19 -0400, Alan Cudmore wrote:
> Hi Padmarao,
> Could you try this patch on your Polarfire board? It works on the
> generic QEMU BSP and the BSP I am working on which uses the
> FRDME310ARTY/SiFive UART. It builds with the Polarfire BSP, but I am
> not able to test it. I downloaded and built QEMU that has Polarfire
> support, but I need to download and install SoftConsole to get the
> rest of the parts I need to prepare the binary.
> Thanks!
> Alan
>  
> From: Alan Cudmore
> Sent: Thursday, September 29, 2022 12:12 PM
> To: devel@rtems.org
> Cc: Alan Cudmore
> Subject: [PATCH] bsps: Improve riscv console FDT parsing
>  
> This fixes a problem with parsing the FDT compatible property by
> replacing the RISCV_CONSOLE_IS_COMPATIBLE macro with calls to
> the fdt_stringlist_contains function. The macro only works when
> the compatible FDT entry is a single string and not a list of
> strings. The new call will compare each item in the string list.
>  
> Close #4728.
> ---
> bsps/riscv/riscv/console/console-config.c | 14 +-
> 1 file changed, 5 insertions(+), 9 deletions(-)
>  
> diff --git a/bsps/riscv/riscv/console/console-config.c
> b/bsps/riscv/riscv/console/console-config.c
> index d962a5a418..7908c2f325 100644
> --- a/bsps/riscv/riscv/console/console-config.c
> +++ b/bsps/riscv/riscv/console/console-config.c
> @@ -139,10 +139,6 @@ static void riscv_console_set_reg_32(uintptr_t
> addr, uint8_t i, uint8_t val)
> }
> #endif
> -#define RISCV_CONSOLE_IS_COMPATIBLE(actual, actual_len, desired) \
> -  (actual_len == sizeof(desired) \
> - && memcmp(actual, desired, sizeof(desired) - 1) == 0)
> -
> static void riscv_console_probe(void)
> {
>const void *fdt;
> @@ -170,7 +166,7 @@ static void riscv_console_probe(void)
>  }
>  #if RISCV_ENABLE_HTIF_SUPPORT != 0
> -if (RISCV_CONSOLE_IS_COMPATIBLE(compat, compat_len,
> "ucb,htif0")) {
> +if (fdt_stringlist_contains(compat, compat_len, "ucb,htif0")) {
>htif_console_context_init(_console_instance.base, node);
>riscv_console.context = _console_instance.base;
> @@ -181,8 +177,8 @@ static void riscv_console_probe(void)
>  #if RISCV_CONSOLE_MAX_NS16550_DEVICES > 0
>  if (
> -  (RISCV_CONSOLE_IS_COMPATIBLE(compat, compat_len, "ns16550a")
> -  || RISCV_CONSOLE_IS_COMPATIBLE(compat, compat_len,
> "ns16750"))
> +(fdt_stringlist_contains(compat, compat_len, "ns16550a")
> +|| fdt_stringlist_contains(compat, compat_len, "ns16750"))
>  && ns16550_devices < RISCV_CONSOLE_MAX_NS16550_DEVICES
>  ) {
>ns16550_context *ctx;
> @@ -203,7 +199,7 @@ static void riscv_console_probe(void)
>  ctx->set_reg = riscv_console_set_reg_8;
>}
> -  if (RISCV_CONSOLE_IS_COMPATIBLE(compat, compat_len,
> "ns16750")) {
> +  if (fdt_stringlist_contains(compat, compat_len, "ns16750")) {
>  ctx->has_precision_clock_synthesizer = true;
>}
> @@ -243,7 +239,7 @@ static void riscv_console_probe(void)
> #endif
>  #if RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0
> -if (RISCV_CONSOLE_IS_COMPATIBLE(compat, compat_len,
> "sifive,uart0")) {
> +if (fdt_stringlist_contains(compat, compat_len, "sifive,uart0"))
> {
>fe310_uart_context *ctx;
>ctx = _uart_instance;
> --
> 2.34.1
>  
>  
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 0/4] Microchip PolarFire SoC support

[Padmarao.Begari]

Hi Chris,

Thank You for a tar file build, will try to build same using your repo.

Regards
Padmarao

> On Wed, 2022-09-21 at 14:34 +1000, Chris Johns wrote:
> 
> On 21/9/2022 3:03 am, Joel Sherrill wrote:
> > I have pushed this patch set. Please check that the merge is OK and
> > follow up
> > with an update to the Users Guide for those looking for this BSP.
> 
> Thanks. Great to see the addition of this BSP.
> 
> I have updated the RSB to include this BSP. I have also added this
> BSP to my
> deployment repo:
> 
>   https://git.rtems.org/chrisj/rtems-deployment.git/
> 
> https://git.rtems.org/chrisj/rtems-deployment.git/tree/config/6/polarfire-icicle-bsp-smp.ini
> 
> To build a tar file:
> 
>  git clone git://git.rtems.org/rtems-source-builder.git
>  git clone git://git.rtems.org/chrisj/rtems-deployment.git
>  cd rtems-deployment
>  ./waf configure --prefix=/opt/rtems --rsb=../rtems-source-builder
>  ./waf --targets=6/polarfire-icicle-bsp dry-run
>  ./waf --targets=6/polarfire-icicle-bsp
> 
> The results:
> 
> $ ls tar
> polarfire-icicle-bsp.tar.bz2
> 
> To have the tools and BSP installed when built add to configure `
> --install`.
> 
> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 0/4] Microchip PolarFire SoC support

[Padmarao.Begari]

Hi Joel,

> On Tue, 2022-09-20 at 12:03 -0500, Joel Sherrill wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know the content is safe
> I have pushed this patch set. Please check that the merge is OK and
> follow up with an update to the Users Guide for those looking for
> this BSP.
> 

Thank You.

I have checked the merge is OK. Sure, will update the User Guide for
this BSP.

Thanks & Regards
Padmarao

> Thanks.
> 
> On Tue, Sep 20, 2022 at 8:56 AM Joel Sherrill <
> joel.sherr...@gmail.com> wrote:
> > This procedure should be added to the Users Guide under the BSPs
> > section.
> > 
> > Otherwise, it looks like I should coordinate with Padmarao to make
> > sure it's ok after I merged it
> > 
> > On Tue, Sep 20, 2022, 1:50 AM 
> > wrote:
> > > RTEMS SMP on the Microchip PolarFire Icicle Kit
> > > 
> > > Test Procedure:
> > > 
> > > 1. Create the "config.ini" file with below content at rtems root 
> > > 
> > > [riscv/mpfs64imafdc]
> > > BUILD_TESTS = True
> > > RTEMS_POSIX_API=True
> > > RTEMS_SMP = True
> > > BSP_START_COPY_FDT_FROM_U_BOOT=False
> > > BSP_VERBOSE_FATAL_EXTENSION = False
> > > 
> > > 2. Build RTEMS
> > > $ ./waf configure --prefix=$HOME/rtems-start/rtems/6
> > > $ ./waf
> > > 
> > > 3. Convert .exe to .elf file
> > > 
> > > $ riscv-rtems6-objcopy 
> > > build/riscv/mpfs64imafdc/testsuites/smptests/sm
> > > p01.exe
> > >  build/riscv/mpfs64imafdc/testsuites/smptests/smp01.elf
> > > 
> > > 4. Generate the payload for the smp01.elf using the hss-payload-
> > > generator with hart-entry-points/exec-addr: 0x10
> > > 
> > > https://github.com/polarfire-soc/hart-software-services/tree/master/tools/hss-payload-generator
> > > 
> > > 5. Programming the'payload.bin' for the eMMC/SD
> > > 
> > >  5.1) Board setting and FPGA Programing
> > > 
> > > https://github.com/polarfire-soc/polarfire-soc-documentation/blob/master/boards/mpfs-icicle-kit-es/updating-icicle-kit/updating-icicle-kit-design-and-linux.md
> > > 
> > > 
> > >  5.2). Power Cycle the Microchip PolarFire Icicle Kit and stop at
> > > the  
> > >HSS.
> > > 
> > >  5.3) type "mmc" and then "usbdmsc" on the HSS terminal(UART0).
> > > 
> > >  5.4) Load payload from the Host PC.
> > > $ sudo dd if=payload.bin of=/dev/sdb bs=512
> > > 
> > >  5.5) Quit USB and Reset the Icicle Kit
> > > 
> > >  5.6) Serial terminal UART1 displays the SMP example messages   
> > > 
> > > *** BEGIN OF TEST SMP 1 ***
> > > *** TEST VERSION: 6.0.0.ef33f861e16de9bf4190a36e4d18062c7300986c
> > > *** TEST STATE: EXPECTED_PASS
> > > *** TEST BUILD: RTEMS_POSIX_API RTEMS_SMP
> > > *** TEST TOOLS: 12.1.1 20220622 (RTEMS 6, RSB
> > > 3cb78b0b815ba05d17f5c6
> > > 5865d246a8333aa087, Newlib ea99f21)
> > > 
> > > CPU 3 start task TA0
> > > CPU 2 running Task TA0 
> > > CPU 3 start task TA1
> > > CPU 1 running Task TA1 
> > > CPU 3 start task TA2
> > > CPU 0 running Task TA2 
> > > 
> > > *** END OF TEST SMP 1 ***
> > > 
> > > Regards
> > > Padmarao
> > > On Mon, 2022-09-19 at 18:30 +0530, Padmarao Begari wrote:
> > > > This patch set adds the Microchip PolarFire SoC BSP Variant
> > > > support to RISC-V 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, more
> > > > info available here:
> > > >   https://www.microchip.com/en-us/products/fpgas-and-plds/
> > > >   system-on-chip-fpgas/polarfire-soc-fpgas#Overview
> > > > 
> > > > This new BSP variant is added for the 4x U54 cores not for E51
> > > > because the E51 monitor core is resreved for first stage
> > > > bootloader (Hart Software Services).
> > > > 
> > > > The boot HARTID configurable is implemented for the riscv BSP
> > > > to work with individual hart(cpu core) or SMP.
> > > > 
> > > > This BSP support components: 4 CPU Cores (U54), Interrupt
> > > > controller (PLIC), Timer (CLINT), UART (16550-compatible)
> > > > work fine on actual Microchip PolarFire SoC Icicle Kit.
> > > > 
> > > > v2:
> > > > - Add a license and copyright information in dtb header file
> > > > - Use RISCV_BOOT_HARDID instead of RTEMS_BOOT_HARDID
> > > > - Add '_RISCV_Map_hardid_to_cpu_index()' and
> > > > '_RISCV_Map_cpu_index_to_hardid()' functions
> > > > - Change bsp_fdt_get() instead of bsp_fdt_copy() function for
> > > dtb
> > > > - Move dtb and dtb header configurable build option to the bsps
> > > > 
> > > > Padmarao Begari (4):
> > > >   bsps/riscv: Add device tree blob
> > > >   spec/build/bsps: Add dtb support
> > > >   bsps/riscv: Add Microchip PolarFire SoC BSP variant
> > > >   bsps/shared/: Use device tree blob
> > > > 
> > > >  bsps/riscv/riscv/clock/clockdrv.c |   6 +-
> > > >  bsps/riscv/riscv/config/mpfs64imafdc.cfg  |   9 +
> > > >  bsps/riscv/riscv/dts/mpfs.dts | 365
> > > +++
> > > >  bsps/riscv/riscv/include/bsp/mpfs-dtb.h   | 602
> > > > 

Re: [PATCH v2 0/4] Microchip PolarFire SoC support

[Padmarao.Begari]

RTEMS SMP on the Microchip PolarFire Icicle Kit

Test Procedure:

1. Create the "config.ini" file with below content at rtems root 

[riscv/mpfs64imafdc]
BUILD_TESTS = True
RTEMS_POSIX_API=True
RTEMS_SMP = True
BSP_START_COPY_FDT_FROM_U_BOOT=False
BSP_VERBOSE_FATAL_EXTENSION = False

2. Build RTEMS
$ ./waf configure --prefix=$HOME/rtems-start/rtems/6
$ ./waf

3. Convert .exe to .elf file

$ riscv-rtems6-objcopy  build/riscv/mpfs64imafdc/testsuites/smptests/sm
p01.exe
 build/riscv/mpfs64imafdc/testsuites/smptests/smp01.elf

4. Generate the payload for the smp01.elf using the hss-payload-
generator with hart-entry-points/exec-addr: 0x10

https://github.com/polarfire-soc/hart-software-services/tree/master/tools/hss-payload-generator

5. Programming the'payload.bin' for the eMMC/SD

 5.1) Board setting and FPGA Programing
  
https://github.com/polarfire-soc/polarfire-soc-documentation/blob/master/boards/mpfs-icicle-kit-es/updating-icicle-kit/updating-icicle-kit-design-and-linux.md


 5.2). Power Cycle the Microchip PolarFire Icicle Kit and stop at the  
   HSS.

 5.3) type "mmc" and then "usbdmsc" on the HSS terminal(UART0).

 5.4) Load payload from the Host PC.
$ sudo dd if=payload.bin of=/dev/sdb bs=512

 5.5) Quit USB and Reset the Icicle Kit

 5.6) Serial terminal UART1 displays the SMP example messages   

*** BEGIN OF TEST SMP 1 ***
*** TEST VERSION: 6.0.0.ef33f861e16de9bf4190a36e4d18062c7300986c
*** TEST STATE: EXPECTED_PASS
*** TEST BUILD: RTEMS_POSIX_API RTEMS_SMP
*** TEST TOOLS: 12.1.1 20220622 (RTEMS 6, RSB 3cb78b0b815ba05d17f5c6
5865d246a8333aa087, Newlib ea99f21)

CPU 3 start task TA0
CPU 2 running Task TA0 
CPU 3 start task TA1
CPU 1 running Task TA1 
CPU 3 start task TA2
CPU 0 running Task TA2 

*** END OF TEST SMP 1 ***

Regards
Padmarao
On Mon, 2022-09-19 at 18:30 +0530, Padmarao Begari wrote:
> This patch set adds the Microchip PolarFire SoC BSP Variant
> support to RISC-V 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, more
> info available here:
>   https://www.microchip.com/en-us/products/fpgas-and-plds/
>   system-on-chip-fpgas/polarfire-soc-fpgas#Overview
> 
> This new BSP variant is added for the 4x U54 cores not for E51
> because the E51 monitor core is resreved for first stage
> bootloader (Hart Software Services).
> 
> The boot HARTID configurable is implemented for the riscv BSP
> to work with individual hart(cpu core) or SMP.
> 
> This BSP support components: 4 CPU Cores (U54), Interrupt
> controller (PLIC), Timer (CLINT), UART (16550-compatible)
> work fine on actual Microchip PolarFire SoC Icicle Kit.
> 
> v2:
> - Add a license and copyright information in dtb header file
> - Use RISCV_BOOT_HARDID instead of RTEMS_BOOT_HARDID
> - Add '_RISCV_Map_hardid_to_cpu_index()' and
> '_RISCV_Map_cpu_index_to_hardid()' functions
> - Change bsp_fdt_get() instead of bsp_fdt_copy() function for dtb
> - Move dtb and dtb header configurable build option to the bsps
> 
> Padmarao Begari (4):
>   bsps/riscv: Add device tree blob
>   spec/build/bsps: Add dtb support
>   bsps/riscv: Add Microchip PolarFire SoC BSP variant
>   bsps/shared/: Use device tree blob
> 
>  bsps/riscv/riscv/clock/clockdrv.c |   6 +-
>  bsps/riscv/riscv/config/mpfs64imafdc.cfg  |   9 +
>  bsps/riscv/riscv/dts/mpfs.dts | 365 +++
>  bsps/riscv/riscv/include/bsp/mpfs-dtb.h   | 602
> ++
>  bsps/riscv/riscv/include/bsp/riscv.h  |  14 +
>  bsps/riscv/riscv/irq/irq.c|  81 +++
>  bsps/riscv/riscv/start/bsp_fatal_halt.c   |   3 +
>  bsps/riscv/riscv/start/bspsmp.c   |   2 +-
>  bsps/riscv/riscv/start/bspstart.c |  19 +-
>  bsps/riscv/shared/start/start.S   |   2 +
>  bsps/shared/start/bsp-fdt.c   |   8 +
>  .../score/cpu/riscv/include/rtems/score/cpu.h |   2 +-
>  .../cpu/riscv/include/rtems/score/cpuimpl.h   |   2 +-
>  spec/build/bsps/optdtb.yml|  19 +
>  spec/build/bsps/optdtbheaderpath.yml  |  20 +
>  spec/build/bsps/riscv/optextirqmax.yml|   5 +-
>  spec/build/bsps/riscv/optrambegin.yml |   5 +-
>  spec/build/bsps/riscv/optramsize.yml  |   5 +-
>  spec/build/bsps/riscv/riscv/abi.yml   |   6 +
>  .../bsps/riscv/riscv/bspmpfs64imafdc.yml  |  19 +
>  spec/build/bsps/riscv/riscv/grp.yml   |   6 +
>  spec/build/bsps/riscv/riscv/optmpfs.yml   |  18 +
>  spec/build/bsps/riscv/riscv/optns16550max.yml |   3 +
>  spec/build/cpukit/cpuopts.yml |   2 +
>  spec/build/cpukit/optarchbits.yml |   1 +
>  spec/build/cpukit/optboothartid.yml   |  19 +
>  

Re: [PATCH v2 0/4] Microchip PolarFire SoC support

[Padmarao.Begari]

Hi Alan,

> On Mon, 2022-09-19 at 12:49 -0400, Alan Cudmore wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know the content is safe
> Hi Padmarao,
> The patches apply cleanly and build for me. What is the recommended
> config.ini file for this BSP?
> I used:
> [riscv/mpfs64imafdc]
> BUILD_TESTS=True
> RTEMS_POSIX_API=True
> RTEMS_SMP=True
> BSP_START_COPY_FDT_FROM_U_BOOT=False
> BSP_DTB_IS_SUPPORTED=True
> BSP_DTB_HEADER_PATH=bsp/mpfs-dtb.h
> 
Yes We can use same like your config.ini file, working fine for me.

The BSP is enabled the 'BSP_DTB_IS_SUPPORTED' and 'BSP_DTB_HEADER_PATH'
by default so I used like below:

[riscv/mpfs64imafdc]
BUILD_TESTS=True
RTEMS_SMP=True
BSP_START_COPY_FDT_FROM_U_BOOT=False

> I don't have a Polarfire SoC board, but is there a QEMU platform to
> run this on?
> 

Yes QEMU Platform is there for the Microchip PolarFire SoC Icicle Kit
but I didn't test it.

Regards
Padmarao
> When this is in, I will rebase my k210 variant and eventually get it
> submitted!
> Thanks,
> Alan
> 
> On Mon, Sep 19, 2022 at 9:00 AM Padmarao Begari <
> padmarao.beg...@microchip.com> wrote:
> > This patch set adds the Microchip PolarFire SoC BSP Variant
> > support to RISC-V 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, more
> > info available here:
> > https://www.microchip.com/en-us/products/fpgas-and-plds/
> > system-on-chip-fpgas/polarfire-soc-fpgas#Overview
> > 
> > This new BSP variant is added for the 4x U54 cores not for E51
> > because the E51 monitor core is resreved for first stage
> > bootloader (Hart Software Services).
> > 
> > The boot HARTID configurable is implemented for the riscv BSP
> > to work with individual hart(cpu core) or SMP.
> > 
> > This BSP support components: 4 CPU Cores (U54), Interrupt
> > controller (PLIC), Timer (CLINT), UART (16550-compatible)
> > work fine on actual Microchip PolarFire SoC Icicle Kit.
> > 
> > v2:
> > - Add a license and copyright information in dtb header file
> > - Use RISCV_BOOT_HARDID instead of RTEMS_BOOT_HARDID
> > - Add '_RISCV_Map_hardid_to_cpu_index()' and
> > '_RISCV_Map_cpu_index_to_hardid()' functions
> > - Change bsp_fdt_get() instead of bsp_fdt_copy() function for dtb
> > - Move dtb and dtb header configurable build option to the bsps
> > 
> > Padmarao Begari (4):
> >   bsps/riscv: Add device tree blob
> >   spec/build/bsps: Add dtb support
> >   bsps/riscv: Add Microchip PolarFire SoC BSP variant
> >   bsps/shared/: Use device tree blob
> > 
> >  bsps/riscv/riscv/clock/clockdrv.c |   6 +-
> >  bsps/riscv/riscv/config/mpfs64imafdc.cfg  |   9 +
> >  bsps/riscv/riscv/dts/mpfs.dts | 365 +++
> >  bsps/riscv/riscv/include/bsp/mpfs-dtb.h   | 602
> > ++
> >  bsps/riscv/riscv/include/bsp/riscv.h  |  14 +
> >  bsps/riscv/riscv/irq/irq.c|  81 +++
> >  bsps/riscv/riscv/start/bsp_fatal_halt.c   |   3 +
> >  bsps/riscv/riscv/start/bspsmp.c   |   2 +-
> >  bsps/riscv/riscv/start/bspstart.c |  19 +-
> >  bsps/riscv/shared/start/start.S   |   2 +
> >  bsps/shared/start/bsp-fdt.c   |   8 +
> >  .../score/cpu/riscv/include/rtems/score/cpu.h |   2 +-
> >  .../cpu/riscv/include/rtems/score/cpuimpl.h   |   2 +-
> >  spec/build/bsps/optdtb.yml|  19 +
> >  spec/build/bsps/optdtbheaderpath.yml  |  20 +
> >  spec/build/bsps/riscv/optextirqmax.yml|   5 +-
> >  spec/build/bsps/riscv/optrambegin.yml |   5 +-
> >  spec/build/bsps/riscv/optramsize.yml  |   5 +-
> >  spec/build/bsps/riscv/riscv/abi.yml   |   6 +
> >  .../bsps/riscv/riscv/bspmpfs64imafdc.yml  |  19 +
> >  spec/build/bsps/riscv/riscv/grp.yml   |   6 +
> >  spec/build/bsps/riscv/riscv/optmpfs.yml   |  18 +
> >  spec/build/bsps/riscv/riscv/optns16550max.yml |   3 +
> >  spec/build/cpukit/cpuopts.yml |   2 +
> >  spec/build/cpukit/optarchbits.yml |   1 +
> >  spec/build/cpukit/optboothartid.yml   |  19 +
> >  spec/build/cpukit/optsmp.yml  |   1 +
> >  27 files changed, 1235 insertions(+), 9 deletions(-)
> >  create mode 100644 bsps/riscv/riscv/config/mpfs64imafdc.cfg
> >  create mode 100644 bsps/riscv/riscv/dts/mpfs.dts
> >  create mode 100644 bsps/riscv/riscv/include/bsp/mpfs-dtb.h
> >  create mode 100644 spec/build/bsps/optdtb.yml
> >  create mode 100644 spec/build/bsps/optdtbheaderpath.yml
> >  create mode 100644 spec/build/bsps/riscv/riscv/bspmpfs64imafdc.yml
> >  create mode 100644 spec/build/bsps/riscv/riscv/optmpfs.yml
> >  create mode 100644 spec/build/cpukit/optboothartid.yml
> > 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel