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

[Cjw X]

Yeah, I agree.

I've already integrated ezynq with the u-boot-spl so that it generates a
boot.bin, and a separate u-boot.img. No fsbl required. My goal is to
completely separate the ps side development from the xilinx tools.

There are a host of other issues that I've noticed. Like the fact that the
fpga clocks are setup in the initial arch init call. I bet there are more
of these things problems hiding in there too.

Because of that, right now the ability to arbitrarily change between
bitstreams is fundamentally broken. I'm not super involved in yocto, (I'm
managing this stuff in a buildroot distro I'm maintaining), so I'm not sure
if you guys have noticed this yet...

Right now my plan is to create a file wrapper around the bitstream's bin
file that has extra "ps-side" configuration information and a library that
will process that header, set the appropriate clocks (or other necessary
peripherals) and load the fpga configuration.

I'm kinda slammed so it might be a little while before I get that together,
but I'm open to suggestions right now.

-Chris



On Tue, Feb 11, 2014 at 1:40 AM, Mike Looijmans <mike.looijmans at topic.nl>wrote:

> 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
>>
>>
> _______________________________________________
> meta-xilinx mailing list
> meta-xilinx at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-xilinx/attachments/20140211/e260e739/attachment.html>