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

[Mike Looijmans]

On 02/11/2014 08:47 AM, Cjw X wrote:
> 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.

Yeah, this one has bitten us also. The hardware guy would set up the clocks in 
his design, but he is never alerted to the fact that whatever he does here, it 
never ends up in the bitstream, so the clocks and similar items are all set 
completely wrong when the bitstream loads and nothing works until he talks to 
the software guy who happens to know that the clock settings are only used 
when generating the FSBL and nowhere else.

> 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.

You could just add extra items to the "bit" file, the format appears to allow it.

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

How about a driver to setup many of these things from user space? The PL 
clocks are already present in the regular clock framework, so controlling them 
should be easy (if they support "set_rate" and similar calls). Similar things 
can be done for pinmuxing and reset lines.


Mike.


>
> On Tue, Feb 11, 2014 at 1:40 AM, Mike Looijmans <mike.looijmans at topic.nl
> <mailto: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 <mailto:meta-xilinx at yoctoproject.org>
>         https://lists.yoctoproject.__org/listinfo/meta-xilinx
>         <https://lists.yoctoproject.org/listinfo/meta-xilinx>
>
>
>     _________________________________________________
>     meta-xilinx mailing list
>     meta-xilinx at yoctoproject.org <mailto:meta-xilinx at yoctoproject.org>
>     https://lists.yoctoproject.__org/listinfo/meta-xilinx
>     <https://lists.yoctoproject.org/listinfo/meta-xilinx>
>
>