RTEMS on PolarFire SoC ICICLE Kit FPGA

somesh deshmukh someshdeshmukh07 at gmail.com
Sun Apr 25 19:04:27 UTC 2021 

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.almatary at cl.cam.ac.uk> wrote:

> Hello Somesh,
>
> On Sat, 24 Apr 2021 at 20:52, somesh deshmukh
> <someshdeshmukh07 at 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. *

>
> >        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.     >> #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 <joel at 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 <
> someshdeshmukh07 at 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 at rtems.org
> >>> http://lists.rtems.org/mailman/listinfo/devel
> >
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210426/a107df39/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: icicle.dts
Type: audio/vnd.dts
Size: 3219 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210426/a107df39/attachment-0001.bin>

More information about the devel mailing list