<div dir="ltr"><div>Hi,</div><div><br></div><div>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.</div><div><br></div><div>--- /rtems/bsps/riscv/riscv/console/console-config.c 2021-04-23 16:01:13.355468092 +0530<br>+++ /quick-start/rtems/bsps/riscv/riscv/console/console-config.c 2021-04-24 21:08:55.000000000 +0530<br>@@ -91,7 +91,7 @@<br> stdout_path = "";<br> }<br> <br>-#if RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0<br>+#if ((RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0) || (RISCV_CONSOLE_MAX_NS16550_DEVICES > 0))<br> int root;<br> int soc;<br> root = fdt_path_offset(fdt, "/");<br>@@ -318,7 +318,7 @@<br> <br> rtems_termios_device_install(<br> path,<br>- &ns16550_handler_interrupt,<br>+ &ns16550_handler_polled,<br> NULL,<br> &ctx->base<br> );<br> <br>--- /rtems/spec/build/bsps/riscv/riscv/bsprv64imafdcmedany.yml 2021-04-23 16:01:13.563436275 +0530<br>+++ /quick-start/rtems/spec/build/bsps/riscv/riscv/bsprv64imafdcmedany.yml 2021-03-26 14:30:37.454515153 +0530<br>@@ -12,7 +12,7 @@<br> install: []<br> links:<br> - role: build-dependency<br>- uid: ../../opto2<br>+ uid: ../../opto0<br> - role: build-dependency<br> uid: grp<br> source: []<br> <br>--- /rtems/bsps/riscv/shared/start/start.S 2021-04-23 16:01:13.359467480 +0530<br>+++ /quick-start/rtems/bsps/riscv/shared/start/start.S 2021-03-18 11:16:47.608079073 +0530<br>@@ -74,17 +74,18 @@<br> LADDR sp, _ISR_Stack_area_end<br> #endif<br> <br>+/* Clear .bss */<br>+LADDR a0, bsp_section_bss_begin<br>+li a1, 0<br>+LADDR a2, bsp_section_bss_size<br>+call memset<br>+<br> #ifdef BSP_START_COPY_FDT_FROM_U_BOOT<br> mv a0, a1<br> call bsp_fdt_copy<br> #endif<br> <br>- /* Clear .bss */<br>- LADDR a0, bsp_section_bss_begin<br>- li a1, 0<br>- LADDR a2, bsp_section_bss_size<br>- call memset<br>-<br> #ifdef RTEMS_SMP<br> /* Give go to secondary processors */<br> LADDR t0, .Lsecondary_processor_go</div><div><br></div><div>Let me know if you have any comments/suggestions for the above changes.<br></div><div><br></div><div>Regards,</div><div>Somesh<br></div><div><br></div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 23, 2021 at 5:15 PM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div>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.<br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 22, 2021, 10:52 PM somesh deshmukh <<a href="mailto:someshdeshmukh07@gmail.com" target="_blank">someshdeshmukh07@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">
<div>I was able to test the rtems hello-world example and ticker example on the polarfire soc icicle kit. <br></div><div><br></div><div>A little background about Polarfire SoC ICICLE Kit.</div><div>
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</div><div>
</div><ul><li>SiFive E51 Monitor core (1 x RV64IMAC)</li><li>SiFive U54 Application cores (4 x RV64GC)</li></ul><div>More info is available at the link below:<br></div><div><a href="https://www.microsemi.com/existing-parts/parts/152514" rel="noreferrer" target="_blank">https://www.microsemi.com/existing-parts/parts/152514</a></div><div><br></div><div>There were few changes I had to make in the rtems source code to make it work, as mentioned below.</div><div><br></div><div>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. <br></div><div>The problem was the call to a memset function was clearing the device tree blob copied in the bsp_fdt_copy() operation. <br></div><div>To fix this I performed the memset first and then bsp_fdt_copy operation.</div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">This sounds like a bug from what you describe. Patch will show.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>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. <br>To fix this I used the sifive code to read the console node. The sifive code was limited to only sifive-uart.</div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">We'll have to see. This may require more smarts in the console driver to support both. Or a BSP variant.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>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.</div><div>To fix this I changed the optimization to -O0 and it resolved the issue.</div><div>I need to debug this more to find the exact cause.<br></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div><br></div><div>4. The default clock driver simply assumes that the code is running on hart0. This was breaking the ticker example testing.</div><div><div>To fix this I updated the clock driver to read the hart ID and then configure the<br>mtimecmp register accordingly.</div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">This sounds like an improvement.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><br></div><div>Let me know if these changes are valid.</div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Patches welcome and then we shall see.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div> <br></div><div><br></div><div>Regards,</div><div>Somesh<br></div><div><br></div><div><br></div></div>
</div>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" rel="noreferrer" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div></div>
</blockquote></div></div></div>