From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Simek Date: Fri, 3 May 2019 11:15:34 -0700 Subject: [U-Boot] [PATCH v2] board/BuR/zynq/brsmarc2: initial commit In-Reply-To: <20190503180421.GZ31207@bill-the-cat> References: <1556799261-28291-1-git-send-email-hannes.schmelzer@br-automation.com> <9d766a8e-0d54-ec07-cb22-cf2960fbc44e@xilinx.com> <3f6e5d48-fa63-b191-e4cc-280d381d8640@schmelzer.or.at> <20190502190332.GM31207@bill-the-cat> <20190503131819.GT31207@bill-the-cat> <22d7e2f5-148a-59de-f45e-3fec5787e13d@xilinx.com> <20190503173511.GX31207@bill-the-cat> <20190503180421.GZ31207@bill-the-cat> Message-ID: <200b2a74-b2fd-e7ae-4150-bc76e687330b@xilinx.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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