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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot