linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: matthew.gerlach@linux.intel.com
To: Alan Tull <delicious.quinoa@gmail.com>
Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
	Moritz Fischer <moritz.fischer@ettus.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-fpga@vger.kernel.org
Subject: Re: [RFC 7/8] fpga-region: add sysfs interface
Date: Wed, 15 Feb 2017 12:07:15 -0800 (PST)	[thread overview]
Message-ID: <alpine.DEB.2.20.1702151133150.2458@mgerlach-VirtualBox> (raw)
In-Reply-To: <CANk1AXSTMynxMrDZ=aHsoX4naqByJnsRXPBvRGTSBpv2_5WptQ@mail.gmail.com>


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@obsidianresearch.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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

  parent reply	other threads:[~2017-02-15 20:07 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-15 16:14 FPGA Region enhancements and fixes Alan Tull
2017-02-15 16:14 ` [RFC 1/8] fpga-mgr: add a single function for fpga loading methods Alan Tull
2017-02-16  0:36   ` matthew.gerlach
2017-02-15 16:14 ` [RFC 2/8] fpga-region: support more than one overlay per FPGA region Alan Tull
2017-02-16 16:50   ` matthew.gerlach
2017-02-16 17:35     ` Alan Tull
2017-02-15 16:14 ` [RFC 3/8] fpga-bridge: add non-dt support Alan Tull
2017-02-15 16:14 ` [RFC 4/8] doc: fpga-mgr: separate getting/locking FPGA manager Alan Tull
2017-02-17 17:14   ` Li, Yi
2017-02-17 21:55     ` Alan Tull
2017-02-17 17:52   ` Moritz Fischer
2017-02-17 22:02     ` Alan Tull
2017-02-15 16:14 ` [RFC 5/8] " Alan Tull
2017-02-15 16:14 ` [RFC 6/8] fpga-region: separate out common code to allow non-dt support Alan Tull
2017-02-15 16:14 ` [RFC 7/8] fpga-region: add sysfs interface Alan Tull
2017-02-15 17:21   ` Jason Gunthorpe
2017-02-15 17:46     ` Alan Tull
2017-02-15 17:55       ` Moritz Fischer
2017-02-15 18:06       ` Jason Gunthorpe
2017-02-15 18:23         ` Alan Tull
2017-02-15 18:31           ` Moritz Fischer
2017-02-15 19:49           ` Jason Gunthorpe
2017-02-15 22:49             ` Alan Tull
2017-02-15 23:07               ` Jason Gunthorpe
2017-02-15 20:07           ` matthew.gerlach [this message]
2017-02-15 20:37             ` Jason Gunthorpe
2017-02-15 20:54               ` Moritz Fischer
2017-02-15 21:15                 ` Jason Gunthorpe
2017-02-15 21:36                   ` Moritz Fischer
2017-02-15 22:42                     ` Alan Tull
2017-02-16  0:16                       ` Moritz Fischer
2017-02-16 17:47                         ` Alan Tull
2017-02-16 17:56                           ` Jason Gunthorpe
2017-02-16 18:11                             ` Moritz Fischer
2017-02-17 22:28                 ` Yves Vandervennet
2017-02-18  2:30                   ` Moritz Fischer
2017-02-18 12:45                     ` Nadathur, Sundar
2017-02-18 20:10                       ` Alan Tull
2017-02-18 20:45                         ` Moritz Fischer
2017-02-19 15:00                           ` Alan Tull
2017-02-19 23:16                             ` Alan Tull
2017-02-20 23:49                               ` Moritz Fischer
2017-02-21 18:33                                 ` Alan Tull
2017-02-22  3:13                                   ` Nadathur, Sundar
2017-02-22  3:49                                     ` Moritz Fischer
2017-02-22  5:12                                       ` Jason Gunthorpe
2017-02-22  5:38                                         ` Moritz Fischer
2017-02-22  5:46                                           ` Nadathur, Sundar
2017-02-22  6:05                                             ` Moritz Fischer
2017-02-22 16:44                                               ` Jason Gunthorpe
2017-02-22 17:50                                                 ` Moritz Fischer
2017-02-22 17:54                                                   ` Jason Gunthorpe
2017-02-22 17:57                                                     ` Moritz Fischer
2017-02-22 16:33                                           ` Alan Tull
2017-02-22 16:44                                             ` Moritz Fischer
2017-02-22 16:52                                               ` Alan Tull
2017-02-27 20:09                                   ` Alan Tull
2017-02-27 22:49                                     ` Moritz Fischer
2017-02-28  0:04                                       ` matthew.gerlach
2017-02-15 21:20         ` Anatolij Gustschin
2017-02-15 16:14 ` [RFC 8/8] doc: fpga: add sysfs document for fpga region Alan Tull
2017-02-28 17:35 ` FPGA Region enhancements and fixes Alan Tull
2017-02-28 22:03   ` Alan Tull

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.20.1702151133150.2458@mgerlach-VirtualBox \
    --to=matthew.gerlach@linux.intel.com \
    --cc=delicious.quinoa@gmail.com \
    --cc=jgunthorpe@obsidianresearch.com \
    --cc=linux-fpga@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=moritz.fischer@ettus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).