<div dir="ltr"><div>Hi Hesham,</div><div><br></div><div>Comments added below and please find the attached device tree source file.</div><div><br></div><div>Regards,</div><div>Somesh<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Apr 25, 2021 at 12:34 AM Hesham Almatary <<a href="mailto:hesham.almatary@cl.cam.ac.uk">hesham.almatary@cl.cam.ac.uk</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">Hello Somesh,<br>
<br>
On Sat, 24 Apr 2021 at 20:52, somesh deshmukh<br>
<<a href="mailto:someshdeshmukh07@gmail.com" target="_blank">someshdeshmukh07@gmail.com</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> 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.<br>
><br>
> --- /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>
Doesn't your UART support interrupts? Could you also paste your DTS?<br></blockquote><div><span style="font-family:comic sans ms,sans-serif"> <i>  <font size="2"><span style="font-family:arial,sans-serif">>>     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. <br>    >>     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. </span></font></i></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<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>
That shouldn't be a bug on the RTEMS side. It seems like your placed<br>
FDT overlaps with RAM/BSS area. How/where are you embedding the FDT?<br></blockquote><div> <i>   >> Yes. The fdt overlaps with the BSS area. The DTB is available at 0x80000000 location and the same address is passed to<br>    >> #a1 register. The bsp_fdt_blob is getting address from .BSS section. <br><br>    >> #ifdef BSP_START_COPY_FDT_FROM_U_BOOT<br>    >>  li  a1, 0x80000000<br>    >> mv  a0, a1<br>    >> call    bsp_fdt_copy<br><br>    >> This is the startup code that copies the fdt blob address in a1 register manually. after this, the bsp_fdt_cpoy will copy the <br>    >>  fdt blob from 0x80000000 to local memory. <br></i></div><div><i><br></i></div><div><i>    Sections:<br>Idx Name           Size            VMA                                        LMA               File off  Algn  Flags<br> 13 .bss           00013ae8  0000000080124e40  0000000080124e40  00025d98  2**6  ALLOC</i></div><div><i>  <br></i></div><div><i>SYMBOL TABLE:<br></i></div><div><i>        0000000080127ac0 l     O .bss    0000000000010000 bsp_fdt_blob</i></div><div><i><br></i></div><div><i>   <br></i></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<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<br>
><br>
> Let me know if you have any comments/suggestions for the above changes.<br>
><br>
> Regards,<br>
> Somesh<br>
><br>
> 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>
>><br>
>> 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>
>> On Thu, Apr 22, 2021, 10:52 PM somesh deshmukh <<a href="mailto:someshdeshmukh07@gmail.com" target="_blank">someshdeshmukh07@gmail.com</a>> wrote:<br>
>>><br>
>>> I was able to test the rtems hello-world example and ticker example on the polarfire soc icicle kit.<br>
>>><br>
>>> A little background about Polarfire SoC ICICLE Kit.<br>
>>> 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<br>
>>><br>
>>> SiFive E51 Monitor core (1 x RV64IMAC)<br>
>>> SiFive U54 Application cores (4 x RV64GC)<br>
>>><br>
>>> More info is available at the link below:<br>
>>> <a href="https://www.microsemi.com/existing-parts/parts/152514" rel="noreferrer" target="_blank">https://www.microsemi.com/existing-parts/parts/152514</a><br>
>>><br>
>>> There were few changes I had to make in the rtems source code to make it work, as mentioned below.<br>
>>><br>
>>> 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>
>>> The problem was the call to a memset function was clearing the device tree blob copied in the bsp_fdt_copy() operation.<br>
>>> To fix this I performed the memset first and then bsp_fdt_copy operation.<br>
>><br>
>><br>
>> This sounds like a bug from what you describe. Patch will show.<br>
>>><br>
>>><br>
>>> 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.<br>
>><br>
>><br>
>> We'll have to see. This may require more smarts in the console driver to support both. Or a BSP variant.<br>
>><br>
>><br>
>>><br>
>>> 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.<br>
>>> To fix this I changed the optimization to -O0 and it resolved the issue.<br>
>>> I need to debug this more to find the exact cause.<br>
>><br>
>><br>
>> 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.<br>
>><br>
>>><br>
>>> 4. The default clock driver simply assumes that the code is running on hart0. This was breaking the ticker example testing.<br>
>>> To fix this I updated the clock driver to read the hart ID and then configure the<br>
>>> mtimecmp register accordingly.<br>
>><br>
>><br>
>> This sounds like an improvement.<br>
>><br>
>>><br>
>>> Let me know if these changes are valid.<br>
>><br>
>><br>
>> Patches welcome and then we shall see.<br>
>>><br>
>>><br>
>>><br>
>>> Regards,<br>
>>> Somesh<br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> devel mailing list<br>
>>> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
>>> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
><br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote></div></div>