RTEMS on PolarFire SoC ICICLE Kit FPGA

[Joel Sherrill]

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/20210423/b94425ef/attachment-0001.html>