On Wed, Apr 26, 2023 at 09:04:56PM -0700, ron minnich wrote: > The device tree is self describing data. Adding new information is easy. If you > add new information to a node, and older software does not know about it, it is > no big deal. It's true that it's easy to add fields to an extensible format, but that wasn't my point of contention. The *semantic* (e.g. all of the relevant DT bindings) and *consumption* of that data is the important part, and that's what I was referring to, though I appreciate my wording did not make that clear. > So I can't agree with this comment: "We'd have to create entirely new ways to > pass that information, which is not > very desirable." > > The whole point of the dt is that you can always add new ways to pass > information, by design. > > Adding memory attributes would be quite easy. I don't disagree that is physically possible, and in isolation adding properties to a DT is trivial, but the approach proposed is not "easy" unless you ignore the cost of specifying analogues for all the EFI portions that you plan to omit, ensuring that those stay functionally equivalent to their EFI analogues as EFI and ACPI evolve over time, developing and maintaining the code which must consume that, avoiding the issues that will arise due to novel interactions (as e.g. DT and ACPI are mutually exclusive today, by design), etc. For example, the UEFI memory map is semantically and structurally different from DT memory nodes. It encodes *different* information, and in practice needs to encode a larger number of physical extents with properties (e.g. cacheability, permissions) associated with each extent. The existing DT memory nodes format isn't really amenable to encoding this, inventing a parallel structure for this opens up all the usual problems of the two becoming out-of-sync, and inventing a new mechanism to describe all of this in a consistent way duplicates all the work done for EFI. I appreciate that at a high level of abstractions this seems conceptually simple, but in practice this is a complex area where components have subtle and often implicit dependencies, and so there is inherent fractal complexity. Thanks, Mark. > On Wed, Apr 26, 2023 at 8:38 PM 运辉崔 <cuiyunhui@xxxxxxxxxxxxx> wrote: > > Hi Mark, > > On Wed, Apr 26, 2023 at 6:07 PM Mark Rutland <mark.rutland@xxxxxxx> wrote: > > > > Ard's point is that the device tree doesn't have all the same information > (e.g. > > nothing in DT describes the memory type attributes), and so this isn't > > sufficient. > > The device tree only needs to complete the parse of the memory type > attributes, > it should not be very complicated. > > > > > We'd have to create entirely new ways to pass that information, which is > not > > very desirable. > > > > > > > Can you extend coreboot to provide EFI services, or to chain-load an EFI > > payload? > > Currently, coreboot does not support UEFI, and it may not support it > in the future. > Hi rminnich, what do you think? > > Thanks, > Yunhui >
