On Sun, 25 Apr 2021 at 21:04, somesh deshmukh <someshdeshmuk...@gmail.com> wrote: > > Hi Hesham, > > Comments added below and please find the attached device tree source file. > > Regards, > Somesh > > On Sun, Apr 25, 2021 at 12:34 AM Hesham Almatary > <hesham.almat...@cl.cam.ac.uk> wrote: >> >> 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? > > >> Yes, my UART supports interrupt mode but in the console-config.c > line 234 and 235 we are assigning the ns16550_polled_putchar and > ns16550_polled_getchar for write and read respectively. Because of this > assignment I wanted to initialize the console as ns16550_handler_polled. > >> But this is not the issue I faced, I was facing a problem in > riscv_get_console_node(diff have the change I made). Without that change, I > was not able to read the console_node correctly for ns16550. Yeah please submit a separate patch for that so that we can review and push it.
>> >> >> > 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? > > >> Yes. The fdt overlaps with the BSS area. The DTB is available at > 0x80000000 location and the same address is passed to > >> #a1 register. The bsp_fdt_blob is getting address from .BSS section. > Right, it is the RTEMS allocated bsp_fdt_blob that's placed in the BSS. If you can submit another patch for that it will be great. Please read https://docs.rtems.org/branches/master/user/support/contrib.html > >> #ifdef BSP_START_COPY_FDT_FROM_U_BOOT > >> li a1, 0x80000000 > >> mv a0, a1 > >> call bsp_fdt_copy > > >> This is the startup code that copies the fdt blob address in a1 > register manually. after this, the bsp_fdt_cpoy will copy the > >> fdt blob from 0x80000000 to local memory. > > Sections: > Idx Name Size VMA > LMA File off Algn Flags > 13 .bss 00013ae8 0000000080124e40 0000000080124e40 00025d98 > 2**6 ALLOC > > SYMBOL TABLE: > 0000000080127ac0 l O .bss 0000000000010000 bsp_fdt_blob > > >> >> >> > #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
