Hi Tom,
On Sun, 10 Dec 2023 at 03:33, Tom Rini <trini(a)konsulko.com> wrote:
>
> On Mon, Dec 04, 2023 at 11:02:57AM +0530, Sumit Garg wrote:
>
> [snip]
> > 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.
>
> I will have more / other things to say but I want to chime in here. That
> U-Boot cannot validate the DTS files is a bug, not a feature. I would
> very much appreciate if someone(s) with time and skills to do so would
> re-sync us with the kernel Kbuild again so that we can both stay in sync
> again and have the validation targets / functionality available here
> too.
>
Agree, the Kbuild changes to add dtbs_check was the first thing I
implemented after importing devicetree-rebasing repo in u-boot (see
commit [1] for details). Usage with PR [2] included:
While building any u-boot target, just add make target: "dtbs_check"
and you will see the DT schema checks being performed. Steps:
$ make <target>_defconfig
$ make -j`nproc` dtbs_check
Currently there are a lot of incompatibility warnings I have seen for
the platforms I built. This shows how much difficult it has been to
keep DT in sync with upstream DT bindings.
TBH, this was the only motivation for me to get into discussion with
DT bindings maintainers for a separate repo. But since with
devicetree-rebasing, we get devictree files bundled along and then I
got into reusing them for building DTBs in u-boot. This has the other
benefit of reducing maintainer's pain to keep DT in sync with Linux
kernel major releases (see amlogic platforms to be the first migrator
[3]).
[1] https://github.com/u-boot/u-boot/pull/451/commits/7ea2dc2477992a603fa881d0d…
[2] https://github.com/u-boot/u-boot/pull/451
[3] https://github.com/u-boot/u-boot/pull/451/commits/38c2ac62e9134604d1a56179d…
-Sumit
> --
> Tom
Le 7 déc. 2023 à 21:31, Conor Dooley <conor(a)kernel.org> a écrit :
What on earth has happened here with quoting? Please fix your mail
client man, this mail is a mess to read.
Conor: Hopefully I have now fixed MacOS Mail configuration…
For all: please accept my apologies on past inconveniences.
On Thu, Dec 07, 2023 at 08:24:01PM +0000, ff wrote:
Le 7 déc. 2023 à 19:51, Rob Herring <robh+dt(a)kernel.org> a écrit :
On Thu, Dec 7, 2023 at 2:08 AM ff <ff(a)shokubai.tech> wrote:
Le 6 déc. 2023 à 21:42, Rob Herring <robh+dt(a)kernel.org> a écrit :
On Tue, Dec 5, 2023 at 11:05 PM Sumit Garg <sumit.garg(a)linaro.org> wrote:
On Tue, 5 Dec 2023 at 15:39, Krzysztof Kozlowski
<krzysztof.kozlowski(a)linaro.org> wrote:
On 05/12/2023 10:45, Sumit Garg wrote:
+ U-boot custodians list
On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski
<krzysztof.kozlowski(a)linaro.org> wrote:
On 05/12/2023 08:13, Sumit Garg wrote:
@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-rebas…
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.
Why?
I suppose you are already aware that Linux DTS files are a subset of
what could be supported by devicetree schemas. There can be
firmware/bootloader specific properties (one example being [1]) which
Linux kernel can simply ignore. Will you be willing to add all of
those DT properties to Linux DTS files and maintain them?
We already added them and we already maintain them. DTS describes the
hardware, not the OS-subset of the hardware.
Let look at some numbers if your statement is justified or not for the
example I gave:
u-boot$ git grep -nr bootph-* arch/arm* | wc -l
4079
linux$ git grep -nr bootph-* arch/arm* | wc -l
267
I have no control over whether anyone has submitted the other 3812 instances.
It looks like there is always going to be a catch up game regarding DT
properties which either Linux kernel or u-boot or any other
firmware/bootloader project don't care about.
As long as dts files in u-boot are manually sync'ed, yes. That is the
problem and it doesn't matter if we have a standalone repository or
not.
If you want to move in that direction, start automating what u-boot
imports. You need to do that for bindings if you want to run
validation, so why not dts files too?
However, DT bindings are something which should be common, the
hardware description of a device should be universal. IMO, splitting
Both DT bindings and DTS should be common. I don't see the difference.
If we really care about DTS to be common then the contribution model
has to change where there is a single repo hosting DT bindings and
DTS. All other projects whether it is Linux kernel or u-boot or any
other OS/firmware/bootloader are just consuming DTS files from that
single repo.
Really, only the kernel and u-boot matter. No, I don't mean I don't
care about other projects, but those are the 2 with the widest h/w
support by far and which have a major effort to sync copies of dts
files in both projects. The rest are just noise in terms of this
problem.
I suppose this is something that Linux DT maintainers
have objected to in the past for ease of maintenance. I am not sure if
you folks are willing to change that stance.
The issue is no one steps up to help maintain such a repository while
there is lots of review and maintainer work on what goes into the
kernel tree. I'm happy to direct my binding review attention to
wherever the majority of the bindings go. But the work on the DTS side
is mostly SoC tree maintainers and sub-maintainers.
Assume for a minute we have this standalone repo. What happens next?
We start with an empty repo and then merge and move platforms 1 by 1?
What about leveraging SystemReady-IR compliant board maintainers and start with a core of motivated people ?
I think there are 2 ATM. Synquacer and i.MX8 variants.
Based on https://www.arm.com/architecture/system-architectures/systemready-certifica…
roughly 30 boards.
Synquacer only
has a DT in u-boot, so not really anything to do there.
I'm pretty
sure the certified DTBs for i.MX8 don't match what's in u-boot or the
kernel tree. Hopefully, it's just a subset, but still, there's a gap.
I don't know that there is motivation there either.
Note that SystemReady currently only requires every node with
'compatible' have a schema. It does not yet require no schema
warnings. If we went with a 1 by 1 approach, I would push that
platforms have to be free of warnings.
How many years will that take?
Should all platforms following that organization be a goal?
You mean should all platforms be moved? Absolutely. I don't think we
want to solve the problem of having DTS files in 2 places by creating
a 3rd place.
I think this bit here is the only thing you actually wrote:
Actually, if we limit he DTS in the third place for SystemReady-IR,
there should be no DTB in the Linux distribution.
It would be the equivalent as ACPI boards . So is it still an issue ?
A reference to the the third repo may be hinted in a text file.
SystemReady is only for one architecture, why would using it as the
centralised point for devicetree files make sense?
SystemReady is an Arm certification but built on EBBR which is
the important part and also adopted by RISC-V.
So when I said SystemReady, one should read EBBR.
EBBR is promoting a DT life cycle that is in line with
having an out of OS/Firmware repos definitions.
I don't really think 1 by 1 is the right approach. I was just
enumerating how this could work. It's not that useful to say we need a
standalone repo without working thru the logistics of how exactly that
will work.
Rob
On Tue, 5 Dec 2023 at 15:39, Krzysztof Kozlowski
<krzysztof.kozlowski(a)linaro.org> wrote:
>
> On 05/12/2023 10:45, Sumit Garg wrote:
> > + U-boot custodians list
> >
> > On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski
> > <krzysztof.kozlowski(a)linaro.org> wrote:
> >>
> >> On 05/12/2023 08:13, Sumit Garg wrote:
> >>>>> @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-rebas…
> >>>
> >>> 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.
> >>
> >> Why?
> >
> > I suppose you are already aware that Linux DTS files are a subset of
> > what could be supported by devicetree schemas. There can be
> > firmware/bootloader specific properties (one example being [1]) which
> > Linux kernel can simply ignore. Will you be willing to add all of
> > those DT properties to Linux DTS files and maintain them?
>
> We already added them and we already maintain them. DTS describes the
> hardware, not the OS-subset of the hardware.
Let look at some numbers if your statement is justified or not for the
example I gave:
u-boot$ git grep -nr bootph-* arch/arm* | wc -l
4079
linux$ git grep -nr bootph-* arch/arm* | wc -l
267
It looks like there is always going to be a catch up game regarding DT
properties which either Linux kernel or u-boot or any other
firmware/bootloader project don't care about.
>
> >
> > However, DT bindings are something which should be common, the
> > hardware description of a device should be universal. IMO, splitting
>
> Both DT bindings and DTS should be common. I don't see the difference.
If we really care about DTS to be common then the contribution model
has to change where there is a single repo hosting DT bindings and
DTS. All other projects whether it is Linux kernel or u-boot or any
other OS/firmware/bootloader are just consuming DTS files from that
single repo. I suppose this is something that Linux DT maintainers
have objected to in the past for ease of maintenance. I am not sure if
you folks are willing to change that stance.
>
> > DT bindings alone would ease the compliance process for u-boot drivers
> > in quite similar manner to Linux drivers.
> >
> > [1] https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/boot…
> >
> >>
> >>> AFAIK, DT bindings should be forwards and backwards
> >>> compatible.
> >>
> >> The same with DTS.
> >>
> >>> 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.
> >>
> >> And why is this argument to decouple DTS from bindings?
> >>
> >
> > See above.
>
> It's not really explained there. You can pick up DTS from any project
> and validate it against the repo Rob mentioned or against kernel.
> Whether DTS is in that repo or not, does not matter for your validation.
>
It is similar to your earlier argument to use the whole mainline
kernel repo. What is the real benefit to keep DT bindings and DTS
together when every project has to maintain a copy of DTS in its own
source tree? It will be just a source of confusion for developers:
- One DTS coming from devicetree-rebasing repo
- One DTS coming from local project
-Sumit
+ U-boot custodians list
On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski
<krzysztof.kozlowski(a)linaro.org> wrote:
>
> On 05/12/2023 08:13, Sumit Garg wrote:
> >>> @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-rebas…
> >
> > 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.
>
> Why?
I suppose you are already aware that Linux DTS files are a subset of
what could be supported by devicetree schemas. There can be
firmware/bootloader specific properties (one example being [1]) which
Linux kernel can simply ignore. Will you be willing to add all of
those DT properties to Linux DTS files and maintain them?
However, DT bindings are something which should be common, the
hardware description of a device should be universal. IMO, splitting
DT bindings alone would ease the compliance process for u-boot drivers
in quite similar manner to Linux drivers.
[1] https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/boot…
>
> > AFAIK, DT bindings should be forwards and backwards
> > compatible.
>
> The same with DTS.
>
> > 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.
>
> And why is this argument to decouple DTS from bindings?
>
See above.
> >
> > 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
>
> Does it mean you will work on this?
I am happy to collaboratively work with DT bindings maintainers and
the u-boot community once we can reach a consensus on the above.
Basically the main motive here is to validate DTS files present in the
u-boot tree and be able to reliably pass them to whichever Linux
kernel version you are trying to boot. IOW, make Linux distros to
reliably boot with devicetree supplied by u-boot.
-Sumit
>
> Best regards,
> Krzysztof
>
+ Linux kernel DT bindings maintainers, EBBR ML
On Thu, 30 Nov 2023 at 20:05, Tom Rini <trini(a)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(a)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(a)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(a)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(a)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.
[1] https://arm-software.github.io/ebbr/#guiding-principles
[2] https://github.com/devicetree-org/dt-schema
-Sumit
> --
> Tom
