[PATCH] RTEMS BSP Buildset

[Gedare Bloom]

Hi Chris,

Did you ever get a chance to submit documentation on BSP Buildsets?

Gedare

On Mon, Aug 12, 2019 at 4:49 PM Chris Johns <chrisj at rtems.org> wrote:
>
> 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
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel