[PATCH 00/21] Qualcomm generic board support

[Sumit Garg]

On Mon, 4 Dec 2023 at 22:31, Rob Herring <robh+dt at kernel.org> wrote:
>
> On Sun, Dec 3, 2023 at 11:33 PM Sumit Garg <sumit.garg at linaro.org> wrote:
> >
> > + Linux kernel DT bindings maintainers, EBBR ML
> >
> > On Thu, 30 Nov 2023 at 20:05, Tom Rini <trini at 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.armstrong at 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.connolly at 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 <trini at 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.connolly at 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/

Thanks, this is certainly a good step which I wasn't aware of. Further
simplification can be done to decouple devicetree source files from DT
bindings. AFAIK, DT bindings should be forwards and backwards
compatible. So if you pick up DTS or DTB from any project tree
(upstream kernel or stable kernel or u-boot) then DT schema validation
would ensure that corresponding DTS or DTB doesn't regress the DT
bindings.

Ideally, it should be more user/CI friendly if DT bindings can be
easily installed alongside devicetree schema tools [1].

[1] https://github.com/devicetree-org/dt-schema

>
> 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.

As Tom has shown interest in this, I think we should be able to add
the DT validation checks during normal u-boot builds hidden behind a
Makefile option (dtbs_check).

-Sumit

>
> Rob