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.przyw...@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.przyw...@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. > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot