Hi Tom,
On Thu, Dec 28, 2023 at 3:54 PM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 28, 2023 at 03:09:12PM +0000, Simon Glass wrote:
Hi Tom, Sumit,
On Thu, Dec 28, 2023 at 2:03 PM Tom Rini trini@konsulko.com wrote:
On Thu, Dec 28, 2023 at 01:37:26PM +0000, Simon Glass wrote:
Hi Sumit,
On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg sumit.garg@linaro.org wrote:
Allow platform owners to mirror devicetree files from devitree-rebasing directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts directory. Also add a new Makefile for arm64.
This will help easy migration for platforms which currently are compliant with upstream Linux kernel devicetree files.
Signed-off-by: Sumit Garg sumit.garg@linaro.org
Changes in v3:
- Minor commit message update
Changes in v2:
- s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
dts/Kconfig | 11 +++++++++++ dts/Makefile | 17 ++++++++++++++--- dts/arch/arm64/Makefile | 14 ++++++++++++++ 3 files changed, 39 insertions(+), 3 deletions(-) create mode 100644 dts/arch/arm64/Makefile
diff --git a/dts/Kconfig b/dts/Kconfig index 00c0aeff893..e58c1c6f2ab 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -85,6 +85,17 @@ config OF_LIVE enables a live tree which is available after relocation, and can be adjusted as needed.
+config OF_UPSTREAM
bool "Enable use of devicetree imported from Linux kernel release"helpTraditionally, U-Boot platforms used to have their custom devicetreefiles or copy devicetree files from Linux kernel which are hard tomaintain and can usually get out-of-sync from Linux kernel. Thisoption enables platforms to migrate to devicetree-rebasing repo wherea regular sync will be maintained every major Linux kernel releasecycle. However, platforms can still have some custom u-boot specificbits maintained as part of *-u-boot.dtsi files.My only other suggestion here is to mention that this should be set in Kconfig, for the SoC as a whole. So I believe that means that it should be hidden, with no string for the 'bool':
bool # Enable use of devicetree imported from Linux kernel releaseI think we can just keep prompting for it now, to make the transition easier, before this option just goes away in time, hopefully.
Also, this doesn't seem to work for me. Before this series I get these files when building firefly-rk3399:
rk3399-eaidk-610.dtb rk3399-khadas-edge-v.dtb rk3399-orangepi.dtb rk3399-rock-pi-4a.dtb rk3399-evb.dtb rk3399-leez-p710.dtb rk3399-pinebook-pro.dtb rk3399-rock-pi-4c.dtb rk3399-ficus.dtb rk3399-nanopc-t4.dtb rk3399-pinephone-pro.dtb rk3399-rockpro64.dtb rk3399-firefly.dtb rk3399-nanopi-m4-2gb.dtb rk3399pro-rock-pi-n10.dtb rk3399-roc-pc.dtb rk3399-gru-bob.dtb rk3399-nanopi-m4b.dtb rk3399-puma-haikou.dtb rk3399-roc-pc-mezzanine.dtb rk3399-gru-kevin.dtb rk3399-nanopi-m4.dtb rk3399-rock-4c-plus.dtb rk3399-khadas-edge-captain.dtb rk3399-nanopi-neo4.dtb rk3399-rock-4se.dtb rk3399-khadas-edge.dtb rk3399-nanopi-r4s.dtb rk3399-rock960.dtb
Afterwards I get this:
make[3]: *** No rule to make target 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'. Stop.
So I set this manually for that one board:
CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly"
and get:
make[3]: *** No rule to make target 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'. Stop.
I am not sure how to fix this, nor how this can be made to build all the DTs for rk3399, as it does today.
Looking at the patch for amlogic boards, you need to make the link to devicetree-rebasing inside dts/...
OK, let me give up on rk3399 for now...that doesn't seem to work even with the link.
Using odroid-c2 with -next I see:
$ ls /tmp/b/odroid-c2/arch/arm/dts/ meson-a1-ad401.dtb meson-g12b-odroid-n2l.dtb meson-gxl-s905x-libretech-cc.dtb meson-axg-jethome-jethub-j100.dtb meson-g12b-odroid-n2-plus.dtb meson-gxl-s905x-libretech-cc-v2.dtb meson-axg-s400.dtb meson-g12b-radxa-zero2.dtb meson-gxl-s905x-p212.dtb meson-g12a-radxa-zero.dtb meson-gxbb-kii-pro.dtb meson-gxm-gt1-ultimate.dtb meson-g12a-sei510.dtb meson-gxbb-nanopi-k2.dtb meson-gxm-khadas-vim2.dtb meson-g12a-u200.dtb meson-gxbb-odroidc2.dtb meson-gxm-s912-libretech-pc.dtb meson-g12b-a311d-bananapi-m2s.dtb meson-gxbb-p200.dtb meson-gxm-wetek-core2.dtb meson-g12b-a311d-khadas-vim3.dtb meson-gxbb-p201.dtb meson-sm1-bananapi-m2-pro.dtb meson-g12b-bananapi-cm4-cm4io.dtb meson-gxbb-wetek-hub.dtb meson-sm1-bananapi-m5.dtb meson-g12b-gsking-x.dtb meson-gxbb-wetek-play2.dtb meson-sm1-khadas-vim3l.dtb meson-g12b-gtking.dtb meson-gxl-s805x-libretech-ac.dtb meson-sm1-odroid-c4.dtb meson-g12b-gtking-pro.dtb meson-gxl-s905d-libretech-pc.dtb meson-sm1-odroid-hc4.dtb meson-g12b-odroid-go-ultra.dtb meson-gxl-s905w-jethome-jethub-j80.dtb meson-sm1-sei610.dtb meson-g12b-odroid-n2.dtb meson-gxl-s905x-khadas-vim.dtb $ With this series (sort of, since I am really not sure how to cherry-pick the commits from the PR) I see nothing:
$ ls /tmp/b/odroid-c2/arch/arm/dts/ $
This shows some of the files:
$ find /tmp/b/odroid-c2/ -name "*.dtb" /tmp/b/odroid-c2/dts/dt.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-odroidc2.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-nanopi-k2.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-play2.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-kii-pro.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p200.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p201.dtb /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-hub.dtb /tmp/b/odroid-c2/u-boot.dtb
but where are the rest? Also, is it possible to put the output .dtb files into the same directory? Otherwise we may have some pain with binman.
What do you mean by same directory? But maybe also, what's an example of a board you think might end up having problems? Converting that in a follow-up series is likely a good idea, to highlight and address these issues sooner rather than later.#
Today the .dtb files go into arch/arm/dts - so it would be easier if this series could do the same.
The problem I have described above applied to meson, so I believe it is clear enough with that. I wasn't able to get rk3399 going, but I am sure it would have the same problem.
The fundamental question is (I believe) whether to:
1. Build only a single DT for a board 2. Build all DTs for the SoC the board uses
This series seems to head towards (1), which worries me. We are currently mostly at (2).
Regards, Simon