[PATCH] RTEMS BSP Buildset

[Chris Johns]

On 12/8/19 3:13 pm, Sebastian Huber wrote:
> On 10/08/2019 01:40, Chris Johns wrote:
>> On 10/8/19 2:54 am, Sebastian Huber wrote:
>>> just my 2ct with respect to the lacking device tree support in the Xilinx
>>> Zynq BSP. This is just a historic accident. The BSP was written before we had
>>> any device tree support in RTEMS.
>>
>> FDT support for the Zynq would be nice however it would need to be more than the
>> uboot way of handling it, ie loading from a file in RTEMS itself with out uboot.
> 
> Yes, but U-Boot is not the only boot loader providing a device tree. There is no
> strong connection between U-Boot and a device tree, these are independent concepts.

I thought there was a u-boot interface to pass the FDT to RTEMS and then on to
other pieces of software, ie libbsd? I did not think these interfaces are
standardised? If this is not done right the board crashes, ie the BBB.

>>> In general, I think we should stick to what Linux does on a certain platform.
>>
>> I am not sure about this. It works for some targets like the BBB and RPi but can
>> it be universally applied? I see issues.
>>
>> Xilinx provides the FSBL and you need to make sure this is aligned to your
>> hardware as it contains the ps7_init code built from the SystemZ designer
>> interface. For some of the hard IP devices in the Zynq the FDT can work but I am
>> not sure about the specialised parts like the AXI bus configurations unless it
>> is exported from the Xilinx tools and complete. Then there is secure mode and
>> non-bricking issues which the Xilinx FSBL has some support for but I have not
>> seen in u-boot. All Zynq Linux systems I have seen do not have these things.
>>
>>> If it boots via a device tree, then the RTEMS BSP should do this as well.
>>
>> How would you integrate the Xilinx tools to handle this, ie ps7_init and friends?
>>
>> U-boot provides the FSBL equivalent, MLO or something like that, that is
>> specific to a build of hardware for example the Microzed. I do not think a
>> Microzed build will operate on a Picozed as it has 1G of RAM and there is no
>> support for a Picozed in u-boot master or Xilinx's u-boot fork. I suspect it is
>> in the Petalinux source tarball. U-boot is GPL and some places ban GPL of all
>> forms on a target.
> 
> 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. These files
also contain the clocks etc. These values are dumped into a piece of code called
ps7_init.[ch] and linked into the FSBL which paints the hardware early in the
boot process. If your hardware (PL) team change a value like an AXI clock
setting for a new bitfile you need to update all the FSBL images. If the
hardware is in production this is not an option, ie bricking.

There use to be XML generated files however these have changed or gone away
between releases of Xilinx tools. A while back even the generated header files
changed the labels of the defines unless you wished to follow the convoluted
indirect method the SDK code uses, it supports Zynq to Microblaze and more.

I suspect Linux will have a device tree for the hard IP but I have never looked.
As for the I2C and gmac I have never looked as you add those. :)

Chris