On Sun, Dec 3, 2023 at 11:33 PM Sumit Garg <sumit.g...@linaro.org> wrote: > > + Linux kernel DT bindings maintainers, EBBR ML > > On Thu, 30 Nov 2023 at 20:05, Tom Rini <tr...@konsulko.com> wrote: > > > > On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote: > > > On Wed, 29 Nov 2023 at 22:06, Neil Armstrong <neil.armstr...@linaro.org> > > > wrote: > > > > > > > > On 29/11/2023 16:34, Caleb Connolly wrote: > > > > > > > > > > > > > > > On 23/11/2023 07:04, Sumit Garg wrote: > > > > >> On Wed, 22 Nov 2023 at 21:34, Caleb Connolly > > > > >> <caleb.conno...@linaro.org> wrote: > > > > >>> > > > > >>> > > > > >>> > > > > >>> On 22/11/2023 14:27, Tom Rini wrote: > > > > >>>> On Wed, Nov 22, 2023 at 07:44:09PM +0530, Sumit Garg wrote: > > > > >>>>> On Wed, 22 Nov 2023 at 19:31, Tom Rini <tr...@konsulko.com> wrote: > > > > >>>>>> > > > > >>>>>> On Wed, Nov 22, 2023 at 11:51:29AM +0530, Sumit Garg wrote: > > > > >>>>>>> Hi Caleb, > > > > >>>>>>> > > > > >>>>>>> On Tue, 21 Nov 2023 at 22:39, Caleb Connolly > > > > >>>>>>> <caleb.conno...@linaro.org> wrote: > > > > >>>>>> [snip] > > > > >>>>>>>> == DT loading == > > > > >>>>>>>> > > > > >>>>>>>> Previously, boards used the FDT blob embedded into U-Boot (via > > > > >>>>>>>> OF_SEPARATE). However, most Qualcomm boards run U-Boot as a > > > > >>>>>>>> secondary > > > > >>>>>>>> bootloader, so we can instead rely on the first-stage > > > > >>>>>>>> bootloader to > > > > >>>>>>>> populate some useful FDT properties for us (notably the > > > > >>>>>>>> /memory node and > > > > >>>>>>>> KASLR seed) and fetch the DTB that it provides. Combined with > > > > >>>>>>>> the memory > > > > >>>>>>>> map changes above, this let's us entirely avoid configuring > > > > >>>>>>>> the memory > > > > >>>>>>>> map explicitly. > > > > >>>>>>> > > > > >>>>>>> Since with this change, we don't need to embed FDT blob in the > > > > >>>>>>> u-boot > > > > >>>>>>> binary, so I was thinking if we really need to import DTs from > > > > >>>>>>> Linux > > > > >>>>>>> for different platforms and then play a catchup game? > > > > >>> > > > > >>> For now, yes. > > > > >> > > > > >> But why? Is there any value added by larger u-boot specific DT (most > > > > >> of the nodes being unused by u-boot) than what currently u-boot > > > > >> supports? The more important part is to get alignment with Linux DT > > > > >> bindings. If you need to have memory/reserved-memory nodes in u-boot > > > > >> DT for generalization purposes then you should import those > > > > >> particular > > > > >> nodes only. > > > > > > > > > > I've been thinking about and hacking on this for the last week or so, > > > > > sorry for the delayed reply here. > > > > > > > > > > The value is in preventing any of the existing bindings from > > > > > regressing, > > > > > > That is actually best addressed in Linux by checking the DTS against > > > yaml DT bindings. We don't have that testing available in u-boot and > > > only depend on careful reviews. > > > > I would absolutely love for someone to make another attempt at updating > > our kbuild infrastucture so that we can run the validation targets. > > > > Given that EBBR requires [1] the platform (firmware/bootloader) and > not OS to supply the devicetree, it becomes evident that > firmware/bootloaders import DTS from Linux kernel (where it is > maintained). > > But currently u-boot doesn't have a proper way to validate those DTS > against DT bindings (maintained in Linux kernel). Although there are > Devicetree schema tools available here [2], there isn't a versioned > release package of DT bindings which one should use to validate DTS > files. > > @DT bindings maintainers, > > Given the ease of maintenance of DT bindings within Linux kernel > source tree, I don't have a specific objection there. But can we ease > DTS testing for firmware/bootloader projects by providing a versioned > release package for DT bindings? Or if someone else has a better idea > here please feel free to chime in.
This doesn't work for you?: https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ Note that I would like to revamp this repo to use some modern CI job, use git_filter_repo python module rather than git-filter-branch, and move to devicetree.org GH, but if projects aren't relying on this repo, I'm not motivated to do that work. Rob _______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-le...@lists.linaro.org
