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