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

Tue Dec 7 23:02:41 CET 2021

Hi Simon

On Mon, 6 Dec 2021 at 16:23, Simon Glass <sjg at chromium.org> wrote:

> Hi François,
>
> On Sat, 4 Dec 2021 at 18:15, François Ozog <francois.ozog at linaro.org>
> wrote:
> >
> > 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 ?
>
> It's so the console works in SPL - the UART needs to be set up.
>
>
> https://u-boot.readthedocs.io/en/latest/develop/driver-model/design.html#pre-relocation-support

I don't see why not using "stdout-path". It was once a linux property but
was promoted to component agnostic. I think I have seen some discussions in
TFA to also have different consoles (secure world...) if you have different
UARTs available. May be a discussion to have with them to have an official
binding for consoles, not just a U-Boot one.

>
>
> >
> > Why do you need to place SPL in the ROM space ?
>
> I believe address 0 is the ROM. We need to put it somewhere where it
> can be started by QEMU. When we run U-Boot proper we put it there, so
> with SPL we put it there also. I believe this is how things normally
> work with QEMU, although I am not an expert on that.
>
So SPL relocates itself in RAM ?
The size thing looks like it could be handled differently: have a branch
instruction at address 0, and the following bytes could be filled by binman
to provide the info or something similar (reserve enough bytes to squeeze
in the DT fragment you showed; or other possible ways)

>
> >
> [..]
>
> Regards,
> Simon
>

-- 
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog at linaro.org | Skype: ffozog