| Message ID | 20231214135103.1606605-1-sumit.garg@linaro.org |
|---|---|
| Headers | show |
| Series | An effort to bring DT bindings compliance within U-boot | expand |
Hi, On 14/12/2023 14:50, Sumit Garg wrote: > Prerquisite s/Prerquisite/Prerequisite/ > ----------- > > This patch series requires devicetree-rebasing git repo to be added as a > subtree to the main U-boot repo via: > > $ git subtree add --prefix devicetree-rebasing \ > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ > v6.6-dts --squash So I think the big question is: when should the subtree be updated ? Because as we discussed in the previous GH pull request, if a bindings changes was made in the upstream Linux DT, then the subtree update should wait until the u-boot support is merged before updating. This could cause a lot of frustration. And this could cause a lot of regressions, even more if both Linux and U-boot are not maintained by the same people. Neil > > Background > ---------- > > This effort started while I was reviewing patch series corresponding to > Qcom platforms [1] which was about to import modified devicetree source > files from Linux kernel. I suppose keeping devicetree files sync with > Linux kernel without any DT bindings schema validation has been a pain > for U-boot SoC/platform maintainers. There has been past discussions > about a single DT repo but that hasn't come up and Linux kernel remained > the place where DT source files as well as bindings are placed and > maintained. > > However, Linux kernel DT maintainers proposed [2] for U-boot to rather > use devicetree-rebasing repo [3] which is a forked copy from Linux > kernel for DT source files as well as bindings. It is tagged at every > Linux kernel major release or intermideate release candidates. So here I > have tried to reuse that to bring DT bingings compliance as well as a > standard way to maintain a regular sync of DT source files with Linux > kernel. > > In order to maintain devicetree files sync, U-boot will maintains a Git > subtree for devicetee-rebasing repo as `devicetee-rebasing/` sub-directory. > It will be regularly updated with every new kernel major release via > subtree pull as follows:: > > $ git subtree pull --prefix devicetree-rebasing \ > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ > <release-tag> --squash > > The RFC/prototype for this series has been discussed with Linux DT > maintainers as well as U-boot maintainers here [4]. Now we would like to > reach out to wider U-boot community to seek feedback. > > [1] https://lore.kernel.org/all/CAFA6WYMLUD9cnkr=R0Uur+1UeTMkKjM2zDdMJtXb3nmrLk+pDg@mail.gmail.com/ > [2] https://lore.kernel.org/all/CAL_JsqKEjv2tSGmT+0ZiO7_qbBfhTycbGnhJhYpKDFzfO9jzDg@mail.gmail.com/ > [3] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ > [4] https://github.com/u-boot/u-boot/pull/451 > > Changes > ------- > > Traditionally, U-boot placed copies of devicetree source files from Linux > kernel into `arch/<arch>/dts/<name>.dts`, which can be selected via: > > CONFIG_DEFAULT_DEVICE_TREE "<name>" > > SoC/board maintainers are encouraged to migrate to using mirrored copies > from `devicetree-rebasing/` into `dts/arch/<arch>/<vendor>` via: > > CONFIG_OF_UPSTREAM=y > CONFIG_DEFAULT_DEVICE_TREE "<vendor>/<name>" > > An example have been shown for Amlogic meson-gxbb SoC and corresponding > derived boards via patch #7 and #8. > > Devicetree bindings schema checks > --------------------------------- > > With devicetee-rebasing Git subtree, the devicetree bindings are also > regularly synced with Linux kernel as `devicetree-rebasing/Bindings/` > sub-directory. This allows U-boot to run devicetree bindings schema checks > which will bring compliance to U-boot core/drivers regarding usage of > devicetree. > > Dependencies > ------------ > > The DT schema project must be installed in order to validate the DT schema > binding documents and validate DTS files using the DT schema. The DT schema > project can be installed with pip: > > $ pip3 install dtschema > > Note that 'dtschema' installation requires 'swig' and Python development > files installed first. On Debian/Ubuntu systems: > > $ apt install swig python3-dev > > Several executables (dt-doc-validate, dt-mk-schema, dt-validate) will be > installed. Ensure they are in your PATH (~/.local/bin by default). > > Recommended is also to install yamllint (used by dtschema when present). > > Running checks > -------------- > > In order to perform validation of DTB files, use the ``dtbs_check`` target: > > $ make dtbs_check > > It is also possible to run checks with a subset of matching schema files by > setting the ``DT_SCHEMA_FILES`` variable to 1 or more specific schema files > or patterns (partial match of a fixed string). Each file or pattern should > be separated by ':'. > > $ make dtbs_check DT_SCHEMA_FILES=trivial-devices.yaml:rtc.yaml > $ make dtbs_check DT_SCHEMA_FILES=/gpio/ > $ make dtbs_check DT_SCHEMA_FILES=trivial-devices.yaml > > Sumit Garg (8): > Azure CI: Exclude devicetree-rebasing subtree for CONFIG checks > Makefile: Add support for DT bindings schema checks > scripts/Makefile.lib: Statically define *-u-boot.dtsi files location > dts: Add alternative location for upstream DTB builds > doc: devicetree: Updates for devicetree-rebasing subtree > MAINTAINERS: Add myself as devicetree-rebasing maintainer > dts: meson-gxbb: Switch to using upstream DT > dts: meson-gxbb: Drop redundant devicetree files > > .azure-pipelines.yml | 3 +- > MAINTAINERS | 6 + > Makefile | 20 +- > arch/arm/dts/Makefile | 8 - > arch/arm/dts/meson-gxbb-kii-pro.dts | 140 ---- > arch/arm/dts/meson-gxbb-nanopi-k2.dts | 415 ------------ > arch/arm/dts/meson-gxbb-odroidc2.dts | 418 ------------ > arch/arm/dts/meson-gxbb-p200.dts | 100 --- > arch/arm/dts/meson-gxbb-p201.dts | 26 - > arch/arm/dts/meson-gxbb-p20x.dtsi | 250 ------- > arch/arm/dts/meson-gxbb-wetek-hub.dts | 58 -- > arch/arm/dts/meson-gxbb-wetek-play2.dts | 119 ---- > arch/arm/dts/meson-gxbb-wetek.dtsi | 292 -------- > arch/arm/dts/meson-gxbb.dtsi | 856 ------------------------ > configs/nanopi-k2_defconfig | 3 +- > configs/odroid-c2_defconfig | 3 +- > configs/p200_defconfig | 3 +- > configs/p201_defconfig | 3 +- > configs/videostrong-kii-pro_defconfig | 3 +- > configs/wetek-hub_defconfig | 3 +- > configs/wetek-play2_defconfig | 3 +- > doc/develop/devicetree/control.rst | 108 ++- > dts/Kconfig | 11 + > dts/Makefile | 17 +- > dts/arch/arm64/Makefile | 23 + > dts/arch/arm64/amlogic | 1 + > scripts/Makefile.lib | 42 +- > 27 files changed, 204 insertions(+), 2730 deletions(-) > delete mode 100644 arch/arm/dts/meson-gxbb-kii-pro.dts > delete mode 100644 arch/arm/dts/meson-gxbb-nanopi-k2.dts > delete mode 100644 arch/arm/dts/meson-gxbb-odroidc2.dts > delete mode 100644 arch/arm/dts/meson-gxbb-p200.dts > delete mode 100644 arch/arm/dts/meson-gxbb-p201.dts > delete mode 100644 arch/arm/dts/meson-gxbb-p20x.dtsi > delete mode 100644 arch/arm/dts/meson-gxbb-wetek-hub.dts > delete mode 100644 arch/arm/dts/meson-gxbb-wetek-play2.dts > delete mode 100644 arch/arm/dts/meson-gxbb-wetek.dtsi > delete mode 100644 arch/arm/dts/meson-gxbb.dtsi > create mode 100644 dts/arch/arm64/Makefile > create mode 120000 dts/arch/arm64/amlogic >
On Thu, Dec 14, 2023 at 03:53:11PM +0100, neil.armstrong@linaro.org wrote: > Hi, > > On 14/12/2023 14:50, Sumit Garg wrote: > > Prerquisite > > s/Prerquisite/Prerequisite/ > > > ----------- > > > > This patch series requires devicetree-rebasing git repo to be added as a > > subtree to the main U-boot repo via: > > > > $ git subtree add --prefix devicetree-rebasing \ > > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ > > v6.6-dts --squash > > So I think the big question is: when should the subtree be updated ? > > Because as we discussed in the previous GH pull request, if a bindings changes > was made in the upstream Linux DT, then the subtree update should wait until > the u-boot support is merged before updating. This could cause a lot of frustration. > > And this could cause a lot of regressions, even more if both Linux and U-boot are > not maintained by the same people. I think some of the important questions to ask are, how often / likely are the breakages to occur? It seems like these days it's either: - U-Boot had an early version of the binding and we already state we don't support backwards compatibility here. It should be on the maintainer to be proactive in this case. - It's a "the DT was wrong about the hardware, sorry not sorry it's an incompatible DTS change now". This too is hopefully the kind of thing that at least board maintainers will be more actively aware of needing to deal with in U-Boot, if it's really a problem. So I would plan on grabbing only full kernel releases and in to -next as soon as possible. Our cadences don't match up exactly, but I think do fairly well enough.
On Thu, Dec 14, 2023 at 12:23 PM Tom Rini <trini@konsulko.com> wrote: > > On Thu, Dec 14, 2023 at 03:53:11PM +0100, neil.armstrong@linaro.org wrote: > > Hi, > > > > On 14/12/2023 14:50, Sumit Garg wrote: > > > Prerquisite > > > > s/Prerquisite/Prerequisite/ > > > > > ----------- > > > > > > This patch series requires devicetree-rebasing git repo to be added as a > > > subtree to the main U-boot repo via: > > > > > > $ git subtree add --prefix devicetree-rebasing \ > > > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ > > > v6.6-dts --squash > > > > So I think the big question is: when should the subtree be updated ? > > > > Because as we discussed in the previous GH pull request, if a bindings changes > > was made in the upstream Linux DT, then the subtree update should wait until > > the u-boot support is merged before updating. This could cause a lot of frustration. > > > > And this could cause a lot of regressions, even more if both Linux and U-boot are > > not maintained by the same people. > > I think some of the important questions to ask are, how often / likely > are the breakages to occur? It seems like these days it's either: > - U-Boot had an early version of the binding and we already state we > don't support backwards compatibility here. It should be on the > maintainer to be proactive in this case. > - It's a "the DT was wrong about the hardware, sorry not sorry it's an > incompatible DTS change now". This too is hopefully the kind of thing > that at least board maintainers will be more actively aware of needing > to deal with in U-Boot, if it's really a problem. A common issue in the kernel is with forward compatibility when platforms add new resources from a new provider. Then the kernel expects a driver for the provider and waits for the dependency. Of course, older kernels don't have that provider driver and so the dependency is never met. Not sure if u-boot will have similar issues? At least you should/could know if the provider driver exists or not. (The kernel doesn't because modules.) Rob
On Thu, Dec 14, 2023 at 01:48:42PM -0600, Rob Herring wrote: > On Thu, Dec 14, 2023 at 12:23 PM Tom Rini <trini@konsulko.com> wrote: > > > > On Thu, Dec 14, 2023 at 03:53:11PM +0100, neil.armstrong@linaro.org wrote: > > > Hi, > > > > > > On 14/12/2023 14:50, Sumit Garg wrote: > > > > Prerquisite > > > > > > s/Prerquisite/Prerequisite/ > > > > > > > ----------- > > > > > > > > This patch series requires devicetree-rebasing git repo to be added as a > > > > subtree to the main U-boot repo via: > > > > > > > > $ git subtree add --prefix devicetree-rebasing \ > > > > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ > > > > v6.6-dts --squash > > > > > > So I think the big question is: when should the subtree be updated ? > > > > > > Because as we discussed in the previous GH pull request, if a bindings changes > > > was made in the upstream Linux DT, then the subtree update should wait until > > > the u-boot support is merged before updating. This could cause a lot of frustration. > > > > > > And this could cause a lot of regressions, even more if both Linux and U-boot are > > > not maintained by the same people. > > > > I think some of the important questions to ask are, how often / likely > > are the breakages to occur? It seems like these days it's either: > > - U-Boot had an early version of the binding and we already state we > > don't support backwards compatibility here. It should be on the > > maintainer to be proactive in this case. > > - It's a "the DT was wrong about the hardware, sorry not sorry it's an > > incompatible DTS change now". This too is hopefully the kind of thing > > that at least board maintainers will be more actively aware of needing > > to deal with in U-Boot, if it's really a problem. > > A common issue in the kernel is with forward compatibility when > platforms add new resources from a new provider. Then the kernel > expects a driver for the provider and waits for the dependency. Of > course, older kernels don't have that provider driver and so the > dependency is never met. Not sure if u-boot will have similar issues? > At least you should/could know if the provider driver exists or not. > (The kernel doesn't because modules.) I think we'll be fine, but time will tell. And perhaps the more frequent re-syncing will make any sort of corner cases show up more quickly and be something we can figure out how to resolve going forward really.
On Thu, 14 Dec 2023 at 23:53, Tom Rini <trini@konsulko.com> wrote: > > On Thu, Dec 14, 2023 at 03:53:11PM +0100, neil.armstrong@linaro.org wrote: > > Hi, > > > > On 14/12/2023 14:50, Sumit Garg wrote: > > > Prerquisite > > > > s/Prerquisite/Prerequisite/ > > Ack. > > > ----------- > > > > > > This patch series requires devicetree-rebasing git repo to be added as a > > > subtree to the main U-boot repo via: > > > > > > $ git subtree add --prefix devicetree-rebasing \ > > > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ > > > v6.6-dts --squash > > > > So I think the big question is: when should the subtree be updated ? > > > > Because as we discussed in the previous GH pull request, if a bindings changes > > was made in the upstream Linux DT, then the subtree update should wait until > > the u-boot support is merged before updating. This could cause a lot of frustration. > > > > And this could cause a lot of regressions, even more if both Linux and U-boot are > > not maintained by the same people. > > I think some of the important questions to ask are, how often / likely > are the breakages to occur? It seems like these days it's either: > - U-Boot had an early version of the binding and we already state we > don't support backwards compatibility here. It should be on the > maintainer to be proactive in this case. > - It's a "the DT was wrong about the hardware, sorry not sorry it's an > incompatible DTS change now". This too is hopefully the kind of thing > that at least board maintainers will be more actively aware of needing > to deal with in U-Boot, if it's really a problem. Agree, also per discussion with Linux DT maintainers, they do care for DT backwards and forward compatibility. I expect the ABI changes to be rare. In case there is an ABI change then it will be great if Linux DT maintainers can ask contributors to CC corresponding U-boot platform maintainers too. BTW, Rob is already working on a tool to detect ABI changes as he described here [1]. If U-boot platform maintainers have any ideas regarding what would constitute an ABI change then feel free to share those. [1] https://lore.kernel.org/all/CAL_JsqLo4nXrJ93dDsfp3UYLs08V02aMnbCCnsDj0MBBomc35w@mail.gmail.com/ > > So I would plan on grabbing only full kernel releases and in to -next as > soon as possible. Our cadences don't match up exactly, but I think do > fairly well enough. I suppose that would give ample time to the U-boot platform/board maintainer to fix any ABI change regression found in the -next branch. That being said we aren't completely immune to changes to devicetree-rebasing subtree. If there is an DT ABI change that will take significant effort to fix in U-boot then we are open to accepting a revert given that it will be fixed before next uprev. -Sumit > > -- > Tom
On Fri, 15 Dec 2023 at 01:45, Tom Rini <trini@konsulko.com> wrote: > > On Thu, Dec 14, 2023 at 01:48:42PM -0600, Rob Herring wrote: > > On Thu, Dec 14, 2023 at 12:23 PM Tom Rini <trini@konsulko.com> wrote: > > > > > > On Thu, Dec 14, 2023 at 03:53:11PM +0100, neil.armstrong@linaro.org wrote: > > > > Hi, > > > > > > > > On 14/12/2023 14:50, Sumit Garg wrote: > > > > > Prerquisite > > > > > > > > s/Prerquisite/Prerequisite/ > > > > > > > > > ----------- > > > > > > > > > > This patch series requires devicetree-rebasing git repo to be added as a > > > > > subtree to the main U-boot repo via: > > > > > > > > > > $ git subtree add --prefix devicetree-rebasing \ > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ > > > > > v6.6-dts --squash > > > > > > > > So I think the big question is: when should the subtree be updated ? > > > > > > > > Because as we discussed in the previous GH pull request, if a bindings changes > > > > was made in the upstream Linux DT, then the subtree update should wait until > > > > the u-boot support is merged before updating. This could cause a lot of frustration. > > > > > > > > And this could cause a lot of regressions, even more if both Linux and U-boot are > > > > not maintained by the same people. > > > > > > I think some of the important questions to ask are, how often / likely > > > are the breakages to occur? It seems like these days it's either: > > > - U-Boot had an early version of the binding and we already state we > > > don't support backwards compatibility here. It should be on the > > > maintainer to be proactive in this case. > > > - It's a "the DT was wrong about the hardware, sorry not sorry it's an > > > incompatible DTS change now". This too is hopefully the kind of thing > > > that at least board maintainers will be more actively aware of needing > > > to deal with in U-Boot, if it's really a problem. > > > > A common issue in the kernel is with forward compatibility when > > platforms add new resources from a new provider. Then the kernel > > expects a driver for the provider and waits for the dependency. Of > > course, older kernels don't have that provider driver and so the > > dependency is never met. Not sure if u-boot will have similar issues? > > At least you should/could know if the provider driver exists or not. > > (The kernel doesn't because modules.) > > I think we'll be fine, but time will tell. And perhaps the more frequent > re-syncing will make any sort of corner cases show up more quickly and > be something we can figure out how to resolve going forward really. > Agree, frequent re-syncing is something we should aim for. However, if required then we can always revisit our approach. -Sumit > -- > Tom
On 14/12/2023 20:48, Rob Herring wrote: >> >> I think some of the important questions to ask are, how often / likely >> are the breakages to occur? It seems like these days it's either: >> - U-Boot had an early version of the binding and we already state we >> don't support backwards compatibility here. It should be on the >> maintainer to be proactive in this case. >> - It's a "the DT was wrong about the hardware, sorry not sorry it's an >> incompatible DTS change now". This too is hopefully the kind of thing >> that at least board maintainers will be more actively aware of needing >> to deal with in U-Boot, if it's really a problem. > > A common issue in the kernel is with forward compatibility when > platforms add new resources from a new provider. Then the kernel > expects a driver for the provider and waits for the dependency. Of > course, older kernels don't have that provider driver and so the > dependency is never met. Not sure if u-boot will have similar issues? > At least you should/could know if the provider driver exists or not. > (The kernel doesn't because modules.) If some U-Boot platform decides to aggressively sync with kernel DTS, then probably the kernel subarch maintainer should be aware of it. Mentioned forward compatibility issue is a result of assumption that there are no out-of-tree upstream consumers of our DTS. I am certainly not aware of any such consumer for Samsung. If someone told me (me wearing Samsung hat), hey U-Boot now cares, I would start caring as well. The usual argument of contributors wanting to break the backward and forward compatibility, is "there is no other OS depending on this" (recent discussion with Johan about order of interrupts: https://lore.kernel.org/all/ZWcPZPX-eT-xHAOv@hovoldconsulting.com/ ). You need to tell the maintainers of that platform, that now they have other OS/firmware/bootloader depending on DTS compatibility. Best regards, Krzysztof
On 14/12/2023 21:15, Tom Rini wrote: > On Thu, Dec 14, 2023 at 01:48:42PM -0600, Rob Herring wrote: >> On Thu, Dec 14, 2023 at 12:23 PM Tom Rini <trini@konsulko.com> wrote: >>> >>> On Thu, Dec 14, 2023 at 03:53:11PM +0100, neil.armstrong@linaro.org wrote: >>>> Hi, >>>> >>>> On 14/12/2023 14:50, Sumit Garg wrote: >>>>> Prerquisite >>>> >>>> s/Prerquisite/Prerequisite/ >>>> >>>>> ----------- >>>>> >>>>> This patch series requires devicetree-rebasing git repo to be added as a >>>>> subtree to the main U-boot repo via: >>>>> >>>>> $ git subtree add --prefix devicetree-rebasing \ >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ >>>>> v6.6-dts --squash >>>> >>>> So I think the big question is: when should the subtree be updated ? >>>> >>>> Because as we discussed in the previous GH pull request, if a bindings changes >>>> was made in the upstream Linux DT, then the subtree update should wait until >>>> the u-boot support is merged before updating. This could cause a lot of frustration. >>>> >>>> And this could cause a lot of regressions, even more if both Linux and U-boot are >>>> not maintained by the same people. >>> >>> I think some of the important questions to ask are, how often / likely >>> are the breakages to occur? It seems like these days it's either: >>> - U-Boot had an early version of the binding and we already state we >>> don't support backwards compatibility here. It should be on the >>> maintainer to be proactive in this case. >>> - It's a "the DT was wrong about the hardware, sorry not sorry it's an >>> incompatible DTS change now". This too is hopefully the kind of thing >>> that at least board maintainers will be more actively aware of needing >>> to deal with in U-Boot, if it's really a problem. >> >> A common issue in the kernel is with forward compatibility when >> platforms add new resources from a new provider. Then the kernel >> expects a driver for the provider and waits for the dependency. Of >> course, older kernels don't have that provider driver and so the >> dependency is never met. Not sure if u-boot will have similar issues? >> At least you should/could know if the provider driver exists or not. >> (The kernel doesn't because modules.) > > I think we'll be fine, but time will tell. And perhaps the more frequent > re-syncing will make any sort of corner cases show up more quickly and > be something we can figure out how to resolve going forward really. > Sure, I suppose I'll only switch the stable boards, and keep the in-progress ones with manual sync. And I'll need to make a prerequisite to any breaking DT change to have the corresponding U-Boot change submitted before (and probably other OSes like *BSD*s) Neil
On Fri, Dec 15, 2023 at 08:50:51AM +0100, Krzysztof Kozlowski wrote: > On 14/12/2023 20:48, Rob Herring wrote: > >> > >> I think some of the important questions to ask are, how often / likely > >> are the breakages to occur? It seems like these days it's either: > >> - U-Boot had an early version of the binding and we already state we > >> don't support backwards compatibility here. It should be on the > >> maintainer to be proactive in this case. > >> - It's a "the DT was wrong about the hardware, sorry not sorry it's an > >> incompatible DTS change now". This too is hopefully the kind of thing > >> that at least board maintainers will be more actively aware of needing > >> to deal with in U-Boot, if it's really a problem. > > > > A common issue in the kernel is with forward compatibility when > > platforms add new resources from a new provider. Then the kernel > > expects a driver for the provider and waits for the dependency. Of > > course, older kernels don't have that provider driver and so the > > dependency is never met. Not sure if u-boot will have similar issues? > > At least you should/could know if the provider driver exists or not. > > (The kernel doesn't because modules.) > > If some U-Boot platform decides to aggressively sync with kernel DTS, > then probably the kernel subarch maintainer should be aware of it. > Mentioned forward compatibility issue is a result of assumption that > there are no out-of-tree upstream consumers of our DTS. I am certainly > not aware of any such consumer for Samsung. If someone told me (me > wearing Samsung hat), hey U-Boot now cares, I would start caring as well. > > The usual argument of contributors wanting to break the backward and > forward compatibility, is "there is no other OS depending on this" > (recent discussion with Johan about order of interrupts: > https://lore.kernel.org/all/ZWcPZPX-eT-xHAOv@hovoldconsulting.com/ ). > You need to tell the maintainers of that platform, that now they have > other OS/firmware/bootloader depending on DTS compatibility. I think this hints at one of the bigger impacts this might have. Reminding everyone that other projects do use the device trees and have for years. Without rehashing history, BSD does use the trees as-is and for platforms U-Boot supports they are supposed to be re-synced periodically. This series moves us from an ad-hoc method to a defined schedule. And presumably some of the Samsung platforms will get moved over to this framework, especially the newer ones being submitted recently :)
On Fri, Dec 15, 2023 at 08:37:43AM -0500, Tom Rini wrote: > On Fri, Dec 15, 2023 at 08:50:51AM +0100, Krzysztof Kozlowski wrote: > > On 14/12/2023 20:48, Rob Herring wrote: > > >> > > >> I think some of the important questions to ask are, how often / likely > > >> are the breakages to occur? It seems like these days it's either: > > >> - U-Boot had an early version of the binding and we already state we > > >> don't support backwards compatibility here. It should be on the > > >> maintainer to be proactive in this case. > > >> - It's a "the DT was wrong about the hardware, sorry not sorry it's an > > >> incompatible DTS change now". This too is hopefully the kind of thing > > >> that at least board maintainers will be more actively aware of needing > > >> to deal with in U-Boot, if it's really a problem. > > > > > > A common issue in the kernel is with forward compatibility when > > > platforms add new resources from a new provider. Then the kernel > > > expects a driver for the provider and waits for the dependency. Of > > > course, older kernels don't have that provider driver and so the > > > dependency is never met. Not sure if u-boot will have similar issues? > > > At least you should/could know if the provider driver exists or not. > > > (The kernel doesn't because modules.) > > > > If some U-Boot platform decides to aggressively sync with kernel DTS, > > then probably the kernel subarch maintainer should be aware of it. > > Mentioned forward compatibility issue is a result of assumption that > > there are no out-of-tree upstream consumers of our DTS. I am certainly > > not aware of any such consumer for Samsung. If someone told me (me > > wearing Samsung hat), hey U-Boot now cares, I would start caring as well. > > > > The usual argument of contributors wanting to break the backward and > > forward compatibility, is "there is no other OS depending on this" > > (recent discussion with Johan about order of interrupts: > > https://lore.kernel.org/all/ZWcPZPX-eT-xHAOv@hovoldconsulting.com/ ). > > You need to tell the maintainers of that platform, that now they have > > other OS/firmware/bootloader depending on DTS compatibility. > > I think this hints at one of the bigger impacts this might have. > Reminding everyone that other projects do use the device trees and have > for years. TBF, we do try to ask these questions as much as possible, usually (for me at least) citing U-Boot or the BSDs as users. It largely seems to me like we are all bark and no bite though, so a project like U-Boot having a defined "schedule" as you suggest below would add more meaning to our questioning. > Without rehashing history, BSD does use the trees as-is and > for platforms U-Boot supports they are supposed to be re-synced > periodically. I know this is the theory, but I also know that how well this is implemented varies wildly per-platform. I generally don't pay all that much attention to the various arm platforms, but I do pay attention to what's going on for RISC-V and there appear to be no active maintainers of individual platforms and the architecture maintainers are not aware of the status of the equivalent patches for Linux when they apply patches. In recent memory, this has lead to the clock indices in the DT differing between U-Boot and Linux for one such platform, which, IMO, is an insidious difference that is hard to spot during review and highly unlikely to crop up while comparing dts files, since the defines were named identically. To be clear, I am not expecting the architecture code maintainers to be aware of the minutiae of the various RISC-V platforms, but rather suggesting they might have an easier time reviewing if both projects' dts files and binding headers were tied together. That said, automatically synced devicetrees will, as has been pointed out, require the platform maintainers in Linux to be more aware of the affect of what they accept on other users, but it will also require the equivalent maintainers on the U-Boot side to engage too, so that the "upstream" dts files do not change in a way that screws the usecase in U-Boot. Also, if people send fixes to the U-Boot copies of these devicetrees, would the plan be to request that these are sent to Linux and the fixes pulled in via a resync after each -rc release of Linux (or similar, just throwing some example schedule out there)? Cheers, Conor. > This series moves us from an ad-hoc method to a defined > schedule. > > And presumably some of the Samsung platforms will get moved over to this > framework, especially the newer ones being submitted recently :)
On Fri, Dec 15, 2023 at 02:45:11PM +0000, Conor Dooley wrote: > On Fri, Dec 15, 2023 at 08:37:43AM -0500, Tom Rini wrote: > > On Fri, Dec 15, 2023 at 08:50:51AM +0100, Krzysztof Kozlowski wrote: > > > On 14/12/2023 20:48, Rob Herring wrote: > > > >> > > > >> I think some of the important questions to ask are, how often / likely > > > >> are the breakages to occur? It seems like these days it's either: > > > >> - U-Boot had an early version of the binding and we already state we > > > >> don't support backwards compatibility here. It should be on the > > > >> maintainer to be proactive in this case. > > > >> - It's a "the DT was wrong about the hardware, sorry not sorry it's an > > > >> incompatible DTS change now". This too is hopefully the kind of thing > > > >> that at least board maintainers will be more actively aware of needing > > > >> to deal with in U-Boot, if it's really a problem. > > > > > > > > A common issue in the kernel is with forward compatibility when > > > > platforms add new resources from a new provider. Then the kernel > > > > expects a driver for the provider and waits for the dependency. Of > > > > course, older kernels don't have that provider driver and so the > > > > dependency is never met. Not sure if u-boot will have similar issues? > > > > At least you should/could know if the provider driver exists or not. > > > > (The kernel doesn't because modules.) > > > > > > If some U-Boot platform decides to aggressively sync with kernel DTS, > > > then probably the kernel subarch maintainer should be aware of it. > > > Mentioned forward compatibility issue is a result of assumption that > > > there are no out-of-tree upstream consumers of our DTS. I am certainly > > > not aware of any such consumer for Samsung. If someone told me (me > > > wearing Samsung hat), hey U-Boot now cares, I would start caring as well. > > > > > > The usual argument of contributors wanting to break the backward and > > > forward compatibility, is "there is no other OS depending on this" > > > (recent discussion with Johan about order of interrupts: > > > https://lore.kernel.org/all/ZWcPZPX-eT-xHAOv@hovoldconsulting.com/ ). > > > You need to tell the maintainers of that platform, that now they have > > > other OS/firmware/bootloader depending on DTS compatibility. > > > > I think this hints at one of the bigger impacts this might have. > > Reminding everyone that other projects do use the device trees and have > > for years. > > TBF, we do try to ask these questions as much as possible, usually (for > me at least) citing U-Boot or the BSDs as users. It largely seems to me > like we are all bark and no bite though, so a project like U-Boot having > a defined "schedule" as you suggest below would add more meaning to our > questioning. > > > Without rehashing history, BSD does use the trees as-is and > > for platforms U-Boot supports they are supposed to be re-synced > > periodically. > > I know this is the theory, but I also know that how well this is > implemented varies wildly per-platform. I generally don't pay all > that much attention to the various arm platforms, but I do pay > attention to what's going on for RISC-V and there appear to be no > active maintainers of individual platforms and the architecture > maintainers are not aware of the status of the equivalent patches > for Linux when they apply patches. > > In recent memory, this has lead to the clock indices in the DT > differing between U-Boot and Linux for one such platform, which, IMO, > is an insidious difference that is hard to spot during review and highly > unlikely to crop up while comparing dts files, since the defines were named > identically. To be clear, I am not expecting the architecture code > maintainers to be aware of the minutiae of the various RISC-V platforms, > but rather suggesting they might have an easier time reviewing if both > projects' dts files and binding headers were tied together. > > That said, automatically synced devicetrees will, as has been pointed out, > require the platform maintainers in Linux to be more aware of the affect of > what they accept on other users, but it will also require the equivalent > maintainers on the U-Boot side to engage too, so that the "upstream" dts > files do not change in a way that screws the usecase in U-Boot. Yeah, it will hopefully lead to better coordination between maintainers in some places. There are SoCs where the kernel DTS people are the U-Boot DTS people too. All in all, I should probably CC more people than I usually do on these resync patches just to try and head off any tricky changes like you've mentioned above. > Also, if people send fixes to the U-Boot copies of these devicetrees, > would the plan be to request that these are sent to Linux and the fixes > pulled in via a resync after each -rc release of Linux (or similar, just > throwing some example schedule out there)? The way we've always tried to operate is that changes should be pushed to Linux and resynced down, or at least submitted simultaneously. If there's some specific bugfixes that need to come in out of cycle I _think_ subtree handles cherry picked commits in a reasonable fashion.
On Sat, 16 Dec 2023 at 00:49, Tom Rini <trini@konsulko.com> wrote: > > On Fri, Dec 15, 2023 at 02:45:11PM +0000, Conor Dooley wrote: > > On Fri, Dec 15, 2023 at 08:37:43AM -0500, Tom Rini wrote: > > > On Fri, Dec 15, 2023 at 08:50:51AM +0100, Krzysztof Kozlowski wrote: > > > > On 14/12/2023 20:48, Rob Herring wrote: > > > > >> > > > > >> I think some of the important questions to ask are, how often / likely > > > > >> are the breakages to occur? It seems like these days it's either: > > > > >> - U-Boot had an early version of the binding and we already state we > > > > >> don't support backwards compatibility here. It should be on the > > > > >> maintainer to be proactive in this case. > > > > >> - It's a "the DT was wrong about the hardware, sorry not sorry it's an > > > > >> incompatible DTS change now". This too is hopefully the kind of thing > > > > >> that at least board maintainers will be more actively aware of needing > > > > >> to deal with in U-Boot, if it's really a problem. > > > > > > > > > > A common issue in the kernel is with forward compatibility when > > > > > platforms add new resources from a new provider. Then the kernel > > > > > expects a driver for the provider and waits for the dependency. Of > > > > > course, older kernels don't have that provider driver and so the > > > > > dependency is never met. Not sure if u-boot will have similar issues? > > > > > At least you should/could know if the provider driver exists or not. > > > > > (The kernel doesn't because modules.) > > > > > > > > If some U-Boot platform decides to aggressively sync with kernel DTS, > > > > then probably the kernel subarch maintainer should be aware of it. > > > > Mentioned forward compatibility issue is a result of assumption that > > > > there are no out-of-tree upstream consumers of our DTS. I am certainly > > > > not aware of any such consumer for Samsung. If someone told me (me > > > > wearing Samsung hat), hey U-Boot now cares, I would start caring as well. > > > > > > > > The usual argument of contributors wanting to break the backward and > > > > forward compatibility, is "there is no other OS depending on this" > > > > (recent discussion with Johan about order of interrupts: > > > > https://lore.kernel.org/all/ZWcPZPX-eT-xHAOv@hovoldconsulting.com/ ). > > > > You need to tell the maintainers of that platform, that now they have > > > > other OS/firmware/bootloader depending on DTS compatibility. > > > > > > I think this hints at one of the bigger impacts this might have. > > > Reminding everyone that other projects do use the device trees and have > > > for years. > > > > TBF, we do try to ask these questions as much as possible, usually (for > > me at least) citing U-Boot or the BSDs as users. It largely seems to me > > like we are all bark and no bite though, so a project like U-Boot having > > a defined "schedule" as you suggest below would add more meaning to our > > questioning. > > > > > Without rehashing history, BSD does use the trees as-is and > > > for platforms U-Boot supports they are supposed to be re-synced > > > periodically. > > > > I know this is the theory, but I also know that how well this is > > implemented varies wildly per-platform. I generally don't pay all > > that much attention to the various arm platforms, but I do pay > > attention to what's going on for RISC-V and there appear to be no > > active maintainers of individual platforms and the architecture > > maintainers are not aware of the status of the equivalent patches > > for Linux when they apply patches. > > > > In recent memory, this has lead to the clock indices in the DT > > differing between U-Boot and Linux for one such platform, which, IMO, > > is an insidious difference that is hard to spot during review and highly > > unlikely to crop up while comparing dts files, since the defines were named > > identically. To be clear, I am not expecting the architecture code > > maintainers to be aware of the minutiae of the various RISC-V platforms, > > but rather suggesting they might have an easier time reviewing if both > > projects' dts files and binding headers were tied together. > > > > That said, automatically synced devicetrees will, as has been pointed out, > > require the platform maintainers in Linux to be more aware of the affect of > > what they accept on other users, but it will also require the equivalent > > maintainers on the U-Boot side to engage too, so that the "upstream" dts > > files do not change in a way that screws the usecase in U-Boot. > > Yeah, it will hopefully lead to better coordination between maintainers > in some places. There are SoCs where the kernel DTS people are the > U-Boot DTS people too. All in all, I should probably CC more people than > I usually do on these resync patches just to try and head off any > tricky changes like you've mentioned above. Makes sense. > > > Also, if people send fixes to the U-Boot copies of these devicetrees, > > would the plan be to request that these are sent to Linux and the fixes > > pulled in via a resync after each -rc release of Linux (or similar, just > > throwing some example schedule out there)? > > The way we've always tried to operate is that changes should be pushed > to Linux and resynced down, or at least submitted simultaneously. If > there's some specific bugfixes that need to come in out of cycle I > _think_ subtree handles cherry picked commits in a reasonable fashion. > Agree. -Sumit > -- > Tom
Hi Sumit, On 12/14/23 14:50, Sumit Garg wrote: > Prerquisite > ----------- > > This patch series requires devicetree-rebasing git repo to be added as a > subtree to the main U-boot repo via: > > $ git subtree add --prefix devicetree-rebasing \ > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ > v6.6-dts --squash > > Background > ---------- > > This effort started while I was reviewing patch series corresponding to > Qcom platforms [1] which was about to import modified devicetree source > files from Linux kernel. I suppose keeping devicetree files sync with > Linux kernel without any DT bindings schema validation has been a pain > for U-boot SoC/platform maintainers. There has been past discussions > about a single DT repo but that hasn't come up and Linux kernel remained > the place where DT source files as well as bindings are placed and > maintained. > > However, Linux kernel DT maintainers proposed [2] for U-boot to rather > use devicetree-rebasing repo [3] which is a forked copy from Linux > kernel for DT source files as well as bindings. It is tagged at every > Linux kernel major release or intermideate release candidates. So here I > have tried to reuse that to bring DT bingings compliance as well as a > standard way to maintain a regular sync of DT source files with Linux > kernel. > > In order to maintain devicetree files sync, U-boot will maintains a Git > subtree for devicetee-rebasing repo as `devicetee-rebasing/` sub-directory. > It will be regularly updated with every new kernel major release via > subtree pull as follows:: > > $ git subtree pull --prefix devicetree-rebasing \ > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ > <release-tag> --squash > > The RFC/prototype for this series has been discussed with Linux DT > maintainers as well as U-boot maintainers here [4]. Now we would like to > reach out to wider U-boot community to seek feedback. > > [1] https://lore.kernel.org/all/CAFA6WYMLUD9cnkr=R0Uur+1UeTMkKjM2zDdMJtXb3nmrLk+pDg@mail.gmail.com/ > [2] https://lore.kernel.org/all/CAL_JsqKEjv2tSGmT+0ZiO7_qbBfhTycbGnhJhYpKDFzfO9jzDg@mail.gmail.com/ > [3] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ > [4] https://github.com/u-boot/u-boot/pull/451 > > Changes > ------- > > Traditionally, U-boot placed copies of devicetree source files from Linux > kernel into `arch/<arch>/dts/<name>.dts`, which can be selected via: > > CONFIG_DEFAULT_DEVICE_TREE "<name>" > > SoC/board maintainers are encouraged to migrate to using mirrored copies > from `devicetree-rebasing/` into `dts/arch/<arch>/<vendor>` via: > > CONFIG_OF_UPSTREAM=y > CONFIG_DEFAULT_DEVICE_TREE "<vendor>/<name>" > > An example have been shown for Amlogic meson-gxbb SoC and corresponding > derived boards via patch #7 and #8. > > Devicetree bindings schema checks > --------------------------------- > > With devicetee-rebasing Git subtree, the devicetree bindings are also > regularly synced with Linux kernel as `devicetree-rebasing/Bindings/` > sub-directory. This allows U-boot to run devicetree bindings schema checks > which will bring compliance to U-boot core/drivers regarding usage of > devicetree. > > Dependencies > ------------ > > The DT schema project must be installed in order to validate the DT schema > binding documents and validate DTS files using the DT schema. The DT schema > project can be installed with pip: > > $ pip3 install dtschema > > Note that 'dtschema' installation requires 'swig' and Python development > files installed first. On Debian/Ubuntu systems: > > $ apt install swig python3-dev > > Several executables (dt-doc-validate, dt-mk-schema, dt-validate) will be > installed. Ensure they are in your PATH (~/.local/bin by default). > > Recommended is also to install yamllint (used by dtschema when present). > > Running checks > -------------- > > In order to perform validation of DTB files, use the ``dtbs_check`` target: > > $ make dtbs_check > > It is also possible to run checks with a subset of matching schema files by > setting the ``DT_SCHEMA_FILES`` variable to 1 or more specific schema files > or patterns (partial match of a fixed string). Each file or pattern should > be separated by ':'. > > $ make dtbs_check DT_SCHEMA_FILES=trivial-devices.yaml:rtc.yaml > $ make dtbs_check DT_SCHEMA_FILES=/gpio/ > $ make dtbs_check DT_SCHEMA_FILES=trivial-devices.yaml Do you also plan to extend this to cover dt overlay + dt base generation and check it against DT schema. Thanks, Michal
Hi Michal, On Wed, 20 Dec 2023 at 16:14, Michal Simek <michal.simek@amd.com> wrote: > > Hi Sumit, > > On 12/14/23 14:50, Sumit Garg wrote: > > Prerquisite > > ----------- > > > > This patch series requires devicetree-rebasing git repo to be added as a > > subtree to the main U-boot repo via: > > > > $ git subtree add --prefix devicetree-rebasing \ > > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ > > v6.6-dts --squash > > > > Background > > ---------- > > > > This effort started while I was reviewing patch series corresponding to > > Qcom platforms [1] which was about to import modified devicetree source > > files from Linux kernel. I suppose keeping devicetree files sync with > > Linux kernel without any DT bindings schema validation has been a pain > > for U-boot SoC/platform maintainers. There has been past discussions > > about a single DT repo but that hasn't come up and Linux kernel remained > > the place where DT source files as well as bindings are placed and > > maintained. > > > > However, Linux kernel DT maintainers proposed [2] for U-boot to rather > > use devicetree-rebasing repo [3] which is a forked copy from Linux > > kernel for DT source files as well as bindings. It is tagged at every > > Linux kernel major release or intermideate release candidates. So here I > > have tried to reuse that to bring DT bingings compliance as well as a > > standard way to maintain a regular sync of DT source files with Linux > > kernel. > > > > In order to maintain devicetree files sync, U-boot will maintains a Git > > subtree for devicetee-rebasing repo as `devicetee-rebasing/` sub-directory. > > It will be regularly updated with every new kernel major release via > > subtree pull as follows:: > > > > $ git subtree pull --prefix devicetree-rebasing \ > > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ > > <release-tag> --squash > > > > The RFC/prototype for this series has been discussed with Linux DT > > maintainers as well as U-boot maintainers here [4]. Now we would like to > > reach out to wider U-boot community to seek feedback. > > > > [1] https://lore.kernel.org/all/CAFA6WYMLUD9cnkr=R0Uur+1UeTMkKjM2zDdMJtXb3nmrLk+pDg@mail.gmail.com/ > > [2] https://lore.kernel.org/all/CAL_JsqKEjv2tSGmT+0ZiO7_qbBfhTycbGnhJhYpKDFzfO9jzDg@mail.gmail.com/ > > [3] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ > > [4] https://github.com/u-boot/u-boot/pull/451 > > > > Changes > > ------- > > > > Traditionally, U-boot placed copies of devicetree source files from Linux > > kernel into `arch/<arch>/dts/<name>.dts`, which can be selected via: > > > > CONFIG_DEFAULT_DEVICE_TREE "<name>" > > > > SoC/board maintainers are encouraged to migrate to using mirrored copies > > from `devicetree-rebasing/` into `dts/arch/<arch>/<vendor>` via: > > > > CONFIG_OF_UPSTREAM=y > > CONFIG_DEFAULT_DEVICE_TREE "<vendor>/<name>" > > > > An example have been shown for Amlogic meson-gxbb SoC and corresponding > > derived boards via patch #7 and #8. > > > > Devicetree bindings schema checks > > --------------------------------- > > > > With devicetee-rebasing Git subtree, the devicetree bindings are also > > regularly synced with Linux kernel as `devicetree-rebasing/Bindings/` > > sub-directory. This allows U-boot to run devicetree bindings schema checks > > which will bring compliance to U-boot core/drivers regarding usage of > > devicetree. > > > > Dependencies > > ------------ > > > > The DT schema project must be installed in order to validate the DT schema > > binding documents and validate DTS files using the DT schema. The DT schema > > project can be installed with pip: > > > > $ pip3 install dtschema > > > > Note that 'dtschema' installation requires 'swig' and Python development > > files installed first. On Debian/Ubuntu systems: > > > > $ apt install swig python3-dev > > > > Several executables (dt-doc-validate, dt-mk-schema, dt-validate) will be > > installed. Ensure they are in your PATH (~/.local/bin by default). > > > > Recommended is also to install yamllint (used by dtschema when present). > > > > Running checks > > -------------- > > > > In order to perform validation of DTB files, use the ``dtbs_check`` target: > > > > $ make dtbs_check > > > > It is also possible to run checks with a subset of matching schema files by > > setting the ``DT_SCHEMA_FILES`` variable to 1 or more specific schema files > > or patterns (partial match of a fixed string). Each file or pattern should > > be separated by ':'. > > > > $ make dtbs_check DT_SCHEMA_FILES=trivial-devices.yaml:rtc.yaml > > $ make dtbs_check DT_SCHEMA_FILES=/gpio/ > > $ make dtbs_check DT_SCHEMA_FILES=trivial-devices.yaml > > Do you also plan to extend this to cover dt overlay + dt base generation and > check it against DT schema. I suppose here you are referring to DT schema checks for *.dtso -> *.dtbo generation. I don't see corresponding checks enabled in Linux kernel [1]. Probably Rob can share plans over there. U-Boot tries to follow Linux kernel kbuild framework. However, if needed we can add checks for *.dtbo generation too as a follow up patch. [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/scripts/Makefile.lib#n421 -Sumit > > Thanks, > Michal >
On Thu, Dec 14, 2023 at 07:20:55PM +0530, Sumit Garg wrote: > Prerquisite > ----------- > > This patch series requires devicetree-rebasing git repo to be added as a > subtree to the main U-boot repo via: > > $ git subtree add --prefix devicetree-rebasing \ > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ > v6.6-dts --squash So, I've played with subtree a little and I think this is the right way forward in these cases. If anyone wants to take a look at how this works in practice, take a look at: https://source.denx.de/u-boot/u-boot/-/commits/WIP/u-boot-with-devicetree-rebasing-since-v6.1/?ref_type=heads In that tree I started with the v6.1-dts tag, sync'd all the configs (to have an example of a normal commit) and then did a merge of each tag until v6.6-dts, so provide some history. And git log looks like what I want to see, the squash commit has clear references to what we are getting and I make a merge commit that says what I did. If you pull the tree and checkout the branch, all the code is right there already, nothing further to do. Same with tarball releases. The only thing I don't like is the size growth there, but we'll reclaim some of it when we delete our obsolete bindings, and then obsolete dts files. Maxim, please switch (back, sorry!) to subtree for the next lwIP patchset and just not in the prerequisite steps what the subtree command is, and make sure the docs have an example of what future re-sync "subtree pull" commands should look like. For CI testing, you'll have to do that to start with and just not include that patch in the ML part.
Hi, On Thu, Dec 21, 2023 at 3:03 PM Tom Rini <trini@konsulko.com> wrote: > > On Thu, Dec 14, 2023 at 07:20:55PM +0530, Sumit Garg wrote: > > > Prerquisite > > ----------- > > > > This patch series requires devicetree-rebasing git repo to be added as a > > subtree to the main U-boot repo via: > > > > $ git subtree add --prefix devicetree-rebasing \ > > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ > > v6.6-dts --squash > > So, I've played with subtree a little and I think this is the right way > forward in these cases. If anyone wants to take a look at how this works > in practice, take a look at: > https://source.denx.de/u-boot/u-boot/-/commits/WIP/u-boot-with-devicetree-rebasing-since-v6.1/?ref_type=heads > In that tree I started with the v6.1-dts tag, sync'd all the configs (to > have an example of a normal commit) and then did a merge of each tag > until v6.6-dts, so provide some history. And git log looks like what I > want to see, the squash commit has clear references to what we are > getting and I make a merge commit that says what I did. If you pull the > tree and checkout the branch, all the code is right there already, > nothing further to do. Same with tarball releases. The only thing I > don't like is the size growth there, but we'll reclaim some of it when > we delete our obsolete bindings, and then obsolete dts files. I spent a bit of time with subtree as well, as part of reviewing this series, using the instructions Sumit provided. It seems OK to me. We have to accept that it adds code and there will be changes/churn, but it is not too different to accepting patches on those files within U-Boot. We will bring in files which U-Boot doesn't use, but U-Boot does support a good proportion of the boards supported by Linux, so I don't see that as a big cost. From my experimentation, subtrees seem to have no impact on buildman, which is great. Am I missing anything? I still worry about the board-level 'switch' between U-Boot DT and upstream ones. I believe that should be at the SoC level instead. > > Maxim, please switch (back, sorry!) to subtree for the next lwIP > patchset and just not in the prerequisite steps what the subtree command > is, and make sure the docs have an example of what future re-sync > "subtree pull" commands should look like. For CI testing, you'll have to > do that to start with and just not include that patch in the ML part. Regards, Simon
On Thu, 21 Dec 2023 at 20:48, Simon Glass <sjg@chromium.org> wrote: > > Hi, > > On Thu, Dec 21, 2023 at 3:03 PM Tom Rini <trini@konsulko.com> wrote: > > > > On Thu, Dec 14, 2023 at 07:20:55PM +0530, Sumit Garg wrote: > > > > > Prerquisite > > > ----------- > > > > > > This patch series requires devicetree-rebasing git repo to be added as a > > > subtree to the main U-boot repo via: > > > > > > $ git subtree add --prefix devicetree-rebasing \ > > > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ > > > v6.6-dts --squash > > > > So, I've played with subtree a little and I think this is the right way > > forward in these cases. If anyone wants to take a look at how this works > > in practice, take a look at: > > https://source.denx.de/u-boot/u-boot/-/commits/WIP/u-boot-with-devicetree-rebasing-since-v6.1/?ref_type=heads > > In that tree I started with the v6.1-dts tag, sync'd all the configs (to > > have an example of a normal commit) and then did a merge of each tag > > until v6.6-dts, so provide some history. And git log looks like what I > > want to see, the squash commit has clear references to what we are > > getting and I make a merge commit that says what I did. If you pull the > > tree and checkout the branch, all the code is right there already, > > nothing further to do. Same with tarball releases. The only thing I > > don't like is the size growth there, but we'll reclaim some of it when > > we delete our obsolete bindings, and then obsolete dts files. > > I spent a bit of time with subtree as well, as part of reviewing this > series, using the instructions Sumit provided. It seems OK to me. We > have to accept that it adds code and there will be changes/churn, but > it is not too different to accepting patches on those files within > U-Boot. We will bring in files which U-Boot doesn't use, but U-Boot > does support a good proportion of the boards supported by Linux, so I > don't see that as a big cost. > > From my experimentation, subtrees seem to have no impact on buildman, > which is great. Am I missing anything? No it shouldn't cause any regression on existing tools/CI/build systems. It is just a version controlled way of importing third party source code as a tarball. > > I still worry about the board-level 'switch' between U-Boot DT and > upstream ones. I believe that should be at the SoC level instead. > Probably I wasn't clear enough in my earlier replies but this series motivates for a SoC level switch only. Patch #7 is essentially a switch for Amlogic meson-gxbb SoC and its derived boards. -Sumit > > > > Maxim, please switch (back, sorry!) to subtree for the next lwIP > > patchset and just not in the prerequisite steps what the subtree command > > is, and make sure the docs have an example of what future re-sync > > "subtree pull" commands should look like. For CI testing, you'll have to > > do that to start with and just not include that patch in the ML part. > > Regards, > Simon
Hi Sumit, On Fri, Dec 22, 2023 at 5:34 AM Sumit Garg <sumit.garg@linaro.org> wrote: > > On Thu, 21 Dec 2023 at 20:48, Simon Glass <sjg@chromium.org> wrote: > > > > Hi, > > > > On Thu, Dec 21, 2023 at 3:03 PM Tom Rini <trini@konsulko.com> wrote: > > > > > > On Thu, Dec 14, 2023 at 07:20:55PM +0530, Sumit Garg wrote: > > > > > > > Prerquisite > > > > ----------- > > > > > > > > This patch series requires devicetree-rebasing git repo to be added as a > > > > subtree to the main U-boot repo via: > > > > > > > > $ git subtree add --prefix devicetree-rebasing \ > > > > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ > > > > v6.6-dts --squash > > > > > > So, I've played with subtree a little and I think this is the right way > > > forward in these cases. If anyone wants to take a look at how this works > > > in practice, take a look at: > > > https://source.denx.de/u-boot/u-boot/-/commits/WIP/u-boot-with-devicetree-rebasing-since-v6.1/?ref_type=heads > > > In that tree I started with the v6.1-dts tag, sync'd all the configs (to > > > have an example of a normal commit) and then did a merge of each tag > > > until v6.6-dts, so provide some history. And git log looks like what I > > > want to see, the squash commit has clear references to what we are > > > getting and I make a merge commit that says what I did. If you pull the > > > tree and checkout the branch, all the code is right there already, > > > nothing further to do. Same with tarball releases. The only thing I > > > don't like is the size growth there, but we'll reclaim some of it when > > > we delete our obsolete bindings, and then obsolete dts files. > > > > I spent a bit of time with subtree as well, as part of reviewing this > > series, using the instructions Sumit provided. It seems OK to me. We > > have to accept that it adds code and there will be changes/churn, but > > it is not too different to accepting patches on those files within > > U-Boot. We will bring in files which U-Boot doesn't use, but U-Boot > > does support a good proportion of the boards supported by Linux, so I > > don't see that as a big cost. > > > > From my experimentation, subtrees seem to have no impact on buildman, > > which is great. Am I missing anything? > > No it shouldn't cause any regression on existing tools/CI/build > systems. It is just a version controlled way of importing third party > source code as a tarball. > > > > > I still worry about the board-level 'switch' between U-Boot DT and > > upstream ones. I believe that should be at the SoC level instead. > > > > Probably I wasn't clear enough in my earlier replies but this series > motivates for a SoC level switch only. Patch #7 is essentially a > switch for Amlogic meson-gxbb SoC and its derived boards. OK good...but that's not quite what I mean. You have a fragment like this in multiple defconfig files: +CONFIG_OF_UPSTREAM=y +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-odroidc2" instead, OF_UPSTREAM should be enabled via 'imply' for the SoC, in the Kconfig. We should not have to specify the filename like this. It is laborious and error-prone. Regards, Simon
Hi Simon, On Tue, 26 Dec 2023 at 15:17, Simon Glass <sjg@chromium.org> wrote: > > Hi Sumit, > > On Fri, Dec 22, 2023 at 5:34 AM Sumit Garg <sumit.garg@linaro.org> wrote: > > > > On Thu, 21 Dec 2023 at 20:48, Simon Glass <sjg@chromium.org> wrote: > > > > > > Hi, > > > > > > On Thu, Dec 21, 2023 at 3:03 PM Tom Rini <trini@konsulko.com> wrote: > > > > > > > > On Thu, Dec 14, 2023 at 07:20:55PM +0530, Sumit Garg wrote: > > > > > > > > > Prerquisite > > > > > ----------- > > > > > > > > > > This patch series requires devicetree-rebasing git repo to be added as a > > > > > subtree to the main U-boot repo via: > > > > > > > > > > $ git subtree add --prefix devicetree-rebasing \ > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ > > > > > v6.6-dts --squash > > > > > > > > So, I've played with subtree a little and I think this is the right way > > > > forward in these cases. If anyone wants to take a look at how this works > > > > in practice, take a look at: > > > > https://source.denx.de/u-boot/u-boot/-/commits/WIP/u-boot-with-devicetree-rebasing-since-v6.1/?ref_type=heads > > > > In that tree I started with the v6.1-dts tag, sync'd all the configs (to > > > > have an example of a normal commit) and then did a merge of each tag > > > > until v6.6-dts, so provide some history. And git log looks like what I > > > > want to see, the squash commit has clear references to what we are > > > > getting and I make a merge commit that says what I did. If you pull the > > > > tree and checkout the branch, all the code is right there already, > > > > nothing further to do. Same with tarball releases. The only thing I > > > > don't like is the size growth there, but we'll reclaim some of it when > > > > we delete our obsolete bindings, and then obsolete dts files. > > > > > > I spent a bit of time with subtree as well, as part of reviewing this > > > series, using the instructions Sumit provided. It seems OK to me. We > > > have to accept that it adds code and there will be changes/churn, but > > > it is not too different to accepting patches on those files within > > > U-Boot. We will bring in files which U-Boot doesn't use, but U-Boot > > > does support a good proportion of the boards supported by Linux, so I > > > don't see that as a big cost. > > > > > > From my experimentation, subtrees seem to have no impact on buildman, > > > which is great. Am I missing anything? > > > > No it shouldn't cause any regression on existing tools/CI/build > > systems. It is just a version controlled way of importing third party > > source code as a tarball. > > > > > > > > I still worry about the board-level 'switch' between U-Boot DT and > > > upstream ones. I believe that should be at the SoC level instead. > > > > > > > Probably I wasn't clear enough in my earlier replies but this series > > motivates for a SoC level switch only. Patch #7 is essentially a > > switch for Amlogic meson-gxbb SoC and its derived boards. > > OK good...but that's not quite what I mean. You have a fragment like > this in multiple defconfig files: > > +CONFIG_OF_UPSTREAM=y > +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-odroidc2" > > instead, OF_UPSTREAM should be enabled via 'imply' for the SoC, in the > Kconfig. Okay I got your point. It makes sense to me. I will do that for v3. > We should not have to specify the filename like this. It is > laborious and error-prone. The only differentiation in naming here is just silicon vendor prefix addition (amlogic/ in this case). The reason for this being that I just want to mirror the whole silicon vendor directory from DT rebasing rather than mirroring individual DT files. Given this do you have any better alternatives? -Sumit
Hi Sumit Hi Simon, On Tue, Dec 26, 2023 at 2:13 AM Sumit Garg <sumit.garg@linaro.org> wrote: > > Hi Simon, > > On Tue, 26 Dec 2023 at 15:17, Simon Glass <sjg@chromium.org> wrote: > > > > Hi Sumit, > > > > On Fri, Dec 22, 2023 at 5:34 AM Sumit Garg <sumit.garg@linaro.org> wrote: > > > > > > On Thu, 21 Dec 2023 at 20:48, Simon Glass <sjg@chromium.org> wrote: > > > > > > > > Hi, > > > > > > > > On Thu, Dec 21, 2023 at 3:03 PM Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > On Thu, Dec 14, 2023 at 07:20:55PM +0530, Sumit Garg wrote: > > > > > > > > > > > Prerquisite > > > > > > ----------- > > > > > > > > > > > > This patch series requires devicetree-rebasing git repo to be added as a > > > > > > subtree to the main U-boot repo via: > > > > > > > > > > > > $ git subtree add --prefix devicetree-rebasing \ > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ > > > > > > v6.6-dts --squash > > > > > > > > > > So, I've played with subtree a little and I think this is the right way > > > > > forward in these cases. If anyone wants to take a look at how this works > > > > > in practice, take a look at: > > > > > https://source.denx.de/u-boot/u-boot/-/commits/WIP/u-boot-with-devicetree-rebasing-since-v6.1/?ref_type=heads > > > > > In that tree I started with the v6.1-dts tag, sync'd all the configs (to > > > > > have an example of a normal commit) and then did a merge of each tag > > > > > until v6.6-dts, so provide some history. And git log looks like what I > > > > > want to see, the squash commit has clear references to what we are > > > > > getting and I make a merge commit that says what I did. If you pull the > > > > > tree and checkout the branch, all the code is right there already, > > > > > nothing further to do. Same with tarball releases. The only thing I > > > > > don't like is the size growth there, but we'll reclaim some of it when > > > > > we delete our obsolete bindings, and then obsolete dts files. > > > > > > > > I spent a bit of time with subtree as well, as part of reviewing this > > > > series, using the instructions Sumit provided. It seems OK to me. We > > > > have to accept that it adds code and there will be changes/churn, but > > > > it is not too different to accepting patches on those files within > > > > U-Boot. We will bring in files which U-Boot doesn't use, but U-Boot > > > > does support a good proportion of the boards supported by Linux, so I > > > > don't see that as a big cost. > > > > > > > > From my experimentation, subtrees seem to have no impact on buildman, > > > > which is great. Am I missing anything? > > > > > > No it shouldn't cause any regression on existing tools/CI/build > > > systems. It is just a version controlled way of importing third party > > > source code as a tarball. > > > > > > > > > > > I still worry about the board-level 'switch' between U-Boot DT and > > > > upstream ones. I believe that should be at the SoC level instead. > > > > > > > > > > Probably I wasn't clear enough in my earlier replies but this series > > > motivates for a SoC level switch only. Patch #7 is essentially a > > > switch for Amlogic meson-gxbb SoC and its derived boards. > > > > OK good...but that's not quite what I mean. You have a fragment like > > this in multiple defconfig files: > > > > +CONFIG_OF_UPSTREAM=y > > +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-odroidc2" > > > > instead, OF_UPSTREAM should be enabled via 'imply' for the SoC, in the > > Kconfig. > > Okay I got your point. It makes sense to me. I will do that for v3. > > > We should not have to specify the filename like this. It is > > laborious and error-prone. > > The only differentiation in naming here is just silicon vendor prefix > addition (amlogic/ in this case). The reason for this being that I > just want to mirror the whole silicon vendor directory from DT > rebasing rather than mirroring individual DT files. Given this do you > have any better alternatives? > So how do we handle the case where the DTS exists in u-boot, but not in Linux? For example, the DTS was developed for u-boot first and has not been accepted in the Linux device tree yet. Can we set in the board defconfig like: # CONFIG_OF_UPSTREAM is not set Would that allow the DTS to remain in arch/<architecture>/dts? Thanks, Tony
Hi Tony, On Wed, 27 Dec 2023 at 10:11, Tony Dinh <mibodhi@gmail.com> wrote: > > Hi Sumit > Hi Simon, > > On Tue, Dec 26, 2023 at 2:13 AM Sumit Garg <sumit.garg@linaro.org> wrote: > > > > Hi Simon, > > > > On Tue, 26 Dec 2023 at 15:17, Simon Glass <sjg@chromium.org> wrote: > > > > > > Hi Sumit, > > > > > > On Fri, Dec 22, 2023 at 5:34 AM Sumit Garg <sumit.garg@linaro.org> wrote: > > > > > > > > On Thu, 21 Dec 2023 at 20:48, Simon Glass <sjg@chromium.org> wrote: > > > > > > > > > > Hi, > > > > > > > > > > On Thu, Dec 21, 2023 at 3:03 PM Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > On Thu, Dec 14, 2023 at 07:20:55PM +0530, Sumit Garg wrote: > > > > > > > > > > > > > Prerquisite > > > > > > > ----------- > > > > > > > > > > > > > > This patch series requires devicetree-rebasing git repo to be added as a > > > > > > > subtree to the main U-boot repo via: > > > > > > > > > > > > > > $ git subtree add --prefix devicetree-rebasing \ > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ > > > > > > > v6.6-dts --squash > > > > > > > > > > > > So, I've played with subtree a little and I think this is the right way > > > > > > forward in these cases. If anyone wants to take a look at how this works > > > > > > in practice, take a look at: > > > > > > https://source.denx.de/u-boot/u-boot/-/commits/WIP/u-boot-with-devicetree-rebasing-since-v6.1/?ref_type=heads > > > > > > In that tree I started with the v6.1-dts tag, sync'd all the configs (to > > > > > > have an example of a normal commit) and then did a merge of each tag > > > > > > until v6.6-dts, so provide some history. And git log looks like what I > > > > > > want to see, the squash commit has clear references to what we are > > > > > > getting and I make a merge commit that says what I did. If you pull the > > > > > > tree and checkout the branch, all the code is right there already, > > > > > > nothing further to do. Same with tarball releases. The only thing I > > > > > > don't like is the size growth there, but we'll reclaim some of it when > > > > > > we delete our obsolete bindings, and then obsolete dts files. > > > > > > > > > > I spent a bit of time with subtree as well, as part of reviewing this > > > > > series, using the instructions Sumit provided. It seems OK to me. We > > > > > have to accept that it adds code and there will be changes/churn, but > > > > > it is not too different to accepting patches on those files within > > > > > U-Boot. We will bring in files which U-Boot doesn't use, but U-Boot > > > > > does support a good proportion of the boards supported by Linux, so I > > > > > don't see that as a big cost. > > > > > > > > > > From my experimentation, subtrees seem to have no impact on buildman, > > > > > which is great. Am I missing anything? > > > > > > > > No it shouldn't cause any regression on existing tools/CI/build > > > > systems. It is just a version controlled way of importing third party > > > > source code as a tarball. > > > > > > > > > > > > > > I still worry about the board-level 'switch' between U-Boot DT and > > > > > upstream ones. I believe that should be at the SoC level instead. > > > > > > > > > > > > > Probably I wasn't clear enough in my earlier replies but this series > > > > motivates for a SoC level switch only. Patch #7 is essentially a > > > > switch for Amlogic meson-gxbb SoC and its derived boards. > > > > > > OK good...but that's not quite what I mean. You have a fragment like > > > this in multiple defconfig files: > > > > > > +CONFIG_OF_UPSTREAM=y > > > +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-odroidc2" > > > > > > instead, OF_UPSTREAM should be enabled via 'imply' for the SoC, in the > > > Kconfig. > > > > Okay I got your point. It makes sense to me. I will do that for v3. > > > > > We should not have to specify the filename like this. It is > > > laborious and error-prone. > > > > The only differentiation in naming here is just silicon vendor prefix > > addition (amlogic/ in this case). The reason for this being that I > > just want to mirror the whole silicon vendor directory from DT > > rebasing rather than mirroring individual DT files. Given this do you > > have any better alternatives? > > > > So how do we handle the case where the DTS exists in u-boot, but not > in Linux? For example, the DTS was developed for u-boot first and has > not been accepted in the Linux device tree yet. Can we set in the > board defconfig like: > > # CONFIG_OF_UPSTREAM is not set > > Would that allow the DTS to remain in arch/<architecture>/dts? Yeah that is expected until DTS becomes available in the DT rebasing tree. -Sumit > > Thanks, > Tony
Hi Sumit, On Tue, Dec 26, 2023 at 10:06 AM Sumit Garg <sumit.garg@linaro.org> wrote: > > Hi Simon, > > On Tue, 26 Dec 2023 at 15:17, Simon Glass <sjg@chromium.org> wrote: > > > > Hi Sumit, > > > > On Fri, Dec 22, 2023 at 5:34 AM Sumit Garg <sumit.garg@linaro.org> wrote: > > > > > > On Thu, 21 Dec 2023 at 20:48, Simon Glass <sjg@chromium.org> wrote: > > > > > > > > Hi, > > > > > > > > On Thu, Dec 21, 2023 at 3:03 PM Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > On Thu, Dec 14, 2023 at 07:20:55PM +0530, Sumit Garg wrote: > > > > > > > > > > > Prerquisite > > > > > > ----------- > > > > > > > > > > > > This patch series requires devicetree-rebasing git repo to be added as a > > > > > > subtree to the main U-boot repo via: > > > > > > > > > > > > $ git subtree add --prefix devicetree-rebasing \ > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ > > > > > > v6.6-dts --squash > > > > > > > > > > So, I've played with subtree a little and I think this is the right way > > > > > forward in these cases. If anyone wants to take a look at how this works > > > > > in practice, take a look at: > > > > > https://source.denx.de/u-boot/u-boot/-/commits/WIP/u-boot-with-devicetree-rebasing-since-v6.1/?ref_type=heads > > > > > In that tree I started with the v6.1-dts tag, sync'd all the configs (to > > > > > have an example of a normal commit) and then did a merge of each tag > > > > > until v6.6-dts, so provide some history. And git log looks like what I > > > > > want to see, the squash commit has clear references to what we are > > > > > getting and I make a merge commit that says what I did. If you pull the > > > > > tree and checkout the branch, all the code is right there already, > > > > > nothing further to do. Same with tarball releases. The only thing I > > > > > don't like is the size growth there, but we'll reclaim some of it when > > > > > we delete our obsolete bindings, and then obsolete dts files. > > > > > > > > I spent a bit of time with subtree as well, as part of reviewing this > > > > series, using the instructions Sumit provided. It seems OK to me. We > > > > have to accept that it adds code and there will be changes/churn, but > > > > it is not too different to accepting patches on those files within > > > > U-Boot. We will bring in files which U-Boot doesn't use, but U-Boot > > > > does support a good proportion of the boards supported by Linux, so I > > > > don't see that as a big cost. > > > > > > > > From my experimentation, subtrees seem to have no impact on buildman, > > > > which is great. Am I missing anything? > > > > > > No it shouldn't cause any regression on existing tools/CI/build > > > systems. It is just a version controlled way of importing third party > > > source code as a tarball. > > > > > > > > > > > I still worry about the board-level 'switch' between U-Boot DT and > > > > upstream ones. I believe that should be at the SoC level instead. > > > > > > > > > > Probably I wasn't clear enough in my earlier replies but this series > > > motivates for a SoC level switch only. Patch #7 is essentially a > > > switch for Amlogic meson-gxbb SoC and its derived boards. > > > > OK good...but that's not quite what I mean. You have a fragment like > > this in multiple defconfig files: > > > > +CONFIG_OF_UPSTREAM=y > > +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-odroidc2" > > > > instead, OF_UPSTREAM should be enabled via 'imply' for the SoC, in the > > Kconfig. > > Okay I got your point. It makes sense to me. I will do that for v3. > > > We should not have to specify the filename like this. It is > > laborious and error-prone. > > The only differentiation in naming here is just silicon vendor prefix > addition (amlogic/ in this case). The reason for this being that I > just want to mirror the whole silicon vendor directory from DT > rebasing rather than mirroring individual DT files. Given this do you > have any better alternatives? My current opinion is that a better approach would be to move the files first (in the U-Boot tree). That would be easier if we could just copy the Linux arch/xxx/boot/dts Makefiles but for now that is not possible. The Kconfig options for each SoC are similar but there are various differences. Having a different layout is just a pain and it will get worse, as people add new boards, since they need to know to add the correct directory. I will see if I can devise a small series to point this in what I consider to be the right direction, in line with Linux, and the U-Boot commit 3284c8b8 ("dts: generate multiple device tree blobs"). Regards, Simon
On Wed, Dec 27, 2023 at 07:56:26AM +0000, Simon Glass wrote: > Hi Sumit, > > On Tue, Dec 26, 2023 at 10:06 AM Sumit Garg <sumit.garg@linaro.org> wrote: > > > > Hi Simon, > > > > On Tue, 26 Dec 2023 at 15:17, Simon Glass <sjg@chromium.org> wrote: > > > > > > Hi Sumit, > > > > > > On Fri, Dec 22, 2023 at 5:34 AM Sumit Garg <sumit.garg@linaro.org> wrote: > > > > > > > > On Thu, 21 Dec 2023 at 20:48, Simon Glass <sjg@chromium.org> wrote: > > > > > > > > > > Hi, > > > > > > > > > > On Thu, Dec 21, 2023 at 3:03 PM Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > On Thu, Dec 14, 2023 at 07:20:55PM +0530, Sumit Garg wrote: > > > > > > > > > > > > > Prerquisite > > > > > > > ----------- > > > > > > > > > > > > > > This patch series requires devicetree-rebasing git repo to be added as a > > > > > > > subtree to the main U-boot repo via: > > > > > > > > > > > > > > $ git subtree add --prefix devicetree-rebasing \ > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ > > > > > > > v6.6-dts --squash > > > > > > > > > > > > So, I've played with subtree a little and I think this is the right way > > > > > > forward in these cases. If anyone wants to take a look at how this works > > > > > > in practice, take a look at: > > > > > > https://source.denx.de/u-boot/u-boot/-/commits/WIP/u-boot-with-devicetree-rebasing-since-v6.1/?ref_type=heads > > > > > > In that tree I started with the v6.1-dts tag, sync'd all the configs (to > > > > > > have an example of a normal commit) and then did a merge of each tag > > > > > > until v6.6-dts, so provide some history. And git log looks like what I > > > > > > want to see, the squash commit has clear references to what we are > > > > > > getting and I make a merge commit that says what I did. If you pull the > > > > > > tree and checkout the branch, all the code is right there already, > > > > > > nothing further to do. Same with tarball releases. The only thing I > > > > > > don't like is the size growth there, but we'll reclaim some of it when > > > > > > we delete our obsolete bindings, and then obsolete dts files. > > > > > > > > > > I spent a bit of time with subtree as well, as part of reviewing this > > > > > series, using the instructions Sumit provided. It seems OK to me. We > > > > > have to accept that it adds code and there will be changes/churn, but > > > > > it is not too different to accepting patches on those files within > > > > > U-Boot. We will bring in files which U-Boot doesn't use, but U-Boot > > > > > does support a good proportion of the boards supported by Linux, so I > > > > > don't see that as a big cost. > > > > > > > > > > From my experimentation, subtrees seem to have no impact on buildman, > > > > > which is great. Am I missing anything? > > > > > > > > No it shouldn't cause any regression on existing tools/CI/build > > > > systems. It is just a version controlled way of importing third party > > > > source code as a tarball. > > > > > > > > > > > > > > I still worry about the board-level 'switch' between U-Boot DT and > > > > > upstream ones. I believe that should be at the SoC level instead. > > > > > > > > > > > > > Probably I wasn't clear enough in my earlier replies but this series > > > > motivates for a SoC level switch only. Patch #7 is essentially a > > > > switch for Amlogic meson-gxbb SoC and its derived boards. > > > > > > OK good...but that's not quite what I mean. You have a fragment like > > > this in multiple defconfig files: > > > > > > +CONFIG_OF_UPSTREAM=y > > > +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-odroidc2" > > > > > > instead, OF_UPSTREAM should be enabled via 'imply' for the SoC, in the > > > Kconfig. > > > > Okay I got your point. It makes sense to me. I will do that for v3. > > > > > We should not have to specify the filename like this. It is > > > laborious and error-prone. > > > > The only differentiation in naming here is just silicon vendor prefix > > addition (amlogic/ in this case). The reason for this being that I > > just want to mirror the whole silicon vendor directory from DT > > rebasing rather than mirroring individual DT files. Given this do you > > have any better alternatives? > > My current opinion is that a better approach would be to move the > files first (in the U-Boot tree). That would be easier if we could > just copy the Linux arch/xxx/boot/dts Makefiles but for now that is > not possible. The Kconfig options for each SoC are similar but there > are various differences. > > Having a different layout is just a pain and it will get worse, as > people add new boards, since they need to know to add the correct > directory. > > I will see if I can devise a small series to point this in what I > consider to be the right direction, in line with Linux, and the U-Boot > commit 3284c8b8 ("dts: generate multiple device tree blobs"). I think we should just go with the approach Sumit has already taken, and encourage SoC maintainers to migrate sooner rather than later. There's also nothing stopping people from adding vendor directories under arch/ at that point, and will likely have to happen anyhow for the case of platforms that aren't yet in the devicetree-rebasing tree. I am hopeful it won't be as much of an issue as my general feedback will change from "what kernel release is this dts in?" to "why didn't you set OF_UPSTREAM and use the existing tree?"
Hi Tom, On Wed, Dec 27, 2023 at 1:37 PM Tom Rini <trini@konsulko.com> wrote: > > On Wed, Dec 27, 2023 at 07:56:26AM +0000, Simon Glass wrote: > > Hi Sumit, > > > > On Tue, Dec 26, 2023 at 10:06 AM Sumit Garg <sumit.garg@linaro.org> wrote: > > > > > > Hi Simon, > > > > > > On Tue, 26 Dec 2023 at 15:17, Simon Glass <sjg@chromium.org> wrote: > > > > > > > > Hi Sumit, > > > > > > > > On Fri, Dec 22, 2023 at 5:34 AM Sumit Garg <sumit.garg@linaro.org> wrote: > > > > > > > > > > On Thu, 21 Dec 2023 at 20:48, Simon Glass <sjg@chromium.org> wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > On Thu, Dec 21, 2023 at 3:03 PM Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > > > > > On Thu, Dec 14, 2023 at 07:20:55PM +0530, Sumit Garg wrote: > > > > > > > > > > > > > > > Prerquisite > > > > > > > > ----------- > > > > > > > > > > > > > > > > This patch series requires devicetree-rebasing git repo to be added as a > > > > > > > > subtree to the main U-boot repo via: > > > > > > > > > > > > > > > > $ git subtree add --prefix devicetree-rebasing \ > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ > > > > > > > > v6.6-dts --squash > > > > > > > > > > > > > > So, I've played with subtree a little and I think this is the right way > > > > > > > forward in these cases. If anyone wants to take a look at how this works > > > > > > > in practice, take a look at: > > > > > > > https://source.denx.de/u-boot/u-boot/-/commits/WIP/u-boot-with-devicetree-rebasing-since-v6.1/?ref_type=heads > > > > > > > In that tree I started with the v6.1-dts tag, sync'd all the configs (to > > > > > > > have an example of a normal commit) and then did a merge of each tag > > > > > > > until v6.6-dts, so provide some history. And git log looks like what I > > > > > > > want to see, the squash commit has clear references to what we are > > > > > > > getting and I make a merge commit that says what I did. If you pull the > > > > > > > tree and checkout the branch, all the code is right there already, > > > > > > > nothing further to do. Same with tarball releases. The only thing I > > > > > > > don't like is the size growth there, but we'll reclaim some of it when > > > > > > > we delete our obsolete bindings, and then obsolete dts files. > > > > > > > > > > > > I spent a bit of time with subtree as well, as part of reviewing this > > > > > > series, using the instructions Sumit provided. It seems OK to me. We > > > > > > have to accept that it adds code and there will be changes/churn, but > > > > > > it is not too different to accepting patches on those files within > > > > > > U-Boot. We will bring in files which U-Boot doesn't use, but U-Boot > > > > > > does support a good proportion of the boards supported by Linux, so I > > > > > > don't see that as a big cost. > > > > > > > > > > > > From my experimentation, subtrees seem to have no impact on buildman, > > > > > > which is great. Am I missing anything? > > > > > > > > > > No it shouldn't cause any regression on existing tools/CI/build > > > > > systems. It is just a version controlled way of importing third party > > > > > source code as a tarball. > > > > > > > > > > > > > > > > > I still worry about the board-level 'switch' between U-Boot DT and > > > > > > upstream ones. I believe that should be at the SoC level instead. > > > > > > > > > > > > > > > > Probably I wasn't clear enough in my earlier replies but this series > > > > > motivates for a SoC level switch only. Patch #7 is essentially a > > > > > switch for Amlogic meson-gxbb SoC and its derived boards. > > > > > > > > OK good...but that's not quite what I mean. You have a fragment like > > > > this in multiple defconfig files: > > > > > > > > +CONFIG_OF_UPSTREAM=y > > > > +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-odroidc2" > > > > > > > > instead, OF_UPSTREAM should be enabled via 'imply' for the SoC, in the > > > > Kconfig. > > > > > > Okay I got your point. It makes sense to me. I will do that for v3. > > > > > > > We should not have to specify the filename like this. It is > > > > laborious and error-prone. > > > > > > The only differentiation in naming here is just silicon vendor prefix > > > addition (amlogic/ in this case). The reason for this being that I > > > just want to mirror the whole silicon vendor directory from DT > > > rebasing rather than mirroring individual DT files. Given this do you > > > have any better alternatives? > > > > My current opinion is that a better approach would be to move the > > files first (in the U-Boot tree). That would be easier if we could > > just copy the Linux arch/xxx/boot/dts Makefiles but for now that is > > not possible. The Kconfig options for each SoC are similar but there > > are various differences. > > > > Having a different layout is just a pain and it will get worse, as > > people add new boards, since they need to know to add the correct > > directory. > > > > I will see if I can devise a small series to point this in what I > > consider to be the right direction, in line with Linux, and the U-Boot > > commit 3284c8b8 ("dts: generate multiple device tree blobs"). > > I think we should just go with the approach Sumit has already taken, and > encourage SoC maintainers to migrate sooner rather than later. There's > also nothing stopping people from adding vendor directories under arch/ > at that point, and will likely have to happen anyhow for the case of > platforms that aren't yet in the devicetree-rebasing tree. I am hopeful > it won't be as much of an issue as my general feedback will change from > "what kernel release is this dts in?" to "why didn't you set > OF_UPSTREAM and use the existing tree?" OK. But I do want to see a move to using the same dir structure as Linux. Regards, Simon
Prerquisite ----------- This patch series requires devicetree-rebasing git repo to be added as a subtree to the main U-boot repo via: $ git subtree add --prefix devicetree-rebasing \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ v6.6-dts --squash Background ---------- This effort started while I was reviewing patch series corresponding to Qcom platforms [1] which was about to import modified devicetree source files from Linux kernel. I suppose keeping devicetree files sync with Linux kernel without any DT bindings schema validation has been a pain for U-boot SoC/platform maintainers. There has been past discussions about a single DT repo but that hasn't come up and Linux kernel remained the place where DT source files as well as bindings are placed and maintained. However, Linux kernel DT maintainers proposed [2] for U-boot to rather use devicetree-rebasing repo [3] which is a forked copy from Linux kernel for DT source files as well as bindings. It is tagged at every Linux kernel major release or intermideate release candidates. So here I have tried to reuse that to bring DT bingings compliance as well as a standard way to maintain a regular sync of DT source files with Linux kernel. In order to maintain devicetree files sync, U-boot will maintains a Git subtree for devicetee-rebasing repo as `devicetee-rebasing/` sub-directory. It will be regularly updated with every new kernel major release via subtree pull as follows:: $ git subtree pull --prefix devicetree-rebasing \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ <release-tag> --squash The RFC/prototype for this series has been discussed with Linux DT maintainers as well as U-boot maintainers here [4]. Now we would like to reach out to wider U-boot community to seek feedback. [1] https://lore.kernel.org/all/CAFA6WYMLUD9cnkr=R0Uur+1UeTMkKjM2zDdMJtXb3nmrLk+pDg@mail.gmail.com/ [2] https://lore.kernel.org/all/CAL_JsqKEjv2tSGmT+0ZiO7_qbBfhTycbGnhJhYpKDFzfO9jzDg@mail.gmail.com/ [3] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ [4] https://github.com/u-boot/u-boot/pull/451 Changes ------- Traditionally, U-boot placed copies of devicetree source files from Linux kernel into `arch/<arch>/dts/<name>.dts`, which can be selected via: CONFIG_DEFAULT_DEVICE_TREE "<name>" SoC/board maintainers are encouraged to migrate to using mirrored copies from `devicetree-rebasing/` into `dts/arch/<arch>/<vendor>` via: CONFIG_OF_UPSTREAM=y CONFIG_DEFAULT_DEVICE_TREE "<vendor>/<name>" An example have been shown for Amlogic meson-gxbb SoC and corresponding derived boards via patch #7 and #8. Devicetree bindings schema checks --------------------------------- With devicetee-rebasing Git subtree, the devicetree bindings are also regularly synced with Linux kernel as `devicetree-rebasing/Bindings/` sub-directory. This allows U-boot to run devicetree bindings schema checks which will bring compliance to U-boot core/drivers regarding usage of devicetree. Dependencies ------------ The DT schema project must be installed in order to validate the DT schema binding documents and validate DTS files using the DT schema. The DT schema project can be installed with pip: $ pip3 install dtschema Note that 'dtschema' installation requires 'swig' and Python development files installed first. On Debian/Ubuntu systems: $ apt install swig python3-dev Several executables (dt-doc-validate, dt-mk-schema, dt-validate) will be installed. Ensure they are in your PATH (~/.local/bin by default). Recommended is also to install yamllint (used by dtschema when present). Running checks -------------- In order to perform validation of DTB files, use the ``dtbs_check`` target: $ make dtbs_check It is also possible to run checks with a subset of matching schema files by setting the ``DT_SCHEMA_FILES`` variable to 1 or more specific schema files or patterns (partial match of a fixed string). Each file or pattern should be separated by ':'. $ make dtbs_check DT_SCHEMA_FILES=trivial-devices.yaml:rtc.yaml $ make dtbs_check DT_SCHEMA_FILES=/gpio/ $ make dtbs_check DT_SCHEMA_FILES=trivial-devices.yaml Sumit Garg (8): Azure CI: Exclude devicetree-rebasing subtree for CONFIG checks Makefile: Add support for DT bindings schema checks scripts/Makefile.lib: Statically define *-u-boot.dtsi files location dts: Add alternative location for upstream DTB builds doc: devicetree: Updates for devicetree-rebasing subtree MAINTAINERS: Add myself as devicetree-rebasing maintainer dts: meson-gxbb: Switch to using upstream DT dts: meson-gxbb: Drop redundant devicetree files .azure-pipelines.yml | 3 +- MAINTAINERS | 6 + Makefile | 20 +- arch/arm/dts/Makefile | 8 - arch/arm/dts/meson-gxbb-kii-pro.dts | 140 ---- arch/arm/dts/meson-gxbb-nanopi-k2.dts | 415 ------------ arch/arm/dts/meson-gxbb-odroidc2.dts | 418 ------------ arch/arm/dts/meson-gxbb-p200.dts | 100 --- arch/arm/dts/meson-gxbb-p201.dts | 26 - arch/arm/dts/meson-gxbb-p20x.dtsi | 250 ------- arch/arm/dts/meson-gxbb-wetek-hub.dts | 58 -- arch/arm/dts/meson-gxbb-wetek-play2.dts | 119 ---- arch/arm/dts/meson-gxbb-wetek.dtsi | 292 -------- arch/arm/dts/meson-gxbb.dtsi | 856 ------------------------ configs/nanopi-k2_defconfig | 3 +- configs/odroid-c2_defconfig | 3 +- configs/p200_defconfig | 3 +- configs/p201_defconfig | 3 +- configs/videostrong-kii-pro_defconfig | 3 +- configs/wetek-hub_defconfig | 3 +- configs/wetek-play2_defconfig | 3 +- doc/develop/devicetree/control.rst | 108 ++- dts/Kconfig | 11 + dts/Makefile | 17 +- dts/arch/arm64/Makefile | 23 + dts/arch/arm64/amlogic | 1 + scripts/Makefile.lib | 42 +- 27 files changed, 204 insertions(+), 2730 deletions(-) delete mode 100644 arch/arm/dts/meson-gxbb-kii-pro.dts delete mode 100644 arch/arm/dts/meson-gxbb-nanopi-k2.dts delete mode 100644 arch/arm/dts/meson-gxbb-odroidc2.dts delete mode 100644 arch/arm/dts/meson-gxbb-p200.dts delete mode 100644 arch/arm/dts/meson-gxbb-p201.dts delete mode 100644 arch/arm/dts/meson-gxbb-p20x.dtsi delete mode 100644 arch/arm/dts/meson-gxbb-wetek-hub.dts delete mode 100644 arch/arm/dts/meson-gxbb-wetek-play2.dts delete mode 100644 arch/arm/dts/meson-gxbb-wetek.dtsi delete mode 100644 arch/arm/dts/meson-gxbb.dtsi create mode 100644 dts/arch/arm64/Makefile create mode 120000 dts/arch/arm64/amlogic