[U-Boot] [PATCH v3 2/5] board support of arm64

[Tom Rini]

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 <scottwood at 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 <scottwood at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130823/09fdafea/attachment.pgp>