Hi François, On Sat, 4 Dec 2021 at 18:15, François Ozog <francois.o...@linaro.org> wrote: > > 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 ?
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 > > 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. > [..] Regards, Simon
