On 4/30/22 7:59 PM, Andre Przywara wrote:
> So those DT updates are really only important for mobile devices like the > Pinephone, which probably don't use UEFI booting.
We would really like to use UEFI booting on the PinePhone, and the out-of-date devicetree is one thing blocking that. We need to use $fdtcontroladdr to pick up the CPU idle states that are added at runtime by TF-A.
Yes, I was wondering about that. I could imagine that suspend/resume is a killer feature for the PinePhone. It probably sounds useful to fully update just the Pinephone .dts, giving up compatibility for older kernels. IIUC the PinePhone doesn't run normal "desktop" distros, but relies more on custom OSes, tailored to a Phone use case in general?
There is a mix of desktop distros, mobile spins of desktop distros (the largest/most popular category), and mobile-specific OSes[1].
[1]: https://wiki.pine64.org/wiki/PinePhone_Software_Releases
What kernels are those OSes using?
Most are using Ondrej's fork[2]. Some (at least Mobian) maintain their own patch set.
[2]: https://github.com/megous/linux/tags
The only caveat would be that this adds to the mess and increases the diff to mainline, but maybe this could be solved by a sun50i-a64-pinephone-u-boot.dtsi?
Devicetree changes are still needed for camera and USB Type C support, so the r_intc changes could go in with those. I don't think we need to do anything special from the U-Boot side at this point.
So, does that mean the plan is to keep the r_intc changes out of U-Boot for now, but we can sync the rest, and come up with a plan to fully update in time?
That's one possible solution, yes, and so far the easiest, it provides a good balance between features and compatibility.
This was my understanding of the plan as well.
Theoretically we can never fully sync, unless we decide to no longer support those older OSes (older Linux kernels and (current) *BSD).
Do we have any guidance for when this could be? After the n+1 LTS kernel/BSD release? After the distro/BSD installers update their kernels?
More the latter, I'd say when major distros stop shipping those old kernels in relevant releases. Especially Debian is one to keep an eye on I guess, since they are on 5.10 *currently*, and their installer properly stays there for a while. Ubuntu 20.04 shipped with 5.4, and I'd like to support that say at least one more year still. Don't really keep track of the kernels in other distros, but I think these two are among the more conservative ones.
OK, that makes sense.
Samuel, since I have you here: With your new hat Linux hat on, can you say whether incompatible DT changes won't happen in the future anymore?
No, I really cannot.
As for major breaking changes, there is some push from the Linux clock maintainers toward finishing the conversion from legacy to sunxi-ng clock drivers. This affects A31, A23/A33, and A80. (In fact, this unfinished conversion is causing me quite some trouble trying to expand the DM clock drivers in U-Boot.)
And then there are always little easy-to-miss things (like adding references to new ASoC widgets) that prevent drivers from loading on old kernels.
From experience I'd say there are ways to avoid them, though possibly at some cost (less clean DT, or deviating from some DT rules).
and, as I'm sure you're painfully aware of, delays in adding support for new hardware, until we can get the binding perfect, because we know we will be stuck with it.
One thing we could explore is patching the DT at runtime, but U-Boot cannot know if the OS supports the new style or not, so it has to be manually triggered.
Right, automatically handling this is not really feasible. Users that need the r_intc changes for suspend/resume will have to load a DTB or overlay from disk. (We could possibly build in such an overlay, and load it based on some environment variable, but this seems like little benefit when most users load a DTB from disk anyway.)
But loading from disk would lose any manipulation that previous firmware did, for instance TF-A. Plus I think reserved memory is not properly propagated, at least last time I checked. Also the DT would really need to be loaded by U-Boot, loading it via grub would lose even more manipulations like the DRAM size and MAC address.
So I believe an overlay is the way to go. I have a patch sitting here that applies all .dtbo files found in a directory on some block device (e.g. "fdt apply_all mmc 0:1 overlays/"), would that help?
Possibly? I will defer to others on how devicetree overlays could/should be integrated into the distro boot process.
Regards, Samuel