Francescodario Cuzzocrea commented on a discussion on bsps/riscv/shared/start/bspgetworkarea.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/194#note_112111 > int ac; > int sc; > int len; > + uint64_t start64; > + uint64_t size64; > + uint64_t start32; > + uint64_t size32; The existing MPFS DTS for on Beagle V Fire board will not work on Beagle V Fire. That MPFS DTS it is valid only on ICICLE Kit with Microchip reference design loaded on it, which is configured to have 4 UARTs (UART0,1,2,3), with UART0 being reserved for HSS. With this configuration, when you load RTEMS, on UART0 there will be the output of the HSS and on UART1 there is the output of RTEMS. Beagle V Fire FPGA reference design is configured differently. It is configured to only have one UART (UART0) and HSS is configured to release UART0 after booting the payload, so UART0 can be used by the payload, which can be either RTEMS, Linux, or any other RTOS/OS. DTS on Polarfire SoC FPGA based devices it is stricly coupled with the FPGA design which is loaded on the SoC itself, and as a consequence must be adapted according to the hard controllers which are enabled in the Polarfire SoC configurator and to the soft controllers that are eventually added in the FPGA design. Indeed I believe that in current RTEMS tree the DTS naming is misleading, that should really be mpfs-icicle-kit.dts, because it is valid for ICICLE Kit with reference design only. What I was proposing in my previous commit was to rework DTS handling in the same way the Linux kernel handles it : https://github.com/torvalds/linux/tree/master/arch/riscv/boot/dts/microchip as you can see in here there is a common mpfs.dtsi, which includes the configuration for all the hard controllers which are present on the Polarfire SoC FPGA, defaulting with each controller being disabled. Then, for each Polarfire SoC FPGA supported device there is a -fabric.dtsi fragment with the configuration for the soft peripherals. Finally, for each board there is the mpfs-board-name.dts which inherits from the common and the fabric dtsi and enables the hard controllers which are configured on the board. I believe this is the most common and straightforward way to use devicetree to configure those Microchip Polarfire SoC devices, but it requires some modification to the build system as I said before (we need to compile DTB at RTEMS build time instead of relying on a prebuilt DTB). -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/194#note_112111 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
