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, 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 + #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 <j...@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 <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