| Message ID | 1462396534-32390-7-git-send-email-andre.przywara@arm.com |
|---|---|
| State | Changes Requested |
| Delegated to: | Hans de Goede |
| Headers | show |
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, 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. Peter > +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set > +CONFIG_HUSH_PARSER=y > +# CONFIG_CMD_IMLS is not set > +# CONFIG_CMD_FLASH is not set > +CONFIG_CMD_MMC=y > +# CONFIG_CMD_FPGA is not set > +CONFIG_CMD_DHCP=y > +CONFIG_CMD_MII=y > +CONFIG_CMD_PING=y > +CONFIG_CMD_EXT2=y > +CONFIG_CMD_EXT4=y > +CONFIG_CMD_FAT=y > +CONFIG_CMD_FS_GENERIC=y > diff --git a/configs/pine64_plus_defconfig b/configs/pine64_plus_defconfig > deleted file mode 100644 > index 0977334..0000000 > --- a/configs/pine64_plus_defconfig > +++ /dev/null > @@ -1,20 +0,0 @@ > -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" > -# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set > -CONFIG_HUSH_PARSER=y > -# CONFIG_CMD_IMLS is not set > -# CONFIG_CMD_FLASH is not set > -CONFIG_CMD_MMC=y > -# CONFIG_CMD_FPGA is not set > -CONFIG_CMD_DHCP=y > -CONFIG_CMD_MII=y > -CONFIG_CMD_PING=y > -CONFIG_CMD_EXT2=y > -CONFIG_CMD_EXT4=y > -CONFIG_CMD_FAT=y > -CONFIG_CMD_FS_GENERIC=y > -- > 2.7.3 > > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot
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? Cheers, Andre. >> +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set >> +CONFIG_HUSH_PARSER=y >> +# CONFIG_CMD_IMLS is not set >> +# CONFIG_CMD_FLASH is not set >> +CONFIG_CMD_MMC=y >> +# CONFIG_CMD_FPGA is not set >> +CONFIG_CMD_DHCP=y >> +CONFIG_CMD_MII=y >> +CONFIG_CMD_PING=y >> +CONFIG_CMD_EXT2=y >> +CONFIG_CMD_EXT4=y >> +CONFIG_CMD_FAT=y >> +CONFIG_CMD_FS_GENERIC=y >> diff --git a/configs/pine64_plus_defconfig b/configs/pine64_plus_defconfig >> deleted file mode 100644 >> index 0977334..0000000 >> --- a/configs/pine64_plus_defconfig >> +++ /dev/null >> @@ -1,20 +0,0 @@ >> -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" >> -# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set >> -CONFIG_HUSH_PARSER=y >> -# CONFIG_CMD_IMLS is not set >> -# CONFIG_CMD_FLASH is not set >> -CONFIG_CMD_MMC=y >> -# CONFIG_CMD_FPGA is not set >> -CONFIG_CMD_DHCP=y >> -CONFIG_CMD_MII=y >> -CONFIG_CMD_PING=y >> -CONFIG_CMD_EXT2=y >> -CONFIG_CMD_EXT4=y >> -CONFIG_CMD_FAT=y >> -CONFIG_CMD_FS_GENERIC=y >> -- >> 2.7.3 >> >> _______________________________________________ >> U-Boot mailing list >> U-Boot@lists.denx.de >> http://lists.denx.de/mailman/listinfo/u-boot >
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? 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.
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. >
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@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? 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.
Hi, On 04-05-16 23:15, Andre Przywara 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> So further down the thread there is some good discussion on autodetection. I would prefer to keep the name as is (and matching the dts name) for now until this is sorted out. As for the auto-detect discussion I'm all in favor of doing auto-detect and having only one pine64 target in u-boot. But I'm against the idea to pass the u-boot dtb into the kernel. People will typically only install u-boot once and then get kernel upgrades, including major version updates (Fedora does this within a release, Debian on dist-upgrade) from their distro, so we really want to stick with using the dtb from the fdtdir entry in extlinux.conf The way this sofar works for sunxi boards is that the chosen entry in extlinux.conf sets the fdtdir and then u-boot determines the dtb name to use, since it knows which board it is booting from. So when we do autodetection, the thing todo would be for the autodetect code to update the fdtfile environment variable to be one of: "sun50i-a64-pine64-plus", "sun50i-a64-pine64", "sun50i-a64-pine64-other-variant" (*). And then upon booting u-boot will load $fdtdir/$fdtfile. Let me give one example where this will be beneficial over using a u-boot supplied dtb: 1) User installs u-boot today, using boot0 and other closed bits + say Fedora 24. 2) In the future we add support for the csi camera 3) User gets newer kernel from Fedora, this comes with an updated "sun50i-a64-pine64-plus.dtb" which includes the necessary changes to enable the csi interface, csi interface just works. If u-boot where to supply the dtb, then the user would also need to update u-boot, which is not part of the standard yum / dnf / apt-get update process. Same for later enabling hdmi output support, audio in/out, etc. Note I'm not advocating to have different dtb-s, all sunxi boards use the same dts files in u-boot and the kernel, but the _kernel_ is considered the canonical source, and for u-boot we simply sync the included dts files with the kernel every now and then. As an added advantage this keeps the ABI part of the dtb between u-boot and the kernel really small, it basically is just the $fdtfile name. Which means that if we mess up some bindings we can chose to change them, we try to avoid this but always using the dtb file bundled with the kernel allows this. The main argument for always using the dtb file bundled with the kernel is to always get the latest new features (think extended hw support) and bugfixes, without the user needing to update the bootlader (which is something which is not done automatically by the distro, unlike the kernel). Regards, Hans *) Note we will likely need something more then just that, since e.g. some variants have an emmc and others do not and this is relevant for u-boot itself > --- > 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" > +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set > +CONFIG_HUSH_PARSER=y > +# CONFIG_CMD_IMLS is not set > +# CONFIG_CMD_FLASH is not set > +CONFIG_CMD_MMC=y > +# CONFIG_CMD_FPGA is not set > +CONFIG_CMD_DHCP=y > +CONFIG_CMD_MII=y > +CONFIG_CMD_PING=y > +CONFIG_CMD_EXT2=y > +CONFIG_CMD_EXT4=y > +CONFIG_CMD_FAT=y > +CONFIG_CMD_FS_GENERIC=y > diff --git a/configs/pine64_plus_defconfig b/configs/pine64_plus_defconfig > deleted file mode 100644 > index 0977334..0000000 > --- a/configs/pine64_plus_defconfig > +++ /dev/null > @@ -1,20 +0,0 @@ > -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" > -# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set > -CONFIG_HUSH_PARSER=y > -# CONFIG_CMD_IMLS is not set > -# CONFIG_CMD_FLASH is not set > -CONFIG_CMD_MMC=y > -# CONFIG_CMD_FPGA is not set > -CONFIG_CMD_DHCP=y > -CONFIG_CMD_MII=y > -CONFIG_CMD_PING=y > -CONFIG_CMD_EXT2=y > -CONFIG_CMD_EXT4=y > -CONFIG_CMD_FAT=y > -CONFIG_CMD_FS_GENERIC=y >
On 15/05/16 11:30, Hans de Goede wrote: > Hi, > > On 04-05-16 23:15, Andre Przywara 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> > > So further down the thread there is some good discussion on > autodetection. > > I would prefer to keep the name as is (and matching the dts name) > for now until this is sorted out. > > As for the auto-detect discussion I'm all in favor of doing > auto-detect and having only one pine64 target in u-boot. I fully agree. Hence I was proposing a more generic name (Pine64), as this is what people usually say, implying the plus variants of it as well. I found this several times when I was typing "make pine64_defconfig" and wondering why it didn't work. Typing pine64_plus_defconfig when everyone talks about those "Pine64" boards is just a bit counterintuitive - an also this pine64_plus config would cover the none-plus boards as well - which is just confusing. So my proposal was really about just a name change. But then again it's just a configuration name, so I don't have a strong opinion on this. > But I'm against the idea to pass the u-boot dtb into the kernel. > > People will typically only install u-boot once and then get > kernel upgrades, including major version updates (Fedora does > this within a release, Debian on dist-upgrade) from their > distro, so we really want to stick with using the > dtb from the fdtdir entry in extlinux.conf > > The way this sofar works for sunxi boards is that the chosen > entry in extlinux.conf sets the fdtdir and then u-boot determines > the dtb name to use, since it knows which board it is booting > from. > > So when we do autodetection, the thing todo would be for the > autodetect code to update the fdtfile environment variable > to be one of: "sun50i-a64-pine64-plus", "sun50i-a64-pine64", > "sun50i-a64-pine64-other-variant" (*). > > And then upon booting u-boot will load $fdtdir/$fdtfile. > > Let me give one example where this will be beneficial over > using a u-boot supplied dtb: > > 1) User installs u-boot today, using boot0 and other closed > bits + say Fedora 24. > 2) In the future we add support for the csi camera > 3) User gets newer kernel from Fedora, this comes with > an updated "sun50i-a64-pine64-plus.dtb" which includes the > necessary changes to enable the csi interface, csi interface > just works. > > If u-boot where to supply the dtb, then the user would also > need to update u-boot, which is not part of the standard > yum / dnf / apt-get update process. Same for later enabling > hdmi output support, audio in/out, etc. I understand and support all of these arguments (and hope you didn't spend too much time in writing this down ;-) My idea was to have some kind of fallback DT in case there is none provided by the distribution. For many cases it would be good enough to just use U-Boot's DT, so I am looking for an easy way to set U-Boot's "externally-facing" DT addr to the internal one - something like "fdt internal" or having the internal DT address in a variable or just making it the default unless the user or boot script loads a custom one. So from a technical side this is probably not a challenging request and orthogonal to the rest of the DT discussion. I see that one of the beauties of the DT is to be easily "hackable", so I fully support the option of loading a new DT and passing that on to the kernel. But: on ARM64 most boards I am aware of provide a DT as part of the firmware and it sits in some kind of onboard storage - so distributions don't need to care about shipping DTs. I see that those SBCs are different here, but frankly - in contrast to ARM(32) boards - there are not the majority. It may even be that DT boards (in contrast to ones using ACPI only) become a niche in the mid-term future (not that I am happy about that). I am not sure those SBCs have a strong enough audience to push distributions to deviate from that single-kernel-file-only approach for arm64. Also all those boards - and their firmware - are in their early infancy, so why not rather push for a unified approach here, possibly deviating from the (legacy) ARM one (explicitly supporting certain boards and shipping DTs for it)? So: the DT becomes part of the firmware. In the beginning of the support era (and I calculate with something like a year here) I expect firmware to improve significantly - even U-Boot, for that matter (USB, Ethernet, EFI support, you name it ...). So there is a strong incentive to upgrade your firmware anyway. But also I see that the kernel support evolves quickly, so putting a new DT in your /boot directory is probably a good idea - at least for a start. But when the board support has matured - say to a level the A20 SoC sees today - I would expect the DT to become very stable and only minor features requiring an update, something that many people just may not care about. Those new DTs could then come as part of a firmware update - which may fix other issues as well. So for instance ARM Trusted Firmware is part of the Pine64 firmware stack, which gets regular updates with new features and security fixes (for silicon erratas, for instance). As part of such an update, a DT update would be included. To compare this: if I don't miss anything and I don't have issues, I wouldn't upgrade my Thinkpad firmware either - definitely not for something like added IR support, which I just don't need (just an example). > Note I'm not advocating to have different dtb-s, all sunxi > boards use the same dts files in u-boot and the kernel, > but the _kernel_ is considered the canonical source, and > for u-boot we simply sync the included dts files with the > kernel every now and then. Yes, that makes sense and I support this. > As an added advantage this keeps the ABI part of the dtb > between u-boot and the kernel really small, it basically > is just the $fdtfile name. Which means that if we mess up > some bindings we can chose to change them, we try to avoid > this but always using the dtb file bundled with the kernel > allows this. But U-Boot does not use the DT from the disk (or from PXE), instead it will always use the one embedded in the binary, won't it? So every time there is a DT issue and/or we update U-Boot's DT, we could just adjust U-Boot's _drivers_ to cope with that new reference DT (whether that comes from the kernel or from the vendor). So for U-Boot itself we don't need to provide backward compatibility of say older U-Boot binaries with newer DTs. At least this is my perception, please correct me if I miss something here. > The main argument for always using the dtb file bundled with > the kernel is to always get the latest new features (think > extended hw support) and bugfixes, without the user needing > to update the bootlader (which is something which is not > done automatically by the distro, unlike the kernel). I see that - and that makes some sense especially during the beginning of the board support. But also I would like to see a bit beyond Linux - there are other OSes, think the BSDs, for instance. So everything that forces people to agree on _one_ single DT for a board is helpful - the fact that we currently get away with changing the DT _just for Linux_ is not a good argument to drag on with this in the future. And frankly, the support level required for those ARM SBCs is quite high at the moment. Everything that pushes people - board vendors and kernel hackers - into a simpler approach - more towards providing better firmware, which helps abstracting things and for shipping one "golden" DT with the board - is helpful and we should look into this. Frankly I don't see why a distribution would need to ship support files for certain boards when there would be one canonical firmware source - be that the vendor or a community like linux-sunxi. Cheers, Andre. > > *) Note we will likely need something more then just that, since > e.g. some variants have an emmc and others do not and this is > relevant for u-boot itself >
Hi, On 15-05-16 14:49, André Przywara wrote: > On 15/05/16 11:30, Hans de Goede wrote: >> Hi, >> >> On 04-05-16 23:15, Andre Przywara 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> >> >> So further down the thread there is some good discussion on >> autodetection. >> >> I would prefer to keep the name as is (and matching the dts name) >> for now until this is sorted out. >> >> As for the auto-detect discussion I'm all in favor of doing >> auto-detect and having only one pine64 target in u-boot. > > I fully agree. Hence I was proposing a more generic name (Pine64), as > this is what people usually say, implying the plus variants of it as well. > I found this several times when I was typing "make pine64_defconfig" and > wondering why it didn't work. Typing pine64_plus_defconfig when everyone > talks about those "Pine64" boards is just a bit counterintuitive - an > also this pine64_plus config would cover the none-plus boards as well - > which is just confusing. > So my proposal was really about just a name change. > But then again it's just a configuration name, so I don't have a strong > opinion on this. I understand, but I would like to keep the dts/dtb and defconfig names matched (the dts has plus in it too) until we've autoconfig. >> But I'm against the idea to pass the u-boot dtb into the kernel. >> >> People will typically only install u-boot once and then get >> kernel upgrades, including major version updates (Fedora does >> this within a release, Debian on dist-upgrade) from their >> distro, so we really want to stick with using the >> dtb from the fdtdir entry in extlinux.conf >> >> The way this sofar works for sunxi boards is that the chosen >> entry in extlinux.conf sets the fdtdir and then u-boot determines >> the dtb name to use, since it knows which board it is booting >> from. >> >> So when we do autodetection, the thing todo would be for the >> autodetect code to update the fdtfile environment variable >> to be one of: "sun50i-a64-pine64-plus", "sun50i-a64-pine64", >> "sun50i-a64-pine64-other-variant" (*). >> >> And then upon booting u-boot will load $fdtdir/$fdtfile. >> >> Let me give one example where this will be beneficial over >> using a u-boot supplied dtb: >> >> 1) User installs u-boot today, using boot0 and other closed >> bits + say Fedora 24. >> 2) In the future we add support for the csi camera >> 3) User gets newer kernel from Fedora, this comes with >> an updated "sun50i-a64-pine64-plus.dtb" which includes the >> necessary changes to enable the csi interface, csi interface >> just works. >> >> If u-boot where to supply the dtb, then the user would also >> need to update u-boot, which is not part of the standard >> yum / dnf / apt-get update process. Same for later enabling >> hdmi output support, audio in/out, etc. > > I understand and support all of these arguments (and hope you didn't > spend too much time in writing this down ;-) No not too much time :) > My idea was to have some kind of fallback DT in case there is none > provided by the distribution. For many cases it would be good enough to > just use U-Boot's DT, so I am looking for an easy way to set U-Boot's > "externally-facing" DT addr to the internal one - something like "fdt > internal" or having the internal DT address in a variable or just making > it the default unless the user or boot script loads a custom one. > So from a technical side this is probably not a challenging request and > orthogonal to the rest of the DT discussion. > I see that one of the beauties of the DT is to be easily "hackable", so > I fully support the option of loading a new DT and passing that on to > the kernel. > > But: on ARM64 most boards I am aware of provide a DT as part of the > firmware and it sits in some kind of onboard storage - so distributions > don't need to care about shipping DTs. > I see that those SBCs are different here, but frankly - in contrast to > ARM(32) boards - there are not the majority. It may even be that DT > boards (in contrast to ones using ACPI only) become a niche in the > mid-term future (not that I am happy about that). > I am not sure those SBCs have a strong enough audience to push > distributions to deviate from that single-kernel-file-only approach for > arm64. Also all those boards - and their firmware - are in their early > infancy, so why not rather push for a unified approach here, possibly > deviating from the (legacy) ARM one (explicitly supporting certain > boards and shipping DTs for it)? > > So: the DT becomes part of the firmware. In the beginning of the support > era (and I calculate with something like a year here) I expect firmware > to improve significantly - even U-Boot, for that matter (USB, Ethernet, > EFI support, you name it ...). So there is a strong incentive to upgrade > your firmware anyway. > But also I see that the kernel support evolves quickly, so putting a new > DT in your /boot directory is probably a good idea - at least for a start. > But when the board support has matured - say to a level the A20 SoC sees > today - I would expect the DT to become very stable and only minor > features requiring an update, something that many people just may not > care about. Those new DTs could then come as part of a firmware update - > which may fix other issues as well. So for instance ARM Trusted Firmware > is part of the Pine64 firmware stack, which gets regular updates with > new features and security fixes (for silicon erratas, for instance). As > part of such an update, a DT update would be included. > > To compare this: if I don't miss anything and I don't have issues, I > wouldn't upgrade my Thinkpad firmware either - definitely not for > something like added IR support, which I just don't need (just an example). > >> Note I'm not advocating to have different dtb-s, all sunxi >> boards use the same dts files in u-boot and the kernel, >> but the _kernel_ is considered the canonical source, and >> for u-boot we simply sync the included dts files with the >> kernel every now and then. > > Yes, that makes sense and I support this. > >> As an added advantage this keeps the ABI part of the dtb >> between u-boot and the kernel really small, it basically >> is just the $fdtfile name. Which means that if we mess up >> some bindings we can chose to change them, we try to avoid >> this but always using the dtb file bundled with the kernel >> allows this. > > But U-Boot does not use the DT from the disk (or from PXE), instead it > will always use the one embedded in the binary, won't it? Correct, u-boot (currently) always uses its embedded DT, at least for sunxi it does, I'm not 100% sure about other SoCs. > So every time there is a DT issue and/or we update U-Boot's DT, we could > just adjust U-Boot's _drivers_ to cope with that new reference DT > (whether that comes from the kernel or from the vendor). So for U-Boot > itself we don't need to provide backward compatibility of say older > U-Boot binaries with newer DTs. At least this is my perception, please > correct me if I miss something here. Right, this is also why I often allow dt-enabled drivers in u-boot before the binding is set in the upstream kernel, since we bundle u-boot with its own dt we can always break the binding from u-boot's pov. Note I do not want to get in a situation where u-boot's dt and the kernels diverge as we've seen with other SoCs though, so once the kernel dt binding is stable I expect the u-boot code to be fixed to use it and the bundled dt to be synced with the final one from the kernel. >> The main argument for always using the dtb file bundled with >> the kernel is to always get the latest new features (think >> extended hw support) and bugfixes, without the user needing >> to update the bootlader (which is something which is not >> done automatically by the distro, unlike the kernel). > > I see that - and that makes some sense especially during the beginning > of the board support. > > But also I would like to see a bit beyond Linux - there are other OSes, > think the BSDs, for instance. > So everything that forces people to agree on _one_ single DT for a board > is helpful - the fact that we currently get away with changing the DT > _just for Linux_ is not a good argument to drag on with this in the future. Agreed, as said above I at least want to always see u-boot and the kernel in sync wrt dt consumption, unlike some other SoCs which have different dt bindings for u-boot and the kernel (this is mostly a historical thing but still). > And frankly, the support level required for those ARM SBCs is quite high > at the moment. Everything that pushes people - board vendors and kernel > hackers - into a simpler approach - more towards providing better > firmware, which helps abstracting things and for shipping one "golden" > DT with the board - is helpful and we should look into this. > Frankly I don't see why a distribution would need to ship support files > for certain boards when there would be one canonical firmware source - > be that the vendor or a community like linux-sunxi. I also agree with this, my dream is to have the SBCs as easy to use / install Linux on as a PC, unfortunately we still have a long way to go. I can see how a firmware provided dtb can be helpful for a more plug and play experience, I'm afraid though that we will always be playing catch-up by the time we've a full set of bindings for the A64, so that a newer A64 based SBC could in theory ship with a dtb on board which enables all desirable functionality, chances are the A64 has been obsoleted by something new, so what we really need here is for the SoC vendors to start doing hardware enablement directly upstream, rather then with some questionable quality BSP. Regards, Hans
On 15.05.16 14:49, André Przywara wrote: > On 15/05/16 11:30, Hans de Goede wrote: >> Hi, >> >> On 04-05-16 23:15, Andre Przywara 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> >> >> So further down the thread there is some good discussion on >> autodetection. >> >> I would prefer to keep the name as is (and matching the dts name) >> for now until this is sorted out. >> >> As for the auto-detect discussion I'm all in favor of doing >> auto-detect and having only one pine64 target in u-boot. > > I fully agree. Hence I was proposing a more generic name (Pine64), as > this is what people usually say, implying the plus variants of it as well. > I found this several times when I was typing "make pine64_defconfig" and > wondering why it didn't work. Typing pine64_plus_defconfig when everyone > talks about those "Pine64" boards is just a bit counterintuitive - an > also this pine64_plus config would cover the none-plus boards as well - > which is just confusing. > So my proposal was really about just a name change. > But then again it's just a configuration name, so I don't have a strong > opinion on this. > >> But I'm against the idea to pass the u-boot dtb into the kernel. >> >> People will typically only install u-boot once and then get >> kernel upgrades, including major version updates (Fedora does >> this within a release, Debian on dist-upgrade) from their >> distro, so we really want to stick with using the >> dtb from the fdtdir entry in extlinux.conf >> >> The way this sofar works for sunxi boards is that the chosen >> entry in extlinux.conf sets the fdtdir and then u-boot determines >> the dtb name to use, since it knows which board it is booting >> from. >> >> So when we do autodetection, the thing todo would be for the >> autodetect code to update the fdtfile environment variable >> to be one of: "sun50i-a64-pine64-plus", "sun50i-a64-pine64", >> "sun50i-a64-pine64-other-variant" (*). >> >> And then upon booting u-boot will load $fdtdir/$fdtfile. >> >> Let me give one example where this will be beneficial over >> using a u-boot supplied dtb: >> >> 1) User installs u-boot today, using boot0 and other closed >> bits + say Fedora 24. >> 2) In the future we add support for the csi camera >> 3) User gets newer kernel from Fedora, this comes with >> an updated "sun50i-a64-pine64-plus.dtb" which includes the >> necessary changes to enable the csi interface, csi interface >> just works. >> >> If u-boot where to supply the dtb, then the user would also >> need to update u-boot, which is not part of the standard >> yum / dnf / apt-get update process. Same for later enabling >> hdmi output support, audio in/out, etc. > > I understand and support all of these arguments (and hope you didn't > spend too much time in writing this down ;-) > > My idea was to have some kind of fallback DT in case there is none > provided by the distribution. For many cases it would be good enough to > just use U-Boot's DT, so I am looking for an easy way to set U-Boot's > "externally-facing" DT addr to the internal one - something like "fdt > internal" or having the internal DT address in a variable or just making It's already in a variable today, so you can access (and copy) it if you want :). > it the default unless the user or boot script loads a custom one. In the EFI case, we fall back to the internal fdt if we can't find a matching file name on the boot media. That way users / distros can provide newer dtb files while we still maintain compatibility with distros / OSs that choose not to. Other than those 2 points, I fully agree with you :). We should try to provide a "known good" device tree on all systems we care about, so that an OS can just consume it. Whether it's the internal dt or an additionally bundled dt is an implementation detail imho. Alex
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" +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set +CONFIG_HUSH_PARSER=y +# CONFIG_CMD_IMLS is not set +# CONFIG_CMD_FLASH is not set +CONFIG_CMD_MMC=y +# CONFIG_CMD_FPGA is not set +CONFIG_CMD_DHCP=y +CONFIG_CMD_MII=y +CONFIG_CMD_PING=y +CONFIG_CMD_EXT2=y +CONFIG_CMD_EXT4=y +CONFIG_CMD_FAT=y +CONFIG_CMD_FS_GENERIC=y diff --git a/configs/pine64_plus_defconfig b/configs/pine64_plus_defconfig deleted file mode 100644 index 0977334..0000000 --- a/configs/pine64_plus_defconfig +++ /dev/null @@ -1,20 +0,0 @@ -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" -# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set -CONFIG_HUSH_PARSER=y -# CONFIG_CMD_IMLS is not set -# CONFIG_CMD_FLASH is not set -CONFIG_CMD_MMC=y -# CONFIG_CMD_FPGA is not set -CONFIG_CMD_DHCP=y -CONFIG_CMD_MII=y -CONFIG_CMD_PING=y -CONFIG_CMD_EXT2=y -CONFIG_CMD_EXT4=y -CONFIG_CMD_FAT=y -CONFIG_CMD_FS_GENERIC=y
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