[PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file

[François Ozog]

Le ven. 3 déc. 2021 à 21:14, Simon Glass <sjg at chromium.org> a écrit :

> Hi François,
>
> On Fri, 3 Dec 2021 at 10:03, François Ozog <francois.ozog at linaro.org>
> wrote:
> >
> >
> >
> > On Fri, 3 Dec 2021 at 17:04, Simon Glass <sjg at chromium.org> wrote:
> >>
> >> Hi Tom,
> >>
> >> On Fri, 3 Dec 2021 at 05:14, Tom Rini <trini at konsulko.com> wrote:
> >> >
> >> > On Thu, Dec 02, 2021 at 12:23:10PM -0700, Simon Glass wrote:
> >> > > Hi François,
> >> > >
> >> > > On Thu, 2 Dec 2021 at 11:44, François Ozog <
> francois.ozog at linaro.org> wrote:
> >> > > >
> >> > > > Hi Simon
> >> > > >
> >> > > > On Thu, 2 Dec 2021 at 19:29, Simon Glass <sjg at chromium.org>
> wrote:
> >> > > >>
> >> > > >> Hi François,
> >> > > >>
> >> > > >> On Thu, 2 Dec 2021 at 11:17, François Ozog <
> francois.ozog at linaro.org> wrote:
> >> > > >> >
> >> > > >> > Hi Simon
> >> > > >> >
> >> > > >> > On Thu, 2 Dec 2021 at 19:05, Simon Glass <sjg at chromium.org>
> wrote:
> >> > > >> >>
> >> > > >> >> Hi Tom,
> >> > > >> >>
> >> > > >> >> On Thu, 2 Dec 2021 at 10:56, Tom Rini <trini at konsulko.com>
> wrote:
> >> > > >> >> >
> >> > > >> >> > On Thu, Dec 02, 2021 at 05:40:46PM +0000, Oleksandr
> Andrushchenko wrote:
> >> > > >> >> > > Hi, Simon!
> >> > > >> >> > >
> >> > > >> >> > > Sorry for being late to the party
> >> > > >> >> > >
> >> > > >> >> > > On 02.12.21 17:59, Simon Glass wrote:
> >> > > >> >> > > > Add an empty file to prevent build errors when building
> with
> >> > > >> >> > > > CONFIG_OF_SEPARATE enabled.
> >> > > >> >> > > >
> >> > > >> >> > > > The build instructions in U-Boot do not provide enough
> detail to build a
> >> > > >> >> > > > useful devicetree, unfortunately.
> >> > > >> >> > > Xen guest doesn't use any built-in device trees as the
> guest's device tree is provided
> >> > > >> >> > > by the Xen hypervisor itself and is generated at the
> virtual machine creation time: it is
> >> > > >> >> > > populated with memory size, number of CPUs etc. based on
> [1].
> >> > > >> >> > > So, even if we provide some device tree here it must not
> be used by U-boot at
> >> > > >> >> > > the end of the day. Thus, it might be a reasonable
> solution to provide an empty device
> >> > > >> >> > > tree as you do, but put a comment that it is not used.
> >> > > >> >> >
> >> > > >> >> > So another example of why this series is taking things in
> the wrong
> >> > > >> >> > direction.
> >> > > >> >>
> >> > > >> >> Why?
> >> > > >> >
> >> > > >> > I only had that comment in mind: "there is none so deaf as he
> who will not hear."
> >> > > >>
> >> > > >> Hey, stop the pile-on. It's not useful.
> >> > > >>
> >> > > >> I've guided U-Boot's use of devicetree for 10 years
> successfully. The
> >> > > >> current state is a mess and I just to straighten it out.
> >> > > >>
> >> > > > I admire your talent and knowledge.
> >> > > > I know you are 99,99% of the time correct and spot on for your
> comments in many meetings we were attending.
> >> > > > When you questioned a number of points I made, I first tried to
> understand what I got wrong because you said it.
> >> > > > And you were right ;-)
> >> > > > For this topic, I made every effort to come to your position, but
> definitively can't.
> >> > >
> >> > > Thank you. I think this will come together in a few years when
> >> > > devicetree is sorted out in U-Boot and Binman is more widely used.
> >> > >
> >> > > For this series, if and when it is applied, I predict:
> >> > > - it will not cause any confusion
> >> > > - it will aid development
> >> > > - it will help with discoverability, pressuring people to explain
> how
> >> > > to build for their systems
> >> > > - it will be a good basis for future work (we have a long list)
> >> > > - everyone will wonder what the fuss was about
> >> > >
> >> > > Here is the commit that introduced OF_PRIOR_STAGE. It attracted no
> >> > > such push-back.
> >> > >
> >> > > commit 894c3ad27fa940beb7fdc07d01dcfe81c03d0481
> >> > > Author: Thomas Fitzsimmons <fitzsim at fitzsim.org>
> >> > > Date:   Fri Jun 8 17:59:45 2018 -0400
> >> > >
> >> > >     board: arm: Add support for Broadcom BCM7445
> >> > >
> >> > >     Add support for loading U-Boot on the Broadcom 7445 SoC.  This
> port
> >> > >     assumes Broadcom's BOLT bootloader is acting as the second stage
> >> > >     bootloader, and U-Boot is acting as the third stage bootloader,
> loaded
> >> > >     as an ELF program by BOLT.
> >> > >
> >> > >     Signed-off-by: Thomas Fitzsimmons <fitzsim at fitzsim.org>
> >> > >     Cc: Stefan Roese <sr at denx.de>
> >> > >     Cc: Tom Rini <trini at konsulko.com>
> >> > >     Cc: Florian Fainelli <f.fainelli at gmail.com>
> >> >
> >> > I want to cycle back over here.  Yes, historically a number of things
> >> > came in that perhaps shouldn't have.  I went with "well, this is what
> we
> >> > need to handle this case I suppose" and applied it.
> >>
> >> Yes and we need to move things forward. We can't just object to things
> >> without an alternative.
> >
> > As far as I can follow the threads, I proposed the dts to be empty to
> pass compilation and move forward, but I think you haven't replied. The
> empty dts can contain a comment pointing to documentation, which could
> describe the DT lifecycle of the platform, and a template dts that could be
> used for adventurous developers.
>
> That does not go far enough for me. We actually do want to be able to
> build U-Boot and run it on the board, e.g. in a lab. We cannot do that
> if there are manual instructions involved. The onus needs to be on
> contributors to make their boards actually buildable/bootable with
> U-Boot.

Compromise seems to be missing here…
If the dts is empty and defconfig is set to of_board it works well. So if
you want more, it means you want to tweak the DT lifecycle for those boards
as the standard way. Not good.

>
>
> [..]
>
> REgards,
> Simon
>
-- 
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog at linaro.org | Skype: ffozog