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