Le ven. 3 déc. 2021 à 21:14, Simon Glass <s...@chromium.org> a écrit :
> 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. 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.o...@linaro.org | Skype: ffozog