[U-Boot] [RFC PATCH v1 0/9] Add support for applications of overlays in SPL

[U-Boot] [RFC PATCH v1 0/9] Add support for applications of overlays in SPL

[Jean-Jacques Hiblot]

The purpose of this series is to provide the SPL with ability to apply
overlays for u-boot. this is only a RFC so far, to get a feedback on the
approach.

Our use-case is the support of the daughter boards of the AM65x EVM. In
Linux, each board is supported by a unique overlay. The presence of the
boards is detected at runtime, and some useful features (like USB) are
implemented on those daughter boards. Instead of providing multiple dtbs
and fall in a combinatorial pit, we propose to use DT overlays.

The first 4 patches are small fixes/improvement related to the build.
Patch #5 may be a bit controversial. It basically replaces u-boot.img with
a symlink to u-boot.itb in case we use a "complex" FIT (ie: if
SPL_FIT_SOURCE or SPL_FIT_GENERATOR are set)

Patch #6 and #7 are the core support for DTB application in the SPL. Based
on a patch posted by Michal Simek a few weeks ago. The list of overlays is
read from the "fdt" of the configuration chosen in the ITB (same property
as for the DTB):
  configurations {
     default = "conf-1";
     conf-1 {
       description = "dra76-evm";
       firmware = "firmware-1";
       fdt = "fdt-1", "overlay-1";
      };
  }


Patch #8 adds a way to dynamically select the DT overlays. That is were we
would use HW detection to select the required overlays. In that case, the
board-level code tells what overlay it needs (it gives the name of the
node).

Patch #9 is not required, but demonstrates on a DRA76-evm how this series
can be used.


Jean-Jacques Hiblot (8):
  dtbo: also generate dtbo from dtso
  Makefile.lib: include /__symbols__ in dtb if OF_LIBFDT_OVERLAY is
    enabled
  Makefile: Fix u-boot.itb generation when building outside the source
    tree
  Makefile: Pass the board name to the FIT generator scripts
  Makefile: use custom ITS to build u-boot.img if SPL_FIT_SOURCE or
    SPL_FIT_GENERATOR are set
  spl: fit: Allow calling spl_load_fit_image() to only get the image
    size
  sp: fit: Allow the board to dynamically select the DTB overlays it
    needs.
  !!! TEMP !!! For demonstration only !!! DRA76: Usage of overlays in
    SPL

Michal Simek (1):
  spl: fit: Add support for applying DT overlay

 Makefile                                      |  20 ++-
 arch/arm/dts/Makefile                         |   2 +-
 arch/arm/dts/dra76-evm-dummy.dtso             |  14 +++
 arch/arm/dts/dra76-evm-dummy2.dtso            |  15 +++
 arch/arm/mach-imx/mkimage_fit_atf.sh          |   3 +-
 arch/arm/mach-rockchip/make_fit_atf.py        |   5 +-
 .../lion_rk3368/fit_spl_atf.its               |   6 +-
 .../puma_rk3399/fit_spl_atf.its               |   8 +-
 board/ti/dra7xx/evm.c                         |  30 +++++
 board/ti/dra7xx/evm.its                       |  48 ++++++++
 common/spl/spl_fit.c                          | 114 +++++++++++++++++-
 configs/dra7xx_evm_defconfig                  |   2 +
 include/spl.h                                 |  20 +++
 scripts/Makefile.lib                          |   7 ++
 14 files changed, 273 insertions(+), 21 deletions(-)
 create mode 100644 arch/arm/dts/dra76-evm-dummy.dtso
 create mode 100644 arch/arm/dts/dra76-evm-dummy2.dtso
 create mode 100644 board/ti/dra7xx/evm.its

-- 
2.17.1

[U-Boot] [RFC PATCH v1 1/9] dtbo: also generate dtbo from dtso

[Jean-Jacques Hiblot]

Some overlay source files use a "dtso" extension instead of a "dts"
extension.

Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
---

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

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 70de9bb13a..e4c6077fea 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -327,6 +327,9 @@ cmd_dtco = mkdir -p $(dir ${dtc-tmp}) ; \
 $(obj)/%.dtbo: $(src)/%.dts FORCE
 	$(call if_changed_dep,dtco)
 
+$(obj)/%.dtbo: $(src)/%.dtso FORCE
+	$(call if_changed_dep,dtco)
+
 # Fonts
 # ---------------------------------------------------------------------------
 
-- 
2.17.1

[U-Boot] [RFC PATCH v1 1/9] dtbo: also generate dtbo from dtso

[Michal Simek]

On 22. 03. 19 15:39, Jean-Jacques Hiblot wrote:
> Some overlay source files use a "dtso" extension instead of a "dts"
> extension.
> 
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
> ---
> 
>  scripts/Makefile.lib | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index 70de9bb13a..e4c6077fea 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -327,6 +327,9 @@ cmd_dtco = mkdir -p $(dir ${dtc-tmp}) ; \
>  $(obj)/%.dtbo: $(src)/%.dts FORCE
>  	$(call if_changed_dep,dtco)
>  
> +$(obj)/%.dtbo: $(src)/%.dtso FORCE
> +	$(call if_changed_dep,dtco)
> +
>  # Fonts
>  # ---------------------------------------------------------------------------
>  
> 

This is the first time I hear about dtso. Will be good to have this
covered in devicetree-specification.

Thanks,
Michal

[U-Boot] [RFC PATCH v1 2/9] Makefile.lib: include /__symbols__ in dtb if OF_LIBFDT_OVERLAY is enabled

[Jean-Jacques Hiblot]

In order to apply an overlay to a DTB. The DTB must have been generated
with the option '-@'.

Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
---

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

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index e4c6077fea..85366b7f27 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -292,6 +292,10 @@ cmd_dt_S_dtb=						\
 $(obj)/%.dtb.S: $(obj)/%.dtb
 	$(call cmd,dt_S_dtb)
 
+ifeq ($(CONFIG_OF_LIBFDT_OVERLAY),y)
+DTC_FLAGS += -@
+endif
+
 quiet_cmd_dtc = DTC     $@
 # Modified for U-Boot
 # Bring in any U-Boot-specific include at the end of the file
-- 
2.17.1

[U-Boot] [RFC PATCH v1 2/9] Makefile.lib: include /__symbols__ in dtb if OF_LIBFDT_OVERLAY is enabled

[Michal Simek]

On 22. 03. 19 15:39, Jean-Jacques Hiblot wrote:
> In order to apply an overlay to a DTB. The DTB must have been generated
> with the option '-@'.
> 
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
> ---
> 
>  scripts/Makefile.lib | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index e4c6077fea..85366b7f27 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -292,6 +292,10 @@ cmd_dt_S_dtb=						\
>  $(obj)/%.dtb.S: $(obj)/%.dtb
>  	$(call cmd,dt_S_dtb)
>  
> +ifeq ($(CONFIG_OF_LIBFDT_OVERLAY),y)
> +DTC_FLAGS += -@
> +endif
> +
>  quiet_cmd_dtc = DTC     $@
>  # Modified for U-Boot
>  # Bring in any U-Boot-specific include at the end of the file
> 

I wanted to send it long time ago. Definitely this is good to do.

Thanks,
Michal

[U-Boot] [RFC PATCH v1 3/9] Makefile: Fix u-boot.itb generation when building outside the source tree

[Jean-Jacques Hiblot]

Include the object tree and the source tree in the search path of the
FIT compîler (dtc). This allows to use paths relative to the root of the
source or object trees in the ITS instead of working backward from the
actual location of the ITS.
It also allows to use a build directory different of the source directory.

Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
---

 Makefile                                            | 5 +++--
 board/theobroma-systems/lion_rk3368/fit_spl_atf.its | 6 +++---
 board/theobroma-systems/puma_rk3399/fit_spl_atf.its | 8 ++++----
 3 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/Makefile b/Makefile
index c52a33b403..a95255ebef 100644
--- a/Makefile
+++ b/Makefile
@@ -893,7 +893,8 @@ cmd_mkimage = $(objtree)/tools/mkimage $(MKIMAGEFLAGS_$(@F)) -d $< $@ \
 	>$(MKIMAGEOUTPUT) $(if $(KBUILD_VERBOSE:0=), && cat $(MKIMAGEOUTPUT))
 
 quiet_cmd_mkfitimage = MKIMAGE $@
-cmd_mkfitimage = $(objtree)/tools/mkimage $(MKIMAGEFLAGS_$(@F)) -f $(U_BOOT_ITS) -E -p $(CONFIG_FIT_EXTERNAL_OFFSET) $@\
+cmd_mkfitimage = $(objtree)/tools/mkimage $(MKIMAGEFLAGS_$(@F)) -D "-i $(obj) -i $(src)"\
+	-f $(U_BOOT_ITS) -E $@ -p $(CONFIG_FIT_EXTERNAL_OFFSET)\
 	>$(MKIMAGEOUTPUT) $(if $(KBUILD_VERBOSE:0=), && cat $(MKIMAGEOUTPUT))
 
 quiet_cmd_cat = CAT     $@
@@ -1151,7 +1152,7 @@ endif
 # Boards with more complex image requirments can provide an .its source file
 # or a generator script
 ifneq ($(CONFIG_SPL_FIT_SOURCE),"")
