[PATCH] RTEMS BSP Buildset

[Chris Johns]

On 13/8/19 2:46 am, Jonathan Brandmeyer wrote:
> 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.
> 

Hmm.

>>>>
>>>> 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.

I see it as being more subtle than this. Yes the bootloader should handle SDRAM,
critical clocks and similar low level support but the bootloader's paint of the
hardware covers everything including the default baudrate for the console. This
is why there is no code to set the baudrate in the console driver in the Zynq. A
change in SystemZ is a change in your BSP.

Your hardware team needs to know what changes they can make and how it effects
the software. If you support field upgradable applications and one version needs
a change to match a specific bitfile you have to update the specific registers
in the application as the bootloader will not do this and that specific
application and bitfile needs to be joined together some how. These links are
human based and not easy to audit in a formal way.

> It would be nice to have some additional driver support for the things
> that RTEMS already has hardware abstractions for.

We are happy to accept patches or contact a support service to have them added. :)

> But it isn't
> outrageously difficult to use Xilinx bare-metal drivers as a base for
> application code in the RTEMS environment.

You end up needing to reference the generated headers or you need to provide a
means to incorporate those defines.

LibBSD seems to be filling in the pieces we need.

> Xilinx' licenses are liberal enough to allow it.

They are now after Joel and I visited Xilinx a number of times _and_ they
listened to us. When the Zynq was first added the license did not allow us to
add the code to RTEMS. Xilinx has been great to work with.

>>> 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.

Great, this is how it was intended to be used. It would be nice to have a
section on this in the user manual's Zynq BSP section ... :) :)

Chris