uboot overlays, FIT image & unittest

In some cases you need to add a property but the contents of it are not known at creation time, merely the extend of it.

This method allows you to create a property of a given size (filled with garbage) while a pointer to the property data will be provided.

Signed-off-by Pantelis Antoniou <[email protected]>

[dwg: Corrected commit message]

Signed-off-by David Gibson <[email protected]>

---
 lib/libfdt/fdt_rw.c | 20 +++++++++++++++++---
 lib/libfdt/libfdt.h | 31 +++++++++++++++++++++++++++++++
 2 files changed, 48 insertions(+), 3 deletions(-)

In some cases you need to add a property but the contents of it are not known at creation time, merely the extend of it.

This method allows you to create a property of a given size (filled with garbage) while a pointer to the property data will be provided.

Signed-off-by Pantelis Antoniou <[email protected]>

[dwg: Corrected commit message]

Signed-off-by David Gibson <[email protected]>

---
 lib/libfdt/fdt_rw.c | 20 +++++++++++++++++---
 lib/libfdt/libfdt.h | 31 +++++++++++++++++++++++++++++++
 2 files changed, 48 insertions(+), 3 deletions(-)

Introduce fdt_overlay_apply_verbose, a method that applies an overlay but in the case of an error produces a helpful message.

In addition if a base tree is found to be missing the __symbols__ node the message will point out that the probable reason is that the base tree was miscompiled without the -@ option.

Signed-off-by Pantelis Antoniou <[email protected]>

---
 common/fdt_support.c  | 31 +++++++++++++++++++++++++++++++
 include/fdt_support.h |  2 ++
 2 files changed, 33 insertions(+)

Introduce fdt_overlay_apply_verbose, a method that applies an overlay but in the case of an error produces a helpful message.

In addition if a base tree is found to be missing the __symbols__ node the message will point out that the probable reason is that the base tree was miscompiled without the -@ option.

Signed-off-by Pantelis Antoniou <[email protected]>

---
 common/fdt_support.c  | 31 +++++++++++++++++++++++++++++++
 include/fdt_support.h |  2 ++
 2 files changed, 33 insertions(+)

The verbose overlay application method prints out more helpful messages, so switch to it.

Signed-off-by Pantelis Antoniou <[email protected]>

---
 cmd/fdt.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

Quoted 7 lines · Pantelis Antoniou

The verbose overlay application method prints out more helpful messages, so switch to it.

Signed-off-by Pantelis Antoniou <[email protected]>

---
 cmd/fdt.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

Acked-by Simon Glass <[email protected]>

This patch enables an overlay to refer to a previous overlay's labels by performing a merge of symbol information at application time.

In a nutshell it allows an overlay to refer to a symbol that a previous overlay has defined. It requires both the base and all the overlays to be compiled with the -@ command line switch so that symbol information is included.

base.dts
--------

        /dts-v1/;
        / {
                foo: foonode {
                        foo-property;
                };
        };

        $ dtc -@ -I dts -O dtb -o base.dtb base.dts

bar.dts
-------

        /dts-v1/;
        /plugin/;
        / {
                fragment at 1 {
                        target = <&foo>;
                        __overlay__ {
                                overlay-1-property;
                                bar: barnode {
                                        bar-property;
                                };
                        };
                };
        };

        $ dtc -@ -I dts -O dtb -o bar.dtb bar.dts

baz.dts
-------

        /dts-v1/;
        /plugin/;
        / {
                fragment at 1 {
                        target = <&bar>;
                        __overlay__ {
                                overlay-2-property;
                                baz: baznode {
                                        baz-property;
                                };
                        };
                };
        };

        $ dtc -@ -I dts -O dtb -o baz.dtb baz.dts

Applying the overlays:

        $ fdtoverlay -i base.dtb -o target.dtb bar.dtb baz.dtb

Dumping:

        $ fdtdump target.dtb
        / {
            foonode {
                overlay-1-property;
                foo-property;
                linux,phandle = <0x00000001>;
                phandle = <0x00000001>;
                barnode {
                    overlay-2-property;
                    phandle = <0x00000002>;
                    linux,phandle = <0x00000002>;
                    bar-property;
                    baznode {
                        phandle = <0x00000003>;
                        linux,phandle = <0x00000003>;
                        baz-property;
                    };
                };
            };
            __symbols__ {
                baz = "/foonode/barnode/baznode";
                bar = "/foonode/barnode";
                foo = "/foonode";
            };
        };

Signed-off-by Pantelis Antoniou <[email protected]>

Signed-off-by David Gibson <[email protected]>

---
 lib/libfdt/fdt_overlay.c | 228 ++++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 206 insertions(+), 22 deletions(-)

This patch enables an overlay to refer to a previous overlay's labels by performing a merge of symbol information at application time.

In a nutshell it allows an overlay to refer to a symbol that a previous overlay has defined. It requires both the base and all the overlays to be compiled with the -@ command line switch so that symbol information is included.

base.dts
--------

        /dts-v1/;
        / {
                foo: foonode {
                        foo-property;
                };
        };

        $ dtc -@ -I dts -O dtb -o base.dtb base.dts

bar.dts
-------

        /dts-v1/;
        /plugin/;
        / {
                fragment at 1 {
                        target = <&foo>;
                        __overlay__ {
                                overlay-1-property;
                                bar: barnode {
                                        bar-property;
                                };
                        };
                };
        };

        $ dtc -@ -I dts -O dtb -o bar.dtb bar.dts

baz.dts
-------

        /dts-v1/;
        /plugin/;
        / {
                fragment at 1 {
                        target = <&bar>;
                        __overlay__ {
                                overlay-2-property;
                                baz: baznode {
                                        baz-property;
                                };
                        };
                };
        };

        $ dtc -@ -I dts -O dtb -o baz.dtb baz.dts

Applying the overlays:

        $ fdtoverlay -i base.dtb -o target.dtb bar.dtb baz.dtb

Dumping:

        $ fdtdump target.dtb
        / {
            foonode {
                overlay-1-property;
                foo-property;
                linux,phandle = <0x00000001>;
                phandle = <0x00000001>;
                barnode {
                    overlay-2-property;
                    phandle = <0x00000002>;
                    linux,phandle = <0x00000002>;
                    bar-property;
                    baznode {
                        phandle = <0x00000003>;
                        linux,phandle = <0x00000003>;
                        baz-property;
                    };
                };
            };
            __symbols__ {
                baz = "/foonode/barnode/baznode";
                bar = "/foonode/barnode";
                foo = "/foonode";
            };
        };

Signed-off-by Pantelis Antoniou <[email protected]>

Signed-off-by David Gibson <[email protected]>

---
 lib/libfdt/fdt_overlay.c | 228 ++++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 206 insertions(+), 22 deletions(-)

As part of the fdt overlay support which need it, allow a list of configurations per property.

Signed-off-by Pantelis Antoniou <[email protected]>

---
 common/image-fit.c | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

As part of the fdt overlay support which need it, allow a list of configurations per property.

Signed-off-by Pantelis Antoniou <[email protected]>

---
 common/image-fit.c | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

fit_image_load() threw away the extra configuration parts when loading. We need them around for applying extra overlays for building the boot fdt.

