Re: [RFC 7/8] fpga-region: add sysfs interface

[Moritz Fischer <moritz.fischer@ettus.com>]

[-- Attachment #1: Type: text/plain, Size: 2034 bytes --]

On Wed, Feb 15, 2017 at 11:46:01AM -0600, Alan Tull wrote:
> On Wed, Feb 15, 2017 at 11:21 AM, Jason Gunthorpe
> <jgunthorpe@obsidianresearch.com> wrote:
> > On Wed, Feb 15, 2017 at 10:14:20AM -0600, Alan Tull wrote:
> >> Add a sysfs interface to control programming FPGA.
> >>
> >> Each fpga-region will get the following files which set values
> >> in the fpga_image_info struct for that region.  More files will
> >> need to be added as fpga_image_info expands.
> >>
> >> firmware_name
> >> * writing a name of a FPGA image file to firmware_name causes the
> >>   FPGA region to write the FPGA
> >>
> >> partial_config
> >> * 0 : full reconfiguration
> >> * 1 : partial reconfiguration
> >
> > This is really a property of the bitfile. It would be really nice to
> > have a saner system for describing the bitfiles that doesn't rely on
> > so much out of band stuff.

Agreed.
> >
> > Eg when doing partial reconfiguration it would be really sane to have
> > some checks that the full bitfile is the correct basis for the partial
> > bitfile.
> >
> > It also seems link Zynq needs an encrypted/not encrypted flag..

Well, we could also run always at half rate and not benefit from faster
config for the non-encrypted case ;-)

> > I wonder if we should require a Linux specific header on the bitfile
> > instead? That would make the bitfile self describing at least.

> I agree.  I've heard some discussions about adding a header.  We would
> want it to not be manufacturer or fpga device specific. That would be
> nice and would eliminate some of this struct.  We would need a tool to
> add the header, given a bitstream and some info about the bitstream.
> If the tool communicated seamlessly with vendor's tools that would be
> nice, but that is complicated to get that to happen.  So far nobody
> has posted their proposals to the mailing list.

Well, there's not that many vendors out there. If we can figure out a
format and stick to it, keep it reasonably extensible, 'the vendors'
will eventually adopt it.

Cheers,

Moritz

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]