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

[Tom Rini]

On Fri, May 06, 2016 at 04:20:57PM +0100, Andre Przywara wrote:
> Hi Tom,
> 
> On 06/05/16 16:11, Tom Rini wrote:
> > 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?
> 
> So for the Pine64 there are three models at the moment, each with a
> different size of DRAM. U-Boot detects this already, so for the time
> being we could just tell them apart easily - be it at SPL or U-Boot level.
> There is a good chance that community feedback will be heard on future
> boards (at least from Pine64.com), so we can make sure that even new
> boards are somehow distinguishable.
> 
> > 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.
> 
> Is the following a feasible approach?
> - use the plus model DT as a base
> - detect RAM size
> - if RAM == 512MB
> 	change Ethernet PHY property from RGMII to MII
> 	nuke (potential) CSI, camera, touchscreen nodes
> - push this DT by default to any kernel loaded
> - be done.
> 
> Sounds like easily coded, if one allows either board specific hooks or a
> generic framework for such rules.
> 
> Does that make sense?

Yes, this makes sense.  The only problem I see here is that if the board
isn't designed with some form of reliable runtime detection you can have
conflicts later on if you can't probe for a given device or whatever.

-- 
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/b7845d35/attachment.sig>