-U_BOOT_ITS = $(subst ",,$(CONFIG_SPL_FIT_SOURCE))
+U_BOOT_ITS = $(src)/$(subst ",,$(CONFIG_SPL_FIT_SOURCE))
 else
 ifneq ($(CONFIG_SPL_FIT_GENERATOR),"")
 U_BOOT_ITS := u-boot.its
diff --git a/board/theobroma-systems/lion_rk3368/fit_spl_atf.its b/board/theobroma-systems/lion_rk3368/fit_spl_atf.its
index 6b04fbc7da..69202a117b 100644
--- a/board/theobroma-systems/lion_rk3368/fit_spl_atf.its
+++ b/board/theobroma-systems/lion_rk3368/fit_spl_atf.its
@@ -14,7 +14,7 @@
 	images {
 		uboot {
 			description = "U-Boot (64-bit)";
-			data = /incbin/("../../../u-boot-nodtb.bin");
+			data = /incbin/("u-boot-nodtb.bin");
 			type = "standalone";
 			os = "U-Boot";
 			arch = "arm64";
@@ -23,7 +23,7 @@
 		};
 		atf {
 			description = "ARM Trusted Firmware";
-			data = /incbin/("../../../bl31-rk3368.bin");
+			data = /incbin/("bl31-rk3368.bin");
 			type = "firmware";
 			os = "arm-trusted-firmware";
 			arch = "arm64";
@@ -34,7 +34,7 @@
 
 		fdt {
 			description = "RK3368-uQ7 (Lion) flat device-tree";
-			data = /incbin/("../../../u-boot.dtb");
+			data = /incbin/("u-boot.dtb");
 			type = "flat_dt";
 			compression = "none";
 		};
diff --git a/board/theobroma-systems/puma_rk3399/fit_spl_atf.its b/board/theobroma-systems/puma_rk3399/fit_spl_atf.its
index 530f059f3d..659183ecc1 100644
--- a/board/theobroma-systems/puma_rk3399/fit_spl_atf.its
+++ b/board/theobroma-systems/puma_rk3399/fit_spl_atf.its
@@ -14,7 +14,7 @@
 	images {
 		uboot {
 			description = "U-Boot (64-bit)";
-			data = /incbin/("../../../u-boot-nodtb.bin");
+			data = /incbin/("u-boot-nodtb.bin");
 			type = "standalone";
 			os = "U-Boot";
 			arch = "arm64";
@@ -23,7 +23,7 @@
 		};
 		atf {
 			description = "ARM Trusted Firmware";
-			data = /incbin/("../../../bl31-rk3399.bin");
+			data = /incbin/("bl31-rk3399.bin");
 			type = "firmware";
 			arch = "arm64";
 			os = "arm-trusted-firmware";
@@ -33,14 +33,14 @@
 		};
 		pmu {
 		        description = "Cortex-M0 firmware";
-			data = /incbin/("../../../rk3399m0.bin");
+			data = /incbin/("rk3399m0.bin");
 			type = "pmu-firmware";
 			compression = "none";
 			load = <0x180000>;
                 };
 		fdt {
 			description = "RK3399-Q7 (Puma) flat device-tree";
-			data = /incbin/("../../../u-boot.dtb");
+			data = /incbin/("u-boot.dtb");
 			type = "flat_dt";
 			compression = "none";
 		};
-- 
2.17.1

[U-Boot] [RFC PATCH v1 3/9] Makefile: Fix u-boot.itb generation when building outside the source tree

[Simon Glass]

On Fri, 22 Mar 2019 at 08:39, Jean-Jacques Hiblot <jjhiblot@ti.com> wrote:
>
> Include the object tree and the source tree in the search path of the
> FIT compîler (dtc). This allows to use paths relative to the root of the
> source or object trees in the ITS instead of working backward from the
> actual location of the ITS.
> It also allows to use a build directory different of the source directory.
>
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
> ---
>
>  Makefile                                            | 5 +++--
>  board/theobroma-systems/lion_rk3368/fit_spl_atf.its | 6 +++---
>  board/theobroma-systems/puma_rk3399/fit_spl_atf.its | 8 ++++----
>  3 files changed, 10 insertions(+), 9 deletions(-)
>

Reviewed-by: Simon Glass <sjg@chromium.org>

But I think the 'Makefile' change should be in a separate patch from
board-specific stuff.

[U-Boot] [RFC PATCH v1 4/9] Makefile: Pass the board name to the FIT generator scripts

[Jean-Jacques Hiblot]

Currently the FIT generator scripts are passed only a list of dtbs.
However some platforms may also require information about the board itself.

Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
---

 Makefile                               | 2 +-
 arch/arm/mach-imx/mkimage_fit_atf.sh   | 3 ++-
 arch/arm/mach-rockchip/make_fit_atf.py | 5 +++--
 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/Makefile b/Makefile
index a95255ebef..8616382f42 100644
--- a/Makefile
+++ b/Makefile
@@ -1163,7 +1163,7 @@ ifeq ($(CONFIG_SPL_FIT_GENERATOR),"arch/arm/mach-rockchip/make_fit_atf.py")
 U_BOOT_ITS_DEPS += u-boot
 endif
 $(U_BOOT_ITS): $(U_BOOT_ITS_DEPS) FORCE
-	$(srctree)/$(CONFIG_SPL_FIT_GENERATOR) \
+	$(srctree)/$(subst ",,$(CONFIG_SPL_FIT_GENERATOR)) $(BOARD) \
 	$(patsubst %,arch/$(ARCH)/dts/%.dtb,$(subst ",,$(CONFIG_OF_LIST))) > $@
 endif
 endif
diff --git a/arch/arm/mach-imx/mkimage_fit_atf.sh b/arch/arm/mach-imx/mkimage_fit_atf.sh
index 38c9858e84..45b325665e 100755
--- a/arch/arm/mach-imx/mkimage_fit_atf.sh
+++ b/arch/arm/mach-imx/mkimage_fit_atf.sh
@@ -4,7 +4,7 @@
 # script to generate FIT image source for i.MX8MQ boards with
 # ARM Trusted Firmware and multiple device trees (given on the command line)
 #
-# usage: $0 <dt_name> [<dt_name> [<dt_name] ...]
+# usage: $0 <board> <dt_name> [<dt_name> [<dt_name] ...]
 
 [ -z "$BL31" ] && BL31="bl31.bin"
 [ -z "$TEE_LOAD_ADDR" ] && TEE_LOAD_ADDR="0xfe000000"
@@ -39,6 +39,7 @@ else
 	ls -lct u-boot-nodtb.bin | awk '{print $5}' >&2
 fi
 
+shift
 for dtname in $*
 do
 	echo "$dtname size: " >&2
diff --git a/arch/arm/mach-rockchip/make_fit_atf.py b/arch/arm/mach-rockchip/make_fit_atf.py
index d1faff1957..4138b04a37 100755
--- a/arch/arm/mach-rockchip/make_fit_atf.py
+++ b/arch/arm/mach-rockchip/make_fit_atf.py
@@ -4,7 +4,7 @@ A script to generate FIT image source for rockchip boards
 with ARM Trusted Firmware
 and multiple device trees (given on the command line)
 
-usage: $0 <dt_name> [<dt_name> [<dt_name] ...]
+usage: $0 <board> <dt_name> [<dt_name> [<dt_name] ...]
 """
 
 import os
@@ -209,7 +209,8 @@ def main():
             print(__doc__)
             sys.exit(2)
 
-    dtbs = args
+    board = args[0]
+    dtbs = args[1:]
     #get_bl31_segments_info("u-boot")
     #get_bl31_segments_info("bl31.elf")
 
-- 
2.17.1

[U-Boot] [RFC PATCH v1 4/9] Makefile: Pass the board name to the FIT generator scripts

[Simon Glass]

On Fri, 22 Mar 2019 at 08:39, Jean-Jacques Hiblot <jjhiblot@ti.com> wrote:
>
> Currently the FIT generator scripts are passed only a list of dtbs.
> However some platforms may also require information about the board itself.
>
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
> ---
>
>  Makefile                               | 2 +-
>  arch/arm/mach-imx/mkimage_fit_atf.sh   | 3 ++-
>  arch/arm/mach-rockchip/make_fit_atf.py | 5 +++--
>  3 files changed, 6 insertions(+), 4 deletions(-)

Reviewed-by: Simon Glass <sjg@chromium.org>

[U-Boot] [RFC PATCH v1 5/9] Makefile: use custom ITS to build u-boot.img if SPL_FIT_SOURCE or SPL_FIT_GENERATOR are set

[Jean-Jacques Hiblot]

If SPL_FIT_SOURCE or SPL_FIT_GENERATOR are set, then the default output
image should be built using the provided/generated ITS, not using the
default template implemented by mkimage.
In that case, make u-boot.img a symbolic link to u-boot.itb

Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
---

 Makefile | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 8616382f42..2d4eebc01b 100644
--- a/Makefile
+++ b/Makefile
@@ -888,6 +888,9 @@ cmd_efipayload = $(OBJCOPY) -I binary -O $(EFIPAYLOAD_BFDTARGET) -B $(EFIPAYLOAD
 
 MKIMAGEOUTPUT ?= /dev/null
 
+quiet_cmd_ln = LN      $@ -> $<
+cmd_ln = ln -f -s $< $@
+
 quiet_cmd_mkimage = MKIMAGE $@
 cmd_mkimage = $(objtree)/tools/mkimage $(MKIMAGEFLAGS_$(@F)) -d $< $@ \
 	>$(MKIMAGEOUTPUT) $(if $(KBUILD_VERBOSE:0=), && cat $(MKIMAGEOUTPUT))
@@ -1196,15 +1199,23 @@ MKIMAGEFLAGS_u-boot-spl.kwb = -n $(srctree)/$(CONFIG_SYS_KWD_CONFIG:"%"=%) \
 MKIMAGEFLAGS_u-boot.pbl = -n $(srctree)/$(CONFIG_SYS_FSL_PBL_RCW:"%"=%) \
 		-R $(srctree)/$(CONFIG_SYS_FSL_PBL_PBI:"%"=%) -T pblimage
 
-u-boot-dtb.img u-boot.img u-boot.kwb u-boot.pbl u-boot-ivt.img: \
+u-boot-dtb.img u-boot.kwb u-boot.pbl u-boot-ivt.img: \
 		$(if $(CONFIG_SPL_LOAD_FIT),u-boot-nodtb.bin dts/dt.dtb,u-boot.bin) FORCE
 	$(call if_changed,mkimage)
 	$(BOARD_SIZE_CHECK)
 
+ifndef U_BOOT_ITS
+u-boot.img: $(if $(CONFIG_SPL_LOAD_FIT),u-boot-nodtb.bin dts/dt.dtb,u-boot.bin) FORCE
+	$(call if_changed,mkimage)
+else
 u-boot.itb: u-boot-nodtb.bin dts/dt.dtb $(U_BOOT_ITS) FORCE
 	$(call if_changed,mkfitimage)
 	$(BOARD_SIZE_CHECK)
 
+u-boot.img: u-boot.itb
+	$(call if_changed,ln)
+endif
+
 u-boot-spl.kwb: u-boot.img spl/u-boot-spl.bin FORCE
 	$(call if_changed,mkimage)
 
-- 
2.17.1

[U-Boot] [RFC PATCH v1 5/9] Makefile: use custom ITS to build u-boot.img if SPL_FIT_SOURCE or SPL_FIT_GENERATOR are set

[Simon Glass]

On Fri, 22 Mar 2019 at 08:39, Jean-Jacques Hiblot <jjhiblot@ti.com> wrote:
>
> If SPL_FIT_SOURCE or SPL_FIT_GENERATOR are set, then the default output
> image should be built using the provided/generated ITS, not using the
> default template implemented by mkimage.
> In that case, make u-boot.img a symbolic link to u-boot.itb
>
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
> ---
>
>  Makefile | 13 ++++++++++++-
>  1 file changed, 12 insertions(+), 1 deletion(-)

Reviewed-by: Simon Glass <sjg@chromium.org>

[U-Boot] [RFC PATCH v1 6/9] spl: fit: Allow calling spl_load_fit_image() to only get the image size

[Jean-Jacques Hiblot]

To allow for dynamic allocation of the area where the image will be loaded,
adapt spl_load_fit_image() to be able to get the size of the image without
doing to the actual load.

Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
---

 common/spl/spl_fit.c | 26 +++++++++++++++++++++-----
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index db436268cb..90bf458ee8 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -164,12 +164,15 @@ static int get_aligned_image_size(struct spl_load_info *info, int data_size,
  *		If the FIT node does not contain a "load" (address) property,
  *		the image gets loaded to the address pointed to by the
  *		load_addr member in this struct.
+ * @no_load:	If true, the data is not loaded from the medium. Used to get
+ *		the size of the data in the case of a dynamic allocation of
+ *		the memory.
  *
  * Return:	0 on success or a negative error number.
  */
 static int spl_load_fit_image(struct spl_load_info *info, ulong sector,
 			      void *fit, ulong base_offset, int node,
-			      struct spl_image_info *image_info)
+			      struct spl_image_info *image_info, bool no_load)
 {
 	int offset;
 	size_t length;
@@ -216,7 +219,20 @@ static int spl_load_fit_image(struct spl_load_info *info, ulong sector,
 
 		load_ptr = (load_addr + align_len) & ~align_len;
 		length = len;
+	} else {
+		/* Embedded data */
+		if (fit_image_get_data(fit, node, &data, &length)) {
+			puts("Cannot get image data/size\n");
+			return -ENOENT;
+		}
+	}
 
+	if (no_load && image_info) {
+		image_info->size = length;
+		return 0;
+	}
+
+	if (external_data) {
 		overhead = get_aligned_image_overhead(info, offset);
 		nr_sectors = get_aligned_image_size(info, length, offset);
 
@@ -293,7 +309,7 @@ static int spl_fit_append_fdt(struct spl_image_info *spl_image,
 	 */
 	image_info.load_addr = spl_image->load_addr + spl_image->size;
 	ret = spl_load_fit_image(info, sector, fit, base_offset, node,
-				 &image_info);
+				 &image_info, false);
 
 	if (ret < 0)
 		return ret;
@@ -401,7 +417,7 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
 	if (node >= 0) {
 		/* Load the image and set up the spl_image structure */
 		ret = spl_load_fit_image(info, sector, fit, base_offset, node,
-					 spl_image);
+					 spl_image, false);
 		if (ret) {
 			printf("%s: Cannot load the FPGA: %i\n", __func__, ret);
 			return ret;
@@ -453,7 +469,7 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
 
 	/* Load the image and set up the spl_image structure */
 	ret = spl_load_fit_image(info, sector, fit, base_offset, node,
-				 spl_image);
+				 spl_image, false);
 	if (ret)
 		return ret;
 
@@ -485,7 +501,7 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
 			break;
 
 		ret = spl_load_fit_image(info, sector, fit, base_offset, node,
-					 &image_info);
+					 &image_info, false);
 		if (ret < 0)
 			continue;
 
-- 
2.17.1

[U-Boot] [RFC PATCH v1 6/9] spl: fit: Allow calling spl_load_fit_image() to only get the image size

[Michal Simek]

On 22. 03. 19 15:39, Jean-Jacques Hiblot wrote:
> To allow for dynamic allocation of the area where the image will be loaded,
> adapt spl_load_fit_image() to be able to get the size of the image without
> doing to the actual load.
> 
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
> ---
> 
>  common/spl/spl_fit.c | 26 +++++++++++++++++++++-----
>  1 file changed, 21 insertions(+), 5 deletions(-)
> 
> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> index db436268cb..90bf458ee8 100644
> --- a/common/spl/spl_fit.c
> +++ b/common/spl/spl_fit.c
> @@ -164,12 +164,15 @@ static int get_aligned_image_size(struct spl_load_info *info, int data_size,
>   *		If the FIT node does not contain a "load" (address) property,
>   *		the image gets loaded to the address pointed to by the
>   *		load_addr member in this struct.
> + * @no_load:	If true, the data is not loaded from the medium. Used to get
> + *		the size of the data in the case of a dynamic allocation of
> + *		the memory.
>   *
>   * Return:	0 on success or a negative error number.
>   */
>  static int spl_load_fit_image(struct spl_load_info *info, ulong sector,
>  			      void *fit, ulong base_offset, int node,
> -			      struct spl_image_info *image_info)
> +			      struct spl_image_info *image_info, bool no_load)
>  {
>  	int offset;
>  	size_t length;
> @@ -216,7 +219,20 @@ static int spl_load_fit_image(struct spl_load_info *info, ulong sector,
>  
>  		load_ptr = (load_addr + align_len) & ~align_len;
>  		length = len;
> +	} else {
> +		/* Embedded data */
> +		if (fit_image_get_data(fit, node, &data, &length)) {
> +			puts("Cannot get image data/size\n");
> +			return -ENOENT;
> +		}
> +	}
>  
> +	if (no_load && image_info) {
> +		image_info->size = length;
> +		return 0;
> +	}

This is return you size of image in FIT but not size of image after
uncompression. There is SPL_GZIP support and that's the size you should
work with.

M

[U-Boot] [RFC PATCH v1 7/9] spl: fit: Add support for applying DT overlay

[Jean-Jacques Hiblot]

From: Michal Simek <michal.simek@xilinx.com>

doc/uImage.FIT/overlay-fdt-boot.txt is describing how to create FIT
image with DT overlays in it.
Add support for this feature to SPL.

The whole feature depends on OF_LIBFDT_OVERLAY

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
---

 common/spl/spl_fit.c | 60 +++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 59 insertions(+), 1 deletion(-)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 90bf458ee8..ebce93ec1f 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -8,6 +8,7 @@
 #include <errno.h>
 #include <fpga.h>
 #include <image.h>
+#include <malloc.h>
 #include <linux/libfdt.h>
 #include <spl.h>
 
@@ -289,6 +290,48 @@ static int spl_load_fit_image(struct spl_load_info *info, ulong sector,
 	return 0;
 }
 
+#if defined(CONFIG_OF_LIBFDT_OVERLAY)
+static int load_and_apply_overlay(void *fdt_addr, struct spl_load_info *info,
+				  ulong sector, void *fit, ulong base_offset,
+				  int node)
+{
+	int ret;
+	struct spl_image_info img_info;
+
+	/* get the size of the image */
+	ret = spl_load_fit_image(info, sector, fit, base_offset, node,
+				 &img_info, true);
+	if (ret < 0)
+		return ret;
+
+	/* allocate space to load the image */
+	img_info.load_addr = (ulong)malloc(img_info.size);
+	if (!img_info.load_addr)
+		return -ENOMEM;
+
+	/* load the image */
+	ret = spl_load_fit_image(info, sector, fit, base_offset, node,
+				 &img_info, false);
+	if (ret < 0)
+		return ret;
+
+	/* Increase the size of the fdt before applying the dtbo */
+	fdt_shrink_to_minimum(fdt_addr, img_info.size);
+
+	/* apply the DTB overlay */
+	ret = fdt_overlay_apply_verbose(fdt_addr, (void *)img_info.load_addr);
+	free((void *)img_info.load_addr);
+	if (ret) {
+		pr_err("Could not apply overlay %s\n",
+		       fit_get_name(fit, node, NULL));
+		return ret;
+	}
+	debug("DT overlay %s applied\n", fit_get_name(fit, node, NULL));
+
+	return 0;
+}
+#endif
+
 static int spl_fit_append_fdt(struct spl_image_info *spl_image,
 			      struct spl_load_info *info, ulong sector,
 			      void *fit, int images, ulong base_offset)
@@ -316,11 +359,26 @@ static int spl_fit_append_fdt(struct spl_image_info *spl_image,
 
 	/* Make the load-address of the FDT available for the SPL framework */
 	spl_image->fdt_addr = (void *)image_info.load_addr;
+#if defined(CONFIG_OF_LIBFDT_OVERLAY)
+	int index;
+
+	/* Apply overlays located in the "fdt" property (after the DTB) */
+	for (index = 1; ; index++) {
+		node = spl_fit_get_image_node(fit, images, FIT_FDT_PROP, index);
+		if (node < 0) {
+			debug("%s: No additional FDT node\n", __func__);
+			break;
+		}
+		ret = load_and_apply_overlay(spl_image->fdt_addr, info, sector,
+					     fit, base_offset, node);
+		if (ret)
+			return ret;
+	}
+#endif
 #if !CONFIG_IS_ENABLED(FIT_IMAGE_TINY)
 	/* Try to make space, so we can inject details on the loadables */
 	ret = fdt_shrink_to_minimum(spl_image->fdt_addr, 8192);
 #endif
-
 	return ret;
 }
 
-- 
2.17.1

[U-Boot] [RFC PATCH v1 7/9] spl: fit: Add support for applying DT overlay

[Michal Simek]

On 22. 03. 19 15:39, Jean-Jacques Hiblot wrote:
> From: Michal Simek <michal.simek@xilinx.com>
> 
> doc/uImage.FIT/overlay-fdt-boot.txt is describing how to create FIT
> image with DT overlays in it.
> Add support for this feature to SPL.
> 
> The whole feature depends on OF_LIBFDT_OVERLAY
> 
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

First of all will be better if you based this on the top of my patch and
not change the origin one. I have it in my queue to send it when merge
window is open.

> ---
> 
>  common/spl/spl_fit.c | 60 +++++++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 59 insertions(+), 1 deletion(-)
> 
> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> index 90bf458ee8..ebce93ec1f 100644
> --- a/common/spl/spl_fit.c
> +++ b/common/spl/spl_fit.c
> @@ -8,6 +8,7 @@
>  #include <errno.h>
>  #include <fpga.h>
>  #include <image.h>
> +#include <malloc.h>
>  #include <linux/libfdt.h>
>  #include <spl.h>
>  
> @@ -289,6 +290,48 @@ static int spl_load_fit_image(struct spl_load_info *info, ulong sector,
>  	return 0;
>  }
>  
> +#if defined(CONFIG_OF_LIBFDT_OVERLAY)
> +static int load_and_apply_overlay(void *fdt_addr, struct spl_load_info *info,
> +				  ulong sector, void *fit, ulong base_offset,
> +				  int node)
> +{
> +	int ret;
> +	struct spl_image_info img_info;
> +
> +	/* get the size of the image */
> +	ret = spl_load_fit_image(info, sector, fit, base_offset, node,
> +				 &img_info, true);
> +	if (ret < 0)
> +		return ret;
> +
> +	/* allocate space to load the image */
> +	img_info.load_addr = (ulong)malloc(img_info.size);
> +	if (!img_info.load_addr)
> +		return -ENOMEM;
> +

I am not quite sure about this. You are allocating memory for overlay
and when load address for overlay is specified this place will be
completely unused. And then you are freeing it later.

And allocating size is just for image inside FIT not uncompressed one.

I understand that you don't want to put load address to FIT not to deal
with memory layouts which is not bad idea. But right now you should be
re data out of malloc area.

I am really not quite sure if this is the right way how to handle images
without load address specified. I didn't try to solve this in my patch
but we should really solve it to handle all these cases.


> +	/* load the image */
> +	ret = spl_load_fit_image(info, sector, fit, base_offset, node,
> +				 &img_info, false);
> +	if (ret < 0)
> +		return ret;
> +
> +	/* Increase the size of the fdt before applying the dtbo */

Good to be align with comment style and start with "increase"

> +	fdt_shrink_to_minimum(fdt_addr, img_info.size);
> +
> +	/* apply the DTB overlay */
> +	ret = fdt_overlay_apply_verbose(fdt_addr, (void *)img_info.load_addr);
> +	free((void *)img_info.load_addr);
> +	if (ret) {
> +		pr_err("Could not apply overlay %s\n",
> +		       fit_get_name(fit, node, NULL));
> +		return ret;
> +	}
> +	debug("DT overlay %s applied\n", fit_get_name(fit, node, NULL));
> +
> +	return 0;
> +}
> +#endif
> +
>  static int spl_fit_append_fdt(struct spl_image_info *spl_image,
>  			      struct spl_load_info *info, ulong sector,
>  			      void *fit, int images, ulong base_offset)
> @@ -316,11 +359,26 @@ static int spl_fit_append_fdt(struct spl_image_info *spl_image,
>  
>  	/* Make the load-address of the FDT available for the SPL framework */
>  	spl_image->fdt_addr = (void *)image_info.load_addr;
> +#if defined(CONFIG_OF_LIBFDT_OVERLAY)
> +	int index;
> +
> +	/* Apply overlays located in the "fdt" property (after the DTB) */
> +	for (index = 1; ; index++) {
> +		node = spl_fit_get_image_node(fit, images, FIT_FDT_PROP, index);
> +		if (node < 0) {
> +			debug("%s: No additional FDT node\n", __func__);
> +			break;
> +		}
> +		ret = load_and_apply_overlay(spl_image->fdt_addr, info, sector,
> +					     fit, base_offset, node);
> +		if (ret)
> +			return ret;
> +	}
> +#endif
>  #if !CONFIG_IS_ENABLED(FIT_IMAGE_TINY)
>  	/* Try to make space, so we can inject details on the loadables */
>  	ret = fdt_shrink_to_minimum(spl_image->fdt_addr, 8192);
>  #endif
> -

unrelated.

>  	return ret;
>  }
>  
> 

M

[U-Boot] [RFC PATCH v1 7/9] spl: fit: Add support for applying DT overlay

[Jean-Jacques Hiblot]

Hi Michal,

On 25/03/2019 09:18, Michal Simek wrote:
> On 22. 03. 19 15:39, Jean-Jacques Hiblot wrote:
>> From: Michal Simek <michal.simek@xilinx.com>
>>
>> doc/uImage.FIT/overlay-fdt-boot.txt is describing how to create FIT
>> image with DT overlays in it.
>> Add support for this feature to SPL.
>>
>> The whole feature depends on OF_LIBFDT_OVERLAY
>>
>> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
>> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
> First of all will be better if you based this on the top of my patch and
> not change the origin one. I have it in my queue to send it when merge
> window is open.

Thanks for the review.

Do you have a branch with this work publicly available ? I could rebase 
this series on top of it.

JJ

>> ---
>>
>>   common/spl/spl_fit.c | 60 +++++++++++++++++++++++++++++++++++++++++++-
>>   1 file changed, 59 insertions(+), 1 deletion(-)
>>
>> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
>> index 90bf458ee8..ebce93ec1f 100644
>> --- a/common/spl/spl_fit.c
>> +++ b/common/spl/spl_fit.c
>> @@ -8,6 +8,7 @@
>>   #include <errno.h>
>>   #include <fpga.h>
>>   #include <image.h>
>> +#include <malloc.h>
>>   #include <linux/libfdt.h>
>>   #include <spl.h>
>>   
>> @@ -289,6 +290,48 @@ static int spl_load_fit_image(struct spl_load_info *info, ulong sector,
>>   	return 0;
>>   }
>>   
>> +#if defined(CONFIG_OF_LIBFDT_OVERLAY)
>> +static int load_and_apply_overlay(void *fdt_addr, struct spl_load_info *info,
>> +				  ulong sector, void *fit, ulong base_offset,
>> +				  int node)
>> +{
>> +	int ret;
>> +	struct spl_image_info img_info;
>> +
>> +	/* get the size of the image */
>> +	ret = spl_load_fit_image(info, sector, fit, base_offset, node,
>> +				 &img_info, true);
>> +	if (ret < 0)
>> +		return ret;
>> +
>> +	/* allocate space to load the image */
>> +	img_info.load_addr = (ulong)malloc(img_info.size);
>> +	if (!img_info.load_addr)
>> +		return -ENOMEM;
>> +
> I am not quite sure about this. You are allocating memory for overlay
> and when load address for overlay is specified this place will be
> completely unused. And then you are freeing it later.
>
> And allocating size is just for image inside FIT not uncompressed one.
>
> I understand that you don't want to put load address to FIT not to deal
> with memory layouts which is not bad idea. But right now you should be
> re data out of malloc area.
>
> I am really not quite sure if this is the right way how to handle images
> without load address specified. I didn't try to solve this in my patch
> but we should really solve it to handle all these cases.
>
>
>> +	/* load the image */
>> +	ret = spl_load_fit_image(info, sector, fit, base_offset, node,
>> +				 &img_info, false);
>> +	if (ret < 0)
>> +		return ret;
>> +
>> +	/* Increase the size of the fdt before applying the dtbo */
> Good to be align with comment style and start with "increase"
>
>> +	fdt_shrink_to_minimum(fdt_addr, img_info.size);
>> +
>> +	/* apply the DTB overlay */
>> +	ret = fdt_overlay_apply_verbose(fdt_addr, (void *)img_info.load_addr);
>> +	free((void *)img_info.load_addr);
>> +	if (ret) {
>> +		pr_err("Could not apply overlay %s\n",
>> +		       fit_get_name(fit, node, NULL));
>> +		return ret;
>> +	}
>> +	debug("DT overlay %s applied\n", fit_get_name(fit, node, NULL));
>> +
>> +	return 0;
>> +}
>> +#endif
>> +
>>   static int spl_fit_append_fdt(struct spl_image_info *spl_image,
>>   			      struct spl_load_info *info, ulong sector,
>>   			      void *fit, int images, ulong base_offset)
>> @@ -316,11 +359,26 @@ static int spl_fit_append_fdt(struct spl_image_info *spl_image,
>>   
>>   	/* Make the load-address of the FDT available for the SPL framework */
>>   	spl_image->fdt_addr = (void *)image_info.load_addr;
>> +#if defined(CONFIG_OF_LIBFDT_OVERLAY)
>> +	int index;
>> +
>> +	/* Apply overlays located in the "fdt" property (after the DTB) */
>> +	for (index = 1; ; index++) {
>> +		node = spl_fit_get_image_node(fit, images, FIT_FDT_PROP, index);
>> +		if (node < 0) {
>> +			debug("%s: No additional FDT node\n", __func__);
>> +			break;
>> +		}
>> +		ret = load_and_apply_overlay(spl_image->fdt_addr, info, sector,
>> +					     fit, base_offset, node);
>> +		if (ret)
>> +			return ret;
>> +	}
>> +#endif
>>   #if !CONFIG_IS_ENABLED(FIT_IMAGE_TINY)
>>   	/* Try to make space, so we can inject details on the loadables */
>>   	ret = fdt_shrink_to_minimum(spl_image->fdt_addr, 8192);
>>   #endif
>> -
> unrelated.
>
>>   	return ret;
>>   }
>>   
>>
> M
>

[U-Boot] [RFC PATCH v1 7/9] spl: fit: Add support for applying DT overlay

[Michal Simek]

On 25. 03. 19 12:40, Jean-Jacques Hiblot wrote:
> Hi Michal,
> 
> On 25/03/2019 09:18, Michal Simek wrote:
>> On 22. 03. 19 15:39, Jean-Jacques Hiblot wrote:
>>> From: Michal Simek <michal.simek@xilinx.com>
>>>
>>> doc/uImage.FIT/overlay-fdt-boot.txt is describing how to create FIT
>>> image with DT overlays in it.
>>> Add support for this feature to SPL.
>>>
>>> The whole feature depends on OF_LIBFDT_OVERLAY
>>>
>>> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
>>> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
>> First of all will be better if you based this on the top of my patch and
>> not change the origin one. I have it in my queue to send it when merge
>> window is open.
> 
> Thanks for the review.
> 
> Do you have a branch with this work publicly available ? I could rebase
> this series on top of it.

I am keep rebasing that to check that this is still working with latest
head.
Anyway you can use this branch.
http://git.denx.de/?p=u-boot/u-boot-microblaze.git;a=summary

I would simply just cherry-pick that my patch and based your on the top
of it. When it reaches mainline it will disappear from your branch anyway.

Thanks,
Michal

[U-Boot] [RFC PATCH v1 8/9] sp: fit: Allow the board to dynamically select the DTB overlays it needs.

[Jean-Jacques Hiblot]

Currently the list of DTB overlays to apply on top of the DTB is described
in a configuration node. With this scheme, it becomes quickly hard to
manage combinations of more than a hand few of DTB overlays. Instead the
board could tell for each overlay if it is needed or not.
This is the role of board_fit_get_additionnal_images().
Note that it is not limited to dtb overlays, it could be used for kind of
images (fpga, loadables, etc.)

Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
---

 common/spl/spl_fit.c | 28 ++++++++++++++++++++++++++++
 include/spl.h        | 20 ++++++++++++++++++++
 2 files changed, 48 insertions(+)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index ebce93ec1f..6e39bfa2b4 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -25,6 +25,12 @@ __weak ulong board_spl_fit_size_align(ulong size)
 	return size;
 }
 
+__weak int board_fit_get_additionnal_images(int index, const char *type,
+					    const char **name)
+{
+	return -ENOENT;
+}
+
 /**
  * spl_fit_get_image_name(): By using the matching configuration subnode,
  * retrieve the name of an image, specified by a property name and an index
@@ -374,6 +380,28 @@ static int spl_fit_append_fdt(struct spl_image_info *spl_image,
 		if (ret)
 			return ret;
 	}
+
+	/* Apply overlays, the name of which are provided by board-level code */
+	for (index = 0; ; index++) {
+		const char *str;
+
+		ret = board_fit_get_additionnal_images(index, FIT_FDT_PROP,
+						       &str);
+		if (ret)
+			break;
+		if (!str)
+			continue;
+
+		node = fdt_subnode_offset(fit, images, str);
+		if (node < 0) {
+			pr_err("cannot find image node '%s': %d\n", str, node);
+			continue;
+		}
+		ret = load_and_apply_overlay(spl_image->fdt_addr, info, sector,
+					     fit, base_offset, node);
+		if (ret)
+			return ret;
+	}
 #endif
 #if !CONFIG_IS_ENABLED(FIT_IMAGE_TINY)
 	/* Try to make space, so we can inject details on the loadables */
diff --git a/include/spl.h b/include/spl.h
index f09909e189..5acc0a6c6e 100644
--- a/include/spl.h
+++ b/include/spl.h
@@ -370,6 +370,26 @@ void board_spl_fit_post_load(ulong load_addr, size_t length);
  */
 ulong board_spl_fit_size_align(ulong size);
 
+/**
+ * board_fit_get_additionnal_images - Get additional image names from board-
+ *				      level code.
+ * This function can be used to provide the image names based on runtime
+ * detection. A classic use-case would when DTBOs are used to describe
+ * additionnal daughter cards.
+ *
+ * @param index	Index of the image. Starts at 0 and gets incremented after each
+ *		call to this function.
+ * @param type	The type of image. For example, "fdt" for DTBs
+ * @param name	Output. The name of the node describing the image. If  NULL, it
+ *		should be ignored by the caller but it does not indicate that
+ *		there no more images to get from this function.
+ *
+ * @return 0 if there are still images to get of this type to get from
+ *	   this function. Otherwise error code.
+ */
+int board_fit_get_additionnal_images(int index, const char *type,
+				     const char **name);
+
 /**
  * spl_perform_fixups() - arch/board-specific callback before processing
  *                        the boot-payload
-- 
2.17.1

[U-Boot] [RFC PATCH v1 8/9] sp: fit: Allow the board to dynamically select the DTB overlays it needs.

[Michal Simek]

On 22. 03. 19 15:39, Jean-Jacques Hiblot wrote:
> Currently the list of DTB overlays to apply on top of the DTB is described
> in a configuration node. With this scheme, it becomes quickly hard to
> manage combinations of more than a hand few of DTB overlays. Instead the
> board could tell for each overlay if it is needed or not.
> This is the role of board_fit_get_additionnal_images().
> Note that it is not limited to dtb overlays, it could be used for kind of
> images (fpga, loadables, etc.)

You are describing this here properly. It doesn't need to be just FDT.
It can be whatever else that's why I think that this code should go out
of spl_fit_append_fdt() which is designed just for FDT.



> 
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
> ---
> 
>  common/spl/spl_fit.c | 28 ++++++++++++++++++++++++++++
>  include/spl.h        | 20 ++++++++++++++++++++
>  2 files changed, 48 insertions(+)
> 
> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> index ebce93ec1f..6e39bfa2b4 100644
> --- a/common/spl/spl_fit.c
> +++ b/common/spl/spl_fit.c
> @@ -25,6 +25,12 @@ __weak ulong board_spl_fit_size_align(ulong size)
>  	return size;
>  }
>  
> +__weak int board_fit_get_additionnal_images(int index, const char *type,
> +					    const char **name)
> +{
> +	return -ENOENT;
> +}
> +
>  /**
>   * spl_fit_get_image_name(): By using the matching configuration subnode,
>   * retrieve the name of an image, specified by a property name and an index
> @@ -374,6 +380,28 @@ static int spl_fit_append_fdt(struct spl_image_info *spl_image,
>  		if (ret)
>  			return ret;
>  	}
> +
> +	/* Apply overlays, the name of which are provided by board-level code */
> +	for (index = 0; ; index++) {
> +		const char *str;

better = NULL; here.


> +
> +		ret = board_fit_get_additionnal_images(index, FIT_FDT_PROP,
> +						       &str);
> +		if (ret)
> +			break;
> +		if (!str)
> +			continue;
> +
> +		node = fdt_subnode_offset(fit, images, str);
> +		if (node < 0) {
> +			pr_err("cannot find image node '%s': %d\n", str, node);
> +			continue;
> +		}
> +		ret = load_and_apply_overlay(spl_image->fdt_addr, info, sector,
> +					     fit, base_offset, node);
> +		if (ret)
> +			return ret;
> +	}

I would get this out of spl_fit_append_fdt() and make it more generic.
Then it could be easily used for generic configuration.

I think that ITS configuration should be discussed first. Right now you
have just DTB there that's why you are using FIT_FDT_PROP there.

I was using full format for these images to describe just dtbo.
                dtbo {
                        description = "DTBO";
                        data =
/incbin/("$DIR/arch/arm/dts/zynqmp-zcu100-revA-loopbk.dtbo");
                        type = "flat_dt";
                        arch = "arm";
                        compression = "none";
                        load = <0x2f00000>;
                        hash {
                                algo = "md5";
                        };
                };

Maybe we should simply introduce new type that instead of flat_dt it
will be flat_dtbo to call overlay function in dt case.


dra76-evm-dummy.dtbo {
	description = "dra76-evm-dummy.dtbo";
	data = /incbin/("arch/arm/dts/dra76-evm-dummy.dtbo");
        type = "flat_dtbo";
        arch = "arm";
        compression = "gzip";
        load = <0x2f00000>; /* optional */
        hash {
              algo = "md5";
        };
};

dra76-evm-dummy {
	description = "dra76-evm-dummy daughter card";
	fdt = "dra76-evm-dummy.dtbo";
	/* optional config, fpga, etc objects */
};


It could maybe end up in daughter card identification - finding up node
and calling the whole SPL loading mechanism again.

>  #endif
>  #if !CONFIG_IS_ENABLED(FIT_IMAGE_TINY)
>  	/* Try to make space, so we can inject details on the loadables */
> diff --git a/include/spl.h b/include/spl.h
> index f09909e189..5acc0a6c6e 100644
> --- a/include/spl.h
> +++ b/include/spl.h
> @@ -370,6 +370,26 @@ void board_spl_fit_post_load(ulong load_addr, size_t length);
>   */
>  ulong board_spl_fit_size_align(ulong size);
>  
> +/**
> + * board_fit_get_additionnal_images - Get additional image names from board-

typo - additional

> + *				      level code.
> + * This function can be used to provide the image names based on runtime
> + * detection. A classic use-case would when DTBOs are used to describe
> + * additionnal daughter cards.

ditto.

> + *
> + * @param index	Index of the image. Starts at 0 and gets incremented after each
> + *		call to this function.
> + * @param type	The type of image. For example, "fdt" for DTBs
> + * @param name	Output. The name of the node describing the image. If  NULL, it
> + *		should be ignored by the caller but it does not indicate that
> + *		there no more images to get from this function.
> + *
> + * @return 0 if there are still images to get of this type to get from
> + *	   this function. Otherwise error code.
> + */
> +int board_fit_get_additionnal_images(int index, const char *type,
> +				     const char **name);
> +
>  /**
>   * spl_perform_fixups() - arch/board-specific callback before processing
>   *                        the boot-payload
> 

M

[U-Boot] [RFC PATCH v1 9/9] !!! TEMP !!! For demonstration only !!! DRA76: Usage of overlays in SPL

[Jean-Jacques Hiblot]

This is an example of how to apply overlays in SPL for the DRA76

Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>


---

 arch/arm/dts/Makefile              |  2 +-
 arch/arm/dts/dra76-evm-dummy.dtso  | 14 +++++++++
 arch/arm/dts/dra76-evm-dummy2.dtso | 15 ++++++++++
 board/ti/dra7xx/evm.c              | 30 +++++++++++++++++++
 board/ti/dra7xx/evm.its            | 48 ++++++++++++++++++++++++++++++
 configs/dra7xx_evm_defconfig       |  2 ++
 6 files changed, 110 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/dra76-evm-dummy.dtso
 create mode 100644 arch/arm/dts/dra76-evm-dummy2.dtso
 create mode 100644 board/ti/dra7xx/evm.its

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 2a040b20a5..a6e29ebfd4 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -228,7 +228,7 @@ dtb-$(CONFIG_ARCH_SOCFPGA) +=				\
 	socfpga_stratix10_socdk.dtb
 
 dtb-$(CONFIG_TARGET_DRA7XX_EVM) += dra72-evm.dtb dra7-evm.dtb	\
-	dra72-evm-revc.dtb dra71-evm.dtb dra76-evm.dtb
+	dra72-evm-revc.dtb dra71-evm.dtb dra76-evm.dtb dra76-evm-dummy.dtbo dra76-evm-dummy2.dtbo
 dtb-$(CONFIG_TARGET_AM57XX_EVM) += am57xx-beagle-x15.dtb \
 	am57xx-beagle-x15-revb1.dtb \
 	am57xx-beagle-x15-revc.dtb \
diff --git a/arch/arm/dts/dra76-evm-dummy.dtso b/arch/arm/dts/dra76-evm-dummy.dtso
new file mode 100644
index 0000000000..6b55670281
--- /dev/null
+++ b/arch/arm/dts/dra76-evm-dummy.dtso
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+/dts-v1/;
+/plugin/;
+
+
+&mmc1 {
+	dummy_node {
+		dummy_val = "this is only in overlay 1";
+	};
+};
diff --git a/arch/arm/dts/dra76-evm-dummy2.dtso b/arch/arm/dts/dra76-evm-dummy2.dtso
new file mode 100644
index 0000000000..0f0411164c
--- /dev/null
+++ b/arch/arm/dts/dra76-evm-dummy2.dtso
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+/dts-v1/;
+/plugin/;
+
+
+&mmc2 {
+	dummy_node {
+		dummy_val = "this is only in overlay 2";
+	};
+
+};
diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index d69641e3a0..f560159bce 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -704,6 +704,13 @@ int board_late_init(void)
 	if (device_okay("/ocp/omap_dwc3_2 at 488c0000"))
 		enable_usb_clocks(1);
 #endif
+	char preboot_cmd[255];
+	sprintf(preboot_cmd, "fdt addr %p;\
+		fdt print /ocp/mmc at 480b4000/dummy_node;\
+		fdt print /ocp/mmc at 4809c000/dummy_node;",
+		gd->fdt_blob);
+
+	env_set("preboot", preboot_cmd);
 	return 0;
 }
 
@@ -1069,6 +1076,29 @@ int ft_board_setup(void *blob, bd_t *bd)
 #endif
 
 #ifdef CONFIG_SPL_LOAD_FIT
+bool use_dummy_2 = true;
+bool use_dummy = false;
+
+int board_fit_get_additionnal_images(int index, const char *type, const char **name)
+{
+	const char *dtbo = NULL;
+
+	if (strcmp(type, FIT_FDT_PROP))
+		return -ENOENT;
+
+	if (index > 2)
+		return -ENOENT;
+
+	if (index == 1 && use_dummy_2)
+		dtbo = "dra76-evm-dummy2.dtbo";
+	else if (index == 2 && use_dummy)
+		dtbo = "dra76-evm-dummy.dtbo";
+
+	*name = dtbo;
+
+	return 0;
+}
+
 int board_fit_config_name_match(const char *name)
 {
 	if (is_dra72x()) {
diff --git a/board/ti/dra7xx/evm.its b/board/ti/dra7xx/evm.its
new file mode 100644
index 0000000000..d0fc0d46eb
--- /dev/null
+++ b/board/ti/dra7xx/evm.its
@@ -0,0 +1,48 @@
+/dts-v1/;
+
+/ {
+	description = "Firmware image with one or more FDT blobs";
+	#address-cells = <0x1>;
+
+	images {
+
+		firmware-1 {
+			description = "U-Boot 2019.01 for DRA76 board";
+                        type = "firmware";
+                        arch = "arm";
+                        os = "u-boot";
+                        compression = "none";
+                        load = <0x80800000>;
+                        entry = <0x0>;
+			data = /incbin/("u-boot-nodtb.bin");
+
+		};
+
+		fdt-1 {
+			description = "dra76-evm";
+			type = "fdt";
+			data = /incbin/("arch/arm/dts/dra76-evm.dtb");
+		};
+
+		dra76-evm-dummy.dtbo {
+			description = "dra76-evm-dummy.dtbo";
+			data = /incbin/("arch/arm/dts/dra76-evm-dummy.dtbo");
+		};
+
+		dra76-evm-dummy2.dtbo {
+			description = "dra76-evm-dummy2.dtbo";
+			data = /incbin/("arch/arm/dts/dra76-evm-dummy2.dtbo");
+		};
+	};
+
+	configurations {
+		default = "dra76-evm";
+
+                dra76-evm {
+                        description = "dra76-evm";
+                        firmware = "firmware-1";
+                        fdt = "fdt-1";
+                };
+
+	};
+};
diff --git a/configs/dra7xx_evm_defconfig b/configs/dra7xx_evm_defconfig
index ef061501ef..f9d296ea2d 100644
--- a/configs/dra7xx_evm_defconfig
+++ b/configs/dra7xx_evm_defconfig
@@ -12,10 +12,12 @@ CONFIG_AHCI=y
 CONFIG_DISTRO_DEFAULTS=y
 CONFIG_NR_DRAM_BANKS=2
 CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_FIT_SOURCE="board/ti/dra7xx/evm.its"
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS="androidboot.serialno=${serial#} console=ttyS0,115200 androidboot.console=ttyS0 androidboot.hardware=jacinto6evmboard"
 # CONFIG_USE_BOOTCOMMAND is not set
+CONFIG_USE_PREBOOT=y
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 # CONFIG_MISC_INIT_R is not set
 CONFIG_VERSION_VARIABLE=y
-- 
2.17.1

[U-Boot] [RFC PATCH v1 0/9] Add support for applications of overlays in SPL

[Michal Simek]

On 22. 03. 19 15:39, Jean-Jacques Hiblot wrote:
> 
> The purpose of this series is to provide the SPL with ability to apply
> overlays for u-boot. this is only a RFC so far, to get a feedback on the
> approach.
> 
> Our use-case is the support of the daughter boards of the AM65x EVM. In
> Linux, each board is supported by a unique overlay. The presence of the
> boards is detected at runtime, and some useful features (like USB) are
> implemented on those daughter boards. Instead of providing multiple dtbs
> and fall in a combinatorial pit, we propose to use DT overlays.

Not sure if you have it on these boards too but I expect you are able to
detect base board with this code board/ti/common/board_detect.c

How do you detect these daughter cards? Is there additional I2C
connection to them and they have on board eeprom with any format for
detection?
Something similar what it is part of FMC standard/VITA 57.1 with using
FRU spec for daughter card description?
Anyway we are working on FRU parser exactly for this purpose.

Do you also need to apply that overlays in SPL?
Isn't it enough to apply them as the part of board_fdt_blob_setup()?

Thanks,
Michal

[U-Boot] [RFC PATCH v1 0/9] Add support for applications of overlays in SPL

[Michal Simek]

On 25. 03. 19 9:08, Michal Simek wrote:
> On 22. 03. 19 15:39, Jean-Jacques Hiblot wrote:
>>
>> The purpose of this series is to provide the SPL with ability to apply
>> overlays for u-boot. this is only a RFC so far, to get a feedback on the
>> approach.
>>
>> Our use-case is the support of the daughter boards of the AM65x EVM. In
>> Linux, each board is supported by a unique overlay. The presence of the
>> boards is detected at runtime, and some useful features (like USB) are
>> implemented on those daughter boards. Instead of providing multiple dtbs
>> and fall in a combinatorial pit, we propose to use DT overlays.
> 
> Not sure if you have it on these boards too but I expect you are able to
> detect base board with this code board/ti/common/board_detect.c
> 
> How do you detect these daughter cards? Is there additional I2C
> connection to them and they have on board eeprom with any format for
> detection?
> Something similar what it is part of FMC standard/VITA 57.1 with using
> FRU spec for daughter card description?
> Anyway we are working on FRU parser exactly for this purpose.
> 
> Do you also need to apply that overlays in SPL?
> Isn't it enough to apply them as the part of board_fdt_blob_setup()?

I see v2 now but without answering my questions here.

M

[U-Boot] [RFC PATCH v1 0/9] Add support for applications of overlays in SPL

[Jean-Jacques Hiblot]

On 28/03/2019 14:54, Michal Simek wrote:
> On 25. 03. 19 9:08, Michal Simek wrote:
>> On 22. 03. 19 15:39, Jean-Jacques Hiblot wrote:
>>> The purpose of this series is to provide the SPL with ability to apply
>>> overlays for u-boot. this is only a RFC so far, to get a feedback on the
>>> approach.
>>>
>>> Our use-case is the support of the daughter boards of the AM65x EVM. In
>>> Linux, each board is supported by a unique overlay. The presence of the
>>> boards is detected at runtime, and some useful features (like USB) are
>>> implemented on those daughter boards. Instead of providing multiple dtbs
>>> and fall in a combinatorial pit, we propose to use DT overlays.
>> Not sure if you have it on these boards too but I expect you are able to
>> detect base board with this code board/ti/common/board_detect.c
>>
>> How do you detect these daughter cards? Is there additional I2C
>> connection to them and they have on board eeprom with any format for
>> detection?
Yes. There is EEPROM and GPIOs involved in the detection process.
>> Something similar what it is part of FMC standard/VITA 57.1 with using
>> FRU spec for daughter card description?
>> Anyway we are working on FRU parser exactly for this purpose.
>>
>> Do you also need to apply that overlays in SPL?
We need to apply in SPL so that u-boot has the right information in the DT.
>> Isn't it enough to apply them as the part of board_fdt_blob_setup()?
No it's possible to do that in board_fdt_blob_setup().
> I see v2 now but without answering my questions here.

Yes I had prepared the answer and forgot to push the send button.

in the V2 the biggest change is when the list of additional images is 
obtained from the board. It is now in spl_fit_get_image_name() and that 
makes its usable for other kind of binaries than just overlays.


JJ

>
> M
>

[U-Boot] [RFC PATCH v1 0/9] Add support for applications of overlays in SPL

[Michal Simek]

On 29. 03. 19 11:13, Jean-Jacques Hiblot wrote:
> 
> On 28/03/2019 14:54, Michal Simek wrote:
>> On 25. 03. 19 9:08, Michal Simek wrote:
>>> On 22. 03. 19 15:39, Jean-Jacques Hiblot wrote:
>>>> The purpose of this series is to provide the SPL with ability to apply
>>>> overlays for u-boot. this is only a RFC so far, to get a feedback on
>>>> the
>>>> approach.
>>>>
>>>> Our use-case is the support of the daughter boards of the AM65x EVM. In
>>>> Linux, each board is supported by a unique overlay. The presence of the
>>>> boards is detected at runtime, and some useful features (like USB) are
>>>> implemented on those daughter boards. Instead of providing multiple
>>>> dtbs
>>>> and fall in a combinatorial pit, we propose to use DT overlays.
>>> Not sure if you have it on these boards too but I expect you are able to
>>> detect base board with this code board/ti/common/board_detect.c
>>>
>>> How do you detect these daughter cards? Is there additional I2C
>>> connection to them and they have on board eeprom with any format for
>>> detection?
> Yes. There is EEPROM and GPIOs involved in the detection process.

Does that mean that you use gpio bitbanging i2c eeprom to read information?

>>> Something similar what it is part of FMC standard/VITA 57.1 with using
>>> FRU spec for daughter card description?
>>> Anyway we are working on FRU parser exactly for this purpose.
>>>
>>> Do you also need to apply that overlays in SPL?
> We need to apply in SPL so that u-boot has the right information in the DT.
>>> Isn't it enough to apply them as the part of board_fdt_blob_setup()?
> No it's possible to do that in board_fdt_blob_setup().

A little bit confused by your response. yes/no?


>> I see v2 now but without answering my questions here.
> 
> Yes I had prepared the answer and forgot to push the send button.
> 
> in the V2 the biggest change is when the list of additional images is
> obtained from the board. It is now in spl_fit_get_image_name() and that
> makes its usable for other kind of binaries than just overlays.

Yes I have seen that. Give me some time to test this.
As I said V2 looks better.

M

[U-Boot] [RFC PATCH v1 0/9] Add support for applications of overlays in SPL

[Jean-Jacques Hiblot]

On 29/03/2019 11:26, Michal Simek wrote:
> On 29. 03. 19 11:13, Jean-Jacques Hiblot wrote:
>> On 28/03/2019 14:54, Michal Simek wrote:
>>> On 25. 03. 19 9:08, Michal Simek wrote:
>>>> On 22. 03. 19 15:39, Jean-Jacques Hiblot wrote:
>>>>> The purpose of this series is to provide the SPL with ability to apply
>>>>> overlays for u-boot. this is only a RFC so far, to get a feedback on
>>>>> the
>>>>> approach.
>>>>>
>>>>> Our use-case is the support of the daughter boards of the AM65x EVM. In
>>>>> Linux, each board is supported by a unique overlay. The presence of the
>>>>> boards is detected at runtime, and some useful features (like USB) are
>>>>> implemented on those daughter boards. Instead of providing multiple
>>>>> dtbs
>>>>> and fall in a combinatorial pit, we propose to use DT overlays.
>>>> Not sure if you have it on these boards too but I expect you are able to
>>>> detect base board with this code board/ti/common/board_detect.c
>>>>
>>>> How do you detect these daughter cards? Is there additional I2C
>>>> connection to them and they have on board eeprom with any format for
>>>> detection?
>> Yes. There is EEPROM and GPIOs involved in the detection process.
> Does that mean that you use gpio bitbanging i2c eeprom to read information?
no, on am65 we use GPIOs and a true I2C to detect the daughter boards
> x
>
>>>> Something similar what it is part of FMC standard/VITA 57.1 with using
>>>> FRU spec for daughter card description?
>>>> Anyway we are working on FRU parser exactly for this purpose.
>>>>
>>>> Do you also need to apply that overlays in SPL?
>> We need to apply in SPL so that u-boot has the right information in the DT.
>>>> Isn't it enough to apply them as the part of board_fdt_blob_setup()?
>> No it's possible to do that in board_fdt_blob_setup().
> A little bit confused by your response. yes/no?
I forgot a key word here. it is not possible. board_fdt_blob_setup is 
used to provide a DTB blob
>
>
>>> I see v2 now but without answering my questions here.
>> Yes I had prepared the answer and forgot to push the send button.
>>
>> in the V2 the biggest change is when the list of additional images is
>> obtained from the board. It is now in spl_fit_get_image_name() and that
>> makes its usable for other kind of binaries than just overlays.
> Yes I have seen that. Give me some time to test this.
> As I said V2 looks better.
>
> M
>
>

[U-Boot] [RFC PATCH v1 0/9] Add support for applications of overlays in SPL

[Michal Simek]

On 29. 03. 19 13:50, Jean-Jacques Hiblot wrote:
> 
> On 29/03/2019 11:26, Michal Simek wrote:
>> On 29. 03. 19 11:13, Jean-Jacques Hiblot wrote:
>>> On 28/03/2019 14:54, Michal Simek wrote:
>>>> On 25. 03. 19 9:08, Michal Simek wrote:
>>>>> On 22. 03. 19 15:39, Jean-Jacques Hiblot wrote:
>>>>>> The purpose of this series is to provide the SPL with ability to
>>>>>> apply
>>>>>> overlays for u-boot. this is only a RFC so far, to get a feedback on
>>>>>> the
>>>>>> approach.
>>>>>>
>>>>>> Our use-case is the support of the daughter boards of the AM65x
>>>>>> EVM. In
>>>>>> Linux, each board is supported by a unique overlay. The presence
>>>>>> of the
>>>>>> boards is detected at runtime, and some useful features (like USB)
>>>>>> are
>>>>>> implemented on those daughter boards. Instead of providing multiple
>>>>>> dtbs
>>>>>> and fall in a combinatorial pit, we propose to use DT overlays.
>>>>> Not sure if you have it on these boards too but I expect you are
>>>>> able to
>>>>> detect base board with this code board/ti/common/board_detect.c
>>>>>
>>>>> How do you detect these daughter cards? Is there additional I2C
>>>>> connection to them and they have on board eeprom with any format for
>>>>> detection?
>>> Yes. There is EEPROM and GPIOs involved in the detection process.
>> Does that mean that you use gpio bitbanging i2c eeprom to read
>> information?
> no, on am65 we use GPIOs and a true I2C to detect the daughter boards

ok.

>> x
>>
>>>>> Something similar what it is part of FMC standard/VITA 57.1 with using
>>>>> FRU spec for daughter card description?
>>>>> Anyway we are working on FRU parser exactly for this purpose.
>>>>>
>>>>> Do you also need to apply that overlays in SPL?
>>> We need to apply in SPL so that u-boot has the right information in
>>> the DT.
>>>>> Isn't it enough to apply them as the part of board_fdt_blob_setup()?
>>> No it's possible to do that in board_fdt_blob_setup().
>> A little bit confused by your response. yes/no?
> I forgot a key word here. it is not possible. board_fdt_blob_setup is
> used to provide a DTB blob

ok. Will play with this and will see.

Thanks,
Michal

[U-Boot] [RFC PATCH v1 0/9] Add support for applications of overlays in SPL

[Lukasz Majewski]

Hi Jean-Jacques,

> The purpose of this series is to provide the SPL with ability to apply
> overlays for u-boot. this is only a RFC so far, to get a feedback on
> the approach.
> 
> Our use-case is the support of the daughter boards of the AM65x EVM.
> In Linux, each board is supported by a unique overlay. The presence
> of the boards is detected at runtime, and some useful features (like
> USB) are implemented on those daughter boards. Instead of providing
> multiple dtbs and fall in a combinatorial pit, we propose to use DT
> overlays.
> 
> The first 4 patches are small fixes/improvement related to the build.
> Patch #5 may be a bit controversial. It basically replaces u-boot.img
> with a symlink to u-boot.itb in case we use a "complex" FIT (ie: if
> SPL_FIT_SOURCE or SPL_FIT_GENERATOR are set)
> 
> Patch #6 and #7 are the core support for DTB application in the SPL.
> Based on a patch posted by Michal Simek a few weeks ago. The list of
> overlays is read from the "fdt" of the configuration chosen in the
> ITB (same property as for the DTB):
>   configurations {
>      default = "conf-1";
>      conf-1 {
>        description = "dra76-evm";
>        firmware = "firmware-1";
>        fdt = "fdt-1", "overlay-1";
>       };
>   }
> 
> 
> Patch #8 adds a way to dynamically select the DT overlays. That is
> were we would use HW detection to select the required overlays. In
> that case, the board-level code tells what overlay it needs (it gives
> the name of the node).
> 
> Patch #9 is not required, but demonstrates on a DRA76-evm how this
> series can be used.
> 
> 
> Jean-Jacques Hiblot (8):
>   dtbo: also generate dtbo from dtso
>   Makefile.lib: include /__symbols__ in dtb if OF_LIBFDT_OVERLAY is
>     enabled
>   Makefile: Fix u-boot.itb generation when building outside the source
>     tree
>   Makefile: Pass the board name to the FIT generator scripts
>   Makefile: use custom ITS to build u-boot.img if SPL_FIT_SOURCE or
>     SPL_FIT_GENERATOR are set
>   spl: fit: Allow calling spl_load_fit_image() to only get the image
>     size
>   sp: fit: Allow the board to dynamically select the DTB overlays it
>     needs.
>   !!! TEMP !!! For demonstration only !!! DRA76: Usage of overlays in
>     SPL
> 
> Michal Simek (1):
>   spl: fit: Add support for applying DT overlay

Just out of curiosity - what is the difference in SPL footprint when
with and without this feature?

> 
>  Makefile                                      |  20 ++-
>  arch/arm/dts/Makefile                         |   2 +-
>  arch/arm/dts/dra76-evm-dummy.dtso             |  14 +++
>  arch/arm/dts/dra76-evm-dummy2.dtso            |  15 +++
>  arch/arm/mach-imx/mkimage_fit_atf.sh          |   3 +-
>  arch/arm/mach-rockchip/make_fit_atf.py        |   5 +-
>  .../lion_rk3368/fit_spl_atf.its               |   6 +-
>  .../puma_rk3399/fit_spl_atf.its               |   8 +-
>  board/ti/dra7xx/evm.c                         |  30 +++++
>  board/ti/dra7xx/evm.its                       |  48 ++++++++
>  common/spl/spl_fit.c                          | 114
> +++++++++++++++++- configs/dra7xx_evm_defconfig                  |
> 2 + include/spl.h                                 |  20 +++
>  scripts/Makefile.lib                          |   7 ++
>  14 files changed, 273 insertions(+), 21 deletions(-)
>  create mode 100644 arch/arm/dts/dra76-evm-dummy.dtso
>  create mode 100644 arch/arm/dts/dra76-evm-dummy2.dtso
>  create mode 100644 board/ti/dra7xx/evm.its
> 




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190327/e20a8e97/attachment.sig>

[U-Boot] [RFC PATCH v1 0/9] Add support for applications of overlays in SPL

[Jean-Jacques Hiblot]

On 27/03/2019 10:39, Lukasz Majewski wrote:
> Hi Jean-Jacques,
>
>> The purpose of this series is to provide the SPL with ability to apply
>> overlays for u-boot. this is only a RFC so far, to get a feedback on
>> the approach.
>>
>> Our use-case is the support of the daughter boards of the AM65x EVM.
>> In Linux, each board is supported by a unique overlay. The presence
>> of the boards is detected at runtime, and some useful features (like
>> USB) are implemented on those daughter boards. Instead of providing
>> multiple dtbs and fall in a combinatorial pit, we propose to use DT
>> overlays.
>>
>> The first 4 patches are small fixes/improvement related to the build.
>> Patch #5 may be a bit controversial. It basically replaces u-boot.img
>> with a symlink to u-boot.itb in case we use a "complex" FIT (ie: if
>> SPL_FIT_SOURCE or SPL_FIT_GENERATOR are set)
>>
>> Patch #6 and #7 are the core support for DTB application in the SPL.
>> Based on a patch posted by Michal Simek a few weeks ago. The list of
>> overlays is read from the "fdt" of the configuration chosen in the
>> ITB (same property as for the DTB):
>>    configurations {
>>       default = "conf-1";
>>       conf-1 {
>>         description = "dra76-evm";
>>         firmware = "firmware-1";
>>         fdt = "fdt-1", "overlay-1";
>>        };
>>    }
>>
>>
>> Patch #8 adds a way to dynamically select the DT overlays. That is
>> were we would use HW detection to select the required overlays. In
>> that case, the board-level code tells what overlay it needs (it gives
>> the name of the node).
>>
>> Patch #9 is not required, but demonstrates on a DRA76-evm how this
>> series can be used.
>>
>>
>> Jean-Jacques Hiblot (8):
>>    dtbo: also generate dtbo from dtso
>>    Makefile.lib: include /__symbols__ in dtb if OF_LIBFDT_OVERLAY is
>>      enabled
>>    Makefile: Fix u-boot.itb generation when building outside the source
>>      tree
>>    Makefile: Pass the board name to the FIT generator scripts
>>    Makefile: use custom ITS to build u-boot.img if SPL_FIT_SOURCE or
>>      SPL_FIT_GENERATOR are set
>>    spl: fit: Allow calling spl_load_fit_image() to only get the image
>>      size
>>    sp: fit: Allow the board to dynamically select the DTB overlays it
>>      needs.
>>    !!! TEMP !!! For demonstration only !!! DRA76: Usage of overlays in
>>      SPL
>>
>> Michal Simek (1):
>>    spl: fit: Add support for applying DT overlay
> Just out of curiosity - what is the difference in SPL footprint when
> with and without this feature?

For the dra76-evm, the diff in SPL size is 3.3kB

JJ


>
>>   Makefile                                      |  20 ++-
>>   arch/arm/dts/Makefile                         |   2 +-
>>   arch/arm/dts/dra76-evm-dummy.dtso             |  14 +++
>>   arch/arm/dts/dra76-evm-dummy2.dtso            |  15 +++
>>   arch/arm/mach-imx/mkimage_fit_atf.sh          |   3 +-
>>   arch/arm/mach-rockchip/make_fit_atf.py        |   5 +-
>>   .../lion_rk3368/fit_spl_atf.its               |   6 +-
>>   .../puma_rk3399/fit_spl_atf.its               |   8 +-
>>   board/ti/dra7xx/evm.c                         |  30 +++++
>>   board/ti/dra7xx/evm.its                       |  48 ++++++++
>>   common/spl/spl_fit.c                          | 114
>> +++++++++++++++++- configs/dra7xx_evm_defconfig                  |
>> 2 + include/spl.h                                 |  20 +++
>>   scripts/Makefile.lib                          |   7 ++
>>   14 files changed, 273 insertions(+), 21 deletions(-)
>>   create mode 100644 arch/arm/dts/dra76-evm-dummy.dtso
>>   create mode 100644 arch/arm/dts/dra76-evm-dummy2.dtso
>>   create mode 100644 board/ti/dra7xx/evm.its
>>
>
>
>
> Best regards,
>
> Lukasz Majewski
>
> --
>
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma at denx.de

[U-Boot] [RFC PATCH v1 0/9] Add support for applications of overlays in SPL

[Lukasz Majewski]

On Wed, 27 Mar 2019 18:41:08 +0100
Jean-Jacques Hiblot <jjhiblot@ti.com> wrote:

> On 27/03/2019 10:39, Lukasz Majewski wrote:
> > Hi Jean-Jacques,
> >  
> >> The purpose of this series is to provide the SPL with ability to
> >> apply overlays for u-boot. this is only a RFC so far, to get a
> >> feedback on the approach.
> >>
> >> Our use-case is the support of the daughter boards of the AM65x
> >> EVM. In Linux, each board is supported by a unique overlay. The
> >> presence of the boards is detected at runtime, and some useful
> >> features (like USB) are implemented on those daughter boards.
> >> Instead of providing multiple dtbs and fall in a combinatorial
> >> pit, we propose to use DT overlays.
> >>
> >> The first 4 patches are small fixes/improvement related to the
> >> build. Patch #5 may be a bit controversial. It basically replaces
> >> u-boot.img with a symlink to u-boot.itb in case we use a "complex"
> >> FIT (ie: if SPL_FIT_SOURCE or SPL_FIT_GENERATOR are set)
> >>
> >> Patch #6 and #7 are the core support for DTB application in the
> >> SPL. Based on a patch posted by Michal Simek a few weeks ago. The
> >> list of overlays is read from the "fdt" of the configuration
> >> chosen in the ITB (same property as for the DTB):
> >>    configurations {
> >>       default = "conf-1";
> >>       conf-1 {
> >>         description = "dra76-evm";
> >>         firmware = "firmware-1";
> >>         fdt = "fdt-1", "overlay-1";
> >>        };
> >>    }
> >>
> >>
> >> Patch #8 adds a way to dynamically select the DT overlays. That is
> >> were we would use HW detection to select the required overlays. In
> >> that case, the board-level code tells what overlay it needs (it
> >> gives the name of the node).
> >>
> >> Patch #9 is not required, but demonstrates on a DRA76-evm how this
> >> series can be used.
> >>
> >>
> >> Jean-Jacques Hiblot (8):
> >>    dtbo: also generate dtbo from dtso
> >>    Makefile.lib: include /__symbols__ in dtb if OF_LIBFDT_OVERLAY
> >> is enabled
> >>    Makefile: Fix u-boot.itb generation when building outside the
> >> source tree
> >>    Makefile: Pass the board name to the FIT generator scripts
> >>    Makefile: use custom ITS to build u-boot.img if SPL_FIT_SOURCE
> >> or SPL_FIT_GENERATOR are set
> >>    spl: fit: Allow calling spl_load_fit_image() to only get the
> >> image size
> >>    sp: fit: Allow the board to dynamically select the DTB overlays
> >> it needs.
> >>    !!! TEMP !!! For demonstration only !!! DRA76: Usage of
> >> overlays in SPL
> >>
> >> Michal Simek (1):
> >>    spl: fit: Add support for applying DT overlay  
> > Just out of curiosity - what is the difference in SPL footprint when
> > with and without this feature?  
> 
> For the dra76-evm, the diff in SPL size is 3.3kB

And the increase in percentage? (What is the dra76-evm size?)

> 
> JJ
> 
> 
> >  
> >>   Makefile                                      |  20 ++-
> >>   arch/arm/dts/Makefile                         |   2 +-
> >>   arch/arm/dts/dra76-evm-dummy.dtso             |  14 +++
> >>   arch/arm/dts/dra76-evm-dummy2.dtso            |  15 +++
> >>   arch/arm/mach-imx/mkimage_fit_atf.sh          |   3 +-
> >>   arch/arm/mach-rockchip/make_fit_atf.py        |   5 +-
> >>   .../lion_rk3368/fit_spl_atf.its               |   6 +-
> >>   .../puma_rk3399/fit_spl_atf.its               |   8 +-
> >>   board/ti/dra7xx/evm.c                         |  30 +++++
> >>   board/ti/dra7xx/evm.its                       |  48 ++++++++
> >>   common/spl/spl_fit.c                          | 114
> >> +++++++++++++++++- configs/dra7xx_evm_defconfig                  |
> >> 2 + include/spl.h                                 |  20 +++
> >>   scripts/Makefile.lib                          |   7 ++
> >>   14 files changed, 273 insertions(+), 21 deletions(-)
> >>   create mode 100644 arch/arm/dts/dra76-evm-dummy.dtso
> >>   create mode 100644 arch/arm/dts/dra76-evm-dummy2.dtso
> >>   create mode 100644 board/ti/dra7xx/evm.its
> >>  
> >
> >
> >
> > Best regards,
> >
> > Lukasz Majewski
> >
> > --
> >
> > DENX Software Engineering GmbH,      Managing Director: Wolfgang
> > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> > Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> > lukma at denx.de  




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190328/85ba6fcc/attachment.sig>