RTEMS on PolarFire SoC ICICLE Kit FPGA
Hesham Almatary
hesham.almatary at cl.cam.ac.uk
Mon Apr 26 18:51:28 UTC 2021
On Sun, 25 Apr 2021 at 21:04, somesh deshmukh
<someshdeshmukh07 at 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.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.
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 <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
More information about the devel
mailing list