From: Michal Simek <michal.simek@xilinx.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2] board/BuR/zynq/brsmarc2: initial commit
Date: Fri, 3 May 2019 11:15:34 -0700 [thread overview]
Message-ID: <200b2a74-b2fd-e7ae-4150-bc76e687330b@xilinx.com> (raw)
In-Reply-To: <20190503180421.GZ31207@bill-the-cat>
On 03. 05. 19 11:04, Tom Rini wrote:
> On Fri, May 03, 2019 at 10:49:34AM -0700, Michal Simek wrote:
>> On 03. 05. 19 10:35, Tom Rini wrote:
>>> On Fri, May 03, 2019 at 09:29:32AM -0700, Michal Simek wrote:
>>> [snip]
>>>> I think we need to get more clarity what exactly vxworks expects and
>>>> what are just your "hacks" to get it work.
>>>> If vxworks deviates existing dt binding, or create completely new one.
>>>
>>> Hold up. If it's not in the spec itself (and most stuff is not), the
>>> Linux bindings are no more authoritative than the BSD ones (which are
>>> also not, unless things have changed, the Linux ones) than the vxWorks
>>> ones than anything else. For a board that is not supported in Linux, I
>>> don't think it makes sense to treat the primary OS support as something
>>> that's added to another DT.
>>
>> This board is using u-boot which is using linux binding. It means this
>> should be IMHO in separate file from the rest what vxworks expects.
>> Then we can review u-boot configurations properly.
>
> I see. I've always looked at it as "primary OS + u-boot additions in
> another file". When we use bindings they are the Linux ones, yes (when
> they aren't our own things). I've always seen it as making sync with
> the authoritative DTS for the HW easy as why we copy Linux and add to
> it. The end goal to me is to make sure that DTS maintenance is easy on
> the HW owner.
But still you can do right split with soc dtsi/clock dtsi/board/vxworks.
And we have done a decision long time ago in Linux and also the same
decision was taken to u-boot that mainline DT file won't contain any
fpga/pl description.
If you still want to do it that you should pack dt overlay with
bitstream to FIT and let u-boot to do the job.
But this PL overlay shouldn't land in mainline.
Thanks,
Michal
next prev parent reply other threads:[~2019-05-03 18:15 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-02 12:14 [U-Boot] [PATCH v2] board/BuR/zynq/brsmarc2: initial commit Hannes Schmelzer
2019-05-02 16:06 ` Michal Simek
2019-05-02 18:34 ` Hannes Schmelzer
2019-05-02 19:03 ` Tom Rini
2019-05-03 11:17 ` Hannes Schmelzer
2019-05-03 11:34 ` Hannes Schmelzer
2019-05-03 13:18 ` Tom Rini
2019-05-03 16:29 ` Michal Simek
2019-05-03 17:35 ` Tom Rini
2019-05-03 17:36 ` Tom Rini
2019-05-03 17:49 ` Michal Simek
2019-05-03 18:04 ` Tom Rini
2019-05-03 18:15 ` Michal Simek [this message]
2019-05-08 12:37 ` Hannes Schmelzer
2019-05-09 21:49 ` Michal Simek
2019-05-10 5:49 ` Hannes Schmelzer
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=200b2a74-b2fd-e7ae-4150-bc76e687330b@xilinx.com \
--to=michal.simek@xilinx.com \
--cc=u-boot@lists.denx.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox