> Date: Fri, 3 Dec 2021 09:50:44 +0200 > From: Ilias Apalodimas <ilias.apalodi...@linaro.org> > > Hi Mark, > > > > > > > > > [...] > > > > > > > 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... > > Last time we said we don't really have to remove them, but I get the > point.
Ah, when I said "pull it out" I meant "read it back"; not "delete it". > > 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. > > Very relevant indeed. That's close to what I was afraid of when I said > "if we could figure out were the specific U-Boot config nodes are needed > and *when* are they needed". Obviously this is a clear no go, since more > boards will have similar requirements in the future. > > > > > 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. > > That might make sense for a project like m1n1 were you are dealing with a > handful of devices, but I think it's going to be a pain on a larger scale, > unless of course the bindings are documented in upstream. In that case we > could ask previous bootloaders to add them etc. > > > > > 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. > > Yep it wouldn't > > > 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... > > I think there is, for example I was thinking of TF-A doing all the hardware > init > and then handover a DTB into u-boot on a register. In that case U-boot > could fixup the DTB before initialing the rest of the subsystems and make DM > happy. However as you pointed out that's not the case for all boards and > dealing with this in the early pre-relocation stage is close to > impossible, so let's drop that. > > > Thanks! > /Ilias >
