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. *
>
> > 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 <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
>
icicle.dts
Description: audio/vnd.dts
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
