linux-kernel - Re: [RFC PATCH] fpga: Introduce new fpga subsystem

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <5242F695.2070506@monstr.eu>
Date:	Wed, 25 Sep 2013 16:43:33 +0200
From:	Michal Simek <monstr@...str.eu>
To:	Philip Balister <philip@...ister.org>
CC:	Pavel Machek <pavel@...x.de>, "H. Peter Anvin" <hpa@...or.com>,
	Alan Tull <atull@...era.com>,
	Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
	Jason Cooper <jason@...edaemon.net>,
	Michal Simek <michal.simek@...inx.com>,
	linux-kernel@...r.kernel.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Dinh Nguyen <dinguyen@...era.com>,
	Alessandro Rubini <rubini@...dd.com>,
	Mauro Carvalho Chehab <m.chehab@...sung.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Cesar Eduardo Barros <cesarb@...arb.net>,
	Joe Perches <joe@...ches.com>,
	"David S. Miller" <davem@...emloft.net>,
	Stephen Warren <swarren@...dia.com>,
	Arnd Bergmann <arnd@...db.de>,
	David Brown <davidb@...eaurora.org>,
	Dom Cobley <popcornmix@...il.com>
Subject: Re: [RFC PATCH] fpga: Introduce new fpga subsystem

On 09/25/2013 04:27 PM, Philip Balister wrote:
> On 09/25/2013 08:00 AM, Pavel Machek wrote:
>> Hi!
>>
>>>>> The firmware approach is interesting.  It might be less flexible
>>>>> compared with my original code (see link to git below) that this is
>>>>
>>>> On the other hand... that's the interface world wants, right? To most
>>>> users, fpga bitstream is just a firmware.
>>>>
>>>
>>> No, not really.
>>>
>>> The typical assumption with the firmware interface is that there is
>>> exactly one possible firmware for each device (possibly modulated by
>>> driver version, but still.)  
>>
>> Actually, I have seen counterexample there, too. Wifi card had
>> different firmware for host and access points mode, probably because
>> internal RAM could not fit both at same time. 
> 
> And another counter example ...
> 
> For the Zynq based product I am working on, we encourage the end user to
> create their own bitstreams to customize their application. So we need
> an easy way for the user to load a bitstream. cat foo.bin > /dev/xdevcfg
> works well for us.

You probably don't care if this will be
cat foo.bin > /sys/fpga/fpga0/<whatever>
(for zynq case you can also run)
cat foo.bit > /sys/fpga/fpga0/<whatever>

FYI: Current driver in xilinx repo supports bit format too.

> Then we need to make sure that the interface supports partial
> reconfiguration.

That will be next step.

> That said, having a sane user api that addresses the various fpga use
> cases would be a win for use since we would not need to write custom
> user space code for every platform created in the future. I'd like to
> see this api work with things like PCI based FPGA cards and discrete
> fpgas that are not integrated with an arm etc.

I don't have any PCI based FPGA card to have information how to work with
it but for discrete fpga I have one application note where jtag is emulated
by gpio interface and you can program another fpga from zynq (This can
be probably generic case for any combination in this 4 pin connection).

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform



Download attachment "signature.asc" of type "application/pgp-signature" (264 bytes)