ARM: dts: DT overlay support infra + some data
Subsystems (4)
cover ARM: dts: DT overlay support infra + some data
Hi,
This series is an attempt to start discussion on the DT overlay build time support. Basically, one can build DT overlays directly from kernel tree, and also build FIT images that contain the kernel + devicetree blobs required for specific configuration that can be booted directly with u-boot. No runtime support for overlay switching is touched by this series.
What this series does, is to:
1) add subdir support under arch/arm/boot/dts
2) provide DT overlay build support to kernel tree
3) provide FIT image build support to kernel tree
4) provide a number of DT overlay + FIT image files for some TI SoCs to show the reasons why we are doing this, this is only a subset of our boards that we would want to use overlays with
Main reason for TI to use DT overlays right now is the rather large amount of different displays we have around, which can be used with different boards. With the current approach one needs to write a separate .dts file for each board + display config, but with overlays, one can just create a single overlay that would apply to different boards. There are some other cases like the shown dra71-evm case in this series, where the gpmc vs. display support is mutually exclusive, as they are sharing certain pieces of the HW.
The main controversy with this series is most likely where the DT overlay files should be stored at. Should they still reside with the kernel tree or someplace else? Also, the FIT image support is probably controversial, should it be part of the kernel build system like shown here, or should it be separate? The zImage dependency is pretty annoying so maybe it should be done somewhere else.
Any comments welcome as this is just an RFC for now, but basically we would really want a solution to this problem.
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
RFC 1/13 ARM: dts: allow building .dtb files under platform subdirs
Add support to base ARM makefile for building .dtb files under platform specific subdirs (e.g. arch/arm/boot/dts/ti for TI SoCs.)
--- arch/arm/Makefile | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
arch/arm/Makefile +3 -1
@@ -343,8 +343,10 @@ $(BOOT_TARGETS): vmlinux $(INSTALL_TARGETS): $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $@ +%.dtb: dtbdir=$(patsubst %/,%,$(patsubst %./,%,$(boot)/dts/$(dir $@))) + %.dtb: | scripts - $(Q)$(MAKE) $(build)=$(boot)/dts MACHINE=$(MACHINE) $(boot)/dts/$@ + $(Q)$(MAKE) $(build)=$(dtbdir) MACHINE=$(MACHINE) $(boot)/dts/$@ PHONY += dtbs dtbs_install
Signature · 4 lines
1.9.1 -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [RFC 01/13] ARM: dts: allow building .dtb files under platform subdirs
Quoted 13 lines · Tero Kristo
Add support to base ARM makefile for building .dtb files under platform specific subdirs (e.g.
arch/arm/boot/dts/tifor TI SoCs.)Signed-off-by Tero Kristo <[email protected]>--- arch/arm/Makefile | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)arch/arm/Makefile +0
-0
arch/arm/Makefile $(BOOT_TARGETS): vmlinux · line 346
Quoted 4 lines
arch/arm/Makefile +1
-0@@ -343,8 +343,10 @@ $(BOOT_TARGETS): vmlinux $(INSTALL_TARGETS): $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $@ +%.dtb: dtbdir=$(patsubst %/,%,$(patsubst %./,%,$(boot)/dts/$(dir $@)))
I'd expect this to look more like the arm64 version and just add 'subdir-y' entries in the boot/dts/Makefile.
arch/arm/Makefile $(BOOT_TARGETS): vmlinux · line 349
Quoted 4 lines
arch/arm/Makefile +2
-1+ %.dtb: | scripts - $(Q)$(MAKE) $(build)=$(boot)/dts MACHINE=$(MACHINE) $(boot)/dts/$@ + $(Q)$(MAKE) $(build)=$(dtbdir) MACHINE=$(MACHINE) $(boot)/dts/$@
We can drop MACHINE here.
Rob
RFC 2/13 ARM: dts: add support for building DT overlays
In reply to Tero KristoAdd support for building DT overlay files from the kernel DT source tree. These can be built either from the base DT source directory, or platform specific subdir under the base directory.
--- arch/arm/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/arm/Makefile +2 -2
@@ -343,9 +343,9 @@ $(BOOT_TARGETS): vmlinux $(INSTALL_TARGETS): $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $@ -%.dtb: dtbdir=$(patsubst %/,%,$(patsubst %./,%,$(boot)/dts/$(dir $@))) +%.dtb %.dtbo: dtbdir=$(patsubst %/,%,$(patsubst %./,%,$(boot)/dts/$(dir $@))) -%.dtb: | scripts +%.dtb %.dtbo: | scripts $(Q)$(MAKE) $(build)=$(dtbdir) MACHINE=$(MACHINE) $(boot)/dts/$@ PHONY += dtbs dtbs_install
Signature · 4 lines
1.9.1 -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
RFC 3/13 ARM: dts: add subdir for TI SoC DT files
In reply to Tero KristoAdd subdir for TI SoC DT files under the main DT source directory. Initially, this directory will only be used for DT overlay build purposes.
--- arch/arm/boot/dts/Makefile | 4 ++++ arch/arm/boot/dts/ti/Makefile | 1 + 2 files changed, 5 insertions(+) create mode 100644 arch/arm/boot/dts/ti/Makefile
arch/arm/boot/dts/Makefile +4 -0
@@ -729,6 +729,7 @@ dtb-$(CONFIG_SOC_DRA7XX) += \ dra72-evm-revc.dtb \ dra71-evm.dtb \ dra76-evm.dtb +dts-dirs-$(CONFIG_SOC_DRA7XX) += ti dtb-$(CONFIG_ARCH_ORION5X) += \ orion5x-kuroboxpro.dtb \ orion5x-lacie-d2-network.dtb \
@@ -1163,3 +1164,6 @@ dtb-$(CONFIG_ARCH_ASPEED) += \ aspeed-bmc-opp-witherspoon.dtb \ aspeed-bmc-opp-zaius.dtb \ aspeed-bmc-quanta-q71l.dtb + +subdir-y += $(dts-dirs-y) +subdir- += $(dts-dirs-)
arch/arm/boot/dts/ti/Makefile new file +1 -0
@@ -0,0 +1 @@ +clean-files += *.dtbo
Signature · 4 lines
1.9.1 -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
RFC 4/13 kbuild: add support for building %.dtbo targets
In reply to Tero KristoAdd support for building DT overlay targets.
--- scripts/Makefile.lib | 3 +++ 1 file changed, 3 insertions(+)
scripts/Makefile.lib +3 -0
@@ -290,6 +290,9 @@ cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \ $(obj)/%.dtb: $(src)/%.dts $(DTC) FORCE $(call if_changed_dep,dtc) +$(obj)/%.dtbo: $(src)/%.dtso $(DTC) FORCE + $(call if_changed_dep,dtc) + dtc-tmp = $(subst $(comma),_,$(dot-target).dts.tmp) # Bzip2
Signature · 4 lines
1.9.1 -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [RFC 04/13] kbuild: add support for building %.dtbo targets
Quoted 3 lines · Tero Kristo
Add support for building DT overlay targets.
Signed-off-by Tero Kristo <[email protected]>
Gr{oetje,eeting}s,
Geert
Signature · 5 lines
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected] In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
RFC 5/13 ARM: dts: ti: add support for building .dtb files containing symbols
In reply to Tero KristoSymbols in the DTB files are needed so that overlays can be applied properly. Add support for building TI SoC specific .dtb files, the source is fetched from parent directory.
--- arch/arm/boot/dts/ti/Makefile | 5 +++++ 1 file changed, 5 insertions(+)
arch/arm/boot/dts/ti/Makefile +5 -0
@@ -1 +1,6 @@ +DTC_FLAGS += -@ -Wno-reg_format -Wno-avoid_default_addr_size + +$(obj)/%.dtb: $(src)/../%.dts FORCE + $(call if_changed_dep,dtc) + clean-files += *.dtbo
Signature · 4 lines
1.9.1 -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [RFC 05/13] ARM: dts: ti: add support for building .dtb files containing symbols
Hi Tero,
Quoted 5 lines · Tero Kristo
Symbols in the DTB files are needed so that overlays can be applied properly. Add support for building TI SoC specific .dtb files, the source is fetched from parent directory.
Signed-off-by Tero Kristo <[email protected]>
Thanks for your patch!
arch/arm/boot/dts/ti/Makefile line 1
Quoted 10 lines
--- arch/arm/boot/dts/ti/Makefile | 5 +++++ 1 file changed, 5 insertions(+)arch/arm/boot/dts/ti/Makefile +1
-0@@ -1 +1,6 @@ +DTC_FLAGS += -@ -Wno-reg_format -Wno-avoid_default_addr_size
Why the -W options?
arch/arm/boot/dts/ti/Makefile line 3
Quoted 2 lines
arch/arm/boot/dts/ti/Makefile +2
-0+ +$(obj)/%.dtb: $(src)/../%.dts FORCE
I guess you want a dependency on $(DTC), too?
arch/arm/boot/dts/ti/Makefile line 6
Quoted 3 lines
arch/arm/boot/dts/ti/Makefile +2
-0+ $(call if_changed_dep,dtc) + clean-files += *.dtbo
Gr{oetje,eeting}s,
Geert
Signature · 5 lines
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected] In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Re: [RFC 05/13] ARM: dts: ti: add support for building .dtb files containing symbols
Quoted 15 lines · Geert Uytterhoeven
Hi Tero,
Quoted 5 lines · Tero Kristo
Symbols in the DTB files are needed so that overlays can be applied properly. Add support for building TI SoC specific .dtb files, the source is fetched from parent directory.
Signed-off-by Tero Kristo <[email protected]>Thanks for your patch!
Quoted 4 lines
--- arch/arm/boot/dts/ti/Makefile | 5 +++++ 1 file changed, 5 insertions(+)
Quoted 8 lines
arch/arm/boot/dts/ti/Makefile line 1
Quoted 6 lines
arch/arm/boot/dts/ti/Makefile +1
-0@@ -1 +1,6 @@ +DTC_FLAGS += -@ -Wno-reg_format -Wno-avoid_default_addr_sizeWhy the -W options?
The overlay files typically contain declarations that miss these bits, and will lead to build time warnings. Mostly, because we are working with fragments / references only, and don't have the base declaration available at all.
Quoted 5 lines
arch/arm/boot/dts/ti/Makefile line 3
Quoted 3 lines
arch/arm/boot/dts/ti/Makefile +2
-0+ +$(obj)/%.dtb: $(src)/../%.dts FORCEI guess you want a dependency on $(DTC), too?
Yeah, that should be added actually.
Quoted 9 lines
arch/arm/boot/dts/ti/Makefile line 6
Quoted 4 lines
arch/arm/boot/dts/ti/Makefile +2
-0+ $(call if_changed_dep,dtc) + clean-files += *.dtboGr{oetje,eeting}s,
Geert
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [RFC 05/13] ARM: dts: ti: add support for building .dtb files containing symbols
In reply to Geert UytterhoevenQuoted 24 lines · Geert Uytterhoeven
Hi Tero,
Quoted 5 lines · Tero Kristo
Symbols in the DTB files are needed so that overlays can be applied properly. Add support for building TI SoC specific .dtb files, the source is fetched from parent directory.
Signed-off-by Tero Kristo <[email protected]>Thanks for your patch!
arch/arm/boot/dts/ti/Makefile line 1
Quoted 10 lines
--- arch/arm/boot/dts/ti/Makefile | 5 +++++ 1 file changed, 5 insertions(+)arch/arm/boot/dts/ti/Makefile +1
-0@@ -1 +1,6 @@ +DTC_FLAGS += -@ -Wno-reg_format -Wno-avoid_default_addr_sizeWhy the -W options?
Quoted 4 lines
arch/arm/boot/dts/ti/Makefile line 3
Quoted 2 lines
arch/arm/boot/dts/ti/Makefile +2
-0+ +$(obj)/%.dtb: $(src)/../%.dts FORCEI guess you want a dependency on $(DTC), too?
I think that is handled globally already. I did a fix not to long ago.
Rob
Re: [RFC 05/13] ARM: dts: ti: add support for building .dtb files containing symbols
Quoted 26 lines · Rob Herring
Quoted 24 lines · Geert Uytterhoeven
Hi Tero,
Quoted 5 lines · Tero Kristo
Symbols in the DTB files are needed so that overlays can be applied properly. Add support for building TI SoC specific .dtb files, the source is fetched from parent directory.
Signed-off-by Tero Kristo <[email protected]>Thanks for your patch!
arch/arm/boot/dts/ti/Makefile line 1
Quoted 10 lines
--- arch/arm/boot/dts/ti/Makefile | 5 +++++ 1 file changed, 5 insertions(+)arch/arm/boot/dts/ti/Makefile +1
-0@@ -1 +1,6 @@ +DTC_FLAGS += -@ -Wno-reg_format -Wno-avoid_default_addr_sizeWhy the -W options?
Quoted 6 lines
Quoted 4 lines
arch/arm/boot/dts/ti/Makefile line 3
Quoted 2 lines
arch/arm/boot/dts/ti/Makefile +2
-0+ +$(obj)/%.dtb: $(src)/../%.dts FORCEI guess you want a dependency on $(DTC), too?
I think that is handled globally already. I did a fix not to long ago.
Globally it is handled, but as you see this is a special rule under the TI SoC specific makefile. This is building the .dts files under arch/arm/boot/dts/* into arch/arm/boot/dts/ti/ containing the symbol info (-@ flag for DTC.)
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [RFC 05/13] ARM: dts: ti: add support for building .dtb files containing symbols
Quoted 40 lines · Tero Kristo
Quoted 39 lines · Rob Herring
Quoted 34 lines · Geert Uytterhoeven
Hi Tero,
Quoted 6 lines · Tero Kristo
Symbols in the DTB files are needed so that overlays can be applied properly. Add support for building TI SoC specific .dtb files, the source is fetched from parent directory.
Signed-off-by Tero Kristo <[email protected]>Thanks for your patch!
arch/arm/boot/dts/ti/Makefile line 1
Quoted 11 lines
--- arch/arm/boot/dts/ti/Makefile | 5 +++++ 1 file changed, 5 insertions(+)arch/arm/boot/dts/ti/Makefile +1
-0@@ -1 +1,6 @@ +DTC_FLAGS += -@ -Wno-reg_format -Wno-avoid_default_addr_sizeWhy the -W options?
arch/arm/boot/dts/ti/Makefile line 3
Quoted 2 lines
arch/arm/boot/dts/ti/Makefile +2
-0+ +$(obj)/%.dtb: $(src)/../%.dts FORCEI guess you want a dependency on $(DTC), too?
Quoted 7 lines
Quoted 1 line
I think that is handled globally already. I did a fix not to long ago.
Globally it is handled, but as you see this is a special rule under the TI SoC specific makefile. This is building the .dts files under
arch/arm/boot/dts/*intoarch/arm/boot/dts/ti/containing the symbol info (-@ flag for DTC.)
Ah, I see. That means we end up with 2 builds of the base dtbs, right? We need to not do that. Either we need to be able to set per dtb flags or set per directory flags and move the TI base dts files to /ti directory.
Rob
Re: [RFC 05/13] ARM: dts: ti: add support for building .dtb files containing symbols
Quoted 44 lines · Rob Herring
Quoted 43 lines · Tero Kristo
Quoted 40 lines · Rob Herring
Quoted 29 lines · Geert Uytterhoeven
Hi Tero,
Quoted 6 lines · Tero Kristo
Symbols in the DTB files are needed so that overlays can be applied properly. Add support for building TI SoC specific .dtb files, the source is fetched from parent directory.
Signed-off-by Tero Kristo <[email protected]>Thanks for your patch!
arch/arm/boot/dts/ti/Makefile line 1
Quoted 11 lines
--- arch/arm/boot/dts/ti/Makefile | 5 +++++ 1 file changed, 5 insertions(+)arch/arm/boot/dts/ti/Makefile +1
-0@@ -1 +1,6 @@ +DTC_FLAGS += -@ -Wno-reg_format -Wno-avoid_default_addr_sizeWhy the -W options?
Quoted 5 lines
arch/arm/boot/dts/ti/Makefile line 3
Quoted 2 lines
arch/arm/boot/dts/ti/Makefile +2
-0+ +$(obj)/%.dtb: $(src)/../%.dts FORCEI guess you want a dependency on $(DTC), too?
I think that is handled globally already. I did a fix not to long ago.
Quoted 6 lines
Quoted 4 lines
Globally it is handled, but as you see this is a special rule under the TI SoC specific makefile. This is building the .dts files under
arch/arm/boot/dts/*intoarch/arm/boot/dts/ti/containing the symbol info (-@ flag for DTC.)Ah, I see. That means we end up with 2 builds of the base dtbs, right?
Yes, thats intentional in this series.
Quoted 3 lines
We need to not do that. Either we need to be able to set per dtb flags or set per directory flags and move the TI base dts files to /ti directory.
Well, actually we kind of need two builds of the same file. One is for the base beagle-x15 board, which doesn't need any overlays, and as such, does not need the symbol info either. The other one needs symbol info, as it is used with applying overlays. The application of overlays can't be done without the symbol info.
If we force both builds to use symbols, then the resulting beagle-x15 DTB file is unnecessarily large (the size delta might be irrelevant in practice, but it is there; ~40 kilobytes in this case, or +50% increase in size.)
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
RFC 6/13 ARM: dts: am57xx-evm: add AM57xx-evm DT overlay
In reply to Tero KristoThe AM57xx-evm is an overlay on top of beagle-x15 board. This contains a display extension macro, and a few extra peripherals. Two versions of the evm are supported, the base evm and the latest rev A3 evm. A common overlay file is used for both boards.
--- arch/arm/boot/dts/ti/am57xx-evm-common.dtso | 175 ++++++++++++++++++++++++++++ arch/arm/boot/dts/ti/am57xx-evm-reva3.dtso | 11 ++ arch/arm/boot/dts/ti/am57xx-evm.dtso | 11 ++ 3 files changed, 197 insertions(+) create mode 100644 arch/arm/boot/dts/ti/am57xx-evm-common.dtso create mode 100644 arch/arm/boot/dts/ti/am57xx-evm-reva3.dtso create mode 100644 arch/arm/boot/dts/ti/am57xx-evm.dtso
arch/arm/boot/dts/ti/am57xx-evm-common.dtso new file +175 -0
@@ -0,0 +1,175 @@ +/dts-v1/; +/plugin/; +#include <dt-bindings/interrupt-controller/irq.h> +#include <dt-bindings/gpio/gpio.h> +#include <dt-bindings/input/input.h> + +/ { + fragment@101 { + target-path = "/"; + + __overlay__ { + compatible = "ti,am5728-evm", "ti,am572x-beagle-x15", "ti,am5728", "ti,dra742", "ti,dra74", "ti,dra7"; + model = "TI AM5728 EVM"; + + aliases { + display0 = "/display"; + display1 = "/connector"; + }; + + gpio_keys { + compatible = "gpio-keys"; + #address-cells = <1>; + #size-cells = <0>; + autorepeat; + + USER1 { + gpios = <&gpio2 23 GPIO_ACTIVE_LOW>; + label = "Up"; + linux,code = <KEY_UP>; + }; + + USER2 { + gpios = <&gpio2 25 GPIO_ACTIVE_LOW>; + label = "Down"; + linux,code = <KEY_DOWN>; + }; + + USER3 { + gpios = <&gpio2 28 GPIO_ACTIVE_LOW>; + label = "Left"; + linux,code = <KEY_LEFT>; + }; + + USER4 { + gpios = <&gpio2 24 GPIO_ACTIVE_LOW>; + label = "Right"; + linux,code = <KEY_RIGHT>; + }; + + USER5 { + gpios = <&gpio2 20 GPIO_ACTIVE_LOW>; + label = "Home"; + linux,code = <KEY_HOME>; + }; + }; + + lcd0: display { + compatible = "osddisplays,osd070t1718-19ts", "panel-dpi"; + backlight = <&lcd_bl>; + enable-gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>; + label = "lcd"; + + panel-timing { + clock-frequency = <33000000>; + de-active = <1>; + hactive = <800>; + hback-porch = <16>; + hfront-porch = <210>; + hsync-active = <0>; + hsync-len = <30>; + pixelclk-active = <1>; + vactive = <480>; + vback-porch = <10>; + vfront-porch = <22>; + vsync-active = <0>; + vsync-len = <13>; + }; + + port { + lcd_in: endpoint { + remote-endpoint = <&dpi_out>; + }; + }; + }; + + lcd_bl: backlight { + compatible = "pwm-backlight"; + brightness-levels = <0 243 245 247 249 251 252 253 255>; + default-brightness-level = <8>; + pwms = <&ehrpwm1 0 50000 0>; + }; + + com_3v6: fixedregulator-com_3v6 { + compatible = "regulator-fixed"; + regulator-name = "com_3v6"; + regulator-min-microvolt = <3600000>; + regulator-max-microvolt = <3600000>; + vin-supply = <&evm_5v0>; + regulator-always-on; + regulator-boot-on; + }; + + vmmcwl_fixed: fixedregulator-mmcwl { + compatible = "regulator-fixed"; + regulator-name = "vmmcwl_fixed"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + gpio = <&gpio5 8 GPIO_ACTIVE_HIGH>; + enable-active-high; + }; + }; + }; +}; + +&ehrpwm1 { + status = "okay"; +}; + +&epwmss1 { + status = "okay"; +}; + +&i2c5 { + clock-frequency = <400000>; + status = "okay"; + + pixcir_ts@5c { + compatible = "pixcir,pixcir_tangoc"; + attb-gpio = <&gpio2 4 GPIO_ACTIVE_HIGH>; + interrupt-parent = <&gpio2>; + interrupts = <4 0>; + reg = <0x5c>; + reset-gpio = <&gpio2 6 GPIO_ACTIVE_HIGH>; + touchscreen-size-x = <1024>; + touchscreen-size-y = <600>; + }; +}; + +&uart8 { + status = "okay"; +}; + +&dss { + ports { + #address-cells = <1>; + #size-cells = <0>; + + port { + reg = <0>; + + dpi_out: endpoint { + data-lines = <24>; + remote-endpoint = <&lcd_in>; + }; + }; + }; +}; + +&mmc3 { + status = "okay"; + vmmc-supply = <&com_3v6>; + vqmmc-supply = <&vmmcwl_fixed>; + bus-width = <4>; + cap-power-off-card; + keep-power-in-suspend; + non-removable; + #address-cells = <1>; + #size-cells = <0>; + wlcore: wlcore@2 { + compatible = "ti,wl1835"; + reg = <2>; + interrupt-parent = <&gpio5>; + interrupts = <7 IRQ_TYPE_EDGE_RISING>; + }; +};
arch/arm/boot/dts/ti/am57xx-evm-reva3.dtso new file +11 -0
@@ -0,0 +1,11 @@ +/dts-v1/; +/plugin/; + +&mmc3 { + pinctrl-names = "default", "hs", "sdr12", "sdr25", "sdr50"; + pinctrl-0 = <&mmc3_pins_default>; + pinctrl-1 = <&mmc3_pins_hs>; + pinctrl-2 = <&mmc3_pins_sdr12>; + pinctrl-3 = <&mmc3_pins_sdr25>; + pinctrl-4 = <&mmc3_pins_sdr50 &mmc3_iodelay_manual1_rev20_conf>; +};
arch/arm/boot/dts/ti/am57xx-evm.dtso new file +11 -0
@@ -0,0 +1,11 @@ +/dts-v1/; +/plugin/; + +&mmc3 { + pinctrl-names = "default", "hs", "sdr12", "sdr25", "sdr50"; + pinctrl-0 = <&mmc3_pins_default>; + pinctrl-1 = <&mmc3_pins_hs>; + pinctrl-2 = <&mmc3_pins_sdr12>; + pinctrl-3 = <&mmc3_pins_sdr25>; + pinctrl-4 = <&mmc3_pins_sdr50 &mmc3_iodelay_manual1_rev11_conf>; +};
Signature · 4 lines
1.9.1 -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [RFC 06/13] ARM: dts: am57xx-evm: add AM57xx-evm DT overlay
Quoted 22 lines · Tero Kristo
The AM57xx-evm is an overlay on top of beagle-x15 board. This contains a display extension macro, and a few extra peripherals. Two versions of the evm are supported, the base evm and the latest rev A3 evm. A common overlay file is used for both boards.
Signed-off-by Tero Kristo <[email protected]>--- arch/arm/boot/dts/ti/am57xx-evm-common.dtso | 175 ++++++++++++++++++++++++++++ arch/arm/boot/dts/ti/am57xx-evm-reva3.dtso | 11 ++ arch/arm/boot/dts/ti/am57xx-evm.dtso | 11 ++ 3 files changed, 197 insertions(+) create mode 100644 arch/arm/boot/dts/ti/am57xx-evm-common.dtso create mode 100644 arch/arm/boot/dts/ti/am57xx-evm-reva3.dtso create mode 100644 arch/arm/boot/dts/ti/am57xx-evm.dtsoarch/arm/boot/dts/ti/am57xx-evm-common.dtso new file +1
-0@@ -0,0 +1,175 @@ +/dts-v1/;
arch/arm/boot/dts/ti/am57xx-evm-common.dtso line 11
Quoted 10 lines
arch/arm/boot/dts/ti/am57xx-evm-common.dtso new file +10
-0+/plugin/; +#include <dt-bindings/interrupt-controller/irq.h> +#include <dt-bindings/gpio/gpio.h> +#include <dt-bindings/input/input.h> + +/ { + fragment@101 { + target-path = "/"; + + __overlay__ {
It would be good to have "scripts/dtc: Correct overlay syntactic sugar for generating target-path fragments" in the kernel's copy of dtc, so this section can be converted to sugar syntax, too.
Gr{oetje,eeting}s,
Geert
Signature · 5 lines
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected] In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Re: [RFC 06/13] ARM: dts: am57xx-evm: add AM57xx-evm DT overlay
Quoted 29 lines · Geert Uytterhoeven
Quoted 28 lines · Tero Kristo
The AM57xx-evm is an overlay on top of beagle-x15 board. This contains a display extension macro, and a few extra peripherals. Two versions of the evm are supported, the base evm and the latest rev A3 evm. A common overlay file is used for both boards.
Signed-off-by Tero Kristo <[email protected]>--- arch/arm/boot/dts/ti/am57xx-evm-common.dtso | 175 ++++++++++++++++++++++++++++ arch/arm/boot/dts/ti/am57xx-evm-reva3.dtso | 11 ++ arch/arm/boot/dts/ti/am57xx-evm.dtso | 11 ++ 3 files changed, 197 insertions(+)create mode 100644
arch/arm/boot/dts/ti/am57xx-evm-common.dtsocreate mode 100644arch/arm/boot/dts/ti/am57xx-evm-reva3.dtsocreate mode 100644arch/arm/boot/dts/ti/am57xx-evm.dtsoarch/arm/boot/dts/ti/am57xx-evm-common.dtso new file +7
-0@@ -0,0 +1,175 @@ +/dts-v1/; +/plugin/; +#include <dt-bindings/interrupt-controller/irq.h> +#include <dt-bindings/gpio/gpio.h> +#include <dt-bindings/input/input.h> + +/ {
Quoted 8 lines
arch/arm/boot/dts/ti/am57xx-evm-common.dtso line 11
Quoted 4 lines
arch/arm/boot/dts/ti/am57xx-evm-common.dtso new file +4
-0+ fragment@101 { + target-path = "/"; + + __overlay__ {It would be good to have "
scripts/dtc: Correct overlay syntactic sugar for generating target-path fragments" in the kernel's copy of dtc, so this section can be converted to sugar syntax, too.
Ah yea, that seems to be a recent patch I've missed, but yes, if that fixes this limitation, it would be a great addition.
-Tero
Quoted 6 lines
Gr{oetje,eeting}s,
Geert
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [RFC 06/13] ARM: dts: am57xx-evm: add AM57xx-evm DT overlay
As already requested, can you *all* please use my [email protected] address for this stuff please, and not [email protected] - it's screwing up my mailboxes. Thanks.
Quoted 53 lines · Tero Kristo
Quoted 29 lines · Geert Uytterhoeven
Quoted 28 lines · Tero Kristo
The AM57xx-evm is an overlay on top of beagle-x15 board. This contains a display extension macro, and a few extra peripherals. Two versions of the evm are supported, the base evm and the latest rev A3 evm. A common overlay file is used for both boards.
Signed-off-by Tero Kristo <[email protected]>--- arch/arm/boot/dts/ti/am57xx-evm-common.dtso | 175 ++++++++++++++++++++++++++++ arch/arm/boot/dts/ti/am57xx-evm-reva3.dtso | 11 ++ arch/arm/boot/dts/ti/am57xx-evm.dtso | 11 ++ 3 files changed, 197 insertions(+) create mode 100644 arch/arm/boot/dts/ti/am57xx-evm-common.dtso create mode 100644 arch/arm/boot/dts/ti/am57xx-evm-reva3.dtso create mode 100644 arch/arm/boot/dts/ti/am57xx-evm.dtsoarch/arm/boot/dts/ti/am57xx-evm-common.dtso new file +7
-0@@ -0,0 +1,175 @@ +/dts-v1/; +/plugin/; +#include <dt-bindings/interrupt-controller/irq.h> +#include <dt-bindings/gpio/gpio.h> +#include <dt-bindings/input/input.h> + +/ {Quoted 8 lines
arch/arm/boot/dts/ti/am57xx-evm-common.dtso line 11
Quoted 4 lines
arch/arm/boot/dts/ti/am57xx-evm-common.dtso new file +4
-0+ fragment@101 { + target-path = "/"; + + __overlay__ {It would be good to have "
scripts/dtc: Correct overlay syntactic sugar for generating target-path fragments" in the kernel's copy of dtc, so this section can be converted to sugar syntax, too.Ah yea, that seems to be a recent patch I've missed, but yes, if that fixes this limitation, it would be a great addition.
-Tero
Quoted 6 lines
Gr{oetje,eeting}s,
Geert
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Signature · 2 lines
Russell King ARM architecture Linux Kernel maintainer
Re: [RFC 06/13] ARM: dts: am57xx-evm: add AM57xx-evm DT overlay
Hi Russell,
Quoted 3 lines · Russell King
As already requested, can you *all* please use my [email protected] address for this stuff please, and not [email protected] - it's screwing up my mailboxes. Thanks.
I have no idea when you request that (sorry if I missed it), but your rmk address is all over the Linux kernel sources.
Gr{oetje,eeting}s,
Geert
Signature · 5 lines
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected] In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Re: [RFC 06/13] ARM: dts: am57xx-evm: add AM57xx-evm DT overlay
In reply to Geert UytterhoevenQuoted 29 lines · Geert Uytterhoeven
Quoted 28 lines · Tero Kristo
The AM57xx-evm is an overlay on top of beagle-x15 board. This contains a display extension macro, and a few extra peripherals. Two versions of the evm are supported, the base evm and the latest rev A3 evm. A common overlay file is used for both boards.
Signed-off-by Tero Kristo <[email protected]>--- arch/arm/boot/dts/ti/am57xx-evm-common.dtso | 175 ++++++++++++++++++++++++++++ arch/arm/boot/dts/ti/am57xx-evm-reva3.dtso | 11 ++ arch/arm/boot/dts/ti/am57xx-evm.dtso | 11 ++ 3 files changed, 197 insertions(+) create mode 100644 arch/arm/boot/dts/ti/am57xx-evm-common.dtso create mode 100644 arch/arm/boot/dts/ti/am57xx-evm-reva3.dtso create mode 100644 arch/arm/boot/dts/ti/am57xx-evm.dtsoarch/arm/boot/dts/ti/am57xx-evm-common.dtso new file +7
-0@@ -0,0 +1,175 @@ +/dts-v1/; +/plugin/; +#include <dt-bindings/interrupt-controller/irq.h> +#include <dt-bindings/gpio/gpio.h> +#include <dt-bindings/input/input.h> + +/ {
Quoted 8 lines
arch/arm/boot/dts/ti/am57xx-evm-common.dtso line 11
Quoted 4 lines
arch/arm/boot/dts/ti/am57xx-evm-common.dtso new file +4
-0+ fragment@101 { + target-path = "/"; + + __overlay__ {It would be good to have "
scripts/dtc: Correct overlay syntactic sugar for generating target-path fragments" in the kernel's copy of dtc, so this section can be converted to sugar syntax, too.
I'm planning to do a dtc update for 4.18 too. New warnings coming too. :)
Rob
Re: [RFC 06/13] ARM: dts: am57xx-evm: add AM57xx-evm DT overlay
In reply to Tero KristoQuoted 8 lines · Tero Kristo
The AM57xx-evm is an overlay on top of beagle-x15 board. This contains a display extension macro, and a few extra peripherals. Two versions of the evm are supported, the base evm and the latest rev A3 evm. A common overlay file is used for both boards.
Signed-off-by Tero Kristo <[email protected]>--- arch/arm/boot/dts/ti/am57xx-evm-common.dtso | 175 ++++++++++++++++++++++++++++
Why do this as an overlay? To what level is an AM57xx-evm functional using a beagle-x15 dtb?
Quoted 2 lines
arch/arm/boot/dts/ti/am57xx-evm-reva3.dtso | 11 ++ arch/arm/boot/dts/ti/am57xx-evm.dtso | 11 ++
I think I'd structure this as just the A3 is an overlay. Applying it will override everything in am57xx-evm.dtso, so what's the point to making users of both board variations apply an overlay. Plus, you could have only known the differences in the board revisions after you had both boards. That wouldn't work if you developed this as new boards appear.
Rob
Re: [RFC 06/13] ARM: dts: am57xx-evm: add AM57xx-evm DT overlay
Quoted 6 lines · Rob Herring
Quoted 5 lines · Tero Kristo
The AM57xx-evm is an overlay on top of beagle-x15 board. This contains a display extension macro, and a few extra peripherals. Two versions of the evm are supported, the base evm and the latest rev A3 evm. A common overlay file is used for both boards.
Quoted 6 lines
Quoted 3 lines
Signed-off-by Tero Kristo <[email protected]>--- arch/arm/boot/dts/ti/am57xx-evm-common.dtso | 175 ++++++++++++++++++++++++++++Why do this as an overlay? To what level is an AM57xx-evm functional using a beagle-x15 dtb?
Basically, am57xx-evm is just a beagle-x15 with an extension board physically plugged into it. If you don't add the am57xx-evm overlay, display (+ WLAN + some gpios) obviously don't work, but rest of the functionality does.
If you have an am57xx-evm, you can also unplug the extension board to get a plain beagle-x15 board as I did, I don't typically care about things like display / WLAN in my work.
Quoted 10 lines
Quoted 3 lines
arch/arm/boot/dts/ti/am57xx-evm-reva3.dtso | 11 ++ arch/arm/boot/dts/ti/am57xx-evm.dtso | 11 ++I think I'd structure this as just the A3 is an overlay. Applying it will override everything in am57xx-evm.dtso, so what's the point to making users of both board variations apply an overlay. Plus, you could have only known the differences in the board revisions after you had both boards. That wouldn't work if you developed this as new boards appear.
Well, beagle-x15 is still the base board for both, and different revisions of those also. The changes are relatively minor, but they are there. But yes, different hierarchies for these could be applied.
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [RFC 06/13] ARM: dts: am57xx-evm: add AM57xx-evm DT overlay
Quoted 19 lines · Tero Kristo
Quoted 8 lines · Rob Herring
Quoted 6 lines · Tero Kristo
The AM57xx-evm is an overlay on top of beagle-x15 board. This contains a display extension macro, and a few extra peripherals. Two versions of the evm are supported, the base evm and the latest rev A3 evm. A common overlay file is used for both boards.
Quoted 8 lines
Quoted 4 lines
Signed-off-by Tero Kristo <[email protected]>--- arch/arm/boot/dts/ti/am57xx-evm-common.dtso | 175++++++++++++++++++++++++++++
Why do this as an overlay? To what level is an AM57xx-evm functional using a beagle-x15 dtb?
Quoted 8 lines
Basically, am57xx-evm is just a beagle-x15 with an extension board physically plugged into it. If you don't add the am57xx-evm overlay, display (+ WLAN + some gpios) obviously don't work, but rest of the functionality does.
If you have an am57xx-evm, you can also unplug the extension board to get a plain beagle-x15 board as I did, I don't typically care about things like display / WLAN in my work.
Okay, makes sense, but the naming convention doesn't really convey these details. I guess users of the boards would understand this.
Quoted 12 lines
Quoted 10 lines
Quoted 2 lines
arch/arm/boot/dts/ti/am57xx-evm-reva3.dtso | 11 ++ arch/arm/boot/dts/ti/am57xx-evm.dtso | 11 ++I think I'd structure this as just the A3 is an overlay. Applying it will override everything in am57xx-evm.dtso, so what's the point to making users of both board variations apply an overlay. Plus, you could have only known the differences in the board revisions after you had both boards. That wouldn't work if you developed this as new boards appear.
Quoted 3 lines
Well, beagle-x15 is still the base board for both, and different revisions of those also. The changes are relatively minor, but they are there. But yes, different hierarchies for these could be applied.
My point is that if you have 2 revisions of a given board, at some point in time there was only 1 revision of that board. So you have a dtb for that revision. Then a new revision comes out. You should not be refactoring the existing dtbs based on what changed in the new revision such that you have the common bits, rev 1 overlay and rev 2 overlay. Instead, make a rev 1 to rev 2 overlay.
Now if you have 2 different revisions in parallel that's a different story. For example, if the beagle-x15 is stuffed differently for use with the EVM vs. standalone.
Rob
RFC 7/13 ARM: dts: ti: add camera overlays
In reply to Tero KristoFrom: Benoit Parrot <[email protected]>
Add two different camera overlays for am57xx-evm, mt9t111 and ov10635.
--- arch/arm/boot/dts/ti/mt9t111.dtso | 44 ++++++++++++++++++++++++ arch/arm/boot/dts/ti/ov10635.dtso | 71 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 115 insertions(+) create mode 100644 arch/arm/boot/dts/ti/mt9t111.dtso create mode 100644 arch/arm/boot/dts/ti/ov10635.dtso
arch/arm/boot/dts/ti/mt9t111.dtso new file +44 -0
@@ -0,0 +1,44 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2015-2018 Texas Instruments Incorporated - http://www.ti.com/ + */ + +/dts-v1/; +/plugin/; +#include <dt-bindings/gpio/gpio.h> + +&i2c5 { + mt9t11x@3C { + compatible = "aptina,mt9t111"; + bufen-gpios = <&gpio5 12 GPIO_ACTIVE_LOW>; + camen-gpios = <&gpio6 11 GPIO_ACTIVE_LOW>; + oscen-gpios = <&gpio5 10 GPIO_ACTIVE_HIGH>; + powerdown-gpios = <&gpio5 11 GPIO_ACTIVE_LOW>; + reg = <0x3C>; + reset-gpios = <&gpio4 17 GPIO_ACTIVE_LOW>; + + port { + cam: endpoint { + hsync-active = <1>; + input-clock-freq = <32000000>; + pclk-sample = <0>; + pixel-clock-freq = <96000000>; + remote-endpoint = <&vin3a>; + vsync-active = <0>; + }; + }; + }; +}; + +&vin3a { + status = "okay"; + + endpoint { + remote-endpoint = <&cam>; + slave-mode; + }; +}; + +&vip2 { + status = "okay"; +};
arch/arm/boot/dts/ti/ov10635.dtso new file +71 -0
71 lines not on this page · raw message
Signature · 4 lines
1.9.1 -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
RFC 8/13 ARM: dts: ti: add dra71-evm overlays
In reply to Tero KristoAdd dra71-evm overlay files. There are two overlays available, the gpmc and the display ones. These are mutually exclusive, as they share certain hardware resources.
--- .../boot/dts/ti/dra71-evm-lcd-auo-g101evn01.0.dtso | 121 +++++++++++++++++++++ arch/arm/boot/dts/ti/dra71-evm-nand.dtso | 6 + 2 files changed, 127 insertions(+) create mode 100644 arch/arm/boot/dts/ti/dra71-evm-lcd-auo-g101evn01.0.dtso create mode 100644 arch/arm/boot/dts/ti/dra71-evm-nand.dtso
arch/arm/boot/dts/ti/dra71-evm-lcd-auo-g101evn01.0.dtso new file +121 -0
@@ -0,0 +1,121 @@ +/dts-v1/; +/plugin/; +#include <dt-bindings/interrupt-controller/irq.h> +#include <dt-bindings/gpio/gpio.h> + +/ { + fragment@101 { + target-path = "/"; + + __overlay__ { + model = "TI DRA71 EVM-LCD-AUO-Display"; + + aliases { + display0 = "/display"; + display1 = "/connector"; + }; + + backlight { + compatible = "led-backlight"; + brightness-levels = <0 2 38 74 110 146 182 218 255>; + default-brightness-level = <8>; + enable-gpios = <&pcf_display_board 0 GPIO_ACTIVE_LOW>; + leds = <&backlight_led>; + }; + + lcd: display { + compatible = "auo,g101evn01.0", "panel-dpi"; + enable-gpios = <&pcf_lcd 13 GPIO_ACTIVE_LOW>; + label = "lcd"; + + panel-timing { + clock-frequency = <68930000>; + de-active = <1>; + hactive = <1280>; + hback-porch = <48>; + hfront-porch = <48>; + hsync-active = <0>; + hsync-len = <32>; + pixelclk-active = <1>; + vactive = <800>; + vback-porch = <8>; + vfront-porch = <4>; + vsync-active = <0>; + vsync-len = <4>; + }; + + port { + lcd_in: endpoint { + remote-endpoint = <&dpi_out>; + }; + }; + }; + }; + }; +}; + +&pcf_gpio_21 { + p0 { + gpio-hog; + gpios = <0 GPIO_ACTIVE_HIGH>; + line-name = "sel_gpmc_ad_vid_s0"; + output-low; + }; + + p7 { + gpio-hog; + gpios = <7 GPIO_ACTIVE_HIGH>; + line-name = "sel_gpmc_ad_vid_s2"; + output-high; + }; +}; + +&i2c1 { + pcf_display_board: gpio@27 { + compatible = "nxp,pcf8575"; + #gpio-cells = <2>; + gpio-controller; + reg = <0x27>; + }; + + tlc59108@40 { + compatible = "ti,tlc59108"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x40>; + + backlight_led: bl@2 { + label = "backlight"; + reg = <0x2>; + }; + }; + + touchscreen: goodix-gt9271@14 { + compatible = "goodix,gt9271"; + interrupt-parent = <&gpio1>; + interrupts = <15 IRQ_TYPE_LEVEL_HIGH>; + irq-gpios = <&pcf_display_board 6 GPIO_ACTIVE_HIGH>; + reg = <0x14>; + reset-gpios = <&pcf_display_board 5 GPIO_ACTIVE_LOW>; + status = "okay"; + touchscreen-inverted-y; + touchscreen-size-x = <1280>; + touchscreen-size-y = <800>; + }; +}; + +&dss { + ports { + #address-cells = <1>; + #size-cells = <0>; + + dss_port: port { + reg = <2>; + + dpi_out: endpoint { + data-lines = <24>; + remote-endpoint = <&lcd_in>; + }; + }; + }; +};
arch/arm/boot/dts/ti/dra71-evm-nand.dtso new file +6 -0
@@ -0,0 +1,6 @@ +/dts-v1/; +/plugin/; + +&gpmc { + status = "okay"; +};
Signature · 4 lines
1.9.1 -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
RFC 9/13 kbuild: add support for generating FIT images
In reply to Tero KristoFIT images are built with the mkimage tool, from source description similar to that of DT files. There are a few FIT image generation specifics that must be noted with this patch.
The dependency generation for the FIT files requires some makefile magic, due to the build ordering; the dependency binaries must have been built before the FIT image itself, which is different from typical kernel build flow (source files are be built immediately and dependencies can be generated during build.) To use the generated dependency files, the user must manually include the local .itb-deps.d file in their makefile.
The PATH environment variable while calling the mkimage tool is tweaked to contain the local / user provided DTC as first item, so that the correct version of mkimage tool will be used. Otherwise, the build will use the system default DTC, or won't find the tool at all.
--- scripts/Makefile.lib | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+)
scripts/Makefile.lib +32 -0
@@ -295,6 +295,38 @@ $(obj)/%.dtbo: $(src)/%.dtso $(DTC) FORCE dtc-tmp = $(subst $(comma),_,$(dot-target).dts.tmp) +# FIT +# --------------------------------------------------------------------------- +define gen_itb_deps + @if [ -d $(obj) ] ; then \ + echo >> $(obj)/.itb-deps.d ; \ + echo "$(src)/$(patsubst %.its,%.itb,$(notdir $(1))): $(srctree)/$(src)/$(notdir $(1)) \\" >> $(obj)/.itb-deps.d ; \ + cat $(1) | grep incbin | cut -d "\"" -f 2 | awk '{ printf " $(src)/%s \\\n", $$1 }' | sed '$$s/ \\$$//' >> $(obj)/.itb-deps.d ; \ + fi + +endef + +$(obj)/.itb-deps.d: + @if [ -d $(obj) ] ; then \ + echo "$(src)/.itb-deps.d: $(src)/Makefile $(wildcard $(srctree)/$(src)/*.its)" > $(obj)/.itb-deps.d ; \ + echo >> $(obj)/.itb-deps.d ; \ + fi + $(foreach f,$(wildcard $(srctree)/$(src)/*.its),$(call gen_itb_deps,$f)) + +DTC_FLAGS_MKIMAGE = -I dts -O dtb -p 500 -Wno-unit_address_vs_reg \ + -i $(src) +ifneq ($(DTC),) + DTC_PATH=$(dir $(DTC)) +else + DTC_PATH=$(objtree)/scripts/dtc +endif + +quiet_cmd_mkdir = MKIMAGE -f $@ +cmd_mkfit = PATH="$(DTC_PATH):$(PATH)" $(MKIMAGE) -D "$(DTC_FLAGS_MKIMAGE)" -f $< $@ + +$(obj)/%.itb: $(src)/%.its FORCE + $(call cmd,mkfit) + # Bzip2 # ---------------------------------------------------------------------------
Signature · 4 lines
1.9.1 -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
RFC 10/13 ARM: dts: add FIT image build support for ARM architecture
In reply to Tero KristoAdd basic .itb build target for ARM architecture. FIT images generally contain the kernel and different DTB + overlay files, so an extra dependency is made towards zImage being available.
--- arch/arm/Makefile | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
arch/arm/Makefile +4 -1
@@ -343,11 +343,14 @@ $(BOOT_TARGETS): vmlinux $(INSTALL_TARGETS): $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $@ -%.dtb %.dtbo: dtbdir=$(patsubst %/,%,$(patsubst %./,%,$(boot)/dts/$(dir $@))) +%.dtb %.dtbo %.itb: dtbdir=$(patsubst %/,%,$(patsubst %./,%,$(boot)/dts/$(dir $@))) %.dtb %.dtbo: | scripts $(Q)$(MAKE) $(build)=$(dtbdir) MACHINE=$(MACHINE) $(boot)/dts/$@ +%.itb: | scripts zImage + $(Q)$(MAKE) $(build)=$(dtbdir) MACHINE=$(MACHINE) $(boot)/dts/$@ + PHONY += dtbs dtbs_install dtbs: prepare scripts
Signature · 4 lines
1.9.1 -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
RFC 11/13 ARM: dts: ti: add FIT image dependencies
In reply to Tero KristoAdd the local FIT image dependencies file to build. This allows building the FIT image dependency file before building the FIT image, and to build the dependencies themselves also next. Without this, none of the binaries required by the FIT image will be found.
Also, add the built FIT images to the clean targets.
--- arch/arm/boot/dts/ti/Makefile | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
arch/arm/boot/dts/ti/Makefile +3 -1
@@ -1,6 +1,8 @@ DTC_FLAGS += -@ -Wno-reg_format -Wno-avoid_default_addr_size +-include $(obj)/.itb-deps.d + $(obj)/%.dtb: $(src)/../%.dts FORCE $(call if_changed_dep,dtc) -clean-files += *.dtbo +clean-files += *.dtbo *.itb
Signature · 4 lines
1.9.1 -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
RFC 12/13 ARM: dts: ti: add dra71-evm FIT description file
In reply to Tero KristoAdd FIT image description file for dra71-evm, and the available configurations for it.
--- arch/arm/boot/dts/ti/dra71-evm.its | 62 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 62 insertions(+) create mode 100644 arch/arm/boot/dts/ti/dra71-evm.its
arch/arm/boot/dts/ti/dra71-evm.its new file +62 -0
@@ -0,0 +1,62 @@ +/dts-v1/; + +/ { + description = "DRA71x-evm"; + #address-cells = <1>; + + images { + kernel@1 { + description = "Linux kernel"; + data = /incbin/("../../zImage"); + type = "kernel"; + arch = "arm"; + os = "linux"; + compression = "none"; + load = <0x82000000>; + entry = <0x82000000>; + }; + fdt@1 { + description = "DRA71x-evm"; + data = /incbin/("dra71-evm.dtb"); + type = "flat_dt"; + arch = "arm"; + compression = "none"; + load = <0x83000000>; + }; + fdt@2 { + description = "DRA71x-evm LCD"; + data = /incbin/("dra71-evm-lcd-auo-g101evn01.0.dtbo"); + type = "flat_dt"; + arch = "arm"; + compression = "none"; + load = <0x83100000>; + }; + fdt@3 { + description = "DRA71x-evm NAND"; + data = /incbin/("dra71-evm-nand.dtbo"); + type = "flat_dt"; + arch = "arm"; + compression = "none"; + load = <0x83200000>; + }; + }; + + configurations { + default = "dra71-evm"; + dra71-evm { + description = "DRA71x-evm"; + kernel = "kernel@1"; + fdt = "fdt@1"; + }; + dra71-evm-lcd-auo-g101evn01.0 { + description = "DRA71x-evm with LCD overlay"; + kernel = "kernel@1"; + fdt = "fdt@1", "fdt@2"; + }; + dra71-evm-nand { + description = "DRA71x-evm with NAND overlay"; + kernel = "kernel@1"; + fdt = "fdt@1", "fdt@3"; + }; + }; +};
Signature · 4 lines
1.9.1 -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file
Quoted 65 lines · Tero Kristo
Add FIT image description file for dra71-evm, and the available configurations for it.
Signed-off-by Tero Kristo <[email protected]>--- arch/arm/boot/dts/ti/dra71-evm.its | 62 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 62 insertions(+) create mode 100644 arch/arm/boot/dts/ti/dra71-evm.itsarch/arm/boot/dts/ti/dra71-evm.its new file +50
-0@@ -0,0 +1,62 @@ +/dts-v1/; + +/ { + description = "DRA71x-evm"; + #address-cells = <1>; + + images { + kernel@1 { + description = "Linux kernel"; + data = /incbin/("../../zImage"); + type = "kernel"; + arch = "arm"; + os = "linux"; + compression = "none"; + load = <0x82000000>; + entry = <0x82000000>; + }; + fdt@1 { + description = "DRA71x-evm"; + data = /incbin/("dra71-evm.dtb"); + type = "flat_dt"; + arch = "arm"; + compression = "none"; + load = <0x83000000>; + }; + fdt@2 { + description = "DRA71x-evm LCD"; + data = /incbin/("dra71-evm-lcd-auo-g101evn01.0.dtbo"); + type = "flat_dt"; + arch = "arm"; + compression = "none"; + load = <0x83100000>; + }; + fdt@3 { + description = "DRA71x-evm NAND"; + data = /incbin/("dra71-evm-nand.dtbo"); + type = "flat_dt"; + arch = "arm"; + compression = "none"; + load = <0x83200000>; + }; + }; + + configurations { + default = "dra71-evm"; + dra71-evm { + description = "DRA71x-evm"; + kernel = "kernel@1"; + fdt = "fdt@1"; + };
arch/arm/boot/dts/ti/dra71-evm.its line 60
Quoted 10 lines
arch/arm/boot/dts/ti/dra71-evm.its new file +10
-0+ dra71-evm-lcd-auo-g101evn01.0 { + description = "DRA71x-evm with LCD overlay"; + kernel = "kernel@1"; + fdt = "fdt@1", "fdt@2"; + }; + dra71-evm-nand { + description = "DRA71x-evm with NAND overlay"; + kernel = "kernel@1"; + fdt = "fdt@1", "fdt@3"; + };
This strikes me as really horrid and inflexible.
Consider a platform where you have multiple choices, each one independent - for example, you may have the selection of two base DT files depending on the SoC. Then you may have four board-level DT overlays to choose from. Then you may have a selection of overlays depending on what hardware is connected (eg, whether a camera is connected and what type of camera, whether a LVDS panel is connected and what it is, etc.)
Before considering the optional hardware, you already have 8 different combinations, and that multiplies up each time there is another variable to consider.
Exhaustively listing each combination of kernel, base dtb and overlays is not practical in such a scenario, and if this is what FIT requires, FIT is not fit for purpose.
Signature · 1 line
Russell King
Re: [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file
Quoted 87 lines · Russell King
Quoted 65 lines · Tero Kristo
Add FIT image description file for dra71-evm, and the available configurations for it.
Signed-off-by Tero Kristo <[email protected]>--- arch/arm/boot/dts/ti/dra71-evm.its | 62 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 62 insertions(+)create mode 100644
arch/arm/boot/dts/ti/dra71-evm.itsarch/arm/boot/dts/ti/dra71-evm.its new file +50
-0@@ -0,0 +1,62 @@ +/dts-v1/; + +/ { + description = "DRA71x-evm"; + #address-cells = <1>; + + images { + kernel@1 { + description = "Linux kernel"; + data = /incbin/("../../zImage"); + type = "kernel"; + arch = "arm"; + os = "linux"; + compression = "none"; + load = <0x82000000>; + entry = <0x82000000>; + }; + fdt@1 { + description = "DRA71x-evm"; + data = /incbin/("dra71-evm.dtb"); + type = "flat_dt"; + arch = "arm"; + compression = "none"; + load = <0x83000000>; + }; + fdt@2 { + description = "DRA71x-evm LCD"; + data = /incbin/("dra71-evm-lcd-auo-g101evn01.0.dtbo"); + type = "flat_dt"; + arch = "arm"; + compression = "none"; + load = <0x83100000>; + }; + fdt@3 { + description = "DRA71x-evm NAND"; + data = /incbin/("dra71-evm-nand.dtbo"); + type = "flat_dt"; + arch = "arm"; + compression = "none"; + load = <0x83200000>; + }; + }; + + configurations { + default = "dra71-evm"; + dra71-evm { + description = "DRA71x-evm"; + kernel = "kernel@1"; + fdt = "fdt@1"; + };arch/arm/boot/dts/ti/dra71-evm.its line 60
Quoted 10 lines
arch/arm/boot/dts/ti/dra71-evm.its new file +10
-0+ dra71-evm-lcd-auo-g101evn01.0 { + description = "DRA71x-evm with LCD overlay"; + kernel = "kernel@1"; + fdt = "fdt@1", "fdt@2"; + }; + dra71-evm-nand { + description = "DRA71x-evm with NAND overlay"; + kernel = "kernel@1"; + fdt = "fdt@1", "fdt@3"; + };This strikes me as really horrid and inflexible.
Consider a platform where you have multiple choices, each one independent - for example, you may have the selection of two base DT files depending on the SoC. Then you may have four board-level DT overlays to choose from. Then you may have a selection of overlays depending on what hardware is connected (eg, whether a camera is connected and what type of camera, whether a LVDS panel is connected and what it is, etc.)
Quoted 8 lines
Before considering the optional hardware, you already have 8 different combinations, and that multiplies up each time there is another variable to consider.
Exhaustively listing each combination of kernel, base dtb and overlays is not practical in such a scenario, and if this is what FIT requires, FIT is not fit for purpose.
This specific dra71-evm is rather a poor example, as we have built the available configs as separate config entries due to limited amount of them.
In typical setup, you can boot a large number of different configs via:
bootm 0x82000000#dra71-evm#nand#lcd-auo-g101evn01.0
... assuming the configs were named like that, and assuming they would be compatible with each other. The am57xx-evm example provided is better, as you can chain the different cameras to the available evm configs.
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file
Quoted 7 lines · Tero Kristo
In typical setup, you can boot a large number of different configs via:
bootm 0x82000000#dra71-evm#nand#lcd-auo-g101evn01.0
... assuming the configs were named like that, and assuming they would be compatible with each other. The am57xx-evm example provided is better, as you can chain the different cameras to the available evm configs.
Why not just do it in the bootloader to put together the dtb?
Then for external devices, you could just pass info on the kernel cmdline with lcd=foo camera=bar if they cannot be detected over I2C.
Regards,
Tony
RFC 12/13 ARM: dts: ti: add dra71-evm FIT description file
Quoted 9 lines · Tony Lindgren
Quoted 7 lines · Tero Kristo
In typical setup, you can boot a large number of different configs via:
bootm 0x82000000#dra71-evm#nand#lcd-auo-g101evn01.0
... assuming the configs were named like that, and assuming they would be compatible with each other. The am57xx-evm example provided is better, as you can chain the different cameras to the available evm configs.
Quoted 5 lines
Why not just do it in the bootloader to put together the dtb?
Then for external devices, you could just pass info on the kernel cmdline with lcd=foo camera=bar if they cannot be detected over I2C.
(Added Linux ARM list to CC, this was not part of the original delivery.)
Ok trying to resurrect this thread a bit. Is there any kind of consensus how things like this should be handled? Should we add the DT overlay files to kernel tree or not?
Should we add any kind of build infra to kernel tree, and at what level would this be? Just DT overlay file building support, and drop the FIT build support as was proposed in this RFC series or...?
U-boot can obviously parse the base DTB + overlay DTB:s into a single DTB, but this is somewhat clumsy approach and is relatively error prone to get it right.
Building the FIT image post kernel build would also be possible, but who would be doing this, is there any need to get this done in generic manner or shall we just add SoC vendor specific tools for this?
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Rob Herring
maintainerRFC 12/13 ARM: dts: ti: add dra71-evm FIT description file
Quoted 16 lines · Tero Kristo
Quoted 9 lines · Tony Lindgren
Quoted 7 lines · Tero Kristo
In typical setup, you can boot a large number of different configs via:
bootm 0x82000000#dra71-evm#nand#lcd-auo-g101evn01.0
... assuming the configs were named like that, and assuming they would be compatible with each other. The am57xx-evm example provided is better, as you can chain the different cameras to the available evm configs.
Quoted 5 lines
Why not just do it in the bootloader to put together the dtb?
Then for external devices, you could just pass info on the kernel cmdline with lcd=foo camera=bar if they cannot be detected over I2C.
Quoted 5 lines
(Added Linux ARM list to CC, this was not part of the original delivery.)
Ok trying to resurrect this thread a bit. Is there any kind of consensus how things like this should be handled? Should we add the DT overlay files to kernel tree or not?
IMO, yes.
Quoted 3 lines
Should we add any kind of build infra to kernel tree, and at what level would this be? Just DT overlay file building support, and drop the FIT build support as was proposed in this RFC series or...?
I think I mentioned this already, but I expect that this is going to cause a number of conversions of dtsi + dtsi -> dtb into base dts and overlay(s) dts files. In doing so, we still need to be able to build the original, full dtb.
Quoted 3 lines
U-boot can obviously parse the base DTB + overlay DTB:s into a single DTB, but this is somewhat clumsy approach and is relatively error prone to get it right.
Why? How is the kernel better?
Quoted 3 lines
Building the FIT image post kernel build would also be possible, but who would be doing this, is there any need to get this done in generic manner or shall we just add SoC vendor specific tools for this?
I'll tell you up front, I'm not a fan of FIT image (nor uImage, Android boot image, $bootloader image). If you want a collection of files and some configuration data, use a filesystem and a text file.
Rob
RFC 12/13 ARM: dts: ti: add dra71-evm FIT description file
Quoted 25 lines · Rob Herring
Quoted 16 lines · Tero Kristo
Quoted 9 lines · Tony Lindgren
Quoted 7 lines · Tero Kristo
In typical setup, you can boot a large number of different configs via:
bootm 0x82000000#dra71-evm#nand#lcd-auo-g101evn01.0
... assuming the configs were named like that, and assuming they would be compatible with each other. The am57xx-evm example provided is better, as you can chain the different cameras to the available evm configs.
Quoted 5 lines
Why not just do it in the bootloader to put together the dtb?
Then for external devices, you could just pass info on the kernel cmdline with lcd=foo camera=bar if they cannot be detected over I2C.
Quoted 5 lines
(Added Linux ARM list to CC, this was not part of the original delivery.)
Ok trying to resurrect this thread a bit. Is there any kind of consensus how things like this should be handled? Should we add the DT overlay files to kernel tree or not?
IMO, yes.
Quoted 8 lines
Quoted 3 lines
Should we add any kind of build infra to kernel tree, and at what level would this be? Just DT overlay file building support, and drop the FIT build support as was proposed in this RFC series or...?
I think I mentioned this already, but I expect that this is going to cause a number of conversions of dtsi + dtsi -> dtb into base dts and overlay(s) dts files. In doing so, we still need to be able to build the original, full dtb.
So you mean like breaking apart the existing .dts files? Are there any plans to get that done (I know the android folks talk about this but I don't like their idea.) If we do the split, how are we going to determine which dts + overlay files are required to get a specific DTB done? I actually wrote a tool for this purpose which parses the FIT image configurations and generates plain dtb files out of the info there if needed, but assuming FIT is abandoned then what...?
Quoted 6 lines
Quoted 4 lines
U-boot can obviously parse the base DTB + overlay DTB:s into a single DTB, but this is somewhat clumsy approach and is relatively error prone to get it right.
Why? How is the kernel better?
I am mostly speaking about runtime applying of the overlays. If done build time, it is obviously on same level. If you apply the base DTS + overlays from u-boot prompt, it is not too much fun, and if there are any failures it just won't work, but don't really tell you why not.
Quoted 8 lines
Quoted 4 lines
Building the FIT image post kernel build would also be possible, but who would be doing this, is there any need to get this done in generic manner or shall we just add SoC vendor specific tools for this?
I'll tell you up front, I'm not a fan of FIT image (nor uImage, Android boot image, $bootloader image). If you want a collection of files and some configuration data, use a filesystem and a text file.
Ok, thanks for your frank comments. I believe based on this feedback I'll try to modify this series into bare minimal overlay support to kernel, and have the post processing done elsewhere (either u-boot build or possibly completely separate tool.)
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Rob Herring
maintainerRFC 12/13 ARM: dts: ti: add dra71-evm FIT description file
Quoted 48 lines · Tero Kristo
Quoted 41 lines · Rob Herring
Quoted 23 lines · Tero Kristo
Quoted 14 lines · Tony Lindgren
Quoted 10 lines · Tero Kristo
In typical setup, you can boot a large number of different configs via:
bootm 0x82000000#dra71-evm#nand#lcd-auo-g101evn01.0
... assuming the configs were named like that, and assuming they would be
compatible with each other. The am57xx-evm example provided is better, as
you can chain the different cameras to the available evm configs.Quoted 5 lines
Why not just do it in the bootloader to put together the dtb?
Then for external devices, you could just pass info on the kernel cmdline with lcd=foo camera=bar if they cannot be detected over I2C.
Quoted 6 lines
(Added Linux ARM list to CC, this was not part of the original delivery.)
Ok trying to resurrect this thread a bit. Is there any kind of consensus how
things like this should be handled? Should we add the DT overlay files to kernel tree or not?IMO, yes.
Quoted 4 lines
Should we add any kind of build infra to kernel tree, and at what level would this be? Just DT overlay file building support, and drop the FIT build
support as was proposed in this RFC series or...?Quoted 4 lines
I think I mentioned this already, but I expect that this is going to cause a number of conversions of dtsi + dtsi -> dtb into base dts and overlay(s) dts files. In doing so, we still need to be able to build the original, full dtb.
Quoted 7 lines
So you mean like breaking apart the existing .dts files? Are there any plans to get that done (I know the android folks talk about this but I don't like their idea.) If we do the split, how are we going to determine which dts + overlay files are required to get a specific DTB done? I actually wrote a tool for this purpose which parses the FIT image configurations and generates plain dtb files out of the info there if needed, but assuming FIT is abandoned then what...?
There aren't any plans that I'm aware of. I'm just assuming there are some cases in the tree. It would just be some additional build rules:
board-kit.dtb: soc-som.dtb expansion-board.dtbo
fdtoverlay -o $@ -i $^
We'd need to come up with some way to express the input and output files in a kbuild way. Perhaps similar to how multiple module files are done.
Even if you are adding new platforms, having the above would still be good. It captures what base the overlays apply to and tests that applying actually works (rather than leaving that for the user to do in the bootloader). FIT images also have or need that information, so perhaps we can define a format that works as input for both kbuild and FIT images.
Quoted 7 lines
Quoted 7 lines
Quoted 5 lines
U-boot can obviously parse the base DTB + overlay DTB:s into a single DTB,
but this is somewhat clumsy approach and is relatively error prone to get it
right.
Quoted 7 lines
Quoted 1 line
Why? How is the kernel better?
I am mostly speaking about runtime applying of the overlays. If done build time, it is obviously on same level. If you apply the base DTS + overlays from u-boot prompt, it is not too much fun, and if there are any failures it just won't work, but don't really tell you why not.
Runtime, but still at boot time, right?
How is the kernel going to have better error handling? Is libfdt error handling worse than the kernel's overlay code?
I do think we need to standardize how we tell bootloaders what overlays to apply. I expect that we'll do that as part of EBBR spec[1] though that is not part of the immediate focus.
Rob
RFC 12/13 ARM: dts: ti: add dra71-evm FIT description file
In reply to Tero KristoQuoted 7 lines · Tero Kristo
Quoted 6 lines · Rob Herring
Quoted 3 lines · Tero Kristo
Ok trying to resurrect this thread a bit. Is there any kind of consensus how things like this should be handled? Should we add the DT overlay files to kernel tree or not?
IMO, yes.
I too agree the overlay files should be in the kernel rather than people having to try to figure out where to find them.
No idea how we'll verify they'll build though :) Maybe we just need randconfig support for DT overlay files too?
Regards,
Tony
RFC 12/13 ARM: dts: ti: add dra71-evm FIT description file
In reply to Rob HerringQuoted 17 lines · Rob Herring
Quoted 16 lines · Tero Kristo
Quoted 14 lines · Tony Lindgren
Quoted 7 lines · Tero Kristo
In typical setup, you can boot a large number of different configs via:
bootm 0x82000000#dra71-evm#nand#lcd-auo-g101evn01.0
... assuming the configs were named like that, and assuming they would be compatible with each other. The am57xx-evm example provided is better, as you can chain the different cameras to the available evm configs.
Why not just do it in the bootloader to put together the dtb?
Then for external devices, you could just pass info on the kernel cmdline with lcd=foo camera=bar if they cannot be detected over I2C.
Quoted 7 lines
Quoted 5 lines
(Added Linux ARM list to CC, this was not part of the original delivery.)
Ok trying to resurrect this thread a bit. Is there any kind of consensus how things like this should be handled? Should we add the DT overlay files to kernel tree or not?
IMO, yes.
Agreed.
Quoted 16 lines
Quoted 4 lines
Should we add any kind of build infra to kernel tree, and at what level would this be? Just DT overlay file building support, and drop the FIT build support as was proposed in this RFC series or...?
I think I mentioned this already, but I expect that this is going to cause a number of conversions of dtsi + dtsi -> dtb into base dts and overlay(s) dts files. In doing so, we still need to be able to build the original, full dtb.
Quoted 3 lines
U-boot can obviously parse the base DTB + overlay DTB:s into a single DTB, but this is somewhat clumsy approach and is relatively error prone to get it right.
Why? How is the kernel better?
Quoted 7 lines
Quoted 3 lines
Building the FIT image post kernel build would also be possible, but who would be doing this, is there any need to get this done in generic manner or shall we just add SoC vendor specific tools for this?
I'll tell you up front, I'm not a fan of FIT image (nor uImage, Android boot image, $bootloader image). If you want a collection of files and some configuration data, use a filesystem and a text file.
My gut feel is that using a filesystem and a text file is the easier way to create the boot info. But that also makes applying the overlay(s) during early Linux boot (at the point of FDT unflattening) impractical (can't access the file system without a driver, the driver depends on the devicetree, the devicetree depends upon the overlay).
Quoted 3 lines
Rob
Russell King - ARM Linux
maintainerRFC 12/13 ARM: dts: ti: add dra71-evm FIT description file
Quoted 4 lines · Frank Rowand
Quoted 3 lines · Rob Herring
I'll tell you up front, I'm not a fan of FIT image (nor uImage, Android boot image, $bootloader image). If you want a collection of files and some configuration data, use a filesystem and a text file.
Me neither.
Quoted 5 lines
My gut feel is that using a filesystem and a text file is the easier way to create the boot info. But that also makes applying the overlay(s) during early Linux boot (at the point of FDT unflattening) impractical (can't access the file system without a driver, the driver depends on the devicetree, the devicetree depends upon the overlay).
Why do you want to apply overlays during the kernel boot? The boot loader should be providing the kernel with the merged DT to describe the system that the kernel is running on - it's not the kernel's job to put that together.
The whole point of DT is to make the kernel _less_ tied to the hardware and more generic. If we're going to introduce an entirely new set of drivers into the kernel to "probe" the hardware to determine which overlays are required, then that's really defeating the purpose of DT.
Signature · 3 lines
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up
RFC 12/13 ARM: dts: ti: add dra71-evm FIT description file
Quoted 14 lines · Russell King - ARM Linux
Quoted 4 lines · Frank Rowand
Quoted 3 lines · Rob Herring
I'll tell you up front, I'm not a fan of FIT image (nor uImage, Android boot image, $bootloader image). If you want a collection of files and some configuration data, use a filesystem and a text file.
Me neither.
Quoted 5 lines
My gut feel is that using a filesystem and a text file is the easier way to create the boot info. But that also makes applying the overlay(s) during early Linux boot (at the point of FDT unflattening) impractical (can't access the file system without a driver, the driver depends on the devicetree, the devicetree depends upon the overlay).
Quoted 4 lines
Why do you want to apply overlays during the kernel boot? The boot loader should be providing the kernel with the merged DT to describe the system that the kernel is running on - it's not the kernel's job to put that together.
I would much prefer that overlays get applied before the unflattened devicetree is made available to the kernel instead of applying overlays late in the boot (after many susbsystems and drivers are initialized) or after boot.
If overlays are applied before the unflattened devicetree is made available to the kernel then subsystems and drivers do not have to be aware of the possibility of the data in the devicetree changing instead of being invariant. (I will call this "apply early overlays" later in this email.)
There are use cases of overlays where the overlay is not available until late in the boot, or after the boot completes. I am not suggesting that those use cases be ignored. That is a completely different conversation.
If overlays are applied before the unflattened devicetree is made available to the kernel, there are at least two obvious methods (and I can think of at least one more) -- either the kernel does it or the bootloader does it. I do not see either of the two as being the obvious and only correct choice. If the kernel does it, then there is no need for multiple bootloaders to implement the same code. If the bootloaders do it, then there is no need for multiple kernels (Linux, BSD, etc) to implement the same code. I do not have a strong opinion about whether the bootloaders or the kernels are a better place to apply early overlays.
Quoted 4 lines
The whole point of DT is to make the kernel _less_ tied to the hardware and more generic. If we're going to introduce an entirely new set of drivers into the kernel to "probe" the hardware to determine which overlays are required, then that's really defeating the purpose of DT.
If you read my circular dependency sentence carefully, I said a kernel driver is impractical for the task of getting the overlay. So I agree.
If the kernel applies the overlay, an alternative to drivers is that the kernel could receive the overlay(s) in a similar manner as the method it currently receives the base devicetree. (The overlay(s) could be appended to the base devicetree, a wrapper could be placed around the base devicetree and the overlay(s), or some other implementation. There are multiple ways to achieve the same result.)
Russell King - ARM Linux
maintainerRFC 12/13 ARM: dts: ti: add dra71-evm FIT description file
Quoted 4 lines · Frank Rowand
If the kernel applies the overlay, an alternative to drivers is that the kernel could receive the overlay(s) in a similar manner as the method it currently receives the base devicetree. (The overlay(s) could be appended to the base devicetree, a wrapper could be placed around the
No wrappers, sorry. We already have too many places in the Linux kernel and its decompressor that try to work out whether a device tree or ATAGs are present and how large, and that is done in assembly code. We don't need more complexity to deal with some kind of wrapping of device trees as well.
Signature · 3 lines
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up
RFC 13/13 ARM: dts: ti: add am57xx-evm FIT description file
In reply to Tero KristoAdd FIT image description file for am57xx-evm, which contains the available configurations for the board.
--- arch/arm/boot/dts/ti/am57xx-evm.its | 97 +++++++++++++++++++++++++++++++++++++ 1 file changed, 97 insertions(+) create mode 100644 arch/arm/boot/dts/ti/am57xx-evm.its
arch/arm/boot/dts/ti/am57xx-evm.its new file +97 -0
@@ -0,0 +1,97 @@ +/dts-v1/; + +/ { + description = "AM57xx-evm"; + #address-cells = <1>; + + images { + kernel@1 { + description = "Linux kernel"; + data = /incbin/("../../zImage"); + type = "kernel"; + arch = "arm"; + os = "linux"; + compression = "none"; + load = <0x82000000>; + entry = <0x82000000>; + }; + fdt@1 { + description = "AM57xx-beagle-x15"; + data = /incbin/("am57xx-beagle-x15.dtb"); + type = "flat_dt"; + arch = "arm"; + compression = "none"; + load = <0x83000000>; + }; + fdt@2 { + description = "AM57xx-beagle-x15-revc"; + data = /incbin/("am57xx-beagle-x15-revc.dtb"); + type = "flat_dt"; + arch = "arm"; + compression = "none"; + load = <0x83000000>; + }; + fdt@3 { + description = "AM57xx-evm-common overlay"; + data = /incbin/("am57xx-evm-common.dtbo"); + type = "flat_dt"; + arch = "arm"; + compression = "none"; + load = <0x83080000>; + }; + fdt@4 { + description = "MT9T111 camera support"; + data = /incbin/("mt9t111.dtbo"); + type = "flat_dt"; + arch = "arm"; + compression = "none"; + load = <0x83100000>; + }; + fdt@5 { + description = "OV10635 camera support"; + data = /incbin/("ov10635.dtbo"); + type = "flat_dt"; + arch = "arm"; + compression = "none"; + load = <0x83100000>; + }; + fdt@6 { + description = "AM57xx-evm overlay"; + data = /incbin/("am57xx-evm.dtbo"); + type = "flat_dt"; + arch = "arm"; + compression = "none"; + load = <0x83090000>; + }; + fdt@7 { + description = "AM57xx-evm-reva3 overlay"; + data = /incbin/("am57xx-evm-reva3.dtbo"); + type = "flat_dt"; + arch = "arm"; + compression = "none"; + load = <0x83090000>; + }; + }; + + configurations { + default = "am57xx-evm"; + am57xx-evm { + description = "AM57xx EVM"; + kernel = "kernel@1"; + fdt = "fdt@1", "fdt@3", "fdt@6"; + }; + am57xx-evm-reva3 { + description = "AM57xx EVM rev A3"; + kernel = "kernel@1"; + fdt = "fdt@2", "fdt@3", "fdt@7"; + }; + cam-mt9t111 { + description = "MT9T111 camera"; + fdt = "fdt@4"; + }; + cam-ov10635 { + description = "OV10635 camera"; + fdt = "fdt@5"; + }; + }; +};
Signature · 4 lines
1.9.1 -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Hi,
Please copy me at [email protected] not [email protected] - this entire series has ended up in my spam folder.
Quoted 9 lines · Tero Kristo
Hi,
This series is an attempt to start discussion on the DT overlay build time support. Basically, one can build DT overlays directly from kernel tree, and also build FIT images that contain the kernel + devicetree blobs required for specific configuration that can be booted directly with u-boot. No runtime support for overlay switching is touched by this series.
Quoted 6 lines
The main controversy with this series is most likely where the DT overlay files should be stored at. Should they still reside with the kernel tree or someplace else? Also, the FIT image support is probably controversial, should it be part of the kernel build system like shown here, or should it be separate? The zImage dependency is pretty annoying so maybe it should be done somewhere else.
Please, no, do not add any further build targets for special boot loader formats. We already deprecate the "uImage" format when building multi- platform kernels.
The problem is that we either need to pass in parameters like the load address and dtb path to include in the image, or we need to add to the kernel build system the load addresses for every platform, and generate hundreds of images eating up lots of disk space, and adding to the kernel build time.
When we switched to dtb and multi-platform support, we decided that it was much better that such bootloader specific stuff be external to the kernel tree.
Signature · 1 line
Russell King