Hello Somesh, On Sat, 24 Apr 2021 at 20:52, somesh deshmukh <someshdeshmuk...@gmail.com> wrote: > > 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, Doesn't your UART support interrupts? Could you also paste your DTS?
> 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 > + That shouldn't be a bug on the RTEMS side. It seems like your placed FDT overlaps with RAM/BSS area. How/where are you embedding the FDT? > #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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
