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 <chr...@rtems.org> wrote: > > On 13/8/19 2:46 am, Jonathan Brandmeyer wrote: > > 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. > > > > 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@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
