[PATCH 6/8] arm: dts: Sync the sun50i-a64.dtsi from Linux 5.8-rc1

[André Przywara]

On 27/07/2020 14:16, Heinrich Schuchardt wrote:

Hi Peter, Heinrich,

> On 26.07.20 12:17, Peter Robinson wrote:
>> On Thu, Jul 23, 2020 at 12:15 AM André Przywara <andre.przywara at arm.com> wrote:
>>>
>>> On 22/07/2020 15:18, Peter Robinson wrote:
>>>> Sync the Allwinner A64 sun50i-a64.dtsi from Linux.
>>>
>>> Hi Peter,
>>>
>>> thanks for your series!
>>>
>>> While this looks mostly straight-forward, the problem is that this patch
>>> here affects all Allwinner boards. And for them it breaks older kernels,
>>> which cannot cope with some of the changed bindings or nodes.
>>> Your patches up until here are fine, since they only add nodes and
>>> properties, but this update changes nodes, some in a non-compatible way.
>>>
>>> Examples are dropping the "syscon" compatible (which requires 4.18 to
>>> know about the new compatible string) and the dropping of
>>> internal-osc-clk and the connected RTC change. This breaks any kernels
>>> that don't know about the third RTC clock (<&rtc 2>) or the new
>>> compatible string (introduced in 4.20). Similar effects show up in other
>>> OSes.
>>
>> The 4.18 kernel is over 2 years old. How many users are going to
>> actively upgrade U-Boot to the latest and not the kernel all while
>> using the U-Boot provided DT and not just loading the matching kernel
>> DT supplied by what ever ancient kernel they happen to choose to use?

Everyone who wants to boot the UEFI/distro way, using the DT as a
hardware description, provided by the firmware. Yes, for years people
got used to somehow get some matching revision of the right DT loaded
together with the kernel, but the UEFI boot flow makes this rather hard
to do.
And with the availability of $fdtcontroladdr (which is actually
implicit if bootefi is just called with one argument) this would all fit
so nicely: You have your device specific firmware build (firmware in the
classis sense, not the Android meaning), and the rest (kernel, userland,
secondary bootloaders) is generic and everything falls in place.

>> I feel this use case is quite a corner case and in those cases they're
>> probably not using a vanilla upstream U-Boot anyway.
> 
> Sure people using an old Linux distribution not providing an U-Boot
> image may do so.
> 
> But here we are talking about the U-Boot device tree.

What is a "U-Boot device tree"? The device tree describes the hardware,
so how would that be different between Linux, U-Boot, FreeBSD or Zephyr?
For practical reasons (no on-board storage, for instance) the DT is
shipped with some software/firmware, but the concept is still that of a
kernel-agnostic description.

Actually U-Boot's own DT needs are very minimal: we could get away with
a VERY basic DT, barely containing a clock node, and MMC, EMAC and USB
nodes with just reg and clocks properties.

But since a U-Boot build is per-board, it sounds natural to make this
the only place which holds the respective devicetree, so any user would
just consume it and doesn't need to have any further board specific
information.

> As Linux device
> trees are release specific you should not try to boot Linux using a
> devicetree not provided by the exact same Linux version.

Where does this statement come from? Definitely you can boot Linux with
DTs from a previous version, but conceptually DTs are independent from
any software consumer. It's just very hard to get that right if you
don't have all the documentation upfront, to create DT nodes which
describe everything you need. That's why some platform maintainers
decided to not guarantee forward compatibility for their platform.
Which doesn't mean we should not still aim at this, hence my request to
tweak some compatible string to restore compatibility across various
Linux kernel releases (used by distributions as their official kernel).

> So incompatiblities between old Linux releases and U-Boot's device tree
> should be irrelevant.
> 
> Best regards
> 
> Heinrich
> 
>>
>>> I was experimenting with some small changes (compared to mainline) to
>>> overcome those issues, mostly by *adding* compatible strings instead of
>>> *replacing* them.
>>
>> Shouldn't they be added to a -u-boot.dtsi?

This might be a possible way to implement this, although the idea of
those files is to accommodate U-Boot specific nodes or properties.

Cheers,
Andre

>>> So I would like to ask for a few days so that I can do more testing with
>>> various kernels. I would then post those changes, so that we can discuss
>>> them.
>>>
>>> Cheers,
>>> Andre
>>>
>>>>
>>>> Signed-off-by: Peter Robinson <pbrobinson at gmail.com>
>>>> ---
>>>>  arch/arm/dts/sun50i-a64.dtsi | 532 ++++++++++++++++++++++++++++-------
>>>>  1 file changed, 434 insertions(+), 98 deletions(-)
>>>>