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
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
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 it
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 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
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
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
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
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
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
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
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
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 see why
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 bitstream
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 device
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 that there is
On Tue, Oct 8, 2013 at 4:44 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org 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
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
gre...@linuxfoundation.org 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,
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
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,
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 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:
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 mon...@monstr.eu wrote:
On
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.
Special soft IP presenting a PCI device to the host.
Michal Simek mon...@monstr.eu 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
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
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
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
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
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 much more
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 will
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 use case
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 itself
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
>>
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
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
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
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
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
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 >
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,
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
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
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
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
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
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
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 previously stated, I think
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
Yes; I never got too corner Greg ;)
Greg Kroah-Hartman gre...@linuxfoundation.org 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
On 10/04/2013 04:21 PM, H. Peter Anvin wrote:
Yes; I never got too corner Greg ;)
Greg Kroah-Hartman gre...@linuxfoundation.org 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
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
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 gre...@linuxfoundation.org wrote:
On Fri, Oct 04, 2013 at 03:57:57PM +0200, Michal Simek wrote:
But anyway what was resolution from that meeting?
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 gre...@linuxfoundation.org wrote:
On Fri, Oct 04, 2013 at 03:57:57PM +0200, Michal Simek wrote:
But
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 setup
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 gre...@linuxfoundation.org wrote:
On
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_manager/fpga0/firmware
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 in
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 thought
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 might be
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 jguntho...@obsidianresearch.com wrote:
On Fri, Oct 04, 2013 at 04:33:41PM -0700, Greg Kroah-Hartman wrote:
I agree that the firmware interface
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
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 jguntho...@obsidianresearch.com 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
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 >
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
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 because
the
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
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
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
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
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 an
74 matches
Mail list logo
