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

[Simon Glass]

Hi Heinrich,

On Fri, 3 Dec 2021 at 13:28, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>
> 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.

So you are saying that because QEMU wrote it's devicetree support with
Linux in mind, we should, what...? Spent 500ms merging devicetrees
before relocation? Move back to platdata? Delete driver model? Rewrite
U-Boot?

U-Boot works quite nicely as it is. The problem is that people are
still coming to terms with U-Boot's right to use the devicetree. This
could take a few more years, I think, or it may never happen. Most
people don't even know how U-Boot works. We just need to be patient.

Regards,
Simon


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