Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1581425 > unrolled thread
| Started by | Alan Tull <atull@kernel.org> |
|---|---|
| First post | 2017-02-15 17:20 +0100 |
| Last post | 2017-02-15 22:30 +0100 |
| Articles | 6 on this page of 46 — 8 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
[RFC 7/8] fpga-region: add sysfs interface Alan Tull <atull@kernel.org> - 2017-02-15 17:20 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Jason Gunthorpe <jgunthorpe@obsidianresearch.com> - 2017-02-15 18:30 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Alan Tull <delicious.quinoa@gmail.com> - 2017-02-15 18:50 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Moritz Fischer <moritz.fischer@ettus.com> - 2017-02-15 19:00 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Jason Gunthorpe <jgunthorpe@obsidianresearch.com> - 2017-02-15 19:10 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Alan Tull <delicious.quinoa@gmail.com> - 2017-02-15 19:30 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Moritz Fischer <moritz.fischer@ettus.com> - 2017-02-15 19:40 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Jason Gunthorpe <jgunthorpe@obsidianresearch.com> - 2017-02-15 20:50 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Alan Tull <delicious.quinoa@gmail.com> - 2017-02-16 00:00 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Jason Gunthorpe <jgunthorpe@obsidianresearch.com> - 2017-02-16 00:10 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface matthew.gerlach@linux.intel.com - 2017-02-15 21:10 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Jason Gunthorpe <jgunthorpe@obsidianresearch.com> - 2017-02-15 21:40 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Moritz Fischer <moritz.fischer@ettus.com> - 2017-02-15 22:00 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Jason Gunthorpe <jgunthorpe@obsidianresearch.com> - 2017-02-15 22:20 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Moritz Fischer <moritz.fischer@ettus.com> - 2017-02-15 22:40 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Alan Tull <delicious.quinoa@gmail.com> - 2017-02-15 23:50 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Moritz Fischer <moritz.fischer@ettus.com> - 2017-02-16 01:20 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Alan Tull <delicious.quinoa@gmail.com> - 2017-02-16 18:50 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Jason Gunthorpe <jgunthorpe@obsidianresearch.com> - 2017-02-16 19:00 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Moritz Fischer <moritz.fischer@ettus.com> - 2017-02-16 19:20 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Yves Vandervennet <yves.vandervennet@linux.intel.com> - 2017-02-17 23:30 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Moritz Fischer <moritz.fischer@ettus.com> - 2017-02-18 03:40 +0100
RE: [RFC 7/8] fpga-region: add sysfs interface "Nadathur, Sundar" <sundar.nadathur@intel.com> - 2017-02-18 13:50 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Alan Tull <delicious.quinoa@gmail.com> - 2017-02-18 21:20 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Moritz Fischer <moritz.fischer@ettus.com> - 2017-02-18 22:00 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Alan Tull <delicious.quinoa@gmail.com> - 2017-02-19 16:10 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Alan Tull <delicious.quinoa@gmail.com> - 2017-02-20 00:20 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Moritz Fischer <moritz.fischer@ettus.com> - 2017-02-21 01:00 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Alan Tull <delicious.quinoa@gmail.com> - 2017-02-21 19:40 +0100
RE: [RFC 7/8] fpga-region: add sysfs interface "Nadathur, Sundar" <sundar.nadathur@intel.com> - 2017-02-22 04:20 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Moritz Fischer <moritz.fischer@ettus.com> - 2017-02-22 04:50 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Jason Gunthorpe <jgunthorpe@obsidianresearch.com> - 2017-02-22 06:20 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Moritz Fischer <moritz.fischer@ettus.com> - 2017-02-22 06:40 +0100
RE: [RFC 7/8] fpga-region: add sysfs interface "Nadathur, Sundar" <sundar.nadathur@intel.com> - 2017-02-22 06:50 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Moritz Fischer <moritz.fischer@ettus.com> - 2017-02-22 07:10 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Jason Gunthorpe <jgunthorpe@obsidianresearch.com> - 2017-02-22 17:50 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Moritz Fischer <moritz.fischer@ettus.com> - 2017-02-22 19:00 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Jason Gunthorpe <jgunthorpe@obsidianresearch.com> - 2017-02-22 19:00 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Moritz Fischer <moritz.fischer@ettus.com> - 2017-02-22 19:00 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Alan Tull <delicious.quinoa@gmail.com> - 2017-02-22 17:40 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Moritz Fischer <moritz.fischer@ettus.com> - 2017-02-22 17:50 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Alan Tull <delicious.quinoa@gmail.com> - 2017-02-22 18:00 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Moritz Fischer <moritz.fischer@ettus.com> - 2017-02-28 00:00 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface matthew.gerlach@linux.intel.com - 2017-02-28 07:30 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Alan Tull <delicious.quinoa@gmail.com> - 2017-02-28 13:40 +0100
Re: [RFC 7/8] fpga-region: add sysfs interface Anatolij Gustschin <agust@denx.de> - 2017-02-15 22:30 +0100
Page 3 of 3 — ← Prev page 1 2 [3]
| From | Moritz Fischer <moritz.fischer@ettus.com> |
|---|---|
| Date | 2017-02-22 17:50 +0100 |
| Message-ID | <tdIh4-4BG-11@gated-at.bofh.it> |
| In reply to | #1586304 |
On Wed, Feb 22, 2017 at 8:33 AM, Alan Tull <delicious.quinoa@gmail.com> wrote:
> On Tue, Feb 21, 2017 at 11:38 PM, Moritz Fischer
> <moritz.fischer@ettus.com> wrote:
>
> Hi Moritz,
>
>> Hi all,
>>
>> On Tue, Feb 21, 2017 at 9:12 PM, Jason Gunthorpe
>> <jgunthorpe@obsidianresearch.com> wrote:
>>> On Tue, Feb 21, 2017 at 07:49:19PM -0800, Moritz Fischer wrote:
>>>
>>>> fdt does this out of the box, too. So far I've seen nothing fdt
>>>> couldn't do (or doesn't do let's rather say).
>>>
>>> tlv/fdt/http headers are all essentially exactly the same
>>> thing. Key/value pairs with various encoding schemes.
>>>
>>> I don't think we don't need a tree of data, so fdt is overkill.
>>>
>>> tlv is not substantially easier to parse correctly than the
>>> structured plain text headers.. It is just in binary so it can
>>> represent binary-ish things better.
>>
>> TLV Seems easy enough. To give an update, I played with fdt a bit to see
>> how far I get in half an hour. I got bool / int / strings to work
>> quite fast (~30mins).
>
> Thanks for doing this fast piece of exploratory coding. It does
> confirm that for Linux, using fdt is pretty straightforward here.
> However...
>
>> Please disregard the horrible hackyness of this ...
>>
>> For simplicity I stuck the header on top of my bitfile with:
>>
>> <snip>
>> /dts-v1/;
>>
>> /{
>> description = "Test";
>> compressed = <0>;
>> encrypted = <1>;
>> };
>
> I understand that this is a simplified example, but it looks a lot
> like KVP which then gets compiled by dtc.
>
> If we do KVP or TLV we get skip using dtc, which would be nice for non-dt
> OS's using the same images.
I used dtc for pure lazyness. Writing a blob to a file using libfdt is
about as much
code as parsing it. Even with KVP or TLV you have some code that needs
to encode / pack your header into a file.
libfdt has an example that creates an empty tree. Write that to a file, done.
1: Create empty tree
https://github.com/dgibson/dtc/blob/master/libfdt/fdt_empty_tree.c
2: fopen / fwrite, done
> Also, the license of libfdt allows the use by proprietary
> os's, but that's not true for dtc.
Why would that be an issue, you don't need to link anything to run
dtc. That being
said as I pointed out above you don not have to actually use dtc if the values
are known ahead of time (like in our case). What you'd get from using dtc is to
encode arbitrary values (for the types supported).
Cheers,
Moritz
[toc] | [prev] | [next] | [standalone]
| From | Alan Tull <delicious.quinoa@gmail.com> |
|---|---|
| Date | 2017-02-22 18:00 +0100 |
| Message-ID | <tdIqK-4Fw-1@gated-at.bofh.it> |
| In reply to | #1586307 |
On Wed, Feb 22, 2017 at 10:44 AM, Moritz Fischer
<moritz.fischer@ettus.com> wrote:
> On Wed, Feb 22, 2017 at 8:33 AM, Alan Tull <delicious.quinoa@gmail.com> wrote:
>> On Tue, Feb 21, 2017 at 11:38 PM, Moritz Fischer
>> <moritz.fischer@ettus.com> wrote:
>>
>> Hi Moritz,
>>
>>> Hi all,
>>>
>>> On Tue, Feb 21, 2017 at 9:12 PM, Jason Gunthorpe
>>> <jgunthorpe@obsidianresearch.com> wrote:
>>>> On Tue, Feb 21, 2017 at 07:49:19PM -0800, Moritz Fischer wrote:
>>>>
>>>>> fdt does this out of the box, too. So far I've seen nothing fdt
>>>>> couldn't do (or doesn't do let's rather say).
>>>>
>>>> tlv/fdt/http headers are all essentially exactly the same
>>>> thing. Key/value pairs with various encoding schemes.
>>>>
>>>> I don't think we don't need a tree of data, so fdt is overkill.
>>>>
>>>> tlv is not substantially easier to parse correctly than the
>>>> structured plain text headers.. It is just in binary so it can
>>>> represent binary-ish things better.
>>>
>>> TLV Seems easy enough. To give an update, I played with fdt a bit to see
>>> how far I get in half an hour. I got bool / int / strings to work
>>> quite fast (~30mins).
>>
>> Thanks for doing this fast piece of exploratory coding. It does
>> confirm that for Linux, using fdt is pretty straightforward here.
>> However...
>>
>>> Please disregard the horrible hackyness of this ...
>>>
>>> For simplicity I stuck the header on top of my bitfile with:
>>>
>>> <snip>
>>> /dts-v1/;
>>>
>>> /{
>>> description = "Test";
>>> compressed = <0>;
>>> encrypted = <1>;
>>> };
>>
>> I understand that this is a simplified example, but it looks a lot
>> like KVP which then gets compiled by dtc.
>>
>> If we do KVP or TLV we get skip using dtc, which would be nice for non-dt
>> OS's using the same images.
>
> I used dtc for pure lazyness. Writing a blob to a file using libfdt is
> about as much
> code as parsing it.
Thanks for that clarification. I haven't used libfdt myself. That
takes care of the license issue I brought up below.
I have heard that MS is averse to using DT, but I'm not clear
about why other than that it isn't native to Windows already.
Alan
> Even with KVP or TLV you have some code that needs
> to encode / pack your header into a file.
>
> libfdt has an example that creates an empty tree. Write that to a file, done.
>
> 1: Create empty tree
> https://github.com/dgibson/dtc/blob/master/libfdt/fdt_empty_tree.c
>
> 2: fopen / fwrite, done
>
>> Also, the license of libfdt allows the use by proprietary
>> os's, but that's not true for dtc.
>
> Why would that be an issue, you don't need to link anything to run
> dtc. That being
> said as I pointed out above you don not have to actually use dtc if the values
> are known ahead of time (like in our case). What you'd get from using dtc is to
> encode arbitrary values (for the types supported).
>
> Cheers,
>
> Moritz
[toc] | [prev] | [next] | [standalone]
| From | Moritz Fischer <moritz.fischer@ettus.com> |
|---|---|
| Date | 2017-02-28 00:00 +0100 |
| Message-ID | <tfCqR-3Po-5@gated-at.bofh.it> |
| In reply to | #1585611 |
Alan, On Mon, Feb 27, 2017 at 12:09 PM, Alan Tull <delicious.quinoa@gmail.com> wrote: > First case: embedded FPGA. The hardware has one FPGA. The image is > designed for a specific board, so there's no problem including the > enumeration in the image. Agreed. > Second case: embedded FPGA + a PCIe FPGA. The image will be specific > as to whether it goes into the embedded FPGA or the PCIe one. Agreed. > Third case: multiple PCIe FPGAs. The enumeration base will be the > PCIe bus of the individual FPGA. If the FPGAs don't have unique pin > connections, then the images could go on any of the PCie FPGAs. If > there are unique pin connections, then the image will be specific to > the FPGA and having the enumeration data in the image is that much > more helpful for keeping things straight. Part of the header could > specify which specific FPGA it should go on if it is restricted. Agreed. > Of course if the FPGAs have > 1 PR regions, most FPGA architectures do > not have relocatable images so those images will be specific for the > PR region but not specific to the FPGA except as otherwise noted > above. > > So again, including enumeration data in the bitstream should work > unless I'm missing something. What am I missing here? If you enumeration base is sufficiently smart, I suppose that can work. What you'd probably want is some sort of extension to the platform bus? I really need to take another look at how non-dt systems enumerate to give better feedback on this. Cheers, Moritz
[toc] | [prev] | [next] | [standalone]
| From | matthew.gerlach@linux.intel.com |
|---|---|
| Date | 2017-02-28 07:30 +0100 |
| Message-ID | <tfJsl-zM-3@gated-at.bofh.it> |
| In reply to | #1589022 |
On Mon, 27 Feb 2017, Moritz Fischer wrote: > Alan, > > On Mon, Feb 27, 2017 at 12:09 PM, Alan Tull <delicious.quinoa@gmail.com> wrote: > > >> First case: embedded FPGA. The hardware has one FPGA. The image is >> designed for a specific board, so there's no problem including the >> enumeration in the image. > > Agreed. > >> Second case: embedded FPGA + a PCIe FPGA. The image will be specific >> as to whether it goes into the embedded FPGA or the PCIe one. > > Agreed. > > >> Third case: multiple PCIe FPGAs. The enumeration base will be the >> PCIe bus of the individual FPGA. If the FPGAs don't have unique pin >> connections, then the images could go on any of the PCie FPGAs. If >> there are unique pin connections, then the image will be specific to >> the FPGA and having the enumeration data in the image is that much >> more helpful for keeping things straight. Part of the header could >> specify which specific FPGA it should go on if it is restricted. > > Agreed. > >> Of course if the FPGAs have > 1 PR regions, most FPGA architectures do >> not have relocatable images so those images will be specific for the >> PR region but not specific to the FPGA except as otherwise noted >> above. >> >> So again, including enumeration data in the bitstream should work >> unless I'm missing something. What am I missing here? > > If you enumeration base is sufficiently smart, I suppose that can work. > What you'd probably want is some sort of extension to the platform bus? I think there is merit it considering the platform bus as part of the overal enumeration strategy. When using device trees, the platform bus is involved. I have also seen other folks enumerate over a platform bus based on data in a format other than device tree. I have experimented with instantiating platform devices from my pcie driver, but I didn't completely work, which could be related to using a fairly old 3.10 kernel. Matthew Gerlach > > I really need to take another look at how non-dt systems enumerate to > give better feedback on this. > > Cheers, > > Moritz > -- > To unsubscribe from this list: send the line "unsubscribe linux-fpga" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
[toc] | [prev] | [next] | [standalone]
| From | Alan Tull <delicious.quinoa@gmail.com> |
|---|---|
| Date | 2017-02-28 13:40 +0100 |
| Message-ID | <tfCqS-3Po-7@gated-at.bofh.it> |
| In reply to | #1585611 |
On Tue, Feb 21, 2017 at 12:33 PM, Alan Tull <delicious.quinoa@gmail.com> wrote: > On Mon, Feb 20, 2017 at 5:49 PM, Moritz Fischer > <moritz.fischer@ettus.com> wrote: >> Hi Alan, >> >> On Sun, Feb 19, 2017 at 3:16 PM, Alan Tull <delicious.quinoa@gmail.com> wrote: >>> On Sun, Feb 19, 2017 at 9:00 AM, Alan Tull <delicious.quinoa@gmail.com> wrote: >>>> On Sat, Feb 18, 2017 at 2:45 PM, Moritz Fischer >>>> <moritz.fischer@ettus.com> wrote: >>>>> On Sat, Feb 18, 2017 at 02:10:43PM -0600, Alan Tull wrote: >>>>>> On Sat, Feb 18, 2017 at 6:45 AM, Nadathur, Sundar >>>>>> <sundar.nadathur@intel.com> wrote: >>>>>> >>>>>> > Hi all, >>>>>> > Interesting discussion. The discussion so far has brought out many concerns such as OS independence. There is an existing format, well-known to developers, with widespread support, and which is quite extensible: Type-Length-Value triples. >>>>>> > >>>>>> > To elaborate, a TLV-based format has many advantages: >>>>>> > * It is highly extensible in many ways >>>>>> > -- You can express structures and arrays using TLVs. Our needs right now may seem limited but requirements grow over time. >>>> >>>> Device tree can express arrays. >>>> >>>>>> > -- The space of Type values can be decomposed into standard pre-defined values that are in upstreamed code, and possibly experimental or feature-specific values. >>>>>> > -- Forward compatibility: We can write parsers that can skip unexpected type values, thus allowing old parsers to work with new additions. With some tweaks, old parsers can also reject unexpected values in some ranges while accepting them in other ranges. >>>>>> > * It is OS-independent. >>>>>> > * It can be easily parsed, in kernel or user space. >>>>> >>>>> Are there other users of the format? I have to admit I didn't look very >>>>> long, but couldn't find any libs / existing code at a first glance. >>>> >>>> Is there a standard you are looking at? Have you seen any use of TLV's >>>> in the Linux kernel you could point to? >>>> >>>>> >>>>>> > * It can be validated, in terms of Type values, acceptable lengths, etc. >>>>>> > >>>>>> > It is not directly human-readable but that can be easily addressed with a tool that parses TLVs. >>>>>> > >>>>>> > Compared to some other proposals: >>>>>> > * Compared to DTs, TLVs are OS-independent. >>>>> >>>>> That's just alternative facts here. Just because Linux uses fdt for >>>>> devicetree blobs it is *not* OS dependent. There are several (see >>>>> last email) non-Linux users of fdt / libfdt. >>>>> >>>>> Thanks, >>>>> >>>>> Moritz >>>> >>>> It is worth repeating that libdtc is GPL/BSD with the intent of >>>> allowing proprietary code to use libdtc. So license shouldn't be a barrier. >>>> >>>> Using device tree in the header would give us a way of doing enumeration at >>>> least for Linux, not sure if that kind of info can be used in Windows >>>> in some way. >>> >>> Actually, enumeration is the only advantage I see with DT. >> >> Which seems to some point a separate issue to passing in image >> specific info such as >> encrypted or not, compressed or not or build info metadata. >> >> So I think in general we can still separate this out into: >> - Image specific values >> - Reconfiguration specific values >> >>> Currently I like key/value pairs because they are easily implemented >>> and expandable without being rigid in any way. >>> >>> If we use key/value pairs, we could pass in child device info >>> in one of the keys. It could be either a device tree overlay or an >>> ACPI overlay. Or could just be left out. So platforms that >>> aren't already using DT wouldn't have to. Platforms that >>> are have a smooth road to enumeration. >> >> I'm not sure if you can bundle up enumeration info *with* the image >> since you might e.g. >> load the same image (i.e. same header) into different FPGAs and the >> required update to >> the kernel state, i.e. live tree or ACPI would depend entirely on >> which FPGA you loaded >> the image into w.r.t busses it's connected to etc. >> >> I do think this info cannot be image specific, but needs to be passed >> in via something >> external such as a dt overlay. > > Yes, I think you are right about that. Hi Moritz, Actually now I think that enumeration data in the FPGA image should work even for cases with > 1 FPGA. First case: embedded FPGA. The hardware has one FPGA. The image is designed for a specific board, so there's no problem including the enumeration in the image. Second case: embedded FPGA + a PCIe FPGA. The image will be specific as to whether it goes into the embedded FPGA or the PCIe one. Third case: multiple PCIe FPGAs. The enumeration base will be the PCIe bus of the individual FPGA. If the FPGAs don't have unique pin connections, then the images could go on any of the PCie FPGAs. If there are unique pin connections, then the image will be specific to the FPGA and having the enumeration data in the image is that much more helpful for keeping things straight. Part of the header could specify which specific FPGA it should go on if it is restricted. Of course if the FPGAs have > 1 PR regions, most FPGA architectures do not have relocatable images so those images will be specific for the PR region but not specific to the FPGA except as otherwise noted above. So again, including enumeration data in the bitstream should work unless I'm missing something. What am I missing here? Alan > > Thanks! > Alan > >> >> Cheers, >> >> Moritz
[toc] | [prev] | [next] | [standalone]
| From | Anatolij Gustschin <agust@denx.de> |
|---|---|
| Date | 2017-02-15 22:30 +0100 |
| Message-ID | <tbfjb-5cF-3@gated-at.bofh.it> |
| In reply to | #1581527 |
Hi Jason, On Wed, 15 Feb 2017 11:06:12 -0700 Jason Gunthorpe jgunthorpe@obsidianresearch.com wrote: ... >The kernel could detect the bitfile starts with 'Linux_FPGA_BIT/1.0\n' >and then proceed to decode the header providing compat with the >current scheme. > >This is usually the sort of stuff I'd punt to userspace, but since the >kernel is doing request_firmware it is hard to see how that is an >option in this case... Interesting. We have a requirement that the complete history of FPGA configurations (basic configuration and the sequence of following partial reconfigurations) should be readable from FPGA manager framework on request. Each bitfile is associated with meta-data and one should be able to read this meta-data back for complete reconfiguration chain. When the kernel decodes a header, it could optionally store the data and allow to read it back on request. Thanks, Anatolij
[toc] | [prev] | [standalone]
Page 3 of 3 — ← Prev page 1 2 [3]
Back to top | Article view | linux.kernel
csiph-web