Re: [RFC 7/8] fpga-region: add sysfs interface

[Alan Tull]

On Tue, Feb 21, 2017 at 12:33 PM, Alan Tull <delicious.quinoa@xxxxxxxxx> wrote:
> On Mon, Feb 20, 2017 at 5:49 PM, Moritz Fischer
> <moritz.fischer@xxxxxxxxx> wrote:
>> Hi Alan,
>>
>> On Sun, Feb 19, 2017 at 3:16 PM, Alan Tull <delicious.quinoa@xxxxxxxxx> wrote:
>>> On Sun, Feb 19, 2017 at 9:00 AM, Alan Tull <delicious.quinoa@xxxxxxxxx> wrote:
>>>> On Sat, Feb 18, 2017 at 2:45 PM, Moritz Fischer
>>>> <moritz.fischer@xxxxxxxxx> 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@xxxxxxxxx> 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