RTEMS on PolarFire SoC ICICLE Kit FPGA

Sat Apr 24 19:04:05 UTC 2021

Hello Somesh,

On Sat, 24 Apr 2021 at 20:52, somesh deshmukh
<someshdeshmukh07 at gmail.com> wrote:
>
> 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,
Doesn't your UART support interrupts? Could you also paste your DTS?

>        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
> +
That shouldn't be a bug on the RTEMS side. It seems like your placed
FDT overlaps with RAM/BSS area. How/where are you embedding the FDT?

>  #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
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel