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

[Andre Przywara <andre.przywara@arm.com>]

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@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@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?

Cheers,
Andre.

>  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.
>