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

[Jason Gunthorpe]

On Wed, Feb 15, 2017 at 11:46:01AM -0600, Alan Tull wrote:
> 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.

Okay, we've had success using a HTTP style plain text header for the
last 15 years. Here is a header example:

BIT/1.0
Bit-Order: reversed
Builder: jgg
Content-Length: 9987064
Date: Thu, 19 Jan 2017 06:22:42 GMT
Design: tluna
Device: 7k355t
GIT-TOT: 60da4e9e8e9610e490ddeb4e5880778938f80691
Package: ffg901
Pad: xxxx
Speed: 2
Speed-File: PRODUCTION 1.12 2014-09-11
Synplify-Ver: Pro I-2014.03-1 , Build 016R, Mar 24 2014
Xilinx-Ver: Vivado v.2016.1 (lin64) Build 1538259 Fri Apr  8 15:45:23 MDT 2016

[raw bitfile follows, start byte in the file is aligned for DMA]

The plaintext format allows a fair amount of flexibility, eg I could
include the linux header for partial/encrypt along with my usual
headers for identification.

So along those lines I'd suggest the basic Linux format to be

Linux_FPGA_BIT/1.0
FPGA-Device: xc7k355t-ffg901-2    # Allow the kernel driver to check, if it can
# Enable partial reconfiguration and require the full bitfile to have
# the ID 'xxx'
Partial-Reconfiguration-Basis-ID: xxxx
# This is a full bitfile with unique tag xxxx
FPGA-ID: xxxx 
Encrypted: yes/no   # Enable decryption if the driver needs to be told
Pad: xxxx           # Enough 'x' characters to align the bitfile

[raw bitfile follows, start byte in the file is aligned for DMA]

I can publish a version of my python script which produces these files
from typical Xilinx output..

The kernel could detect the bitfile starts with 'Linux_FPGA_BIT/1.0\n'
and then proceed to decode the header providing compat with the
current scheme.

This is usually the sort of stuff I'd punt to userspace, but since the
kernel is doing request_firmware it is hard to see how that is an
option in this case...

Jason