Hi Somesh,
your information are very interesting. Is it possible for your to send a diff of your changes? Thanks, Karel On 4/23/21 5:52 AM, somesh deshmukh 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 > <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. > > 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. > > 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. > > 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. > > Let me know if these changes are valid. > > 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
