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

[François Ozog]

Hi Simon

Le sam. 4 déc. 2021 à 18:42, Simon Glass <sjg at chromium.org> a écrit :

> Hi François,
>
> On Sat, 4 Dec 2021 at 04:06, François Ozog <francois.ozog at linaro.org>
> wrote:
> >
> > Hi Simon
> >
> > Le sam. 4 déc. 2021 à 02:02, Simon Glass <sjg at chromium.org> a écrit :
> >>
> >> 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?
> >
> > heinrich did not said that. He said that QEMU team said it doesn’t want
> to deal with specifics of *any* payload, be it a Linux kernel, a
> hypervisor, TFA, U-Boot, Coreboot or *Boot.
>
> Except that QEMU does deal with the Linux specifics. See the
> qemu-arm.dts file in this series, which is directly taken from QEMU.
> It has linux, properties and a chosen node. I wasn't even suggesting
> that it deal with U-Boot specifics, just provide a way to adjust the
> DT that it creates out of whole cloth.
>
> > In that spirit, TFA made sure they can have the DT they need in the FIP.
> > I add now: U-Boot when loaded by SPL in QEMU can follow the same pattern
> and have a FIT contain U-Boot and the control DTs it needs and deal with
> it. Binman should be used to assemble that image. Something along those
> lines…
>
> Yes, except U-Boot cannot even boot from SPL without some DT
> properties. See my patch
>
>
> https://patchwork.ozlabs.org/project/uboot/patch/20211101011734.1614781-15-sjg@chromium.org/


what is the purpose of

+	pl011 at 9000000 {+		u-boot,dm-spl;+	};

is it to do the same as stdout-path ?

Why do you need to place SPL in the ROM space ?


> I have been working on this for years. Trust me...
>
> Regards,
> Simon
>
> >>
> >>
> >> 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
> >> > >
> >> >
> >
> > --
> > François-Frédéric Ozog | Director Business Development
> > T: +33.67221.6485
> > francois.ozog at linaro.org | Skype: ffozog
> >
>
-- 
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog at linaro.org | Skype: ffozog