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

[Nathan Rossi]

> -----Original Message-----
> From: meta-xilinx-bounces at yoctoproject.org [mailto:meta-xilinx-
> bounces at yoctoproject.org] On Behalf Of Mike Looijmans
> Sent: Tuesday, February 11, 2014 6:22 PM
> To: Cjw X
> Cc: meta-xilinx at yoctoproject.org
> Subject: Re: [meta-xilinx] Bitstream/Boot.bin/etc - Providers/Virtual
> targets
> 
> 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.

Some good ideas, unfortunately the Xilinx Linux efforts are not driven via Yocto. If you could start discussion with git at xilinx.com about the features you are going to get a much greater response from the people who deal with the kernel directly.

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

Don't forget to consider MicroBlaze too, which requires a primary bitstream. However you make a great point, virtual/bitstream is not particularly correct, however it does make sense to be able define the primary or platform bitstream. So for example maybe 'virtual/platform-bitstream' is a more descriptive/specific?

That way systems which actually rely on a bitstream for boot (MicroBlaze and specific Zynq systems) can set the provider and/or RDEPEND on the virtual target, and those which do not require a bitstream for boot do not need to define any RDEPENDS.

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

Was just throwing the 'virtual/platform-loader' into the collection to determine opinions.

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

So does that mean we should throw FSBL in the fires of Mount Doom? ;)

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

FSBL will probably need to exist for the TRDs (due to some functional code in them, like the ZC702 Base TRD) that are provided in meta-xilinx, these will most likely just be the binary elf's pulled from the TRD downloads themselves. They will of course have the license variables set such that commercial whitelisting is required.

u-boot-spl is on the table, and there is definitely interest for it.

Regards,
Nathan