On Tue, Feb 11, 2020 at 11:44 AM Francois Ozog <francois.ozog@xxxxxxxxxx> wrote: > > On Tue, 11 Feb 2020 at 17:32, Rob Herring <robh@xxxxxxxxxx> wrote: > > > > On Mon, Feb 10, 2020 at 10:58 AM Mills, William <wmills@xxxxxx> wrote: > > > > > > Steve, > > > > > > Can TI get on the agenda for this week's meeting? > > > > > > We have a simple approach to make progress on boot loader applied overlays. > > > It is a small repo with just the overlays. > > > It builds the dtb's from the upstream kernel repo and the overlays from this repo. > > > We are going to do this at git.ti.com so we can make progress. > > > However we would like to suggest this as a simple way forward to collectively host things the kernel maintainers do not want in the kernel. > > > > For the record, I'm in favor of hosting overlays in the kernel (of > > course I have opinions on the details). Frank is not in favor IIRC, > > but Frank is only maintainer of 'drivers/of/' so ultimately not his > > decision. > > > > > Does it make sense to host something like this in devicetree.org github account? > > > > Yes, but I would like to see this coordinated with hosting > > 'devicetree-rebasing' there. We should be able to use the same > > makefiles from it. Perhaps the overlay repo should work as a git > > submodule of it as well. That would help keep things in sync. > > > > A concern I have is what happens when someone wants to split some > > portions of an existing dts into an overlay? Then the base dts becomes > > incomplete. Users will have regressions from missing functionality if > > they don't know to apply some overlay. And how do we track what base > > DTs overlays apply to? Not that we have a solution when they are in > > one tree, but 2 trees makes that harder. > > DT lifecycle shall be selectable by the board vendor. If, for any reason > (and there may be plenty), a vendor believes it is a better organization to > handle the DT assembly (static + overlays) outside the kernel, then it > should be possible to do so. Certainly, I don't think I said anything that would prevent that. In that case, I would assume the board is not already upstream and there's not any backwards compatibility (ABI) to worry about. I'm only talking about cases where the split is changed such that we go from a monolithic dtb to a base dtb plus 1 or more overlay dtbs. IOW, we can't just change the split because that is an ABI. We still need to build and provide that original single dtb. There may be exceptions to that, but by default I have to care about backwards compatibility (and overlays add a new dimension to that). I suppose we could decide that a collection of base and overlay DTs are a monolithic unit and there is no ABI between them. However, we'd need to define some way to distinguish both cases. It's plausible that you'd want to do both on the same platform (base and overlay dtbs from the board vendor and 3rd party overlays). Besides the above reason, there is something much more basic. We need build time assembly of base plus overlays just to validate overlays apply successfully. We don't want the only way to check an overlay applies is by booting the specific board that works with a given base and overlay dtb. Whether overlays apply or not is just the first step in validation. There's all the schema validation to do which is going to have its own issues. Rob
