[PATCH] RTEMS BSP Buildset

[Jonathan Brandmeyer]

On Mon, Aug 12, 2019 at 12:10 AM Chris Johns <chrisj at 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