Signed-off-by Pantelis Antoniou <[email protected]>

---
 common/image-fit.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

common/image-fit.c +5 -3

index 74e5557..e75cb64 100644
@@ -1653,6 +1653,7 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
        int cfg_noffset, noffset;
        const char *fit_uname;
        const char *fit_uname_config;
+       const char *fit_base_uname_config;
        const void *fit;
        const void *buf;
        size_t size;

@@ -1668,6 +1669,7 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
        fit = map_sysmem(addr, 0);
        fit_uname = fit_unamep ? *fit_unamep : NULL;
        fit_uname_config = fit_uname_configp ? *fit_uname_configp : NULL;
+       fit_base_uname_config = NULL;
        prop_name = fit_get_image_type_property(image_type);
        printf("## Loading %s from FIT Image at %08lx ...\n", prop_name, addr);
 

@@ -1701,11 +1703,11 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
                                        BOOTSTAGE_SUB_NO_UNIT_NAME);
                        return -ENOENT;
                }
-               fit_uname_config = fdt_get_name(fit, cfg_noffset, NULL);
-               printf("   Using '%s' configuration\n", fit_uname_config);
+               fit_base_uname_config = fdt_get_name(fit, cfg_noffset, NULL);
+               printf("   Using '%s' configuration\n", fit_base_uname_config);
                if (image_type == IH_TYPE_KERNEL) {
                        /* Remember (and possibly verify) this config */
-                       images->fit_uname_cfg = fit_uname_config;
+                       images->fit_uname_cfg = fit_base_uname_config;
                        if (IMAGE_ENABLE_VERIFY && images->verify) {
                                puts("   Verifying Hash Integrity ... ");
                                if (fit_config_verify(fit, cfg_noffset)) {

common/image-fit.c +0 -1

        return noffset;
 }
--

2.1.4

fit_image_load() threw away the extra configuration parts when loading. We need them around for applying extra overlays for building the boot fdt.

Signed-off-by Pantelis Antoniou <[email protected]>

---
 common/image-fit.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

Introduce an overlay based method for constructing a base DT blob to pass to the kernel.

It is based on a specific method now to get the FDT from a FIT image named boot_get_fdt_fit().

Signed-off-by Pantelis Antoniou <[email protected]>

---
 common/image-fdt.c |   7 +--
 common/image-fit.c | 181 +++++++++++++++++++++++++++++++++++++++++++++++++++--
 include/image.h    |  25 ++++++++
 3 files changed, 205 insertions(+), 8 deletions(-)

Introduce an overlay based method for constructing a base DT blob to pass to the kernel.

It is based on a specific method now to get the FDT from a FIT image named boot_get_fdt_fit().

Signed-off-by Pantelis Antoniou <[email protected]>

---
 common/image-fdt.c |   7 +--
 common/image-fit.c | 181 +++++++++++++++++++++++++++++++++++++++++++++++++++--
 include/image.h    |  25 ++++++++
 3 files changed, 205 insertions(+), 8 deletions(-)

Signed-off-by Pantelis Antoniou <[email protected]>

---
  doc/uImage.FIT/command_syntax_extensions.txt |  12 +-
  doc/uImage.FIT/overlay-fdt-boot.txt          | 221 +++++++++++++++++++++++++++
  doc/uImage.FIT/source_file_format.txt        |   6 +-
  3 files changed, 236 insertions(+), 3 deletions(-)

create mode 100644 doc/uImage.FIT/overlay-fdt-boot.txt

doc/uImage.FIT/command_syntax_extensions.txt +11 -1

index 6c99b1c..676f992 100644
@@ -36,7 +36,7 @@ Old uImage:
  New uImage:
  8.  bootm <addr1>
  9.  bootm [<addr1>]:<subimg1>
-10. bootm [<addr1>]#<conf>
+10. bootm [<addr1>]#<conf>[#<extra-conf[#...]]
  11. bootm [<addr1>]:<subimg1> [<addr2>]:<subimg2>
  12. bootm [<addr1>]:<subimg1> [<addr2>]:<subimg2> [<addr3>]:<subimg3>
  13. bootm [<addr1>]:<subimg1> [<addr2>]:<subimg2> <addr3>

@@ -129,6 +129,12 @@ following syntax:
  - new uImage configuration specification
  <addr>#<configuration unit_name>
 
+- new uImage configuration specification with extra configuration components
+<addr>#<configuration unit_name>[#<extra configuration unit_name>[#..]]
+
+The extra configuration currently is supported only for additional device tree
+overlays to apply on the base device tree supplied by the first configuration
+unit.
 
  Examples:
 

@@ -138,6 +144,10 @@ bootm 200000:kernel at 1
  - boot configuration "cfg at 1" from a new uImage located at 200000:
  bootm 200000#cfg at 1
 
+- boot configuration "cfg at 1" with extra "cfg at 2" from a new uImage located
+  at 200000:
+bootm 200000#cfg at 1#cfg at 2
+
  - boot "kernel at 1" from a new uImage at 200000 with initrd "ramdisk at 2" found in
    some other new uImage stored at address 800000:
  bootm 200000:kernel at 1 800000:ramdisk at 2

doc/uImage.FIT/overlay-fdt-boot.txt new file +221 -0

new file mode 100644
index 0000000..dbdf2a1
@@ -0,0 +1,221 @@
+U-Boot FDT Overlay usage
+========================
+
+Introduction
+------------
+In many cases it is desirable to have a single FIT image support a multitude
+of similar boards and their expansion options. The same kernel on DT enabled
+platforms can support this easily enough by providing a DT blob upon boot
+that matches the desired configuration.
+
+Configuration without overlays
+------------------------------
+
+Take a hypothetical board named 'foo' where there are different supported
+revisions, reva and revb. Assume that both board revisions can use add a bar
+add-on board, while only the revb board can use a baz add-on board.
+
+Without using overlays the configuration would be as follows for every case.
+
+	/dts-v1/;
+	/ {
+		images {
+			kernel at 1 {
+				data = /incbin/("./zImage");
+				type = "kernel";
+				arch = "arm";
+				os = "linux";
+				load = <0x82000000>;
+				entry = <0x82000000>;
+			};
+			fdt at 1 {
+				data = /incbin/("./foo-reva.dtb");
+				type = "flat_dt";
+				arch = "arm";
+			};
+			fdt at 2 {
+				data = /incbin/("./foo-revb.dtb");
+				type = "flat_dt";
+				arch = "arm";
+			};
+			fdt at 3 {
+				data = /incbin/("./foo-reva-bar.dtb");
+				type = "flat_dt";
+				arch = "arm";
+			};
+			fdt at 4 {
+				data = /incbin/("./foo-revb-bar.dtb");
+				type = "flat_dt";
+				arch = "arm";
+			};
+			fdt at 5 {
+				data = /incbin/("./foo-revb-baz.dtb");
+				type = "flat_dt";
+				arch = "arm";
+			};
+			fdt at 6 {
+				data = /incbin/("./foo-revb-bar-baz.dtb");
+				type = "flat_dt";
+				arch = "arm";
+			};
+		};
+
+		configurations {
+			default = "foo-reva.dtb;
+			foo-reva.dtb {
+				kernel = "kernel at 1";
+				fdt = "fdt at 1";
+			};
+			foo-revb.dtb {
+				kernel = "kernel at 1";
+				fdt = "fdt at 2";
+			};
+			foo-reva-bar.dtb {
+				kernel = "kernel at 1";
+				fdt = "fdt at 3";
+			};
+			foo-revb-bar.dtb {
+				kernel = "kernel at 1";
+				fdt = "fdt at 4";
+			};
+			foo-revb-baz.dtb {
+				kernel = "kernel at 1";
+				fdt = "fdt at 5";
+			};
+			foo-revb-bar-baz.dtb {
+				kernel = "kernel at 1";
+				fdt = "fdt at 6";
+			};
+		};
+	};
+
+Note the blob needs to be compiled for each case and the combinatorial explosion of
+configurations. A typical device tree blob is in the low hunderds of kbytes so a
+multitude of configuration grows the image quite a bit.
+
+Booting this image is done by using
+
+	# bootm <addr>#<config>
+
+Where config is one of:
+	foo-reva.dtb, foo-revb.dtb, foo-reva-bar.dtb, foo-revb-bar.dtb,
+	foo-revb-baz.dtb, foo-revb-bar-baz.dtb
+
+This selects the DTB to use when booting.
+
+Configuration using overlays
+----------------------------
+
+Device tree overlays can be applied to a base DT and result in the same blob
+being passed to the booting kernel. This saves on space and avoid the combinatorial
+explosion problem.
+
+	/dts-v1/;
+	/ {
+		images {
+			kernel at 1 {
+				data = /incbin/("./zImage");
+				type = "kernel";
+				arch = "arm";
+				os = "linux";
+				load = <0x82000000>;
+				entry = <0x82000000>;
+			};
+			fdt at 1 {
+				data = /incbin/("./foo.dtb");
+				type = "flat_dt";
+				arch = "arm";
+				load = <0x87f00000>;
+			};
+			fdt at 2 {
+				data = /incbin/("./reva.dtbo");
+				type = "flat_dt";
+				arch = "arm";
+				load = <0x87fc0000>;
+			};
+			fdt at 3 {
+				data = /incbin/("./revb.dtbo");
+				type = "flat_dt";
+				arch = "arm";
+				load = <0x87fc0000>;
+			};
+			fdt at 4 {
+				data = /incbin/("./bar.dtbo");
+				type = "flat_dt";
+				arch = "arm";
+				load = <0x87fc0000>;
+			};
+			fdt at 5 {
+				data = /incbin/("./baz.dtbo");
+				type = "flat_dt";
+				arch = "arm";
+				load = <0x87fc0000>;
+			};
+		};
+
+		configurations {
+			default = "foo-reva.dtb;
+			foo-reva.dtb {
+				kernel = "kernel at 1";
+				fdt = "fdt at 1", "fdt at 2";
+			};
+			foo-revb.dtb {
+				kernel = "kernel at 1";
+				fdt = "fdt at 1", "fdt at 3";
+			};
+			foo-reva-bar.dtb {
+				kernel = "kernel at 1";
+				fdt = "fdt at 1", "fdt at 2", "fdt at 4";
+			};
+			foo-revb-bar.dtb {
+				kernel = "kernel at 1";
+				fdt = "fdt at 1", "fdt at 3", "fdt at 4";
+			};
+			foo-revb-baz.dtb {
+				kernel = "kernel at 1";
+				fdt = "fdt at 1", "fdt at 3", "fdt at 5";
+			};
+			foo-revb-bar-baz.dtb {
+				kernel = "kernel at 1";
+				fdt = "fdt at 1", "fdt at 3", "fdt at 4", "fdt at 5";
+			};
+			bar {
+				fdt = "fdt at 4";
+			};
+			baz {
+				fdt = "fdt at 5";
+			};
+		};
+	};
+
+Booting this image is exactly the same as the non-overlay example.
+u-boot will retrieve the base blob and apply the overlays in sequence as
+they are declared in the configuration.
+
+Note the minimum amount of different DT blobs, as well as the requirement for
+the DT blobs to have a load address; the overlay application requires the blobs
+to be writeable.
+
+Configuration using overlays and feature selection
+--------------------------------------------------
+
+Although the configuration in the previous section works is a bit inflexible
+since it requires all possible configuration options to be laid out before
+hand in the FIT image. For the add-on boards the extra config selection method
+might make sense.
+
+Note the two bar & baz configuration nodes. To boot a reva board with
+the bar add-on board enabled simply use:
+
+	# bootm <addr>#foo-reva.dtb#bar
+
+While booting a revb with bar and baz is as follows:
+
+	# bootm <addr>#foo-revb.dtb#bar#baz
+
+The limitation for a feature selection configuration node is that a single
+fdt option is currently supported.
+
+Pantelis Antoniou
+pantelis.antoniou at konsulko.com
+12/6/2017

doc/uImage.FIT/source_file_format.txt +1 -1

index 136d3d7..ba8013a 100644
@@ -235,7 +235,7 @@ o config at 1
    |- description = "configuration description"
    |- kernel = "kernel sub-node unit name"
    |- ramdisk = "ramdisk sub-node unit name"
-  |- fdt = "fdt sub-node unit-name"
+  |- fdt = "fdt sub-node unit-name" [, "fdt overlay sub-node unit-name", ...]
    |- fpga = "fpga sub-node unit-name"
    |- loadables = "loadables sub-node unit-name"
 

Quoted 287 lines · Pantelis Antoniou

Signed-off-by Pantelis Antoniou <[email protected]>

---
  doc/uImage.FIT/command_syntax_extensions.txt |  12 +-
  doc/uImage.FIT/overlay-fdt-boot.txt          | 221 +++++++++++++++++++++++++++
  doc/uImage.FIT/source_file_format.txt        |   6 +-
  3 files changed, 236 insertions(+), 3 deletions(-)

create mode 100644 doc/uImage.FIT/overlay-fdt-boot.txt

doc/uImage.FIT/command_syntax_extensions.txt +11 -1

index 6c99b1c..676f992 100644
@@ -36,7 +36,7 @@ Old uImage:
  New uImage:
  8.  bootm <addr1>
  9.  bootm [<addr1>]:<subimg1>
-10. bootm [<addr1>]#<conf>
+10. bootm [<addr1>]#<conf>[#<extra-conf[#...]]
  11. bootm [<addr1>]:<subimg1> [<addr2>]:<subimg2>
  12. bootm [<addr1>]:<subimg1> [<addr2>]:<subimg2> [<addr3>]:<subimg3>
  13. bootm [<addr1>]:<subimg1> [<addr2>]:<subimg2> <addr3>

@@ -129,6 +129,12 @@ following syntax:
  - new uImage configuration specification
  <addr>#<configuration unit_name>
 
+- new uImage configuration specification with extra configuration components
+<addr>#<configuration unit_name>[#<extra configuration unit_name>[#..]]
+
+The extra configuration currently is supported only for additional device tree
+overlays to apply on the base device tree supplied by the first configuration
+unit.
 
  Examples:
 

@@ -138,6 +144,10 @@ bootm 200000:kernel at 1
  - boot configuration "cfg at 1" from a new uImage located at 200000:
  bootm 200000#cfg at 1
 
+- boot configuration "cfg at 1" with extra "cfg at 2" from a new uImage located
+  at 200000:
+bootm 200000#cfg at 1#cfg at 2
+
  - boot "kernel at 1" from a new uImage at 200000 with initrd "ramdisk at 2" found in
    some other new uImage stored at address 800000:
  bootm 200000:kernel at 1 800000:ramdisk at 2

doc/uImage.FIT/overlay-fdt-boot.txt new file +221 -0

new file mode 100644
index 0000000..dbdf2a1
@@ -0,0 +1,221 @@
+U-Boot FDT Overlay usage
+========================
+
+Introduction
+------------
+In many cases it is desirable to have a single FIT image support a multitude
+of similar boards and their expansion options. The same kernel on DT enabled
+platforms can support this easily enough by providing a DT blob upon boot
+that matches the desired configuration.
+
+Configuration without overlays
+------------------------------
+
+Take a hypothetical board named 'foo' where there are different supported
+revisions, reva and revb. Assume that both board revisions can use add a bar
+add-on board, while only the revb board can use a baz add-on board.
+
+Without using overlays the configuration would be as follows for every case.
+
+	/dts-v1/;
+	/ {
+		images {
+			kernel at 1 {
+				data = /incbin/("./zImage");
+				type = "kernel";
+				arch = "arm";
+				os = "linux";
+				load = <0x82000000>;
+				entry = <0x82000000>;
+			};
+			fdt at 1 {
+				data = /incbin/("./foo-reva.dtb");
+				type = "flat_dt";
+				arch = "arm";
+			};
+			fdt at 2 {
+				data = /incbin/("./foo-revb.dtb");
+				type = "flat_dt";
+				arch = "arm";
+			};
+			fdt at 3 {
+				data = /incbin/("./foo-reva-bar.dtb");
+				type = "flat_dt";
+				arch = "arm";
+			};
+			fdt at 4 {
+				data = /incbin/("./foo-revb-bar.dtb");
+				type = "flat_dt";
+				arch = "arm";
+			};
+			fdt at 5 {
+				data = /incbin/("./foo-revb-baz.dtb");
+				type = "flat_dt";
+				arch = "arm";
+			};
+			fdt at 6 {
+				data = /incbin/("./foo-revb-bar-baz.dtb");
+				type = "flat_dt";
+				arch = "arm";
+			};
+		};
+
+		configurations {
+			default = "foo-reva.dtb;
+			foo-reva.dtb {
+				kernel = "kernel at 1";
+				fdt = "fdt at 1";
+			};
+			foo-revb.dtb {
+				kernel = "kernel at 1";
+				fdt = "fdt at 2";
+			};
+			foo-reva-bar.dtb {
+				kernel = "kernel at 1";
+				fdt = "fdt at 3";
+			};
+			foo-revb-bar.dtb {
+				kernel = "kernel at 1";
+				fdt = "fdt at 4";
+			};
+			foo-revb-baz.dtb {
+				kernel = "kernel at 1";
+				fdt = "fdt at 5";
+			};
+			foo-revb-bar-baz.dtb {
+				kernel = "kernel at 1";
+				fdt = "fdt at 6";
+			};
+		};
+	};
+
+Note the blob needs to be compiled for each case and the combinatorial explosion of
+configurations. A typical device tree blob is in the low hunderds of kbytes so a
+multitude of configuration grows the image quite a bit.
+
+Booting this image is done by using
+
+	# bootm <addr>#<config>
+
+Where config is one of:
+	foo-reva.dtb, foo-revb.dtb, foo-reva-bar.dtb, foo-revb-bar.dtb,
+	foo-revb-baz.dtb, foo-revb-bar-baz.dtb
+
+This selects the DTB to use when booting.
+
+Configuration using overlays
+----------------------------
+
+Device tree overlays can be applied to a base DT and result in the same blob
+being passed to the booting kernel. This saves on space and avoid the combinatorial
+explosion problem.
+
+	/dts-v1/;
+	/ {
+		images {
+			kernel at 1 {
+				data = /incbin/("./zImage");
+				type = "kernel";
+				arch = "arm";
+				os = "linux";
+				load = <0x82000000>;
+				entry = <0x82000000>;
+			};
+			fdt at 1 {
+				data = /incbin/("./foo.dtb");
+				type = "flat_dt";
+				arch = "arm";
+				load = <0x87f00000>;
+			};
+			fdt at 2 {
+				data = /incbin/("./reva.dtbo");
+				type = "flat_dt";
+				arch = "arm";
+				load = <0x87fc0000>;
+			};
+			fdt at 3 {
+				data = /incbin/("./revb.dtbo");
+				type = "flat_dt";
+				arch = "arm";
+				load = <0x87fc0000>;
+			};
+			fdt at 4 {
+				data = /incbin/("./bar.dtbo");
+				type = "flat_dt";
+				arch = "arm";
+				load = <0x87fc0000>;
+			};
+			fdt at 5 {
+				data = /incbin/("./baz.dtbo");
+				type = "flat_dt";
+				arch = "arm";
+				load = <0x87fc0000>;
+			};
+		};
+
+		configurations {
+			default = "foo-reva.dtb;
+			foo-reva.dtb {
+				kernel = "kernel at 1";
+				fdt = "fdt at 1", "fdt at 2";
+			};
+			foo-revb.dtb {
+				kernel = "kernel at 1";
+				fdt = "fdt at 1", "fdt at 3";
+			};
+			foo-reva-bar.dtb {
+				kernel = "kernel at 1";
+				fdt = "fdt at 1", "fdt at 2", "fdt at 4";
+			};
+			foo-revb-bar.dtb {
+				kernel = "kernel at 1";
+				fdt = "fdt at 1", "fdt at 3", "fdt at 4";
+			};
+			foo-revb-baz.dtb {
+				kernel = "kernel at 1";
+				fdt = "fdt at 1", "fdt at 3", "fdt at 5";
+			};
+			foo-revb-bar-baz.dtb {
+				kernel = "kernel at 1";
+				fdt = "fdt at 1", "fdt at 3", "fdt at 4", "fdt at 5";
+			};
+			bar {
+				fdt = "fdt at 4";
+			};
+			baz {
+				fdt = "fdt at 5";
+			};
+		};
+	};
+
+Booting this image is exactly the same as the non-overlay example.
+u-boot will retrieve the base blob and apply the overlays in sequence as
+they are declared in the configuration.
+
+Note the minimum amount of different DT blobs, as well as the requirement for
+the DT blobs to have a load address; the overlay application requires the blobs
+to be writeable.
+
+Configuration using overlays and feature selection
+--------------------------------------------------
+
+Although the configuration in the previous section works is a bit inflexible
+since it requires all possible configuration options to be laid out before
+hand in the FIT image. For the add-on boards the extra config selection method
+might make sense.
+
+Note the two bar & baz configuration nodes. To boot a reva board with
+the bar add-on board enabled simply use:
+
+	# bootm <addr>#foo-reva.dtb#bar
+
+While booting a revb with bar and baz is as follows:
+
+	# bootm <addr>#foo-revb.dtb#bar#baz
+
+The limitation for a feature selection configuration node is that a single
+fdt option is currently supported.
+
+Pantelis Antoniou
+pantelis.antoniou at konsulko.com
+12/6/2017

doc/uImage.FIT/source_file_format.txt +1 -1

index 136d3d7..ba8013a 100644
@@ -235,7 +235,7 @@ o config at 1
    |- description = "configuration description"
    |- kernel = "kernel sub-node unit name"
    |- ramdisk = "ramdisk sub-node unit name"
-  |- fdt = "fdt sub-node unit-name"
+  |- fdt = "fdt sub-node unit-name" [, "fdt overlay sub-node unit-name", ...]
    |- fpga = "fpga sub-node unit-name"
    |- loadables = "loadables sub-node unit-name"
 

doc/uImage.FIT/source_file_format.txt o config at 1 · line 257

Quoted 10 lines

doc/uImage.FIT/source_file_format.txt +3 -1

@@ -249,7 +249,9 @@ o config at 1
    - ramdisk : Unit name of the corresponding ramdisk image (component image
      node of a "ramdisk" type).
    - fdt : Unit name of the corresponding fdt blob (component image node of a
-    "fdt type").
+    "fdt type"). Additional fdt overlay nodes can be supplied which signify
+    that the resulting device tree blob is generated by the first base fdt
+    blob with all subsequent overlays applied.
    - setup : Unit name of the corresponding setup binary (used for booting
      an x86 kernel). This contains the setup.bin file built by the kernel.
    - fpga : Unit name of the corresponding fpga bitstream blob

Reviewed-by Łukasz Majewski

I'm just curious - what was the fit image size reduction on your test setup?

Signed-off-by Pantelis Antoniou <[email protected]>

---
 doc/uImage.FIT/command_syntax_extensions.txt |  12 +-
 doc/uImage.FIT/overlay-fdt-boot.txt          | 221 +++++++++++++++++++++++++++
 doc/uImage.FIT/source_file_format.txt        |   6 +-
 3 files changed, 236 insertions(+), 3 deletions(-)
 create mode 100644 doc/uImage.FIT/overlay-fdt-boot.txt

Signed-off-by Pantelis Antoniou <[email protected]>

---
 doc/uImage.FIT/command_syntax_extensions.txt |  12 +-
 doc/uImage.FIT/overlay-fdt-boot.txt          | 221 +++++++++++++++++++++++++++
 doc/uImage.FIT/source_file_format.txt        |   6 +-
 3 files changed, 236 insertions(+), 3 deletions(-)
 create mode 100644 doc/uImage.FIT/overlay-fdt-boot.txt

We have the capability to apply overlays on the command line but we didn't have a document explaining how.

Signed-off-by Pantelis Antoniou <[email protected]>

---
  doc/README.fdt-overlays | 37 +++++++++++++++++++++++++++++++++++++
  1 file changed, 37 insertions(+)

create mode 100644 doc/README.fdt-overlays

doc/README.fdt-overlays new file +27 -0

new file mode 100644
index 0000000..ee868ec
@@ -0,0 +1,37 @@
+U-Boot FDT Overlay usage (without FIT images)
+=============================================
+
+FDT overlays are now available for use even without FIT images.
+It is not as automagic as with FIT images though and require a few
+manual steps.
+
+1. Figure out where to place both the base device tree blob and the
+overlay. Make sure you have enough space to grow the base tree without
+overlapping anything.
+
+=> setenv fdtaddr 0x87f00000
+=> setenv fdtovaddr 0x87fc0000
+
+2. Load the base blob and overlay blobs
+
+=> load ${devtype} ${bootpart} ${fdtaddr} ${bootdir}/base.dtb
+=> load ${devtype} ${bootpart} ${fdtovaddr} ${bootdir}/overlay.dtb
+
+3. Set it as the working fdt tree.
+
+=> fdtaddr $fdtaddr
+
+4. Grow it enough so it can 'fit' all the applied overlays
+
+=> fdt resize 8192
+

We have the capability to apply overlays on the command line but we didn't have a document explaining how.

Signed-off-by Pantelis Antoniou <[email protected]>

---
 doc/README.fdt-overlays | 37 +++++++++++++++++++++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 doc/README.fdt-overlays

We have the capability to apply overlays on the command line but we didn't have a document explaining how.

Signed-off-by Pantelis Antoniou <[email protected]>

---
 doc/README.fdt-overlays | 37 +++++++++++++++++++++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 doc/README.fdt-overlays

From: Franklin S Cooper Jr <[email protected]>

Pull some information regarding overlays from commit messages and put them directly within the documentation. Also add some information regarding required dtc version to properly use overlays.

Signed-off-by Franklin S Cooper Jr <[email protected]>

---
  doc/README.fdt-overlays             | 85 +++++++++++++++++++++++++++++++++++--
  doc/uImage.FIT/overlay-fdt-boot.txt |  8 +++-
  2 files changed, 87 insertions(+), 6 deletions(-)

doc/README.fdt-overlays +81 -4

index ee868ec..39139cb 100644
@@ -1,9 +1,76 @@
-U-Boot FDT Overlay usage (without FIT images)
+U-Boot FDT Overlay usage
  =============================================
 
-FDT overlays are now available for use even without FIT images.
-It is not as automagic as with FIT images though and require a few
-manual steps.
+Overlays Syntax
+---------------
+
+Overlays require slightly different syntax compared to traditional overlays.
+Please refer to dt-object-internal.txt in the dtc sources for information
+regarding the internal format of overlays:
+https://git.kernel.org/pub/scm/utils/dtc/dtc.git/tree/Documentation/dt-object-internal.txt
+
+Building Overlays
+-----------------
+
+In a nutshell overlays provides a means to manipulate a symbol a previous dtb
+or overlay has defined. It requires both the base and all the overlays
+to be compiled with the -@ command line switch so that symbol information is
+included.
+
+Note support for -@ option can only be found in dtc version 1.4.4 or newer.
+Only version 4.14 or higher of the Linux kernel includes a built in version
+of dtc that meets this requirement.
+
+Building an overlay follows the same process as building a traditional dtb.
+
+For example:
+
+base.dts
+--------
+
+	/dts-v1/;
+	/ {
+		foo: foonode {
+			foo-property;
+		};
+	};
+
+	$ dtc -@ -I dts -O dtb -o base.dtb base.dts
+
+bar.dts
+-------
+
+	/dts-v1/;
+	/plugin/;
+	/ {
+		fragment at 1 {
+			target = <&foo>;
+			__overlay__ {
+				overlay-1-property;
+				bar: barnode {
+					bar-property;
+				};
+			};
+		};
+	};
+
+	$ dtc -@ -I dts -O dtb -o bar.dtb bar.dts
+
+Ways to Utilize Overlays in U-boot
+----------------------------------
+
+There are two ways to apply overlays in U-boot.
+1. Include and define overlays within a FIT image and have overlays
+   automatically applied.
+
+2. Manually load and apply overlays
+
+The remainder of this document will discuss using overlays via the manual
+approach. For information on using overlays as part of a FIT image please see:
+doc/uImage.FIT/overlay-fdt-boot.txt
+
+Manually Loading and Applying Overlays
+--------------------------------------
 
  1. Figure out where to place both the base device tree blob and the
  overlay. Make sure you have enough space to grow the base tree without

@@ -29,6 +96,16 @@ overlapping anything.
 
  => fdt apply $fdtovaddr
 
+6. Boot system like you would do with a traditional dtb.
+
+For bootm:
+
+=> bootm ${kerneladdr} - ${fdtaddr}
+
+For bootz:
+
+=> bootz ${kerneladdr} - ${fdtaddr}
+
  Please note that in case of an error, both the base and overlays are going
  to be invalidated, so keep copies to avoid reloading.
 

doc/uImage.FIT/overlay-fdt-boot.txt +2 -2

index dbdf2a1..63e47da 100644
@@ -1,5 +1,5 @@
-U-Boot FDT Overlay usage
-========================
+U-Boot FDT Overlay FIT usage
+============================
 
  Introduction
  ------------

From: Franklin S Cooper Jr <[email protected]>

Pull some information regarding overlays from commit messages and put them directly within the documentation. Also add some information regarding required dtc version to properly use overlays.

Signed-off-by Franklin S Cooper Jr <[email protected]>

---
 doc/README.fdt-overlays             | 85 +++++++++++++++++++++++++++++++++++--
 doc/uImage.FIT/overlay-fdt-boot.txt |  8 +++-
 2 files changed, 87 insertions(+), 6 deletions(-)

From: Franklin S Cooper Jr <[email protected]>

Pull some information regarding overlays from commit messages and put them directly within the documentation. Also add some information regarding required dtc version to properly use overlays.

Signed-off-by Franklin S Cooper Jr <[email protected]>

---
 doc/README.fdt-overlays             | 85 +++++++++++++++++++++++++++++++++++--
 doc/uImage.FIT/overlay-fdt-boot.txt |  8 +++-
 2 files changed, 87 insertions(+), 6 deletions(-)

Special rule for dtbo generation

Signed-off-by Pantelis Antoniou <[email protected]>

---
 scripts/Makefile.lib | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

scripts/Makefile.lib $(obj)/%.dtb: $(src)/%.dts FORCE · line 335

Quoted 13 lines · Pantelis Antoniou

Special rule for dtbo generation

scripts/Makefile.lib +9 -0

 
+quiet_cmd_dtco = DTCO    $@
+# Rule for objects only; does not put specific u-boot include at the end
+# No generation of assembly file either
+# Modified for U-Boot
+cmd_dtco = mkdir -p $(dir ${dtc-tmp}) ; \
+    $(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) - ; \
+    $(DTC) -@ -O dtb -o $@ -b 0 \
+        -i $(dir $<) $(DTC_FLAGS) \
+        -d $(depfile).dtc.tmp $(dtc-tmp) ; \

As of u-boot-fdt/master commit 503afc3ca1e5 "test: overlay: Add unit test for stacked overlay", the U-Boot build fails for sandbox with the error below. I guess it's due to this commit. Does U-Boot now intentionally rely on a newer dtc or is this an accident?

   DTC     test/overlay/test-fdt-base.dtb
   LD      lib/libfdt/built-in.o
   CC      lib/charset.o
   CC      lib/rsa/rsa-verify.o

dtc: invalid option -- '@'
Usage: dtc [options] <input file>

Options: -[qI:O:o:V:d:R:S:p:fb:i:H:sW:E:hv]
-q, --quiet
Quiet: -q suppress warnings, -qq errors, -qqq all
...

Quoted 24 lines · Stephen Warren

scripts/Makefile.lib $(obj)/%.dtb: $(src)/%.dts FORCE · line 335

Quoted 13 lines · Pantelis Antoniou

Special rule for dtbo generation

scripts/Makefile.lib +9 -0

 
+quiet_cmd_dtco = DTCO    $@
+# Rule for objects only; does not put specific u-boot include at the end
+# No generation of assembly file either
+# Modified for U-Boot
+cmd_dtco = mkdir -p $(dir ${dtc-tmp}) ; \
+    $(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) - ; \
+    $(DTC) -@ -O dtb -o $@ -b 0 \
+        -i $(dir $<) $(DTC_FLAGS) \
+        -d $(depfile).dtc.tmp $(dtc-tmp) ; \

As of u-boot-fdt/master commit 503afc3ca1e5 "test: overlay: Add unit test for stacked overlay", the U-Boot build fails for sandbox with the error below. I guess it's due to this commit. Does U-Boot now intentionally rely on a newer dtc or is this an accident?

  DTC     test/overlay/test-fdt-base.dtb
  LD      lib/libfdt/built-in.o
  CC      lib/charset.o
  CC      lib/rsa/rsa-verify.o

Quoted 7 lines

dtc: invalid option -- '@'
Usage: dtc [options] <input file>

Options: -[qI:O:o:V:d:R:S:p:fb:i:H:sW:E:hv]
-q, --quiet
Quiet: -q suppress warnings, -qq errors, -qqq all
...

Related, the following check in Makefile doesn't trigger:

checkdtc:

	@if test $(call dtc-version) -lt 0104; then \
		echo '*** Your dtc is too old, please upgrade to dtc 1.4 or newer'; \
		false; \
	fi

... because I have dtc 1.4.0. If U-Boot requires a new version now, that Makefile chunk should be updated.

Quoted 41 lines · Stephen Warren

Quoted 24 lines · Stephen Warren

scripts/Makefile.lib $(obj)/%.dtb: $(src)/%.dts FORCE · line 335

Quoted 13 lines · Pantelis Antoniou

Special rule for dtbo generation

scripts/Makefile.lib +9 -0

 
+quiet_cmd_dtco = DTCO    $@
+# Rule for objects only; does not put specific u-boot include at the end
+# No generation of assembly file either
+# Modified for U-Boot
+cmd_dtco = mkdir -p $(dir ${dtc-tmp}) ; \
+    $(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) - ; \
+    $(DTC) -@ -O dtb -o $@ -b 0 \
+        -i $(dir $<) $(DTC_FLAGS) \
+        -d $(depfile).dtc.tmp $(dtc-tmp) ; \

As of u-boot-fdt/master commit 503afc3ca1e5 "test: overlay: Add unit test for stacked overlay", the U-Boot build fails for sandbox with the error below. I guess it's due to this commit. Does U-Boot now intentionally rely on a newer dtc or is this an accident?

   DTC     test/overlay/test-fdt-base.dtb
   LD      lib/libfdt/built-in.o
   CC      lib/charset.o
   CC      lib/rsa/rsa-verify.o

Quoted 7 lines

dtc: invalid option -- '@'
Usage: dtc [options] <input file>

Options: -[qI:O:o:V:d:R:S:p:fb:i:H:sW:E:hv]
-q, --quiet
Quiet: -q suppress warnings, -qq errors, -qqq all
...

Related, the following check in Makefile doesn't trigger:

checkdtc:

	@if test $(call dtc-version) -lt 0104; then \
		echo '*** Your dtc is too old, please upgrade to dtc 1.4 or newer'; \
		false; \
	fi

Quoted 2 lines

... because I have dtc 1.4.0. If U-Boot requires a new version now, that Makefile chunk should be updated.

Ah, this is what needs updating, yes, it needs to cehck for 1.4.3 or newer.

Quoted 42 lines · Tom Rini

Quoted 41 lines · Stephen Warren

Quoted 24 lines · Stephen Warren

scripts/Makefile.lib $(obj)/%.dtb: $(src)/%.dts FORCE · line 335

Quoted 13 lines · Pantelis Antoniou

Special rule for dtbo generation

scripts/Makefile.lib +9 -0

 
+quiet_cmd_dtco = DTCO    $@
+# Rule for objects only; does not put specific u-boot include at the end
+# No generation of assembly file either
+# Modified for U-Boot
+cmd_dtco = mkdir -p $(dir ${dtc-tmp}) ; \
+    $(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) - ; \
+    $(DTC) -@ -O dtb -o $@ -b 0 \
+        -i $(dir $<) $(DTC_FLAGS) \
+        -d $(depfile).dtc.tmp $(dtc-tmp) ; \

As of u-boot-fdt/master commit 503afc3ca1e5 "test: overlay: Add unit test for stacked overlay", the U-Boot build fails for sandbox with the error below. I guess it's due to this commit. Does U-Boot now intentionally rely on a newer dtc or is this an accident?

  DTC     test/overlay/test-fdt-base.dtb
  LD      lib/libfdt/built-in.o
  CC      lib/charset.o
  CC      lib/rsa/rsa-verify.o

Quoted 7 lines

dtc: invalid option -- '@'
Usage: dtc [options] <input file>

Options: -[qI:O:o:V:d:R:S:p:fb:i:H:sW:E:hv]
-q, --quiet
Quiet: -q suppress warnings, -qq errors, -qqq all
...

Related, the following check in Makefile doesn't trigger:

checkdtc:

	@if test $(call dtc-version) -lt 0104; then \
		echo '*** Your dtc is too old, please upgrade to dtc 1.4 or newer'; \
		false; \
	fi

Quoted 5 lines

Quoted 2 lines

... because I have dtc 1.4.0. If U-Boot requires a new version now, that Makefile chunk should be updated.

Ah, this is what needs updating, yes, it needs to cehck for 1.4.3 or newer.

Related: The Travis systems run Ubuntu 14.04 (same as my systems) and hence have dtc 1.4.0. If u-boot-fdt/master is merged into u-boot/master, the build will break in Travis.

The logic in .travis.yml to use a newer dtc (built from upstream dtc source) is disabled since apparently more recent dtc spew lots of warnings and make the logs too long for Travis. Ideally, .travis.yml would check out and build the exact same dtc version/tag that Makefile dictates as the minimum, but I'm not sure that's possible given the log spew issue.

Quoted 5 lines · Tom Rini

Quoted 4 lines · Stephen Warren

Quoted 3 lines · Stephen Warren

Quoted 1 line · Pantelis Antoniou

Special rule for dtbo generation

Add unit tests for sandbox default config.

Signed-off-by Pantelis Antoniou <[email protected]>

---
 configs/sandbox_defconfig | 2 ++
 1 file changed, 2 insertions(+)

Add unit tests for sandbox default config.

Signed-off-by Pantelis Antoniou <[email protected]>

---
 configs/sandbox_defconfig | 2 ++
 1 file changed, 2 insertions(+)

fdt_getprop_u32 is not exported and it's different than what the unit test uses. Rename u32 prop access methods to something that's unit test specific.

Signed-off-by Pantelis Antoniou <[email protected]>

---
 test/overlay/cmd_ut_overlay.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

fdt_getprop_u32 is not exported and it's different than what the unit test uses. Rename u32 prop access methods to something that's unit test specific.

Signed-off-by Pantelis Antoniou <[email protected]>

---
 test/overlay/cmd_ut_overlay.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

Verify that stacked overlays work.

Signed-off-by Pantelis Antoniou <[email protected]>

---
 test/overlay/Makefile                     |  1 +
 test/overlay/cmd_ut_overlay.c             | 34 ++++++++++++++++++++++++++++++-
 test/overlay/test-fdt-overlay-stacked.dts | 21 +++++++++++++++++++
 3 files changed, 55 insertions(+), 1 deletion(-)
 create mode 100644 test/overlay/test-fdt-overlay-stacked.dts

Verify that stacked overlays work.

Signed-off-by Pantelis Antoniou <[email protected]>

---
 test/overlay/Makefile                     |  1 +
 test/overlay/cmd_ut_overlay.c             | 34 ++++++++++++++++++++++++++++++-
 test/overlay/test-fdt-overlay-stacked.dts | 21 +++++++++++++++++++
 3 files changed, 55 insertions(+), 1 deletion(-)
 create mode 100644 test/overlay/test-fdt-overlay-stacked.dts

This patchset allows uboot to handle overlays in a manner that uses a base DT blob and an arbitrary number of DT overlays blobs.

While it is intended to be used with FIT images since handling a multitude of device tree blobs manually is a chore, manual fdt overlay application is supported and described.

Changes since v2:
* Addressed review comments by splitting patches and documenting methods.
* Patch preserving extra configuration on fit-load

The patchset is available at

https://github.com/pantoniou/u-boot/tree/uboot-overlays

and is against mainline u-boot as pulled today, 4/9/2017.

Franklin S Cooper Jr (1):
doc: overlays: Tweak documentation regarding overlays

Pantelis Antoniou (13):
Introduce fdt_setprop_placeholder() method
fdt: Introduce helper method fdt_overlay_apply_verbose()
fdt: Switch to using the verbose overlay application method
fdt: Allow stacked overlays phandle references
fit: Allow multiple images per property
fit: Do not throw away extra configuration on fit_image_load()
fit: Introduce methods for applying overlays on fit-load
fit: fdt overlays doc
doc: Document how to apply fdt overlays
dtbo: make dtbos special
config: sandbox: Add unit tests
ut: fix fdt_getprop_u32() change
test: overlay: Add unit test for stacked overlay

 cmd/fdt.c                                    |   7 +-
 common/fdt_support.c                         |  31 ++++
 common/image-fdt.c                           |   7 +-
 common/image-fit.c                           | 210 ++++++++++++++++++++++--
 configs/sandbox_defconfig                    |   2 +
 doc/README.fdt-overlays                      | 114 ++++++++++++++
 doc/uImage.FIT/command_syntax_extensions.txt |  12 +-
 doc/uImage.FIT/overlay-fdt-boot.txt          | 225 ++++++++++++++++++++++++++
 doc/uImage.FIT/source_file_format.txt        |   6 +-
 include/fdt_support.h                        |   2 +
 include/image.h                              |  25 +++
 lib/libfdt/fdt_overlay.c                     | 228 ++++++++++++++++++++++++---
 lib/libfdt/fdt_rw.c                          |  20 ++-
 lib/libfdt/libfdt.h                          |  31 ++++
 scripts/Makefile.lib                         |  17 ++
 test/overlay/Makefile                        |   1 +
 test/overlay/cmd_ut_overlay.c                |  50 ++++--
 test/overlay/test-fdt-overlay-stacked.dts    |  21 +++
 18 files changed, 953 insertions(+), 56 deletions(-)
 create mode 100644 doc/README.fdt-overlays
 create mode 100644 doc/uImage.FIT/overlay-fdt-boot.txt
 create mode 100644 test/overlay/test-fdt-overlay-stacked.dts

--
2.1.4

Hi Pantelis,

Quoted 20 lines · Pantelis Antoniou

This patchset allows uboot to handle overlays in a manner that uses a base DT blob and an arbitrary number of DT overlays blobs.

While it is intended to be used with FIT images since handling a multitude of device tree blobs manually is a chore, manual fdt overlay application is supported and described.

Changes since v2:
* Addressed review comments by splitting patches and documenting methods.
* Patch preserving extra configuration on fit-load

The patchset is available at

https://github.com/pantoniou/u-boot/tree/uboot-overlays

and is against mainline u-boot as pulled today, 4/9/2017.

Franklin S Cooper Jr (1):
doc: overlays: Tweak documentation regarding overlays

Quoted 14 lines

Pantelis Antoniou (13):
Introduce fdt_setprop_placeholder() method
fdt: Introduce helper method fdt_overlay_apply_verbose()
fdt: Switch to using the verbose overlay application method
fdt: Allow stacked overlays phandle references
fit: Allow multiple images per property
fit: Do not throw away extra configuration on fit_image_load()
fit: Introduce methods for applying overlays on fit-load
fit: fdt overlays doc
doc: Document how to apply fdt overlays
dtbo: make dtbos special
config: sandbox: Add unit tests
ut: fix fdt_getprop_u32() change
test: overlay: Add unit test for stacked overlay

I applied this series (to u-boot-fdt/testing) but it requires a later version of dtc than we use in our travis tests:

https://travis-ci.org/sglass68/u-boot/jobs/275239527

Quoted 39 lines · Simon Glass

Hi Pantelis,

Quoted 34 lines · Pantelis Antoniou

This patchset allows uboot to handle overlays in a manner that uses a base DT blob and an arbitrary number of DT overlays blobs.

While it is intended to be used with FIT images since handling a multitude of device tree blobs manually is a chore, manual fdt overlay application is supported and described.

Changes since v2:
* Addressed review comments by splitting patches and documenting methods.
* Patch preserving extra configuration on fit-load

The patchset is available at

https://github.com/pantoniou/u-boot/tree/uboot-overlays

and is against mainline u-boot as pulled today, 4/9/2017.

Franklin S Cooper Jr (1):
doc: overlays: Tweak documentation regarding overlays

Pantelis Antoniou (13):
Introduce fdt_setprop_placeholder() method
fdt: Introduce helper method fdt_overlay_apply_verbose()
fdt: Switch to using the verbose overlay application method
fdt: Allow stacked overlays phandle references
fit: Allow multiple images per property
fit: Do not throw away extra configuration on fit_image_load()
fit: Introduce methods for applying overlays on fit-load
fit: fdt overlays doc
doc: Document how to apply fdt overlays
dtbo: make dtbos special
config: sandbox: Add unit tests
ut: fix fdt_getprop_u32() change
test: overlay: Add unit test for stacked overlay

Quoted 4 lines

I applied this series (to u-boot-fdt/testing) but it requires a later version of dtc than we use in our travis tests:

https://travis-ci.org/sglass68/u-boot/jobs/275239527

The -@ flag has been around for a long time, relatively speaking. Is there a problem in our .travis.yml perhaps where it's not picking up the dtc we're building from git?

Quoted 40 lines · Tom Rini

Quoted 39 lines · Simon Glass

Hi Pantelis,

Quoted 34 lines · Pantelis Antoniou

This patchset allows uboot to handle overlays in a manner that uses a base DT blob and an arbitrary number of DT overlays blobs.

While it is intended to be used with FIT images since handling a multitude of device tree blobs manually is a chore, manual fdt overlay application is supported and described.

Changes since v2:
* Addressed review comments by splitting patches and documenting methods.
* Patch preserving extra configuration on fit-load

The patchset is available at

https://github.com/pantoniou/u-boot/tree/uboot-overlays

and is against mainline u-boot as pulled today, 4/9/2017.

Franklin S Cooper Jr (1):
doc: overlays: Tweak documentation regarding overlays

Pantelis Antoniou (13):
Introduce fdt_setprop_placeholder() method
fdt: Introduce helper method fdt_overlay_apply_verbose()
fdt: Switch to using the verbose overlay application method
fdt: Allow stacked overlays phandle references
fit: Allow multiple images per property
fit: Do not throw away extra configuration on fit_image_load()
fit: Introduce methods for applying overlays on fit-load
fit: fdt overlays doc
doc: Document how to apply fdt overlays
dtbo: make dtbos special
config: sandbox: Add unit tests
ut: fix fdt_getprop_u32() change
test: overlay: Add unit test for stacked overlay

Quoted 8 lines

Quoted 4 lines

I applied this series (to u-boot-fdt/testing) but it requires a later version of dtc than we use in our travis tests:

https://travis-ci.org/sglass68/u-boot/jobs/275239527

The -@ flag has been around for a long time, relatively speaking. Is there a problem in our .travis.yml perhaps where it's not picking up the dtc we're building from git?

Yeah, it's not:
https://travis-ci.org/trini/u-boot/builds/275424745

I bet this got broken recently too, I'll see what we need to fix in the travis environment.

Hi Pantelis,

Quoted 20 lines · Pantelis Antoniou

This patchset allows uboot to handle overlays in a manner that uses a base DT blob and an arbitrary number of DT overlays blobs.

While it is intended to be used with FIT images since handling a multitude of device tree blobs manually is a chore, manual fdt overlay application is supported and described.

Changes since v2:
* Addressed review comments by splitting patches and documenting methods.
* Patch preserving extra configuration on fit-load

The patchset is available at

https://github.com/pantoniou/u-boot/tree/uboot-overlays

and is against mainline u-boot as pulled today, 4/9/2017.

Franklin S Cooper Jr (1):
doc: overlays: Tweak documentation regarding overlays

Quoted 14 lines

Pantelis Antoniou (13):
Introduce fdt_setprop_placeholder() method
fdt: Introduce helper method fdt_overlay_apply_verbose()
fdt: Switch to using the verbose overlay application method
fdt: Allow stacked overlays phandle references
fit: Allow multiple images per property
fit: Do not throw away extra configuration on fit_image_load()
fit: Introduce methods for applying overlays on fit-load
fit: fdt overlays doc
doc: Document how to apply fdt overlays
dtbo: make dtbos special
config: sandbox: Add unit tests
ut: fix fdt_getprop_u32() change
test: overlay: Add unit test for stacked overlay

I applied this series (to u-boot-fdt/testing) but it requires a later version of dtc than we use in our travis tests:

https://travis-ci.org/sglass68/u-boot/jobs/275239527

Could you please take a look? I don't think I can pull this in until I know it can make it to mainline.

The good news is that with the new dtc my buildman test went through with no errors.