[meta-xilinx] Bitstream/Boot.bin/etc - Providers/Virtual targets

[Mike Looijmans]

One of the things I had to change in the meta-topic layer was the false 
assumption that there would be only one bitstream in an image. This is not the 
case. Which and how many bitstreams are to be installed depends on a choice of 
applications. So don't be tempted to have a single virtual/bitstream provider. 
We're typically using one bitstream that's to be loaded at boot, but many 
images have extra bitstreams, both full and partial, to do their jobs, and 
will happily switch between them.

As for virtual/platform-loader, I don't think other platforms are using this 
either, so think carefully before moving away from the OE established practices.

Personally, I'd rather see just the one bootloader to find them all and in 
darkness bind them. The FSBL has licensing issues and cannot be built from 
sources, so I'd rule that one out. Leaving ezynq and u-boot-spl, which do 
similar things (and I haven't had time to play with them). I'd rather see them 
combined into a single package.

I'm thinking about adding pinmux capability to the kernel to solve the issue 
of requiring bootloader changes when adding extra functionality into logic. 
The most sensible thing to do would be that if you activate a module, say the 
SPI0 controller, and the bootloader didn't set it up, you can safely assume 
that the component hardware is to be activated and connected to EMIO. This 
covers about 95% of use cases with very little effort. I'm not totally sure if 
this would work, I'm assuming the EMIO pins are "fixed" here.

Mike.


On 02/11/2014 02:57 AM, Nathan Rossi wrote:
> Hi All,
>
> So there are layers/recipes out there where everyone is getting bitstream/boot.bin/fsbl/etc going in Yocto. We are hoping to get some of the features into the base meta-xilinx layer (including the boot-gen stuff). One of the questions that needs to be answered is how to describe the dependencies, so that a machine can include its relevant pieces.
>
> For example, a bitstream could be defined a number of ways including recipes that generate the bitstream from Vivado/EDK projects (like in the meta-topic layer of Mike's), or recipes that use bitstream that are locally provided as a source in the layer, or again as a remote source uri for download. Getting the bitstream into the dependency chain could easily be done by using the 'PROVIDERS' feature of packages and defining a virtual provider, e.g. 'virtual/bitstream'. In this example the machine would define "PREFERRED_PROVIDER_virtual/bitstream = 'packagenamehere'".
>
> The same could be done for the 'virtual/boot-image' which would be for binary bitstream blobs, as well as boot.bin images.
>
> And this could also extend to the third case the platform loaders (e.g. fsbl, ezynq and u-boot-spl) which could be "virtual/platform-loader".
>
> I am throwing these out as ideas, all feedback is welcome :).
>
> Regards,
> Nathan
>
>
> _______________________________________________
> meta-xilinx mailing list
> meta-xilinx at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
>