From mboxrd@z Thu Jan 1 00:00:00 1970 From: mike.looijmans@topic.nl (Mike Looijmans) Date: Tue, 13 Oct 2015 07:33:15 +0200 Subject: [PATCH 3/3] fpga manager: Adding FPGA Manager support for Xilinx Zynq 7000 In-Reply-To: <561BA9C7.6070003@xilinx.com> References: <1444344307-22509-1-git-send-email-moritz.fischer@ettus.com> <1444344307-22509-4-git-send-email-moritz.fischer@ettus.com> <20151009163336.GM10631@jcartwri.amer.corp.natinst.com> <561B9687.1070103@xilinx.com> <561BA60C.6010106@topic.nl> <561BA9C7.6070003@xilinx.com> Message-ID: <561C979B.6040201@topic.nl> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org ?On 12-10-15 14:38, Michal Simek wrote: > Hi Mike, > > On 10/12/2015 02:22 PM, Mike Looijmans wrote: >> On 12-10-15 13:16, Michal Simek wrote: >>> >>>>>> +static int zynq_fpga_ops_write(struct fpga_manager *mgr, >>>>>> + const char *buf, size_t count) >>>>>> +{ >>>>>> + struct zynq_fpga_priv *priv; >>>>>> + int err; >>>>>> + char *kbuf; >>>>>> + size_t i, in_count; >>>>>> + dma_addr_t dma_addr; >>>>>> + u32 transfer_length = 0; >>>>>> + bool endian_swap = false; >>>>>> + >>>>>> + in_count = count; >>>>>> + priv = mgr->priv; >>>>>> + >>>>>> + kbuf = dma_alloc_coherent(priv->dev, count, &dma_addr, >>>>>> GFP_KERNEL); >>>>>> + if (!kbuf) >>>>>> + return -ENOMEM; >>>>>> + >>>>>> + memcpy(kbuf, buf, count); >>>>>> + >>>>>> + /* look for the sync word */ >>>>>> + for (i = 0; i < count - 4; i++) { >>>>>> + if (memcmp(kbuf + i, "\x66\x55\x99\xAA", 4) == 0) { >>>>>> + dev_dbg(priv->dev, "Found normal sync word\n"); >>>>>> + endian_swap = false; >>>>>> + break; >>>>>> + } >>> >>> This is bin format >>> >>>>>> + if (memcmp(kbuf + i, "\xAA\x99\x55\x66", 4) == 0) { >>>>>> + dev_dbg(priv->dev, "Found swapped sync word\n"); >>>>>> + endian_swap = true; >>>>>> + break; >>>>>> + } >>> >>> This is bit format from header >>> >>>>>> + } >>>>> >>>>> How much control do we have over mandating the format of firmware at >>>>> this point? It'd be swell if we could just mandate a specific >>>>> endianness, and leave this munging to usermode. >>>> >>>> That's a good question. Personally I do only care about one of both, >>>> but that's just because I get to decide for my targets... >>>> Opinions from the Xilinx guys? >>> >>> Don't know full history about this but in past bitstream in BIT format >>> was used. Which is header (partially decoding in u-boot for example) >>> with data. >>> On zynq native format is BIN which is format without header and data is >>> swapped. >>> This code just detects which format is used. If BIT, header is skipped >>> and data is swapped to BIN format. >>> >>> Back to origin question if this is something what can be handled from >>> user space. And answer is - yes it can be handled there. >>> But based on my experience it is very useful to be able to handle BIT >>> because it is built by tools by default. >>> Also with BIN format you are loosing record what this data bitstream >>> targets. Header in BIT gives you at least some ideas. >> >> People should stop using "cat" to program the FPGA and use a userspace >> tool instead. I've already released such tools under GPL, so anyone can >> pick up on it and extend it as required. > > Link? https://github.com/topic-embedded-products/dyplo-utils/blob/master/dyploprogrammer.cpp https://github.com/topic-embedded-products/libdyplo/blob/master/hardware.cpp#L261 Will need some work to combine into a single tool though. > This is fpga manager based driver where "cat" won't be used. Haven't looked into it yet, but I guess at some point one will have to stream some data from userspace into the device, right? >> The header for the "bit" format is completely ignored (you can't even >> use it to determine if the bitstream is compatible with the current >> device) so there's no point in carrying it around. > > up2you what you want to do with it. If you work with different boards > with different FPGAs it is at least helpful to know if X.bit target this > or that board. Unfortunately I am not aware about any public document > which describe what there is written. > >> On the zynq, doing >> the "swap" in userspace was measurably faster than having the driver >> handle it, and that was even without using NEON instructions for byte >> swapping. >> >> I admit that being able to do "cat static.bit > /dev/xdevcfg" has had >> its uses. But it's not something that belongs in mainline Linux. > > It is about comfort but I have really not a problem that driver will > handle just BIN format. > >> Probably one of the key reasons that the "bit" format is still popular >> is that getting the Vivado tools to create a proper "bin" that will >> actually work on the Zynq is about as easy as nailing jelly to a tree. >> We've been using a simple Python script to do the bit->bin conversion >> for that reason. > > In vivado it is one tcl cmd. But truth is that I don't really get why > BIN is not generated by default. If I recall correctly, Vivado strips the "bit" header but doesn't swap the bytes, so the resulting bin file won't work. >> Using the "bin" format in the driver keeps it simple and singular. >> Userspace tools can add whatever wrappers and headers they feel >> appropriate to it, these checks don't belong in the driver since they >> will be application specific. For example, some users would want to >> verify that a partial bitstream actually matches the static part that's >> currently in the FPGA. > > agree. > > Thanks, > Michal > > Kind regards, Mike Looijmans System Expert TOPIC Embedded Products Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: +31 (0) 499 33 69 79 Telefax: +31 (0) 499 33 69 70 E-mail: mike.looijmans at topicproducts.com Website: www.topicproducts.com Please consider the environment before printing this e-mail From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Looijmans Subject: Re: [PATCH 3/3] fpga manager: Adding FPGA Manager support for Xilinx Zynq 7000 Date: Tue, 13 Oct 2015 07:33:15 +0200 Message-ID: <561C979B.6040201@topic.nl> References: <1444344307-22509-1-git-send-email-moritz.fischer@ettus.com> <1444344307-22509-4-git-send-email-moritz.fischer@ettus.com> <20151009163336.GM10631@jcartwri.amer.corp.natinst.com> <561B9687.1070103@xilinx.com> <561BA60C.6010106@topic.nl> <561BA9C7.6070003@xilinx.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <561BA9C7.6070003@xilinx.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Michal Simek , Moritz Fischer , Josh Cartwright Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, Russell King , "pawel.moll@arm.com" , ijc+devicetree@hellion.org.uk, Alan Tull , Greg KH , linux-kernel@vger.kernel.org, robh+dt@kernel.org, =?UTF-8?Q?S=c3=b6ren_Brinkmann?= , Kumar Gala , "dinguyen@opensource.altera.com" , linux-arm-kernel List-Id: devicetree@vger.kernel.org 77u/T24gMTItMTAtMTUgMTQ6MzgsIE1pY2hhbCBTaW1layB3cm90ZToKPiBIaSBNaWtlLAo+Cj4g T24gMTAvMTIvMjAxNSAwMjoyMiBQTSwgTWlrZSBMb29pam1hbnMgd3JvdGU6Cj4+IE9uIDEyLTEw LTE1IDEzOjE2LCBNaWNoYWwgU2ltZWsgd3JvdGU6Cj4+Pgo+Pj4+Pj4gK3N0YXRpYyBpbnQgenlu cV9mcGdhX29wc193cml0ZShzdHJ1Y3QgZnBnYV9tYW5hZ2VyICptZ3IsCj4+Pj4+PiArICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IGNoYXIgKmJ1Ziwgc2l6ZV90IGNvdW50KQo+Pj4+ Pj4gK3sKPj4+Pj4+ICsgICAgIHN0cnVjdCB6eW5xX2ZwZ2FfcHJpdiAqcHJpdjsKPj4+Pj4+ICsg ICAgIGludCBlcnI7Cj4+Pj4+PiArICAgICBjaGFyICprYnVmOwo+Pj4+Pj4gKyAgICAgc2l6ZV90 IGksIGluX2NvdW50Owo+Pj4+Pj4gKyAgICAgZG1hX2FkZHJfdCBkbWFfYWRkcjsKPj4+Pj4+ICsg ICAgIHUzMiB0cmFuc2Zlcl9sZW5ndGggPSAwOwo+Pj4+Pj4gKyAgICAgYm9vbCBlbmRpYW5fc3dh cCA9IGZhbHNlOwo+Pj4+Pj4gKwo+Pj4+Pj4gKyAgICAgaW5fY291bnQgPSBjb3VudDsKPj4+Pj4+ ICsgICAgIHByaXYgPSBtZ3ItPnByaXY7Cj4+Pj4+PiArCj4+Pj4+PiArICAgICBrYnVmID0gZG1h X2FsbG9jX2NvaGVyZW50KHByaXYtPmRldiwgY291bnQsICZkbWFfYWRkciwKPj4+Pj4+IEdGUF9L RVJORUwpOwo+Pj4+Pj4gKyAgICAgaWYgKCFrYnVmKQo+Pj4+Pj4gKyAgICAgICAgICAgICByZXR1 cm4gLUVOT01FTTsKPj4+Pj4+ICsKPj4+Pj4+ICsgICAgIG1lbWNweShrYnVmLCBidWYsIGNvdW50 KTsKPj4+Pj4+ICsKPj4+Pj4+ICsgICAgIC8qIGxvb2sgZm9yIHRoZSBzeW5jIHdvcmQgKi8KPj4+ Pj4+ICsgICAgIGZvciAoaSA9IDA7IGkgPCBjb3VudCAtIDQ7IGkrKykgewo+Pj4+Pj4gKyAgICAg ICAgICAgICBpZiAobWVtY21wKGtidWYgKyBpLCAiXHg2Nlx4NTVceDk5XHhBQSIsIDQpID09IDAp IHsKPj4+Pj4+ICsgICAgICAgICAgICAgICAgICAgICBkZXZfZGJnKHByaXYtPmRldiwgIkZvdW5k IG5vcm1hbCBzeW5jIHdvcmRcbiIpOwo+Pj4+Pj4gKyAgICAgICAgICAgICAgICAgICAgIGVuZGlh bl9zd2FwID0gZmFsc2U7Cj4+Pj4+PiArICAgICAgICAgICAgICAgICAgICAgYnJlYWs7Cj4+Pj4+ PiArICAgICAgICAgICAgIH0KPj4+Cj4+PiBUaGlzIGlzIGJpbiBmb3JtYXQKPj4+Cj4+Pj4+PiAr ICAgICAgICAgICAgIGlmIChtZW1jbXAoa2J1ZiArIGksICJceEFBXHg5OVx4NTVceDY2IiwgNCkg PT0gMCkgewo+Pj4+Pj4gKyAgICAgICAgICAgICAgICAgICAgIGRldl9kYmcocHJpdi0+ZGV2LCAi Rm91bmQgc3dhcHBlZCBzeW5jIHdvcmRcbiIpOwo+Pj4+Pj4gKyAgICAgICAgICAgICAgICAgICAg IGVuZGlhbl9zd2FwID0gdHJ1ZTsKPj4+Pj4+ICsgICAgICAgICAgICAgICAgICAgICBicmVhazsK Pj4+Pj4+ICsgICAgICAgICAgICAgfQo+Pj4KPj4+IFRoaXMgaXMgYml0IGZvcm1hdCBmcm9tIGhl YWRlcgo+Pj4KPj4+Pj4+ICsgICAgIH0KPj4+Pj4KPj4+Pj4gSG93IG11Y2ggY29udHJvbCBkbyB3 ZSBoYXZlIG92ZXIgbWFuZGF0aW5nIHRoZSBmb3JtYXQgb2YgZmlybXdhcmUgYXQKPj4+Pj4gdGhp cyBwb2ludD8gIEl0J2QgYmUgc3dlbGwgaWYgd2UgY291bGQganVzdCBtYW5kYXRlIGEgc3BlY2lm aWMKPj4+Pj4gZW5kaWFubmVzcywgYW5kIGxlYXZlIHRoaXMgbXVuZ2luZyB0byB1c2VybW9kZS4K Pj4+Pgo+Pj4+IFRoYXQncyBhIGdvb2QgcXVlc3Rpb24uIFBlcnNvbmFsbHkgSSBkbyBvbmx5IGNh cmUgYWJvdXQgb25lIG9mIGJvdGgsCj4+Pj4gYnV0IHRoYXQncyBqdXN0IGJlY2F1c2UgSSBnZXQg dG8gZGVjaWRlIGZvciBteSB0YXJnZXRzLi4uCj4+Pj4gT3BpbmlvbnMgZnJvbSB0aGUgWGlsaW54 IGd1eXM/Cj4+Pgo+Pj4gRG9uJ3Qga25vdyBmdWxsIGhpc3RvcnkgYWJvdXQgdGhpcyBidXQgaW4g cGFzdCBiaXRzdHJlYW0gaW4gQklUIGZvcm1hdAo+Pj4gd2FzIHVzZWQuIFdoaWNoIGlzIGhlYWRl ciAocGFydGlhbGx5IGRlY29kaW5nIGluIHUtYm9vdCBmb3IgZXhhbXBsZSkKPj4+IHdpdGggZGF0 YS4KPj4+IE9uIHp5bnEgbmF0aXZlIGZvcm1hdCBpcyBCSU4gd2hpY2ggaXMgZm9ybWF0IHdpdGhv dXQgaGVhZGVyIGFuZCBkYXRhIGlzCj4+PiBzd2FwcGVkLgo+Pj4gVGhpcyBjb2RlIGp1c3QgZGV0 ZWN0cyB3aGljaCBmb3JtYXQgaXMgdXNlZC4gSWYgQklULCBoZWFkZXIgaXMgc2tpcHBlZAo+Pj4g YW5kIGRhdGEgaXMgc3dhcHBlZCB0byBCSU4gZm9ybWF0Lgo+Pj4KPj4+IEJhY2sgdG8gb3JpZ2lu IHF1ZXN0aW9uIGlmIHRoaXMgaXMgc29tZXRoaW5nIHdoYXQgY2FuIGJlIGhhbmRsZWQgZnJvbQo+ Pj4gdXNlciBzcGFjZS4gQW5kIGFuc3dlciBpcyAtIHllcyBpdCBjYW4gYmUgaGFuZGxlZCB0aGVy ZS4KPj4+IEJ1dCBiYXNlZCBvbiBteSBleHBlcmllbmNlIGl0IGlzIHZlcnkgdXNlZnVsIHRvIGJl IGFibGUgdG8gaGFuZGxlIEJJVAo+Pj4gYmVjYXVzZSBpdCBpcyBidWlsdCBieSB0b29scyBieSBk ZWZhdWx0Lgo+Pj4gQWxzbyB3aXRoIEJJTiBmb3JtYXQgeW91IGFyZSBsb29zaW5nIHJlY29yZCB3 aGF0IHRoaXMgZGF0YSBiaXRzdHJlYW0KPj4+IHRhcmdldHMuIEhlYWRlciBpbiBCSVQgZ2l2ZXMg eW91IGF0IGxlYXN0IHNvbWUgaWRlYXMuCj4+Cj4+IFBlb3BsZSBzaG91bGQgc3RvcCB1c2luZyAi Y2F0IiB0byBwcm9ncmFtIHRoZSBGUEdBIGFuZCB1c2UgYSB1c2Vyc3BhY2UKPj4gdG9vbCBpbnN0 ZWFkLiBJJ3ZlIGFscmVhZHkgcmVsZWFzZWQgc3VjaCB0b29scyB1bmRlciBHUEwsIHNvIGFueW9u ZSBjYW4KPj4gcGljayB1cCBvbiBpdCBhbmQgZXh0ZW5kIGl0IGFzIHJlcXVpcmVkLgo+Cj4gTGlu az8KCmh0dHBzOi8vZ2l0aHViLmNvbS90b3BpYy1lbWJlZGRlZC1wcm9kdWN0cy9keXBsby11dGls cy9ibG9iL21hc3Rlci9keXBsb3Byb2dyYW1tZXIuY3BwCmh0dHBzOi8vZ2l0aHViLmNvbS90b3Bp Yy1lbWJlZGRlZC1wcm9kdWN0cy9saWJkeXBsby9ibG9iL21hc3Rlci9oYXJkd2FyZS5jcHAjTDI2 MQoKV2lsbCBuZWVkIHNvbWUgd29yayB0byBjb21iaW5lIGludG8gYSBzaW5nbGUgdG9vbCB0aG91 Z2guCgo+IFRoaXMgaXMgZnBnYSBtYW5hZ2VyIGJhc2VkIGRyaXZlciB3aGVyZSAiY2F0IiB3b24n dCBiZSB1c2VkLgoKSGF2ZW4ndCBsb29rZWQgaW50byBpdCB5ZXQsIGJ1dCBJIGd1ZXNzIGF0IHNv bWUgcG9pbnQgb25lIHdpbGwgaGF2ZSB0byBzdHJlYW0gCnNvbWUgZGF0YSBmcm9tIHVzZXJzcGFj ZSBpbnRvIHRoZSBkZXZpY2UsIHJpZ2h0PwoKPj4gVGhlIGhlYWRlciBmb3IgdGhlICJiaXQiIGZv cm1hdCBpcyBjb21wbGV0ZWx5IGlnbm9yZWQgKHlvdSBjYW4ndCBldmVuCj4+IHVzZSBpdCB0byBk ZXRlcm1pbmUgaWYgdGhlIGJpdHN0cmVhbSBpcyBjb21wYXRpYmxlIHdpdGggdGhlIGN1cnJlbnQK Pj4gZGV2aWNlKSBzbyB0aGVyZSdzIG5vIHBvaW50IGluIGNhcnJ5aW5nIGl0IGFyb3VuZC4KPgo+ IHVwMnlvdSB3aGF0IHlvdSB3YW50IHRvIGRvIHdpdGggaXQuIElmIHlvdSB3b3JrIHdpdGggZGlm ZmVyZW50IGJvYXJkcwo+IHdpdGggZGlmZmVyZW50IEZQR0FzIGl0IGlzIGF0IGxlYXN0IGhlbHBm dWwgdG8ga25vdyBpZiBYLmJpdCB0YXJnZXQgdGhpcwo+IG9yIHRoYXQgYm9hcmQuIFVuZm9ydHVu YXRlbHkgSSBhbSBub3QgYXdhcmUgYWJvdXQgYW55IHB1YmxpYyBkb2N1bWVudAo+IHdoaWNoIGRl c2NyaWJlIHdoYXQgdGhlcmUgaXMgd3JpdHRlbi4KPgo+PiBPbiB0aGUgenlucSwgZG9pbmcKPj4g dGhlICJzd2FwIiBpbiB1c2Vyc3BhY2Ugd2FzIG1lYXN1cmFibHkgZmFzdGVyIHRoYW4gaGF2aW5n IHRoZSBkcml2ZXIKPj4gaGFuZGxlIGl0LCBhbmQgdGhhdCB3YXMgZXZlbiB3aXRob3V0IHVzaW5n IE5FT04gaW5zdHJ1Y3Rpb25zIGZvciBieXRlCj4+IHN3YXBwaW5nLgo+Pgo+PiBJIGFkbWl0IHRo YXQgYmVpbmcgYWJsZSB0byBkbyAiY2F0IHN0YXRpYy5iaXQgPiAvZGV2L3hkZXZjZmciIGhhcyBo YWQKPj4gaXRzIHVzZXMuIEJ1dCBpdCdzIG5vdCBzb21ldGhpbmcgdGhhdCBiZWxvbmdzIGluIG1h aW5saW5lIExpbnV4Lgo+Cj4gSXQgaXMgYWJvdXQgY29tZm9ydCBidXQgSSBoYXZlIHJlYWxseSBu b3QgYSBwcm9ibGVtIHRoYXQgZHJpdmVyIHdpbGwKPiBoYW5kbGUganVzdCBCSU4gZm9ybWF0Lgo+ Cj4+IFByb2JhYmx5IG9uZSBvZiB0aGUga2V5IHJlYXNvbnMgdGhhdCB0aGUgImJpdCIgZm9ybWF0 IGlzIHN0aWxsIHBvcHVsYXIKPj4gaXMgdGhhdCBnZXR0aW5nIHRoZSBWaXZhZG8gdG9vbHMgdG8g Y3JlYXRlIGEgcHJvcGVyICJiaW4iIHRoYXQgd2lsbAo+PiBhY3R1YWxseSB3b3JrIG9uIHRoZSBa eW5xIGlzIGFib3V0IGFzIGVhc3kgYXMgbmFpbGluZyBqZWxseSB0byBhIHRyZWUuCj4+IFdlJ3Zl IGJlZW4gdXNpbmcgYSBzaW1wbGUgUHl0aG9uIHNjcmlwdCB0byBkbyB0aGUgYml0LT5iaW4gY29u dmVyc2lvbgo+PiBmb3IgdGhhdCByZWFzb24uCj4KPiBJbiB2aXZhZG8gaXQgaXMgb25lIHRjbCBj bWQuIEJ1dCB0cnV0aCBpcyB0aGF0IEkgZG9uJ3QgcmVhbGx5IGdldCB3aHkKPiBCSU4gaXMgbm90 IGdlbmVyYXRlZCBieSBkZWZhdWx0LgoKSWYgSSByZWNhbGwgY29ycmVjdGx5LCBWaXZhZG8gc3Ry aXBzIHRoZSAiYml0IiBoZWFkZXIgYnV0IGRvZXNuJ3Qgc3dhcCB0aGUgCmJ5dGVzLCBzbyB0aGUg cmVzdWx0aW5nIGJpbiBmaWxlIHdvbid0IHdvcmsuCgoKPj4gVXNpbmcgdGhlICJiaW4iIGZvcm1h dCBpbiB0aGUgZHJpdmVyIGtlZXBzIGl0IHNpbXBsZSBhbmQgc2luZ3VsYXIuCj4+IFVzZXJzcGFj ZSB0b29scyBjYW4gYWRkIHdoYXRldmVyIHdyYXBwZXJzIGFuZCBoZWFkZXJzIHRoZXkgZmVlbAo+ PiBhcHByb3ByaWF0ZSB0byBpdCwgdGhlc2UgY2hlY2tzIGRvbid0IGJlbG9uZyBpbiB0aGUgZHJp dmVyIHNpbmNlIHRoZXkKPj4gd2lsbCBiZSBhcHBsaWNhdGlvbiBzcGVjaWZpYy4gRm9yIGV4YW1w bGUsIHNvbWUgdXNlcnMgd291bGQgd2FudCB0bwo+PiB2ZXJpZnkgdGhhdCBhIHBhcnRpYWwgYml0 c3RyZWFtIGFjdHVhbGx5IG1hdGNoZXMgdGhlIHN0YXRpYyBwYXJ0IHRoYXQncwo+PiBjdXJyZW50 bHkgaW4gdGhlIEZQR0EuCj4KPiBhZ3JlZS4KPgo+IFRoYW5rcywKPiBNaWNoYWwKPgo+CgoKCktp bmQgcmVnYXJkcywKCk1pa2UgTG9vaWptYW5zClN5c3RlbSBFeHBlcnQKClRPUElDIEVtYmVkZGVk IFByb2R1Y3RzCkVpbmRob3ZlbnNld2VnIDMyLUMsIE5MLTU2ODMgS0ggQmVzdApQb3N0YnVzIDQ0 MCwgTkwtNTY4MCBBSyBCZXN0ClRlbGVmb29uOiArMzEgKDApIDQ5OSAzMyA2OSA3OQpUZWxlZmF4 OiArMzEgKDApIDQ5OSAzMyA2OSA3MApFLW1haWw6IG1pa2UubG9vaWptYW5zQHRvcGljcHJvZHVj dHMuY29tCldlYnNpdGU6IHd3dy50b3BpY3Byb2R1Y3RzLmNvbQoKUGxlYXNlIGNvbnNpZGVyIHRo ZSBlbnZpcm9ubWVudCBiZWZvcmUgcHJpbnRpbmcgdGhpcyBlLW1haWwKCgoKCgoKX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGludXgtYXJtLWtlcm5lbCBt YWlsaW5nIGxpc3QKbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9s aXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtYXJtLWtlcm5lbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752246AbbJMFxl (ORCPT ); Tue, 13 Oct 2015 01:53:41 -0400 Received: from mx18-05.smtp.antispamcloud.com ([207.244.64.174]:55135 "EHLO mx18-05.smtp.antispamcloud.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751583AbbJMFxg convert rfc822-to-8bit (ORCPT ); Tue, 13 Oct 2015 01:53:36 -0400 X-Greylist: delayed 1161 seconds by postgrey-1.27 at vger.kernel.org; Tue, 13 Oct 2015 01:53:36 EDT Subject: Re: [PATCH 3/3] fpga manager: Adding FPGA Manager support for Xilinx Zynq 7000 To: Michal Simek , Moritz Fischer , Josh Cartwright References: <1444344307-22509-1-git-send-email-moritz.fischer@ettus.com> <1444344307-22509-4-git-send-email-moritz.fischer@ettus.com> <20151009163336.GM10631@jcartwri.amer.corp.natinst.com> <561B9687.1070103@xilinx.com> <561BA60C.6010106@topic.nl> <561BA9C7.6070003@xilinx.com> CC: , , Russell King , "pawel.moll@arm.com" , , Alan Tull , Greg KH , , , linux-arm-kernel , Kumar Gala , "dinguyen@opensource.altera.com" , =?UTF-8?Q?S=c3=b6ren_Brinkmann?= From: Mike Looijmans Organization: TOPIC Message-ID: <561C979B.6040201@topic.nl> Date: Tue, 13 Oct 2015 07:33:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <561BA9C7.6070003@xilinx.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8BIT X-Originating-IP: [192.168.80.121] X-EXCLAIMER-MD-CONFIG: 9833cda7-5b21-4d34-9a38-8d025ddc3664 X-EXCLAIMER-MD-BIFURCATION-INSTANCE: 0 X-Filter-ID: s0sct1PQhAABKnZB5plbIbbvfIHzQjPVmPLZeVYSu3xU9luQrU+8/8qthi+0Jd/W6KAUC/fjyuDn NXFr4uarw6ZD8veLNImDrLDLUiI0AsfAxQbzAqS/RrKKBO4XjlCmeiXIHO35MjHi+eMUCJO2TIYS KBStr7O7vhgxWoFv+epHsjAzwFm2j3sTkEoNu4MFB2XwnnukAbufhj1XYHptaOBfOzFu1iolzW0d Y33uxGtdxolPvBTHlpbbkINvd6Bk6kKV7RLNv7BG4By/UppOuua3jN9Ol113WVdbZbJ4n5SZL3ZK wOcZxaNA3uilioqXHcgm/PYDrgNMeTyYrm6w0A4y43vx9CMfMwdzHKPokH4t76uq2Ikiy7EGEqrS bHxU+P6wwL/Ww4aRJJTYokACQkfkeB1ZozLmEzIAIV2u3PV5DC1pPwtLyzZS88a5qsmrV9H3b3ui +WTkUNrPUTJq27t8OmX1QQGT6C+RTkXg4eT3mGwqeVvV/aoJ9vMsXgu3CSITgN0ugmTS4qKyldkj gGuolx+n8+nrio+Py/D/FV+6lXUJF8c7DPYmIHr06w4X6DLR8Bobhy37nGTUDYXtQigFalNTNgHB 4p0JraSIHbuWQAst2UnlyAFeCH1nr+hjJtn64OSEWF6VcqmDPMWxhzZQ6OtBjX2dhf8r1xeX6dF8 69ddH5pVD4vk5Nhn8kevTec4ARO/9+ZXzwpBF2qmFrnE3ugZYR5DLT24smR4NCxcWwY4V4wSoeUf 4Tc54x6CPIwfcaABxEbSYmuqEIS+ddsVLmYwaaTRpYEGBzS2lSZu1/TOKAdM9bXEcN/54aPl31/E 3ahF5MMcDI7KdpjQKfBca56p9rSaMLHvrFJ/WXoVQQwJ+hLFkhiU5Z37xpMwJsxPsHZhqPAsfqcG efkyHPGq+LDvZGJq+/55nIT0fRv2Kv2ll81eEp+cNoocKNYZp81e65KEKhwtHEfZhshBX4LXS7oI SxfhqpHGPSL93xmPOfJmdPm/r8qHL+iIE/rPxW1Tvts9rK7u4IJwgRglzGvDK3PKrieG7T6bf9hS 7hSGyAxXU04XUx7LlovNt/SF7WoFt+fybNHE73/Q19FC8dDnSshojicvqBOxdT4qb4QU3DgtRxzg sGCElWfUFIwuDpp20HY57zx02G6RARnCiHMcN6qoXPjenLhIOF1oeRZCN7W8OFUXuwrACaSQJxIT eRx6eGt6IMoFClIjgmg4vJ9znrtJX3VbIT1bQrHRaTUzuAJHjLnD6pcynQvLMFtD X-Report-Abuse-To: spam@mx99.antispamcloud.com X-Filter-Fingerprint: IFrWXGses7OKB5S5G8/dJUb3OPwsHaH0Fvg5oXltHd/JUWjZ8+qhjyB23tbDuyLOYL8Ff78gYsez 4Rl08xudmXi4esCQ0R1MchVjt7wblGlvhFgW0MjUMRkF5sMCDfftTXNFDzN17hnrWeZYOJvLq0Ic WjZ+XcEjj/7Pkld0zkmvziDInX9WdMov2kn2yXjdwv61T+KDYyYtREgszdyFwv8IxCB3p/oCKvxr eyISh3JGb7OS5oVgiO+kDxZrVPLz3MmEGC2PrUKqLq5WmHK+Nw== X-Originating-IP: 88.159.208.100 X-Spampanel-Domain: topic.nl X-Spampanel-Username: 88.159.208.100 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=88.159.208.100@topic.nl X-Spampanel-Outgoing-Class: ham X-Spampanel-Outgoing-Evidence: Combined (0.00) X-Recommended-Action: accept Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12-10-15 14:38, Michal Simek wrote: > Hi Mike, > > On 10/12/2015 02:22 PM, Mike Looijmans wrote: >> On 12-10-15 13:16, Michal Simek wrote: >>> >>>>>> +static int zynq_fpga_ops_write(struct fpga_manager *mgr, >>>>>> + const char *buf, size_t count) >>>>>> +{ >>>>>> + struct zynq_fpga_priv *priv; >>>>>> + int err; >>>>>> + char *kbuf; >>>>>> + size_t i, in_count; >>>>>> + dma_addr_t dma_addr; >>>>>> + u32 transfer_length = 0; >>>>>> + bool endian_swap = false; >>>>>> + >>>>>> + in_count = count; >>>>>> + priv = mgr->priv; >>>>>> + >>>>>> + kbuf = dma_alloc_coherent(priv->dev, count, &dma_addr, >>>>>> GFP_KERNEL); >>>>>> + if (!kbuf) >>>>>> + return -ENOMEM; >>>>>> + >>>>>> + memcpy(kbuf, buf, count); >>>>>> + >>>>>> + /* look for the sync word */ >>>>>> + for (i = 0; i < count - 4; i++) { >>>>>> + if (memcmp(kbuf + i, "\x66\x55\x99\xAA", 4) == 0) { >>>>>> + dev_dbg(priv->dev, "Found normal sync word\n"); >>>>>> + endian_swap = false; >>>>>> + break; >>>>>> + } >>> >>> This is bin format >>> >>>>>> + if (memcmp(kbuf + i, "\xAA\x99\x55\x66", 4) == 0) { >>>>>> + dev_dbg(priv->dev, "Found swapped sync word\n"); >>>>>> + endian_swap = true; >>>>>> + break; >>>>>> + } >>> >>> This is bit format from header >>> >>>>>> + } >>>>> >>>>> How much control do we have over mandating the format of firmware at >>>>> this point? It'd be swell if we could just mandate a specific >>>>> endianness, and leave this munging to usermode. >>>> >>>> That's a good question. Personally I do only care about one of both, >>>> but that's just because I get to decide for my targets... >>>> Opinions from the Xilinx guys? >>> >>> Don't know full history about this but in past bitstream in BIT format >>> was used. Which is header (partially decoding in u-boot for example) >>> with data. >>> On zynq native format is BIN which is format without header and data is >>> swapped. >>> This code just detects which format is used. If BIT, header is skipped >>> and data is swapped to BIN format. >>> >>> Back to origin question if this is something what can be handled from >>> user space. And answer is - yes it can be handled there. >>> But based on my experience it is very useful to be able to handle BIT >>> because it is built by tools by default. >>> Also with BIN format you are loosing record what this data bitstream >>> targets. Header in BIT gives you at least some ideas. >> >> People should stop using "cat" to program the FPGA and use a userspace >> tool instead. I've already released such tools under GPL, so anyone can >> pick up on it and extend it as required. > > Link? https://github.com/topic-embedded-products/dyplo-utils/blob/master/dyploprogrammer.cpp https://github.com/topic-embedded-products/libdyplo/blob/master/hardware.cpp#L261 Will need some work to combine into a single tool though. > This is fpga manager based driver where "cat" won't be used. Haven't looked into it yet, but I guess at some point one will have to stream some data from userspace into the device, right? >> The header for the "bit" format is completely ignored (you can't even >> use it to determine if the bitstream is compatible with the current >> device) so there's no point in carrying it around. > > up2you what you want to do with it. If you work with different boards > with different FPGAs it is at least helpful to know if X.bit target this > or that board. Unfortunately I am not aware about any public document > which describe what there is written. > >> On the zynq, doing >> the "swap" in userspace was measurably faster than having the driver >> handle it, and that was even without using NEON instructions for byte >> swapping. >> >> I admit that being able to do "cat static.bit > /dev/xdevcfg" has had >> its uses. But it's not something that belongs in mainline Linux. > > It is about comfort but I have really not a problem that driver will > handle just BIN format. > >> Probably one of the key reasons that the "bit" format is still popular >> is that getting the Vivado tools to create a proper "bin" that will >> actually work on the Zynq is about as easy as nailing jelly to a tree. >> We've been using a simple Python script to do the bit->bin conversion >> for that reason. > > In vivado it is one tcl cmd. But truth is that I don't really get why > BIN is not generated by default. If I recall correctly, Vivado strips the "bit" header but doesn't swap the bytes, so the resulting bin file won't work. >> Using the "bin" format in the driver keeps it simple and singular. >> Userspace tools can add whatever wrappers and headers they feel >> appropriate to it, these checks don't belong in the driver since they >> will be application specific. For example, some users would want to >> verify that a partial bitstream actually matches the static part that's >> currently in the FPGA. > > agree. > > Thanks, > Michal > > Kind regards, Mike Looijmans System Expert TOPIC Embedded Products Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: +31 (0) 499 33 69 79 Telefax: +31 (0) 499 33 69 70 E-mail: mike.looijmans@topicproducts.com Website: www.topicproducts.com Please consider the environment before printing this e-mail