From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1754794AbdBVQda (ORCPT <rfc822;w@1wt.eu>);
        Wed, 22 Feb 2017 11:33:30 -0500
Received: from mail-qk0-f193.google.com ([209.85.220.193]:33361 "EHLO
        mail-qk0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1754641AbdBVQdV (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 22 Feb 2017 11:33:21 -0500
MIME-Version: 1.0
In-Reply-To: <CAAtXAHe-3L4E7sj9RJJwgMEASJCFmYcXyJdm6z7NtnXWGVGG=w@mail.gmail.com>
References: <20170218023010.GA8244@live.com> <1CC272501B5BC543A05DB90AA509DED50AF5EC@fmsmsx122.amr.corp.intel.com>
 <CANk1AXT7EMDw-5qWqKCDJcwySQjhhVGf_1m-b9NTbyzVRkO7cg@mail.gmail.com>
 <20170218204509.GA32544@live.com> <CANk1AXTCi6ccimHmXrNPXUn_MJBAoserCmC2kmapQ3Y=zjM79w@mail.gmail.com>
 <CANk1AXTVuVJR6mAKPWgs-+fyRRU1akgmYidu2ubcGJXAwu0oBQ@mail.gmail.com>
 <CAAtXAHd5C4yz3s0WZBL_YKjhwEEntbowsvfg1GUdRDbnq+t9zg@mail.gmail.com>
 <CANk1AXQxpcbGm-MrjrE-7FCmnXAW=Cieg+8QV6ypc6OSCLHTQg@mail.gmail.com>
 <1CC272501B5BC543A05DB90AA509DED50B005A@fmsmsx122.amr.corp.intel.com>
 <CAAtXAHdBv4Q_WykwBS7yXkRH=DnyPBjCmv+V91Jexr32Pf_WOQ@mail.gmail.com>
 <20170222051201.GB29755@obsidianresearch.com> <CAAtXAHe-3L4E7sj9RJJwgMEASJCFmYcXyJdm6z7NtnXWGVGG=w@mail.gmail.com>
From: Alan Tull <delicious.quinoa@gmail.com>
Date: Wed, 22 Feb 2017 10:33:19 -0600
Message-ID: <CANk1AXT2hpjHRWaqunnWzqu48m212zE11zFGhiu68G9zRcXAOw@mail.gmail.com>
Subject: Re: [RFC 7/8] fpga-region: add sysfs interface
To: Moritz Fischer <moritz.fischer@ettus.com>
Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
        "Nadathur, Sundar" <sundar.nadathur@intel.com>,
        Yves Vandervennet <yves.vandervennet@linux.intel.com>,
        "matthew.gerlach@linux.intel.com" <matthew.gerlach@linux.intel.com>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        "linux-fpga@vger.kernel.org" <linux-fpga@vger.kernel.org>,
        "Marek Va??ut" <marex@denx.de>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.

Also, the license of libfdt allows the use by proprietary
os's, but that's not true for dtc.

Alan

> </snip>
>
> $ dtc -o header.dtb header.dts
>
> $ cat header.dtb mybitfile.bin > /lib/firmware/bitfile_header.bin
>
> + static int __fpga_mgr_blob_to_image_info(const void *blob,
> +                                          struct fpga_image_info *info)
> + {
> +         int root_offset;
> +         const char *desc;
> +         const uint32_t *_compressed, *_encrypted;
> +         int compressed, encrypted;
> +
> +         if (fdt_check_header(blob)) {
> +                 pr_err("Invalid device tree blob header\n");
> +                 return -EINVAL;
> +         }
> +
> +         root_offset = fdt_path_offset(blob, "/");
> +         if (root_offset < 0) {
> +                 pr_err("Invalid root offset\n");
> +                 return -EINVAL;
> +         }
> +
> +         desc = fdt_getprop(blob, root_offset, "description", NULL);
> +
> +         _compressed = fdt_getprop(blob, root_offset, "compressed", NULL);
> +         if (_compressed)
> +                 compressed = fdt32_to_cpu(*_compressed);
> +
> +         _encrypted = fdt_getprop(blob, root_offset, "encrypted", NULL);
> +         if (_encrypted)
> +                 encrypted = fdt32_to_cpu(*_encrypted);
> +
> +         if (desc)
> +                 pr_info("%s: description=%s\n", __func__, desc);
> +
> +         if (_encrypted && _compressed)
> +                 pr_info("%s: compressed? %s encrypted? %s\n", __func__,
> +                         compressed ? "Yes" : "No", encrypted ? "Yes" : "No");
> +
> +         return 0;
> + }
>
> Which gave me:
>
> <snip>
>
> [   19.325182] fpga_manager fpga0: writing bitfile_header.bin to
> Xilinx Zynq FPGA Manager
> [   20.091222] __fpga_mgr_blob_to_image_info: description=Test
> [   20.096730] __fpga_mgr_blob_to_image_info: compressed? No encrypted? Yes
>
> </snip>
>
> So I'm fairly convinced I can make this work, TVLs seem like it could work, too.
>
>> So far the only thing we know we need is a 'bool' for encrypted and a
>> stringish guid thing for partial reconfiguration.
>
> Yeah, shouldn't be hard to implement either way.
>
> Cheers,
>
> Moritz