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

[Cjw X]

We should unequivocally throw the FSBL into the fires of Mount Doom.

I've been working with u-boot-spl running on my microzed for about a month
now, and I'm already considerably happier with it.

The spl design is derived from ezynq from elphel, so it should be pretty
extensible to different platforms. I'll have a zedboard to play with next
week, so I'll get it up and running then.

I've considered trying to get u-boot to generate an spl build from the
ps_init code that xilinx spits out of the sdk. It is nice on some level,
but somewhat contrary to my end goal. My goal is to completely divorce Zynq
software development from Xilinx

Next on my list is some updates to the kernel
1) Fix the mmc writing bug (probably a hack because I think it is a
hardware flaw, but I haven't looked into it)
2) Fix the xdevcfg driver to be a misc driver so that udev recognizes it
properly
 3) Figure out how to change the fpga clock frequencies from linux.
4) ?? I'm open to suggestions

Comments/suggestions welcome.

-Chris


On Thu, Feb 13, 2014 at 12:49 AM, Nathan Rossi <nathan.rossi at xilinx.com>wrote:

> > -----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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-xilinx/attachments/20140213/034ff34d/attachment.html>