Hi Heinrich, On Fri, 3 Dec 2021 at 06:09, Heinrich Schuchardt <[email protected]> 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 <[email protected]> > >> Reviewed-by: Marcel Ziswiler <[email protected]> > >> --- > >> This patch attracted quite a bit of discussion here: > >> > >> https://patchwork.ozlabs.org/project/uboot/patch/[email protected]/ > >> > >> > >> 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/[email protected]/ > 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. 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
