[U-Boot] [PATCH v2] board/BuR/zynq/brsmarc2: initial commit

Michal Simek michal.simek at xilinx.com
Fri May 3 18:15:34 UTC 2019


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


More information about the U-Boot mailing list