On Thu, Aug 22, 2013 at 12:50:44PM -0500, Scott Wood wrote: > On Thu, 2013-08-22 at 12:44 -0500, Stuart Yoder wrote: > > On Thu, Aug 22, 2013 at 11:23 AM, Scott Wood <scottw...@freescale.com> > > wrote: > > > On Thu, 2013-08-22 at 11:15 -0500, Stuart Yoder wrote: > > >> On Mon, Aug 19, 2013 at 2:59 PM, Scott Wood <scottw...@freescale.com> > > >> wrote: > > >> > On Fri, 2013-08-16 at 09:14 -0500, Stuart Yoder wrote: > > >> >> Why is the device tree source in u-boot (instead of in the kernel)? > > >> >> Is this temporary? It > > >> >> looks like this device tree is just a copy from somewhere else. > > >> >> > > >> >> Would suggest removing this from this patch series and keep the dts > > >> >> maintained > > >> >> in the Linux kernel. > > >> > > > >> > U-Boot itself uses the device tree (not just to patch up for Linux) on > > >> > some targets. > > >> > > > >> > Even with the way PPC uses device trees, it doesn't really make sense > > >> > to > > >> > keep them in the kernel given that they're meant to be OS-neutral, and > > >> > have ties to U-Boot in terms of what gets fixed up at runtime. > > >> > > >> It may not make sense, but that is where they are kept currently. > > > > > > For PPC. > > > > $ find arch/arm/boot/dts | wc -l > > 425 > > $ find arch/powerpc/boot/dts | wc -l > > 315 > > My point is this isn't the first device tree to go into U-Boot for ARM.
Right, but a problem we have today is that the existing ones are incompatible with the real device trees for the devices in question. > > >> It doesn't make sense to maintain 2 copies of a vexpress64.dts device > > >> tree in 2 different > > >> places...or to maintain 1 lone device tree in u-boot. > > > > > > Why does it not make sense for there to be one lone device tree in > > > U-Boot? > > > > It doesn't make sense to me to keep one device tree in u-boot > > and the rest in the kernel. > > That's not what's being proposed. > > > > Submodules can be a pain. If we don't use them for DTC, why would we > > > use them for this? Since they require extra commands, you'd be > > > modifying the workflow of everyone that builds U-Boot and/or Linux for > > > affected platforms. > > > > You shouldn't need device trees for building u-boot or the kernel. > > Then why mess around with submodules instead of just a separate > repository? > > > I don't think a couple of extra commands is that burdensome. > > I disagree, and at the least don't want to be the one to advocate such a > change. :-) > > > I agree the DTS files really don't belong in the kernel, but there is > > currently no better repository that has been proposed. I'm not > > sure u-boot is a better place. Device trees should be independent > > of any particular bootloader or OS. > > The final device tree that the OS sees should be independent of the OS. > The dts is not the final device tree, and is tied to U-Boot. The device > tree in general is also tied to the bootloader in other ways -- U-Boot > expects certain aliases, configurable addresses must match, etc. I really hope that when the data gets pulled out of the kernel we'll have a useable central repository somewhere that can be used and various problems like this are taken into consideration. -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
