On 10/09/2013 02:07 PM, Jason Gunthorpe wrote:
> That is sort of backwards though, how does the driver know it should
> load and start fpga progamming?
A common way is for there to be a bitstream stored in flash which
presents an interface to download the data. I think some FPGAs with
hard bus IP
On Wed, Oct 09, 2013 at 01:37:05PM -0700, H. Peter Anvin wrote:
> A very common use case would be where a device contains an FPGA but is
> presented to the user as a product, often having its own device driver
> to drive the programmed device and/or additional logic. From *that*
> point of view i
On Tue, Oct 08, 2013 at 06:47:41PM -0500, delicious quinoa wrote:
> On Tue, Oct 8, 2013 at 4:44 PM, Greg Kroah-Hartman
> wrote:
> > On Tue, Oct 08, 2013 at 12:00:14PM -0500, Alan Tull wrote:
> >> On Fri, 2013-10-04 at 16:33 -0700, Greg Kroah-Hartman wrote:
> >> > On Fri, Oct 04, 2013 at 11:12:13AM
On Tue, Oct 8, 2013 at 4:44 PM, Greg Kroah-Hartman
wrote:
> On Tue, Oct 08, 2013 at 12:00:14PM -0500, Alan Tull wrote:
>> On Fri, 2013-10-04 at 16:33 -0700, Greg Kroah-Hartman wrote:
>> > On Fri, Oct 04, 2013 at 11:12:13AM -0700, H. Peter Anvin wrote:
>> > > On 10/04/2013 10:44 AM, Michal Simek wr
On Tue, Oct 08, 2013 at 12:00:14PM -0500, Alan Tull wrote:
> On Fri, 2013-10-04 at 16:33 -0700, Greg Kroah-Hartman wrote:
> > On Fri, Oct 04, 2013 at 11:12:13AM -0700, H. Peter Anvin wrote:
> > > On 10/04/2013 10:44 AM, Michal Simek wrote:
> > > >
> > > > If you look at it in general I believe tha
On Tue, Oct 08, 2013 at 11:49:46AM -0500, Alan Tull wrote:
> On Tue, 2013-10-08 at 15:00 +0200, Michal Simek wrote:
> > On 10/07/2013 05:07 PM, H. Peter Anvin wrote:
> > > Special soft IP presenting a PCI device to the host.
> >
> > ok. It means that you should need just different backend for this
On Fri, 2013-10-04 at 16:33 -0700, Greg Kroah-Hartman wrote:
> On Fri, Oct 04, 2013 at 11:12:13AM -0700, H. Peter Anvin wrote:
> > On 10/04/2013 10:44 AM, Michal Simek wrote:
> > >
> > > If you look at it in general I believe that there is wide range of
> > > applications which just contain one b
On Tue, 2013-10-08 at 15:00 +0200, Michal Simek wrote:
> On 10/07/2013 05:07 PM, H. Peter Anvin wrote:
> > Special soft IP presenting a PCI device to the host.
>
> ok. It means that you should need just different backend for this device
> which is able to communicate over PCI.
>
> I still can't s
On 10/07/2013 05:07 PM, H. Peter Anvin wrote:
> Special soft IP presenting a PCI device to the host.
ok. It means that you should need just different backend for this device
which is able to communicate over PCI.
I still can't see why this case should be problematic for this fpga
manager.
As Jaso
Special soft IP presenting a PCI device to the host.
Michal Simek wrote:
>On 10/07/2013 04:55 PM, H. Peter Anvin wrote:
>> If I recall correctly we simply poked at the FPGA directly from
>userspace.
>Not ideal by any means and also meant we had to have a backup recovery
>mechanism as it meant
>t
On 10/07/2013 04:55 PM, H. Peter Anvin wrote:
> If I recall correctly we simply poked at the FPGA directly from userspace.
Not ideal by any means and also meant we had to have a backup recovery
mechanism as it meant
that the FPGA had to be programmed already as the bus interface was in soft IP.
If I recall correctly we simply poked at the FPGA directly from userspace. Not
ideal by any means and also meant we had to have a backup recovery mechanism as
it meant that the FPGA had to be programmed already as the bus interface was in
soft IP.
Michal Simek wrote:
>On 10/05/2013 08:56 AM, H
On 10/05/2013 08:56 AM, H. Peter Anvin wrote:
> I would, but in my case it was employer-owned and closed.
ok. But I believe general concept for this can be shared.
If you used char device, sysfs, etc.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p:
On Fri, Oct 04, 2013 at 10:34:10PM -0700, H. Peter Anvin wrote:
> I do it all the time.
>
> JAM/STAPL seems to me to be more used for exotic connections to
> serial flash for persistent programming.
The FPGA tools write two kinds of SVF/JAM/STAPL files, one is ment to
be replayed the to FPGA itse
On 10/05/2013 01:49 AM, Jason Gunthorpe wrote:
> On Fri, Oct 04, 2013 at 04:33:41PM -0700, Greg Kroah-Hartman wrote:
>
>>> I agree that the firmware interface makes sense when the use of the
>>> FPGA is an implementation detail in a fixed hardware configuration,
>>> but that is a fairly restricted
On 10/05/2013 07:34 AM, H. Peter Anvin wrote:
> I do it all the time.
>
> JAM/STAPL seems to me to be more used for exotic connections to serial flash
> for persistent programming.
ok. I expect you have any code which you are using.
Why not to share it with us to see how you are using it?
I wil
On 10/05/2013 01:50 AM, H. Peter Anvin wrote:
> On 10/04/2013 04:33 PM, Greg Kroah-Hartman wrote:
>>
>> Ideally I thought this would be just like "firmware", you dump the file
>> to the FPGA, it validates it and away you go with a new image running in
>> the chip.
>>
>> But, it sounds like this is
I do it all the time.
JAM/STAPL seems to me to be more used for exotic connections to serial flash
for persistent programming.
Jason Gunthorpe wrote:
>On Fri, Oct 04, 2013 at 09:00:28PM -0700, H. Peter Anvin wrote:
>
>> Every FPGA toolchain I know of has a way to emit JAM/STAPL bytecode
>> file
On Fri, Oct 04, 2013 at 09:00:28PM -0700, H. Peter Anvin wrote:
> Every FPGA toolchain I know of has a way to emit JAM/STAPL bytecode
> files... and a fair number of programming scenarios need them.
Yes, but now you are talking about JTAG.
JTAG is a very different problem than configuring over t
Every FPGA toolchain I know of has a way to emit JAM/STAPL bytecode files...
and a fair number of programming scenarios need them.
Jason Gunthorpe wrote:
>On Fri, Oct 04, 2013 at 04:33:41PM -0700, Greg Kroah-Hartman wrote:
>
>> > I agree that the firmware interface makes sense when the use of th
On 10/04/2013 04:33 PM, Greg Kroah-Hartman wrote:
>
> Ideally I thought this would be just like "firmware", you dump the file
> to the FPGA, it validates it and away you go with a new image running in
> the chip.
>
> But, it sounds like this is much more complicated, so much so that
> configfs mi
On Fri, Oct 04, 2013 at 04:33:41PM -0700, Greg Kroah-Hartman wrote:
> > I agree that the firmware interface makes sense when the use of the
> > FPGA is an implementation detail in a fixed hardware configuration,
> > but that is a fairly restricted use case all things considered.
>
> Ideally I tho
On Fri, Oct 04, 2013 at 11:12:13AM -0700, H. Peter Anvin wrote:
> On 10/04/2013 10:44 AM, Michal Simek wrote:
> >
> > If you look at it in general I believe that there is wide range of
> > applications which just contain one bitstream per fpga and the
> > bitstream is replaced by newer version i
On Fri, 2013-10-04 at 17:27 +0200, Michal Simek wrote:
> Hi,
>
> On 10/03/2013 11:46 PM, Alan Tull wrote:
> > On Wed, 2013-10-02 at 17:35 +0200, Michal Simek wrote:
> >
> >>
> >> Through firmware interface:
> >> cat /sys/class/fpga_manager/fpga0/name
> >> echo -n fpga.bin > /sys/class/fpga_manage
On Fri, 2013-10-04 at 19:44 +0200, Michal Simek wrote:
> On 10/04/2013 06:46 PM, H. Peter Anvin wrote:
> > On 10/04/2013 07:28 AM, Michal Simek wrote:
> >> On 10/04/2013 04:21 PM, H. Peter Anvin wrote:
> >>> Yes; I never got too corner Greg ;)
> >>>
> >>> Greg Kroah-Hartman wrote:
> On Fri, O
On 10/04/2013 10:44 AM, Michal Simek wrote:
>
> If you look at it in general I believe that there is wide range of
> applications which just contain one bitstream per fpga and the
> bitstream is replaced by newer version in upgrade. For them
> firmware interface should be pretty useful. Just se
On 10/04/2013 06:46 PM, H. Peter Anvin wrote:
> On 10/04/2013 07:28 AM, Michal Simek wrote:
>> On 10/04/2013 04:21 PM, H. Peter Anvin wrote:
>>> Yes; I never got too corner Greg ;)
>>>
>>> Greg Kroah-Hartman wrote:
On Fri, Oct 04, 2013 at 03:57:57PM +0200, Michal Simek wrote:
> But anyway
On 10/04/2013 07:28 AM, Michal Simek wrote:
> On 10/04/2013 04:21 PM, H. Peter Anvin wrote:
>> Yes; I never got too corner Greg ;)
>>
>> Greg Kroah-Hartman wrote:
>>> On Fri, Oct 04, 2013 at 03:57:57PM +0200, Michal Simek wrote:
But anyway what was resolution from that meeting?
>>>
>>> It n
Hi,
On 10/03/2013 11:46 PM, Alan Tull wrote:
> On Wed, 2013-10-02 at 17:35 +0200, Michal Simek wrote:
>
>>
>> Through firmware interface:
>> cat /sys/class/fpga_manager/fpga0/name
>> echo -n fpga.bin > /sys/class/fpga_manager/fpga0/firmware
>>
>> Through sysfs bin file:
>> cat /sys/class/fpga_man
On 10/04/2013 04:21 PM, H. Peter Anvin wrote:
> Yes; I never got too corner Greg ;)
>
> Greg Kroah-Hartman wrote:
>> On Fri, Oct 04, 2013 at 03:57:57PM +0200, Michal Simek wrote:
>>> But anyway what was resolution from that meeting?
>>
>> It never happened, we got distracted by lunch :)
Then why
Yes; I never got too corner Greg ;)
Greg Kroah-Hartman wrote:
>On Fri, Oct 04, 2013 at 03:57:57PM +0200, Michal Simek wrote:
>> But anyway what was resolution from that meeting?
>
>It never happened, we got distracted by lunch :)
--
Sent from my mobile phone. Please pardon brevity and lack of
On Fri, Oct 04, 2013 at 03:57:57PM +0200, Michal Simek wrote:
> But anyway what was resolution from that meeting?
It never happened, we got distracted by lunch :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
On 10/03/2013 08:49 AM, Pavel Machek wrote:
> On Wed 2013-10-02 12:00:52, H. Peter Anvin wrote:
>> On 10/02/2013 08:35 AM, Michal Simek wrote:
>>>
>>> Based on my discussion at ELC with Greg KH the new driver should
>>> support firmware interface for loading bitstream.
>>>
>>
>> As I have previousl
On Wed, 2013-10-02 at 17:35 +0200, Michal Simek wrote:
>
> Through firmware interface:
> cat /sys/class/fpga_manager/fpga0/name
> echo -n fpga.bin > /sys/class/fpga_manager/fpga0/firmware
>
> Through sysfs bin file:
> cat /sys/class/fpga_manager/fpga0/fpga_config_state
> echo -n write_init > /sy
On Wed 2013-10-02 12:00:52, H. Peter Anvin wrote:
> On 10/02/2013 08:35 AM, Michal Simek wrote:
> >
> > Based on my discussion at ELC with Greg KH the new driver should
> > support firmware interface for loading bitstream.
> >
>
> As I have previously stated, I think this is a mistake simply bec
On 10/02/2013 08:35 AM, Michal Simek wrote:
>
> Based on my discussion at ELC with Greg KH the new driver should
> support firmware interface for loading bitstream.
>
As I have previously stated, I think this is a mistake simply because
the firmware interface is a bad mapping on requirements for
Hi All,
this is the second attempt to introduce new Linux FPGA subsystem which
can help us to unify all fpga drivers which in general do the same
things.
Xilinx has hwicap in the kernel as char driver (drivers/char/xilinx_hwicap/)
and I would like to base Zynq devcfg driver based on this interface
37 matches
Mail list logo
