From: jgunthorpe@obsidianresearch.com (Jason Gunthorpe)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] fpga zynq: Check the bitstream for validity
Date: Mon, 31 Oct 2016 10:23:27 -0600 [thread overview]
Message-ID: <20161031162327.GA28817@obsidianresearch.com> (raw)
In-Reply-To: <20161029000926.GA30169@live.com>
On Fri, Oct 28, 2016 at 05:09:26PM -0700, Moritz Fischer wrote:
> It's not a single command but rather a sequence of steps we take to
> create an image that works (using write_cfgmem instead of write_binfile)
Ah, and it relies on newer Vivado features too.. Never had a use for
write_cfgmem before, and wouldn't have thought it did this.
I always do these transform externally and we tack our own header onto
the bitfile as well..
> > So, the question still remains, should the driver require the header
> > be stripped (eg the sync word is the first 4 bytes), or should it
> > search the first bit for an aligned sync word?
>
> So currently we don't require it to be stripped, changing it so it does
> require stripping would break people's setups that already use the
> current implementation.
Considering there is a way to produce an acceptable bitfile via
write_cfgmem I think we should stick with that and allow the header to
be present, otherwise all users need yet another tool.
I'll send another patch when I get back from the plumbers conference.
> > Either requirement is acceptable to the hardware. My patch does the
> > former, I suspect you need the later?
>
> For my usecases I could deal with either way, looking at backwards
> compat the latter one would be preferential I supose ...
Well, there are no in-kernel users, and no uapi, so it isn't such a
big deal. I'm actually surprised this got merged without users ..
Jason
next prev parent reply other threads:[~2016-10-31 16:23 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-26 22:54 [PATCH] fpga zynq: Check the bitstream for validity Jason Gunthorpe
2016-10-27 7:42 ` Michal Simek
2016-10-27 14:32 ` Jason Gunthorpe
2016-10-27 8:50 ` Matthias Brugger
2016-10-27 14:39 ` Jason Gunthorpe
2016-10-28 11:06 ` Matthias Brugger
2016-10-28 15:47 ` Jason Gunthorpe
2016-10-28 16:36 ` Matthias Brugger
2016-10-28 16:55 ` Jason Gunthorpe
2016-10-28 18:23 ` Moritz Fischer
2016-10-28 20:26 ` Jason Gunthorpe
2016-10-28 21:00 ` Moritz Fischer
2016-10-28 22:05 ` Jason Gunthorpe
2016-10-29 0:09 ` Moritz Fischer
2016-10-31 16:23 ` Jason Gunthorpe [this message]
2016-11-01 6:39 ` Michal Simek
2016-11-01 15:33 ` Jason Gunthorpe
2016-11-01 17:48 ` Michal Simek
2016-11-08 0:05 ` Jason Gunthorpe
2016-11-09 14:21 ` Mike Looijmans
2016-11-09 15:18 ` Matthias Brugger
2016-11-09 16:00 ` Jason Gunthorpe
2016-11-09 15:56 ` Jason Gunthorpe
2016-11-09 17:31 ` Mike Looijmans
2016-11-28 18:00 ` Jason Gunthorpe
2016-11-08 0:46 ` Jason Gunthorpe
2016-11-08 9:59 ` Matthias Brugger
2016-11-08 16:24 ` Jason Gunthorpe
2016-10-28 11:12 ` Matthias Brugger
2016-10-28 15:48 ` Jason Gunthorpe
2016-10-28 16:37 ` Matthias Brugger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161031162327.GA28817@obsidianresearch.com \
--to=jgunthorpe@obsidianresearch.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.