[PATCH v6 00/25] fdt: Make OF_BOARD a boolean option

[Heinrich Schuchardt]

On 12/3/21 11:27, Mark Kettenis wrote:
>> Date: Fri, 3 Dec 2021 09:50:44 +0200
>> From: Ilias Apalodimas <ilias.apalodimas at linaro.org>
>>
>> Hi Mark,
>>
>>>>>>>
>>
>> [...]
>>
>>>>>>> Changes in v6:
>>>>>>> - Fix description of OF_BOARD so it refers just to the current state
>>>>>>> - Explain that the 'two devicetrees' refers to two *control* devicetrees
>>>>>>> - Expand the commit message based on comments
>>>>>>> - Expand the commit message based on comments
>>>>>>
>>>>>> You haven’t addressed any concerns expressed on the mailing list.so I am
>>>>>> not in favor of this new version either.
>>>>>> If you make a version without « fake DTs » as you name them, there are good
>>>>>> advances in the documentation and other areas that would be better in
>>>>>> mainline….
>>>>>> If I am the only one thinking this way and the patch can be accepted, I
>>>>>> would love there is a warning in capital letters at the top of the DTS fake
>>>>>> files that explains the intent of this fake DT, the possible outcomes of
>>>>>> not using the one provided by the platform and the right way of dealing
>>>>>> with DTs for the platform.
>>>>>
>>>>> This is the part that I too am still unhappy about.  I do not want
>>>>> reference or fake or whatever device trees in the U-Boot source tree.
>>>>> We should be able to _remove_ the ones we have, that are not required,
>>>>> with doc/board/...rst explaining how to get / view one.  Not adding
>>>>> more.
>>>>
>>>> So this is a key point for me and the reason I completely disagree
>>>> with this approach.  This proposal is working in the *exact* opposite
>>>> direction and we'll never be able to get rid of device trees from
>>>> U-Boot, even if at some point they move out of the kernel to a
>>>> 'common' repo'.  I'll just repeat what I've been saying since v1.
>>>> Personally I'd be way happier if we could figure out were the specific
>>>> U-Boot config nodes are needed and when are they needed.  Based on
>>>> what we figure out we could, pick up the device tree from a previous
>>>> state bootloader and fix it up with our special nodes before we start
>>>> using it, using internal DTS files (compiled to .dtbos or similar)
>>>> that indeed belong in the u-boot tree.

Applying a devicetree overlay can be implemented in common/board_f.c
before the first usage of the devicetree to initialize devices (there
are some that are initialized before relocation).

>>>
>>> I don't think it makes sense to put stuff in the DT that is specific
>>> for U-Boot only to pull it out moments later.  Maybe it does make some
>>> sense to do this to pass information between TPL/SPL and U-Boot
>>> proper.  But otherwise you can just use global variables...

Linux will silently ignore any node for which it does not have a
compatible string. So application of an overlay once in U-Boot is
sufficient.

Best regards

Heinrich

>>
>> Last time we said we don't really have to remove them,  but I get the
>> point.
>
> Ah, when I said "pull it out" I meant "read it back"; not "delete it".
>
>>> Now I just ran into an issue on Apple M1 that may have some relevance
>>> here.  I'm adding support for power domains and the serial port
>>> requires certain power domains to be on.  Since the serial port is
>>> initialized in the pre-relocation phase this means that the device
>>> tree nodes for the power domain controllers need to have the
>>> "u-boot,dm-pre-reloc" property on them.  Otherwise the DM code won't
>>> be able to bind the power domain controller driver in this phase and
>>> binding the serial port driver itself will fail.  Which makes U-Boot
>>> hang without any visible output on the serial console.
>>
>> Very relevant indeed.  That's close to what I was afraid of when I said
>> "if we could figure out were the specific U-Boot config nodes are needed
>> and *when* are they needed".  Obviously this is a clear no go, since more
>> boards will have similar requirements in the future.
>>
>>>
>>> Within the Asahi Linux group we're currently discussing how to solve
>>> this.  We could just add the "u-boot,dm-pre-reloc" properties in the
>>> device trees that we're going to distribute as part of m1n1 (the
>>> "bootloader" than embeds U-Boot).  Or we can write some code that adds
>>> those properties to the device tree nodes that are dependencies for
>>> the serial port.
>>
>> That might make sense for a project like m1n1 were you are dealing with a
>> handful of devices,  but I think it's going to be a pain on a larger scale,
>> unless of course the bindings are documented in upstream.  In that case we
>> could ask previous bootloaders to add them etc.
>>
>>>
>>> I don't think the suggestion of applying an overlay embedded in U-Boot
>>> would work here.  The code applying the overlay would need to run very
>>> early on in the pre-relocation phase.
>>
>> Yep it wouldn't
>>
>>> We'd also have to include
>>> overlays for all the models that Apple offers and pick the right one.
>>> And if a new model appears we can no longer just add a new device tree
>>> to m1n1.
>>>
>>> But maybe there is a case where the overlay approach would make sense...
>>
>> I think there is, for example I was thinking of TF-A doing all the hardware init
>> and then handover a DTB into u-boot on a register.  In that case U-boot
>> could fixup the DTB before initialing the rest of the subsystems and make DM
>> happy.  However as you pointed out that's not the case for all boards and
>> dealing with this in the early pre-relocation stage is close to
>> impossible, so let's drop that.
>>
>>
>> Thanks!
>> /Ilias
>>