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

Reply via email to