[U-Boot] [RFC] armv8: layerscape: Add support of u-boot device tree fix-up

[Scott Wood]

On Wed, 2016-02-24 at 02:50 +0000, Prabhakar Kushwaha wrote:
> > -----Original Message-----
> > From: Scott Wood [mailto:oss at buserror.net]
> > Sent: Tuesday, February 23, 2016 12:14 PM
> > To: Prabhakar Kushwaha <prabhakar.kushwaha at nxp.com>; u-
> > boot at lists.denx.de
> > Cc: york sun <york.sun at nxp.com>; Priyanka Jain <priyanka.jain at nxp.com>
> > Subject: Re: [RFC] armv8: layerscape: Add support of u-boot device tree
> > fix-
> > up
> > 
> > On Tue, 2016-02-23 at 04:09 +0000, Prabhakar Kushwaha wrote:
> > > > 
> > > > There should be a  mechanism for having multiple device trees
> > > > present, and choosing one based on platform code.
> > > >  That would also avoid any problems of trying to modify a device
> > > > tree before relocation.
> > > > 
> > > 
> > > I agree. But it may have following problems
> > >  - Increasing bootloader size (u-boot + dtb(s)).
> > 
> > Not by much.  If some boot sources are so close to the limit that this
> > presents
> > a problem, then we can deal with it, but this should not be a problem with
> > NOR flash at least.
> > 
> 
> I agree. But we may not be looking to increase u-boot size too much.  

I don't think it's a problem for an evaluation board.  Developers of actual
embedded systems can of course install only the device tree they care about. 
 We could also look into why the device tree is as big as it is -- there's
probably stuff in there U-Boot doesn't need.

> > >  Here board is common and SoC getting change
> > > 
> > > Assumption: SoC does not have major change.
> > 
> > I don't think that's a good assumption -- and what constitutes a major
> > change?
> >  A different core could be considered a major change.  In any case, you
> > need
> > specialized fixup code for every type of difference between the SoCs.
> > 
> 
> Ideally dts fix-up approach should only be applied to new Revision of SoCs. 
> And one should be very careful of using this approach for new SoC.

No.  Again, it's not for new revisions of an SoC.  It's for any SoC that is
user-pluggable into the board.

> > Choosing from multiple device trees is a cleaner solution that does not
> > place
> > limits on the type of change from SoC to SoC, and does not consume OCRAM
> > (among other benefits, this makes the mechanism transferable to other
> > types of devices that may not have enough pre-relocation RAM to hold a
> > device tree).
> 
> Choosing from multiple device tree is cleaner approach.  I agree with you. 
> 
> But same should be applied for Linux also.  We should not have different
> approach for u-boot dts and Linux dts. 

It would be nice to do so, and there's been some discussion of this before:
http://lists.denx.de/pipermail/u-boot/2013-January/143669.html

However, I don't think it's necessarily true that one implies the other.  It's
much less of a burden to change a U-Boot environment variable to get the right
dtb to pass to the OS, versus having to reflash U-Boot itself.

> I will suggest to have both    a) dts fix-up                  b) multiple
> dts 
> 
> SoC with small change can follow "a"
> 
> SoC with major change can follow "b" assuming same approach has been
> accepted in Linux. 

What do you mean by "accepted in Linux"?  Even for the dtb that gets passed to
the OS, we're still talking about U-Boot mechanisms, not anything that Linux
sees.

Why would we want two mechanisms when we could have one, especially if one of
the benefits of "b" is not having to deal with the possibility of modifying
the device tree before relocation?

-Scott