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

Fri Dec 3 21:21:25 CET 2021

On Fri, Dec 03, 2021 at 01:14:04PM -0700, Simon Glass wrote:
> 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.

We can build and boot the platform fine with an empty useless device
tree when we get the actual tree at run time.  You're conflating the
developer use case with the normal use case.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20211203/24816fd3/attachment.sig>