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