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
36 matches
Mail list logo
