On Mon, Aug 12, 2019 at 12:10 AM Chris Johns <chr...@rtems.org> wrote: > >>> If it boots via a device tree, then the RTEMS BSP should do this as well.
Current generation petalinux generates a device tree for Linux. > >> > >> How would you integrate the Xilinx tools to handle this, ie ps7_init and > >> friends? IMO, RTEMS doesn't need to incorporate the functionality of the Xilinx bootloaders. It just needs to cooperate with them. Clock init, I/O init and FPGA fabric init are all in the scope of the bootloader. Some things can be scoped into user application code (such as fabric re-initialization). But I don't really expect RTEMS to manage SDRAM initialization. RTEMS should just deal with the memory map and system clock frequencies that it is given. It would be nice to have some additional driver support for the things that RTEMS already has hardware abstractions for. But it isn't outrageously difficult to use Xilinx bare-metal drivers as a base for application code in the RTEMS environment. Xilinx' licenses are liberal enough to allow it. > > I don't know the Xilinx Zynq good enough. How do yo get the device > > capabilities > > and memory map if you don't have a device tree? The device tree is an open > > format for this purpose. > > Yeah good question. The Xilinx SDK is designed to pick up a range of defined > values from generated header files, this is the bare metal approach Right now, this is the approach I'm using for handing clock information off to RTEMS. I'm overriding the weak symbols `zynq_uart_input_clock`, `a9mpcore_clock_periphclk` and `zynq_setup_mmu_and_cache` to pass information from Xilinx generated headers to RTEMS. RTEMS' Zynq BSP provides fixed base addresses for the minimal set of peripherals needed to boot RTEMS, and that's about it. -- Jonathan Brandmeyer _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
