linux-kernel - Re: [PATCH 2/2] New driver: Xillybus generic interface for FPGA (programmable logic)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20121201203313.GO1718@beefymiracle.amer.corp.natinst.com>
Date:	Sat, 1 Dec 2012 14:33:13 -0600
From:	Josh Cartwright <josh.cartwright@...com>
To:	Philip Balister <philip@...ister.org>
Cc:	Greg KH <gregkh@...uxfoundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	Eli Billauer <eli.billauer@...il.com>,
	linux-kernel@...r.kernel.org, Pavel Machek <pavel@...x.de>,
	John Linn <john.linn@...inx.com>,
	Michal Simek <michal.simek@...inx.com>,
	"Ira W. Snyder" <iws@...o.caltech.edu>
Subject: Re: [PATCH 2/2] New driver: Xillybus generic interface for FPGA
 (programmable logic)

On Sat, Dec 01, 2012 at 11:30:55AM -0800, Philip Balister wrote:
> On 12/01/2012 08:56 AM, Greg KH wrote:
> >On Fri, Nov 30, 2012 at 07:19:16PM -0800, Philip Balister wrote:
[..]
> >
> >>I've been engaged in design discussions today with my customer. Our
> >>target is the Xilinx Zynq hardware. The first pass at a driver
> >>focuses on creating the minimal amount of code in the kernel doing
> >>most of the logic in user space. So the driver code allocates a
> >>large chunk of RAM for the FPGA to read/write to, provides a mmap
> >>function so user space can see this RAM, also mmaps in the address
> >>space of an AXI slave so the user space can control the logic. This
> >>approach has no dependencies on what is loaded into the fpga.
> >
> >Would a simple UIO driver work best for this type of arrangement?  Then
> >those types of hardware wouldn't even need to mess with a fpga-type
> >interface.
>
> It is very close to a UIO approach. My key problem I am trying to solve is
> getting a "large" buffer space for the driver and a way to communicate the
> physical address and size of the buffer to the fpga. The fpga has several
> ports that allow it to directly read/write RAM, but it needs to know
> physical addresses.
>
> >>This is a very different approach then the Xillybus driver, but
> >>should also be useful to a large class of people. Hopefully, we can
> >>converge on a set of useful drivers, and not end up with a million
> >>drivers all based on custom fpga configuration :)
> >
> >Odds are, this should look something like the firmware interface in the
> >end, right?  Userspace dumps a bunch of data to the device, and then
> >needs the driver to toggle some bits somewhere to enable the device.
> >Also, a few control calls like clearing the device, and other minor
> >things should be all that is needed, right?
> >
>
> For zynq, there is an out of tree ( :) ) driver that handles the firmware
> loading. This is an independent problem.
>
> >So, in the grand tradition of, "The first one there wins", why not base
> >it all off of your driver, and how that works, and we can go from there :)
>
> I do not think there will be any one driver that will work for all use cases
> due to the variety of devices that can be implemented in the fpga.

I see this working such that each IP block/independent logic unit in the
FPGA bitfile would be reified as an independent device to the kernel,
perhaps as a child of an 'fpga' bus (or similar).  These devices would
have their own drivers, and would come and go as the logic is
reprogrammed.

This is really useful if you're taking and integrating IP that exposes a
known interface with existing in-kernel Linux drivers.  Think a soft
Ethernet MAC IP or a 16550 or something.

For more application specific things, or lower level/less defined IO
like you described, an instance of a UIO driver might fit well.
(Anything more complicated then simple register accesses or interrupts
might require something more.)

The key point here is that there is a need for a common reprogrammable
logic subsystem that provides an abstraction over the various
reprogrammable logic devices and exposes a common user interfaces for
download and configuration.

This user interface would need to encompass a way to hand the kernel a
blob and a description of the IP contained within.  Grant's recent
dynamic device tree work seems like would be a great fit for this (and
infact, I believe this use case was explicitly listed as a userstory).

  Josh

Content of type "application/pgp-signature" skipped