Hi Simon Le sam. 4 déc. 2021 à 18:42, Simon Glass <s...@chromium.org> a écrit :
> Hi François, > > On Sat, 4 Dec 2021 at 04:06, François Ozog <francois.o...@linaro.org> > wrote: > > > > Hi Simon > > > > Le sam. 4 déc. 2021 à 02:02, Simon Glass <s...@chromium.org> a écrit : > >> > >> Hi Heinrich, > >> > >> On Fri, 3 Dec 2021 at 13:28, Heinrich Schuchardt <xypron.g...@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.g...@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 <s...@chromium.org> > >> > >>>> Reviewed-by: Marcel Ziswiler <marcel.ziswi...@toradex.com> > >> > >>>> --- > >> > >>>> This patch attracted quite a bit of discussion here: > >> > >>>> > >> > >>>> > https://patchwork.ozlabs.org/project/uboot/patch/20210909201033.755713-4-...@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-...@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-...@chromium.org/ what is the purpose of + pl011@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.o...@linaro.org | Skype: ffozog > > > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
