[U-Boot] [PATCH 6/6] Pine64: rename defconfig

[Tom Rini]

On Wed, May 04, 2016 at 11:14:39PM +0100, André Przywara wrote:
> On 04/05/16 22:46, Peter Robinson wrote:
> > On Wed, May 4, 2016 at 10:15 PM, Andre Przywara <andre.przywara at arm.com> wrote:
> >> Rename the defconfig file for the Pine64 from pine64_plus_defconfig to
> >> pine64_defconfig.
> >> The differences between the two versions (more RAM and a different
> >> Ethernet PHY) don't justify two board versions, so lets stick with the
> >> generic name and try to differentiate between the versions at runtime
> >> if this is needed later.
> >>
> >> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> >> ---
> >>  configs/pine64_defconfig      | 20 ++++++++++++++++++++
> >>  configs/pine64_plus_defconfig | 20 --------------------
> >>  2 files changed, 20 insertions(+), 20 deletions(-)
> >>  create mode 100644 configs/pine64_defconfig
> >>  delete mode 100644 configs/pine64_plus_defconfig
> >>
> >> diff --git a/configs/pine64_defconfig b/configs/pine64_defconfig
> >> new file mode 100644
> >> index 0000000..0977334
> >> --- /dev/null
> >> +++ b/configs/pine64_defconfig
> >> @@ -0,0 +1,20 @@
> >> +CONFIG_ARM=y
> >> +CONFIG_ARCH_SUNXI=y
> >> +CONFIG_MACH_SUN50I=y
> >> +CONFIG_DRAM_CLK=672
> >> +CONFIG_DRAM_ZQ=3881915
> >> +# CONFIG_VIDEO is not set
> >> +CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pine64-plus"
> > 
> > If you're building a single u-boot for all variants of Pine64,
> 
> Yes!
> 
> > something which I'd prefer, I don't think we can just set a default
> > but rather need some logic to specify the DT name based on which board
> > is booting. This is done for example in the BeagleBone config to
> > detect the various variants of the BeagleBones.
> 
> OK, I will look at this.
> 
> I wonder if we can just use the plus .dts and then remove the parts that
> the non-plus is missing and push that through to the kernel.
> U-Boot already takes care of one difference: the DRAM size.
> I think we could also detect the different Ethernet PHY (or deduce this
> from the DRAM size?) and fix that up.
> For the third difference - camera and LCD connectors - U-Boot itself
> doesn't even care. But it would be nice if having a 512 MB board would
> result in the respective DT nodes to be deleted.
> This way we would have _one_ DT source - the U-Boot repository - and
> automatically deliver a fixed up version to every OS.
> 
> What do you think?

How well can you at run time determine which variant of pine we're on?
What's coming after v2016.05 is a whole bunch of examples of supporting
N similar but different boards that we can runtime detect and picking
the appropriate DT to use.  That however is at the SPL level.  We need
to I suppose think about how to do something similar at the U-Boot level
itself.

In terms of trying to "fixup" things, if you don't want to handle them
at the kernel level as overlays, there's examples today of using 'fdt
...' to whack nodes as needed I'm fairly certain.  It does depend on
being able to tell at runtime what you're on of course.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160506/d3e771ab/attachment.sig>