RTEMS on PolarFire SoC ICICLE Kit FPGA

[somesh deshmukh]

Hi,

The diff between the changed files is mentioned below. The default riscv
clock driver is recently updated and it includes the changes I was
proposing.

--- /rtems/bsps/riscv/riscv/console/console-config.c 2021-04-23
16:01:13.355468092 +0530
+++ /quick-start/rtems/bsps/riscv/riscv/console/console-config.c 2021-04-24
21:08:55.000000000 +0530
@@ -91,7 +91,7 @@
     stdout_path = "";
   }

-#if RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0
+#if ((RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0) ||
(RISCV_CONSOLE_MAX_NS16550_DEVICES > 0))
   int root;
   int soc;
   root = fdt_path_offset(fdt, "/");
@@ -318,7 +318,7 @@

     rtems_termios_device_install(
       path,
-      &ns16550_handler_interrupt,
+      &ns16550_handler_polled,
       NULL,
       &ctx->base
     );

--- /rtems/spec/build/bsps/riscv/riscv/bsprv64imafdcmedany.yml 2021-04-23
16:01:13.563436275 +0530
+++ /quick-start/rtems/spec/build/bsps/riscv/riscv/bsprv64imafdcmedany.yml
2021-03-26 14:30:37.454515153 +0530
@@ -12,7 +12,7 @@
 install: []
 links:
 - role: build-dependency
-  uid: ../../opto2
+  uid: ../../opto0
 - role: build-dependency
   uid: grp
 source: []

--- /rtems/bsps/riscv/shared/start/start.S 2021-04-23 16:01:13.359467480
+0530
+++ /quick-start/rtems/bsps/riscv/shared/start/start.S 2021-03-18
11:16:47.608079073 +0530
@@ -74,17 +74,18 @@
  LADDR sp, _ISR_Stack_area_end
 #endif

+/* Clear .bss */
+LADDR a0, bsp_section_bss_begin
+li a1, 0
+LADDR a2, bsp_section_bss_size
+call memset
+
 #ifdef BSP_START_COPY_FDT_FROM_U_BOOT
  mv a0, a1
  call bsp_fdt_copy
 #endif

- /* Clear .bss */
- LADDR a0, bsp_section_bss_begin
- li a1, 0
- LADDR a2, bsp_section_bss_size
- call memset
-
 #ifdef RTEMS_SMP
  /* Give go to secondary processors */
  LADDR t0, .Lsecondary_processor_go

Let me know if you have any comments/suggestions for the above changes.

Regards,
Somesh

On Fri, Apr 23, 2021 at 5:15 PM Joel Sherrill <joel at rtems.org> wrote:

> I agree with Karel that a diff posted would be appreciated. It.would be
> nice to see this worked through and merged. Also updates to the Users Guide
> on this.
>
> On Thu, Apr 22, 2021, 10:52 PM somesh deshmukh <someshdeshmukh07 at gmail.com>
> wrote:
>
>> I was able to test the rtems hello-world example and ticker example on
>> the polarfire soc icicle kit.
>>
>> A little background about Polarfire SoC ICICLE Kit.
>> The PolarFire SoC Icicle kit is a low-cost development platform that
>> enables the evaluation of the five-core Linux capable RISC-V microprocessor
>> subsystem. It includes
>>
>>    - SiFive E51 Monitor core (1 x RV64IMAC)
>>    - SiFive U54 Application cores (4 x RV64GC)
>>
>> More info is available at the link below:
>> https://www.microsemi.com/existing-parts/parts/152514
>>
>> There were few changes I had to make in the rtems source code to make it
>> work, as mentioned below.
>>
>> 1. In the startup code the bsp_fdt_copy copies the device tree blob from
>> the address from #a1 register to the .rodata section. This is followed by a
>> memset operation for the bss section.
>> The problem was the call to a memset function was clearing the device
>> tree blob copied in the bsp_fdt_copy() operation.
>> To fix this I performed the memset first and then bsp_fdt_copy operation.
>>
>
> This sounds like a bug from what you describe. Patch will show.
>
>>
>> 2. The riscv_console_probe() will try to read the console_node from the
>> device tree. The original code provided for ns16550 UART was not able to
>> read the console node from the device tree correctly.
>> To fix this I used the sifive code to read the console node. The sifive
>> code was limited to only sifive-uart.
>>
>
> We'll have to see. This may require more smarts in the console driver to
> support both. Or a BSP variant.
>
>
>
>> 3. RTEMS uses -O2 as default optimization settings. With these settings,
>> we were facing a trap while trying to perform the open call on the console
>> device after mounting the file system.
>> To fix this I changed the optimization to -O0 and it resolved the issue.
>> I need to debug this more to find the exact cause.
>>
>
> This is unfortunate. Could be anything from a driver missing a volatile to
> bad code generation. You can try at different optimisation levels and that
> narrows down things a bit. You are right. This requires debugging.
>
>
>> 4. The default clock driver simply assumes that the code is running on
>> hart0. This was breaking the ticker example testing.
>> To fix this I updated the clock driver to read the hart ID and then
>> configure the
>> mtimecmp register accordingly.
>>
>
> This sounds like an improvement.
>
>
>> Let me know if these changes are valid.
>>
>
> Patches welcome and then we shall see.
>
>>
>>
>> Regards,
>> Somesh
>>
>>
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210425/5be66daa/attachment.html>