[PATCH v6 01/25] doc: Add documentation about devicetree usage

[Heinrich Schuchardt]

On 12/3/21 9:13 PM, Simon Glass wrote:
> Hi Heinrich,
>
> On Fri, 3 Dec 2021 at 06:09, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>>
>> On 12/3/21 13:34, Heinrich Schuchardt wrote:
>>> On 12/2/21 16:58, Simon Glass wrote:
>>>> At present some of the ideas and techniques behind devicetree in U-Boot
>>>> are assumed, implied or unsaid. Add some documentation to cover how
>>>> devicetree is build, how it can be modified and the rules about using
>>>> the various CONFIG_OF_... options.
>>>>
>>>> Signed-off-by: Simon Glass <sjg at chromium.org>
>>>> Reviewed-by: Marcel Ziswiler <marcel.ziswiler at toradex.com>
>>>> ---
>>>> This patch attracted quite a bit of discussion here:
>>>>
>>>> https://patchwork.ozlabs.org/project/uboot/patch/20210909201033.755713-4-sjg@chromium.org/
>>>>
>>>>
>>>> I have not included the text suggested by François. While I agree that
>>>> it would be useful to have an introduction in this space, I do not agree
>>>> that we should have two devicetrees or that U-Boot should not have its
>>>> own
>>>> things in the devicetree, so it is not clear to me what we should
>>>> actually
>>>> write.
>>>>
>>>> The 'Devicetree Control in U-Boot' docs were recently merged and these
>>>> provide some base info, for now.
>>>>
>>>> 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
>>>>
>>>> Changes in v5:
>>>> - Bring into the OF_BOARD series
>>>> - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed
>>>> - Refer to the 'control' DTB in the first paragraph
>>>> - Use QEMU instead of qemu
>>>>
>>>> Changes in v3:
>>>> - Clarify the 'bug' refered to at the top
>>>> - Reword 'This means that there' paragraph to explain U-Boot-specific
>>>> things
>>>> - Move to doc/develop/devicetree now that OF_CONTROL is in the docs
>>>>
>>>> Changes in v2:
>>>> - Fix typos per Sean (thank you!) and a few others
>>>> - Add a 'Use of U-Boot /config node' section
>>>> - Drop mention of dm-verity since that actually uses the kernel cmdline
>>>> - Explain that OF_BOARD will still work after these changes (in
>>>>     'Once this bug is fixed...' paragraph)
>>>> - Expand a bit on the reason why the 'Current situation' is bad
>>>> - Clarify in a second place that Linux and U-Boot use the same devicetree
>>>>     in 'To be clear, while U-Boot...'
>>>> - Expand on why we should have rules for other projects in
>>>>     'Devicetree in another project'
>>>> - Add a comment as to why devicetree in U-Boot is not 'bad design'
>>>> - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot'
>>>> - Rewrite 'Devicetree generated on-the-fly in another project' to cover
>>>>     points raised on v1
>>>> - Add 'Why does U-Boot have its nodes and properties?'
>>>> - Add 'Why not have two devicetrees?'
>>>>
>>>>    doc/develop/devicetree/dt_update.rst | 555 +++++++++++++++++++++++++++
>>>>    doc/develop/devicetree/index.rst     |   1 +
>>>>    2 files changed, 556 insertions(+)
>>>>    create mode 100644 doc/develop/devicetree/dt_update.rst
>>>>
> [..]
>
>>>> +
>>>> +- The other project may not provide a way to support U-Boot's
>>>> requirements for
>>>> +  devicetree, such as the /config node. Note: On the U-Boot mailing
>>>> linst, this
>>>
>>> Even if you remove these lines in 17/25 I would prefer not to introduce
>>> typos here:
>>>
>>> %s/linst/list/
>>>
>
> OK I can fix that.
>
> [..]
>
>>>> +Normally, supporting U-Boot's features is trivial, since the
>>>> devicetree compiler
>>>> +(dtc) can compile the source, including any U-Boot pieces. So the
>>>> burden is
>>>> +extremely low.
>>>> +
>>>> +In this case, the devicetree in the other project must track U-Boot's
>>>> use of
>>>> +device tree, so that it remains compatible. See `Devicetree in
>>>> another project`_
>>>> +for reasons why.
>>>
>>> Did you ever ask the QEMU community what they think about your ideas?
>>> What was the reply?
>>
>> Looking at the thread
>> https://lore.kernel.org/all/20210926183410.256484-1-sjg@chromium.org/
>> the QEMU project said NAK. This matches the expectation that I expressed
>> repeatedly.
>>
>> Why don't you mention the QEMU reply in this patch series and adjust
>> your design accordingly?
>
> The QEMU maintainer may react when he sees a problem.

Why are you unwilling to admit the problem? QEMU will never support
U-Boot specific stuff.

Please, develop concepts that solve U-Boot's needs within U-Boot.

Best regards

Heinrich

>
> I have already clearly stated that there is no way we are have two
> control DTBs. The overlay is also unworkable and unnecessary. That is
> why I put so much effort into this patch, after all.
>
> So for now, people will just have to deal with what QEMU provides. I
> sent a patch to resolve the problem which can be accepted at any point
> if people complain enough. So far only François has offered support
> for it.
>
> Regards,
> Simon
>