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.o...@linaro.org> wrote: > > > > > > > > On Fri, 3 Dec 2021 at 17:04, Simon Glass <s...@chromium.org> wrote: > >> > >> Hi Tom, > >> > >> On Fri, 3 Dec 2021 at 05:14, Tom Rini <tr...@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.o...@linaro.org> > >> > > wrote: > >> > > > > >> > > > Hi Simon > >> > > > > >> > > > On Thu, 2 Dec 2021 at 19:29, Simon Glass <s...@chromium.org> wrote: > >> > > >> > >> > > >> Hi François, > >> > > >> > >> > > >> On Thu, 2 Dec 2021 at 11:17, François Ozog > >> > > >> <francois.o...@linaro.org> wrote: > >> > > >> > > >> > > >> > Hi Simon > >> > > >> > > >> > > >> > On Thu, 2 Dec 2021 at 19:05, Simon Glass <s...@chromium.org> > >> > > >> > wrote: > >> > > >> >> > >> > > >> >> Hi Tom, > >> > > >> >> > >> > > >> >> On Thu, 2 Dec 2021 at 10:56, Tom Rini <tr...@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 <fitz...@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 <fitz...@fitzsim.org> > >> > > Cc: Stefan Roese <s...@denx.de> > >> > > Cc: Tom Rini <tr...@konsulko.com> > >> > > Cc: Florian Fainelli <f.faine...@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
signature.asc
Description: PGP signature
