> From: François Ozog <francois.o...@linaro.org> > Date: Thu, 2 Dec 2021 19:32:17 +0100 > > On Thu, 2 Dec 2021 at 19:15, Mark Kettenis <mark.kette...@xs4all.nl> wrote: > > > From: Ilias Apalodimas <ilias.apalodi...@linaro.org> > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini <tr...@konsulko.com> wrote: > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > Hi Simon > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass <s...@chromium.org> a > écrit : > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > OF_HOSTFILE so > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > - OF_SEPARATE - the normal way, where the devicetree is built > and > > > > > appended to U-Boot > > > > > - OF_EMBED - for development purposes, the devicetree is > embedded in > > > > > the ELF file (also used for EFI) > > > > > - OF_BOARD - the board figures it out on its own > > > > > > > > > > The last one is currently set up so that no devicetree is needed > at all > > > > > in the U-Boot tree. Most boards do provide one, but some don't. > Some > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > The problems with this approach are documented in another patch > in this > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. > Any board > > > > > can obtain its devicetree at runtime, even it is has a > devicetree built > > > > > in U-Boot. This is because U-Boot may be a second-stage > bootloader and its > > > > > caller may have a better idea about the hardware available in > the machine. > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should > be an > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > This series makes this change, adding various missing devicetree > files > > > > > (and placeholders) to make the build work. > > > > > > > > > > Note: If board maintainers are able to add their own patch to > add the > > > > > files, some patches in this series can be dropped. > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. > The > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > [1] > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > 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 > > > > > - Expand the commit message based on comments > > > > > - Expand the commit message based on comments > > > > > > > > You haven’t addressed any concerns expressed on the mailing > list.so I am > > > > not in favor of this new version either. > > > > If you make a version without « fake DTs » as you name them, there > are good > > > > advances in the documentation and other areas that would be better > in > > > > mainline…. > > > > If I am the only one thinking this way and the patch can be > accepted, I > > > > would love there is a warning in capital letters at the top of the > DTS fake > > > > files that explains the intent of this fake DT, the possible > outcomes of > > > > not using the one provided by the platform and the right way of > dealing > > > > with DTs for the platform. > > > > > > This is the part that I too am still unhappy about. I do not want > > > reference or fake or whatever device trees in the U-Boot source > tree. > > > We should be able to _remove_ the ones we have, that are not > required, > > > with doc/board/...rst explaining how to get / view one. Not adding > > > more. > > > > So this is a key point for me and the reason I completely disagree > > with this approach. This proposal is working in the *exact* opposite > > direction and we'll never be able to get rid of device trees from > > U-Boot, even if at some point they move out of the kernel to a > > 'common' repo'. I'll just repeat what I've been saying since v1. > > Personally I'd be way happier if we could figure out were the specific > > U-Boot config nodes are needed and when are they needed. Based on > > what we figure out we could, pick up the device tree from a previous > > state bootloader and fix it up with our special nodes before we start > > using it, using internal DTS files (compiled to .dtbos or similar) > > that indeed belong in the u-boot tree. > > I don't think it makes sense to put stuff in the DT that is specific > for U-Boot only to pull it out moments later. Maybe it does make some > sense to do this to pass information between TPL/SPL and U-Boot > proper. But otherwise you can just use global variables... > > Now I just ran into an issue on Apple M1 that may have some relevance > here. I'm adding support for power domains and the serial port > requires certain power domains to be on. Since the serial port is > initialized in the pre-relocation phase this means that the device > tree nodes for the power domain controllers need to have the > "u-boot,dm-pre-reloc" property on them. Otherwise the DM code won't > be able to bind the power domain controller driver in this phase and > binding the serial port driver itself will fail. Which makes U-Boot > hang without any visible output on the serial console. > > Does this hint at a bigger issue that DT shall be parsed and handled in the > U-Boot process way early than it is today?
No it doesn't. It indicates that it is already parsed and handled very early on in the U-Boot process, which implies that applying modifications in U-Boot itself will be a challenge. > Ilias reported a similar problem with TPM handling where you need to > discover TPM very early to deal with it. > There may be one early parse and two scans (one early, one normal > enumeration) Serial ports are explicitly handled early on. I suppose the TPM could be handled in a similar way if there is a valid reason to do so. But in my opinion the TPM is way to complex for doing something like that. > Within the Asahi Linux group we're currently discussing how to solve > this. We could just add the "u-boot,dm-pre-reloc" properties in the > device trees that we're going to distribute as part of m1n1 (the > "bootloader" than embeds U-Boot). Or we can write some code that adds > those properties to the device tree nodes that are dependencies for > the serial port. > > I don't think the suggestion of applying an overlay embedded in U-Boot > would work here. The code applying the overlay would need to run very > early on in the pre-relocation phase. We'd also have to include > overlays for all the models that Apple offers and pick the right one. > And if a new model appears we can no longer just add a new device tree > to m1n1. > > But maybe there is a case where the overlay approach would make sense... > > -- > > * François-Frédéric Ozog | Director Business Development > T: +33.67221.6485 > francois.o...@linaro.org | Skype: ffozog > *