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

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

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 # ---------------------------------------------------------------------------

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

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

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

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"; };

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.

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")

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

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)

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

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;

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

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; }

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

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

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

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

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

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@488c0000")) enable_usb_clocks(1); #endif + char preboot_cmd[255]; + sprintf(preboot_cmd, "fdt addr %p;\ + fdt print /ocp/mmc@480b4000/dummy_node;\ + fdt print /ocp/mmc@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

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

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

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

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

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

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

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@denx.de

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@denx.de

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@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@denx.de
participants (4)
-
Jean-Jacques Hiblot
-
Lukasz Majewski
-
Michal Simek
-
Simon Glass