Message-ID: <alpine.DEB.2.20.1702151133150.2458@mgerlach-VirtualBox>
Date:   Wed, 15 Feb 2017 12:07:15 -0800 (PST)
From:   matthew.gerlach@...ux.intel.com
To:     Alan Tull <delicious.quinoa@...il.com>
cc:     Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
        Moritz Fischer <moritz.fischer@...us.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-fpga@...r.kernel.org
Subject: Re: [RFC 7/8] fpga-region: add sysfs interface


Hi Jason, Alan, and Moritz,

On Wed, 15 Feb 2017, Alan Tull wrote:

> On Wed, Feb 15, 2017 at 12:06 PM, Jason Gunthorpe
> <jgunthorpe@...idianresearch.com> wrote:
>
> Hi Jason,
>
>> 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.

It seems pretty clear that there is a set of meta data associated with 
a fpga bitstream to allow that bit stream to be authenticated, decrypted, 
and configured into the fpga.  When using device tree based fpga 
configuration, the meta data has been put into a device tree or device
tree overlay that is separate from the bitstream itself.

It does seem reasonable to consider combining the meta data with actual 
bitstream data.  The benefit of combining the meta data with the bitstream 
is that it simplifies the userspace/kernel interface to a single file 
transfer instead of having a growing number of sysfs entries for the meta 
data.

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


The format of the meta data associated with a fpga bitstream is certainly 
a subject on its own.  HTTP style plain text is definately easy to 
understand and more importantly it is extendable.  On the other hand, it 
seems dangerous to be doing a lot of string parsing in the kernel.  Is 
there already an example of kernel code parsing an extendable data format? 
Depending on how the kernel is configured, the kernel code can parse a 
device tree blob.  I also think someone mentioned the FIT format which is 
closely related to device tree format.

Matthew Gerlach

>>
>> [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...
>
> I like how extensible (and readable!) this is.  It wouldn't take much
> kernel code to add this.  I'd like to see the python script.
>
> Alan
>
>>
>> Jason
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Powered by blists - more mailing lists