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