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