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

From: matthew . gerlach
Date: Wed Feb 15 2017 - 15:07:24 EST


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