[U-Boot] [PATCH v3 00/19] SPL: extend FIT loading support

[U-Boot] [PATCH v3 00/19] SPL: extend FIT loading support

[Andre Przywara]

Some minor fixes version of the SPL FIT loading series and the respective
patches to enable this feature on 64-bit Allwinner SoCs.
There is a new patch (6/19) fixing the SPL_FIT dependencies, above all
selecting SPL_OF_LIBFDT when SPL_FIT is enabled. This reduces the number
of Kconfig symbols a board has to select for the SPL fit loading from
four down to two, which leads to changes in the final patches enabling
this feature. Compared to the previous version the SPL FIT loading
is now selected in the Kconfig for both 64-bit sunxi SoCs, so there is
less burden on each individual defconfig.
Also following Olliver's suggestion a symbol in mksunxiboot has been renamed.
---

The first five patches introduce the core of the extened SPL FIT loading
support, see below for a description. Patch 6 fixes a Kconfig dependency
to simplify the usage of this option.
Patches 7-10 make some room in the sunxi 64-bit SPL to allow
compiling in the FIT loading bits. Patch 11 and 12 let the SPL choose
the proper DT from the FIT image.
The next two patches add the infrastructure and an actual generator script,
so the FIT image is automatically created at build time.
Patches 14 and 15 enable the SPL FIT support for Allwinner 64-bit SoCs in
general and for the Pine64 and OrangePi PC 2 in particular.
The following two patches store a DT file name in the SPL header, so
U-Boot can easily pick the proper DT when scanning the FIT image.
The idea is that this DT name should stay with the board, ideally on
eMMC or SPI flash. So both U-Boot and a firmware update tool could
identify a board, updating with compatible firmware while keeping the
DT name in place. Ideally a board vendor would once seed this name
onto on-board storage like SPI flash.
I kept those two patches in, as the work on replacing mksunxiboot with
an mkimage extension is not ready yet. Feel free to drop those from
the series if this is a problem.
The final patch updates the Pine64 README file to document the current
way of building U-Boot, which now includes the ARM Trusted Firmware build
in its image.

I would be delighted if that series can make it into the next release,
as this finally enables the fully open source firmware for the 64-bit
Allwinner SoCs (including the ATF binary).

This series is based on sunxi/master, rebased upon origin/master.

Cheers,
Andre.

-------
Currently the FIT format is not used to its full potential in the SPL:
It only loads the first image from the /images node and appends the
proper FDT.
Some boards and platforms would benefit from loading more images before
starting U-Boot proper, notably Allwinner A64 and ARMv8 Rockchip boards,
which use an ARM Trusted Firmware (ATF) image to be executed before U-Boot.

This series tries to solve this in a board agnostic and generic way:
We extend the SPL FIT loading scheme to allow loading multiple images.
So apart from loading the image which is referenced by the "firmware"
property in the respective configuration node and placing the DTB right
behind it, we iterate over all strings in the "loadable" property.
Each image referenced there will be loaded to its specified load address.
The entry point U-Boot eventually branches to will be taken from the
first image to explicitly provide the "entry" property, or, if none
of them does so, from the load address of the "firmware" image.
This keeps the scheme compatible with the FIT images our Makefile creates
automatically at the moment.
Apart from the already mentioned ATF scenario this opens up more usage
scenarios, of which the commit message of patch 04/11 lists some.
The remaining patches prepare ane finally enable this scheme for the 64-bit
Allwinner boards.

Andre Przywara (18):
  SPL: FIT: refactor FDT loading
  SPL: FIT: rework U-Boot image loading
  SPL: FIT: improve error handling
  SPL: FIT: factor out spl_load_fit_image()
  SPL: FIT: allow loading multiple images
  Kconfig: fix SPL_FIT dependency
  tools: mksunxiboot: allow larger SPL binaries
  armv8: SPL: only compile GIC code if needed
  armv8: fsl: move ccn504 code into FSL Makefile
  sunxi: A64: move SPL stack to end of SRAM A2
  sunxi: SPL: store RAM size in gd
  sunxi: SPL: add FIT config selector for Pine64 boards
  Makefile: add rules to generate SPL FIT images
  sunxi: 64-bit SoCs: introduce FIT generator script
  sunxi: defconfig: add supported DT list for Pine64 and OrangePi PC 2
  sunxi: enable automatic FIT build for 64-bit SoCs
  sunxi: use SPL header DT name for FIT board matching
  sunxi: update Pine64 README

Siarhei Siamashka (1):
  sunxi: Store the device tree name in the SPL header

 Kconfig                               |  22 ++-
 Makefile                              |  20 +++
 arch/arm/include/asm/arch-sunxi/spl.h |  19 ++-
 arch/arm/lib/Makefile                 |   4 +-
 board/sunxi/Kconfig                   |   4 +
 board/sunxi/README.pine64             | 177 +++++++++++++-------
 board/sunxi/board.c                   |  36 +++-
 board/sunxi/mksunxi_fit_atf.sh        |  73 +++++++++
 common/spl/spl_fit.c                  | 298 ++++++++++++++++++++++------------
 configs/am335x_evm_defconfig          |   1 -
 configs/evb-rk3399_defconfig          |   1 -
 configs/orangepi_pc2_defconfig        |   1 +
 configs/pine64_plus_defconfig         |   1 +
 doc/uImage.FIT/howto.txt              |  21 +++
 include/configs/sunxi-common.h        |  17 +-
 scripts/Makefile.spl                  |   3 +-
 tools/mksunxiboot.c                   |  53 +++++-
 17 files changed, 562 insertions(+), 189 deletions(-)
 create mode 100755 board/sunxi/mksunxi_fit_atf.sh

-- 
2.8.2

[U-Boot] [PATCH v3 01/19] SPL: FIT: refactor FDT loading

[Andre Przywara]

Currently the SPL FIT loader uses the spl_fit_select_fdt() function to
find the offset to the right DTB within the FIT image.
For this it iterates over all subnodes of the /configuration node in
the FIT tree and compares all "description" strings therein using a
board specific matching function.
If that finds a match, it uses the string in the "fdt" property of that
subnode to locate the matching subnode in the /images node, which points
to the DTB data.
Now this works very well, but is quite specific to cover this particular
use case. To open up the door for a more generic usage, let's split this
function into:
1) a function that just returns the node offset for the matching
   configuration node (spl_fit_find_config_node())
2) a function that returns the image data any given property in a given
   configuration node points to, additionally using a given index into
   a possbile list of strings (spl_fit_select_index())
This allows us to replace the specific function above by asking for the
image the _first string of the "fdt" property_ in the matching
configuration subnode points to.

This patch introduces no functional changes, it just refactors the code
to allow reusing it later.

(diff is overly clever here and produces a hard-to-read patch, so I
recommend to throw a look at the result instead).

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lokesh Vutla <lokeshvuta@ti.com>
---
 common/spl/spl_fit.c | 88 ++++++++++++++++++++++++++++++++++------------------
 1 file changed, 57 insertions(+), 31 deletions(-)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index aae556f..bf9fbb6 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -22,13 +22,16 @@ static ulong fdt_getprop_u32(const void *fdt, int node, const char *prop)
 	return fdt32_to_cpu(*cell);
 }
 
-static int spl_fit_select_fdt(const void *fdt, int images, int *fdt_offsetp)
+/*
+ * Iterate over all /configurations subnodes and call a platform specific
+ * function to find the matching configuration.
+ * Returns the node offset.
+ */
+static int spl_fit_find_config_node(const void *fdt)
 {
-	const char *name, *fdt_name;
-	int conf, node, fdt_node;
-	int len;
+	const char *name;
+	int conf, node, len;
 
-	*fdt_offsetp = 0;
 	conf = fdt_path_offset(fdt, FIT_CONFS_PATH);
 	if (conf < 0) {
 		debug("%s: Cannot find /configurations node: %d\n", __func__,
@@ -50,39 +53,61 @@ static int spl_fit_select_fdt(const void *fdt, int images, int *fdt_offsetp)
 			continue;
 
 		debug("Selecting config '%s'", name);
-		fdt_name = fdt_getprop(fdt, node, FIT_FDT_PROP, &len);
-		if (!fdt_name) {
-			debug("%s: Cannot find fdt name property: %d\n",
-			      __func__, len);
-			return -EINVAL;
-		}
 
-		debug(", fdt '%s'\n", fdt_name);
-		fdt_node = fdt_subnode_offset(fdt, images, fdt_name);
-		if (fdt_node < 0) {
-			debug("%s: Cannot find fdt node '%s': %d\n",
-			      __func__, fdt_name, fdt_node);
-			return -EINVAL;
+		return node;
+	}
+
+	return -1;
+}
+
+static int spl_fit_select_index(const void *fit, int images, int *offsetp,
+				const char *type, int index)
+{
+	const char *name, *str;
+	int node, conf_node;
+	int len, i;
+
+	*offsetp = 0;
+	conf_node = spl_fit_find_config_node(fit);
+	if (conf_node < 0) {
+#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
+		printf("No matching DT out of these options:\n");
+		for (node = fdt_first_subnode(fit, conf_node);
+		     node >= 0;
+		     node = fdt_next_subnode(fit, node)) {
+			name = fdt_getprop(fit, node, "description", &len);
+			printf("   %s\n", name);
 		}
+#endif
+		return -ENOENT;
+	}
 
-		*fdt_offsetp = fdt_getprop_u32(fdt, fdt_node, "data-offset");
-		len = fdt_getprop_u32(fdt, fdt_node, "data-size");
-		debug("FIT: Selected '%s'\n", name);
+	name = fdt_getprop(fit, conf_node, type, &len);
+	if (!name) {
+		debug("cannot find property '%s': %d\n", type, len);
+		return -EINVAL;
+	}
 
-		return len;
+	str = name;
+	for (i = 0; i < index; i++) {
+		str = strchr(str, '\0') + 1;
+		if (!str || (str - name >= len)) {
+			debug("no string for index %d\n", index);
+			return -E2BIG;
+		}
 	}
 
-#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
-	printf("No matching DT out of these options:\n");
-	for (node = fdt_first_subnode(fdt, conf);
-	     node >= 0;
-	     node = fdt_next_subnode(fdt, node)) {
-		name = fdt_getprop(fdt, node, "description", &len);
-		printf("   %s\n", name);
+	debug("%s: '%s'\n", type, str);
+	node = fdt_subnode_offset(fit, images, str);
+	if (node < 0) {
+		debug("cannot find image node '%s': %d\n", str, node);
+		return -EINVAL;
 	}
-#endif
 
-	return -ENOENT;
+	*offsetp = fdt_getprop_u32(fit, node, "data-offset");
+	len = fdt_getprop_u32(fit, node, "data-size");
+
+	return len;
 }
 
 static int get_aligned_image_offset(struct spl_load_info *info, int offset)
@@ -218,7 +243,8 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
 	memcpy(dst, src, data_size);
 
 	/* Figure out which device tree the board wants to use */
-	fdt_len = spl_fit_select_fdt(fit, images, &fdt_offset);
+	fdt_len = spl_fit_select_index(fit, images, &fdt_offset,
+				       FIT_FDT_PROP, 0);
 	if (fdt_len < 0)
 		return fdt_len;
 
-- 
2.8.2

[U-Boot] [PATCH v3 01/19] SPL: FIT: refactor FDT loading

[Simon Glass]

On 31 March 2017 at 16:31, Andre Przywara <andre.przywara@arm.com> wrote:
> Currently the SPL FIT loader uses the spl_fit_select_fdt() function to
> find the offset to the right DTB within the FIT image.
> For this it iterates over all subnodes of the /configuration node in
> the FIT tree and compares all "description" strings therein using a
> board specific matching function.
> If that finds a match, it uses the string in the "fdt" property of that
> subnode to locate the matching subnode in the /images node, which points
> to the DTB data.
> Now this works very well, but is quite specific to cover this particular
> use case. To open up the door for a more generic usage, let's split this
> function into:
> 1) a function that just returns the node offset for the matching
>    configuration node (spl_fit_find_config_node())
> 2) a function that returns the image data any given property in a given
>    configuration node points to, additionally using a given index into
>    a possbile list of strings (spl_fit_select_index())
> This allows us to replace the specific function above by asking for the
> image the _first string of the "fdt" property_ in the matching
> configuration subnode points to.
>
> This patch introduces no functional changes, it just refactors the code
> to allow reusing it later.
>
> (diff is overly clever here and produces a hard-to-read patch, so I
> recommend to throw a look at the result instead).
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Reviewed-by: Lokesh Vutla <lokeshvuta@ti.com>
> ---
>  common/spl/spl_fit.c | 88 ++++++++++++++++++++++++++++++++++------------------
>  1 file changed, 57 insertions(+), 31 deletions(-)

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

[U-Boot] [PATCH v3 01/19] SPL: FIT: refactor FDT loading

[Peter Robinson]

On Fri, Mar 31, 2017 at 11:31 PM, Andre Przywara <andre.przywara@arm.com> wrote:
> Currently the SPL FIT loader uses the spl_fit_select_fdt() function to
> find the offset to the right DTB within the FIT image.
> For this it iterates over all subnodes of the /configuration node in
> the FIT tree and compares all "description" strings therein using a
> board specific matching function.
> If that finds a match, it uses the string in the "fdt" property of that
> subnode to locate the matching subnode in the /images node, which points
> to the DTB data.
> Now this works very well, but is quite specific to cover this particular
> use case. To open up the door for a more generic usage, let's split this
> function into:
> 1) a function that just returns the node offset for the matching
>    configuration node (spl_fit_find_config_node())
> 2) a function that returns the image data any given property in a given
>    configuration node points to, additionally using a given index into
>    a possbile list of strings (spl_fit_select_index())
> This allows us to replace the specific function above by asking for the
> image the _first string of the "fdt" property_ in the matching
> configuration subnode points to.
>
> This patch introduces no functional changes, it just refactors the code
> to allow reusing it later.
>
> (diff is overly clever here and produces a hard-to-read patch, so I
> recommend to throw a look at the result instead).
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Reviewed-by: Lokesh Vutla <lokeshvuta@ti.com>

Tested-by: Peter Robinson <pbrobinson@gmail.com>

Tested entire patch series on a 2Gb Pine64+ with Fedora 26. Looks good

> ---
>  common/spl/spl_fit.c | 88 ++++++++++++++++++++++++++++++++++------------------
>  1 file changed, 57 insertions(+), 31 deletions(-)
>
> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> index aae556f..bf9fbb6 100644
> --- a/common/spl/spl_fit.c
> +++ b/common/spl/spl_fit.c
> @@ -22,13 +22,16 @@ static ulong fdt_getprop_u32(const void *fdt, int node, const char *prop)
>         return fdt32_to_cpu(*cell);
>  }
>
> -static int spl_fit_select_fdt(const void *fdt, int images, int *fdt_offsetp)
> +/*
> + * Iterate over all /configurations subnodes and call a platform specific
> + * function to find the matching configuration.
> + * Returns the node offset.
> + */
> +static int spl_fit_find_config_node(const void *fdt)
>  {
> -       const char *name, *fdt_name;
> -       int conf, node, fdt_node;
> -       int len;
> +       const char *name;
> +       int conf, node, len;
>
> -       *fdt_offsetp = 0;
>         conf = fdt_path_offset(fdt, FIT_CONFS_PATH);
>         if (conf < 0) {
>                 debug("%s: Cannot find /configurations node: %d\n", __func__,
> @@ -50,39 +53,61 @@ static int spl_fit_select_fdt(const void *fdt, int images, int *fdt_offsetp)
>                         continue;
>
>                 debug("Selecting config '%s'", name);
> -               fdt_name = fdt_getprop(fdt, node, FIT_FDT_PROP, &len);
> -               if (!fdt_name) {
> -                       debug("%s: Cannot find fdt name property: %d\n",
> -                             __func__, len);
> -                       return -EINVAL;
> -               }
>
> -               debug(", fdt '%s'\n", fdt_name);
> -               fdt_node = fdt_subnode_offset(fdt, images, fdt_name);
> -               if (fdt_node < 0) {
> -                       debug("%s: Cannot find fdt node '%s': %d\n",
> -                             __func__, fdt_name, fdt_node);
> -                       return -EINVAL;
> +               return node;
> +       }
> +
> +       return -1;
> +}
> +
> +static int spl_fit_select_index(const void *fit, int images, int *offsetp,
> +                               const char *type, int index)
> +{
> +       const char *name, *str;
> +       int node, conf_node;
> +       int len, i;
> +
> +       *offsetp = 0;
> +       conf_node = spl_fit_find_config_node(fit);
> +       if (conf_node < 0) {
> +#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
> +               printf("No matching DT out of these options:\n");
> +               for (node = fdt_first_subnode(fit, conf_node);
> +                    node >= 0;
> +                    node = fdt_next_subnode(fit, node)) {
> +                       name = fdt_getprop(fit, node, "description", &len);
> +                       printf("   %s\n", name);
>                 }
> +#endif
> +               return -ENOENT;
> +       }
>
> -               *fdt_offsetp = fdt_getprop_u32(fdt, fdt_node, "data-offset");
> -               len = fdt_getprop_u32(fdt, fdt_node, "data-size");
> -               debug("FIT: Selected '%s'\n", name);
> +       name = fdt_getprop(fit, conf_node, type, &len);
> +       if (!name) {
> +               debug("cannot find property '%s': %d\n", type, len);
> +               return -EINVAL;
> +       }
>
> -               return len;
> +       str = name;
> +       for (i = 0; i < index; i++) {
> +               str = strchr(str, '\0') + 1;
> +               if (!str || (str - name >= len)) {
> +                       debug("no string for index %d\n", index);
> +                       return -E2BIG;
> +               }
>         }
>
> -#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
> -       printf("No matching DT out of these options:\n");
> -       for (node = fdt_first_subnode(fdt, conf);
> -            node >= 0;
> -            node = fdt_next_subnode(fdt, node)) {
> -               name = fdt_getprop(fdt, node, "description", &len);
> -               printf("   %s\n", name);
> +       debug("%s: '%s'\n", type, str);
> +       node = fdt_subnode_offset(fit, images, str);
> +       if (node < 0) {
> +               debug("cannot find image node '%s': %d\n", str, node);
> +               return -EINVAL;
>         }
> -#endif
>
> -       return -ENOENT;
> +       *offsetp = fdt_getprop_u32(fit, node, "data-offset");
> +       len = fdt_getprop_u32(fit, node, "data-size");
> +
> +       return len;
>  }
>
>  static int get_aligned_image_offset(struct spl_load_info *info, int offset)
> @@ -218,7 +243,8 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
>         memcpy(dst, src, data_size);
>
>         /* Figure out which device tree the board wants to use */
> -       fdt_len = spl_fit_select_fdt(fit, images, &fdt_offset);
> +       fdt_len = spl_fit_select_index(fit, images, &fdt_offset,
> +                                      FIT_FDT_PROP, 0);
>         if (fdt_len < 0)
>                 return fdt_len;
>
> --
> 2.8.2
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 02/19] SPL: FIT: rework U-Boot image loading

[Andre Przywara]

Currently the SPL FIT loader always looks only for the first image in
the /images node a FIT tree, which it loads and later executes.

Generalize this by looking for a "firmware" property in the matched
configuration subnode, or, if that does not exist, for the first string
in the "loadables" property. Then using the string in that property,
load the image of that name from the /images node.
This still loads only one image at the moment, but refactors the code to
allow extending this in a following patch.
To simplify later re-usage, we also generalize the spl_fit_select_index()
function to not return the image location, but just the node offset.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lokesh Vutla <lokeshvuta@ti.com>
---
 common/spl/spl_fit.c | 45 +++++++++++++++++++++++++++++++--------------
 1 file changed, 31 insertions(+), 14 deletions(-)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index bf9fbb6..a4ac27b 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -60,14 +60,24 @@ static int spl_fit_find_config_node(const void *fdt)
 	return -1;
 }
 
-static int spl_fit_select_index(const void *fit, int images, int *offsetp,
-				const char *type, int index)
+/*
+ * By using the matching configuration subnode, retrieve the name of an image,
+ * specified by a property name and an index into that.
+ * @fit: Pointer to the FDT blob.
+ * @images: Offset of the /images subnode.
+ * @type: Name of the property within the configuration subnode.
+ * @index: Index into the list of strings in this property.
+ *
+ * Returns the node offset of the respective image node or a negative error
+ * number.
+ */
+static int spl_fit_get_image_node(const void *fit, int images,
+				  const char *type, int index)
 {
 	const char *name, *str;
 	int node, conf_node;
 	int len, i;
 
-	*offsetp = 0;
 	conf_node = spl_fit_find_config_node(fit);
 	if (conf_node < 0) {
 #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
@@ -104,10 +114,7 @@ static int spl_fit_select_index(const void *fit, int images, int *offsetp,
 		return -EINVAL;
 	}
 
-	*offsetp = fdt_getprop_u32(fit, node, "data-offset");
-	len = fdt_getprop_u32(fit, node, "data-size");
-
-	return len;
+	return node;
 }
 
 static int get_aligned_image_offset(struct spl_load_info *info, int offset)
@@ -193,15 +200,22 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
 	if (count == 0)
 		return -EIO;
 
-	/* find the firmware image to load */
+	/* find the node holding the images information */
 	images = fdt_path_offset(fit, FIT_IMAGES_PATH);
 	if (images < 0) {
 		debug("%s: Cannot find /images node: %d\n", __func__, images);
 		return -1;
 	}
-	node = fdt_first_subnode(fit, images);
+
+	/* find the U-Boot image */
+	node = spl_fit_get_image_node(fit, images, "firmware", 0);
+	if (node < 0) {
+		debug("could not find firmware image, trying loadables...\n");
+		node = spl_fit_get_image_node(fit, images, "loadables", 0);
+	}
 	if (node < 0) {
-		debug("%s: Cannot find first image node: %d\n", __func__, node);
+		debug("%s: Cannot find u-boot image node: %d\n",
+		      __func__, node);
 		return -1;
 	}
 
@@ -243,10 +257,13 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
 	memcpy(dst, src, data_size);
 
 	/* Figure out which device tree the board wants to use */
-	fdt_len = spl_fit_select_index(fit, images, &fdt_offset,
-				       FIT_FDT_PROP, 0);
-	if (fdt_len < 0)
-		return fdt_len;
+	node = spl_fit_get_image_node(fit, images, FIT_FDT_PROP, 0);
+	if (node < 0) {
+		debug("%s: cannot find FDT node\n", __func__);
+		return node;
+	}
+	fdt_offset = fdt_getprop_u32(fit, node, "data-offset");
+	fdt_len = fdt_getprop_u32(fit, node, "data-size");
 
 	/*
 	 * Read the device tree and place it after the image. There may be
-- 
2.8.2

[U-Boot] [PATCH v3 02/19] SPL: FIT: rework U-Boot image loading

[Simon Glass]

On 31 March 2017 at 16:31, Andre Przywara <andre.przywara@arm.com> wrote:
> Currently the SPL FIT loader always looks only for the first image in
> the /images node a FIT tree, which it loads and later executes.
>
> Generalize this by looking for a "firmware" property in the matched
> configuration subnode, or, if that does not exist, for the first string
> in the "loadables" property. Then using the string in that property,
> load the image of that name from the /images node.
> This still loads only one image at the moment, but refactors the code to
> allow extending this in a following patch.
> To simplify later re-usage, we also generalize the spl_fit_select_index()
> function to not return the image location, but just the node offset.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Reviewed-by: Lokesh Vutla <lokeshvuta@ti.com>
> ---
>  common/spl/spl_fit.c | 45 +++++++++++++++++++++++++++++++--------------
>  1 file changed, 31 insertions(+), 14 deletions(-)

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

[U-Boot] [PATCH v3 03/19] SPL: FIT: improve error handling

[Andre Przywara]

At the moment we ignore any errors due to missing FIT properties,
instead go ahead and calculate our addresses with the -1 return value.
Fix this and bail out if any of the mandatory properties are missing.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 common/spl/spl_fit.c | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index a4ac27b..55da37a 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -11,14 +11,17 @@
 #include <libfdt.h>
 #include <spl.h>
 
+#define FDT_ERROR ((ulong)(-1))
+
 static ulong fdt_getprop_u32(const void *fdt, int node, const char *prop)
 {
 	const u32 *cell;
 	int len;
 
 	cell = fdt_getprop(fdt, node, prop, &len);
-	if (len != sizeof(*cell))
-		return -1U;
+	if (!cell || len != sizeof(*cell))
+		return FDT_ERROR;
+
 	return fdt32_to_cpu(*cell);
 }
 
@@ -221,7 +224,11 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
 
 	/* Get its information and set up the spl_image structure */
 	data_offset = fdt_getprop_u32(fit, node, "data-offset");
+	if (data_offset == FDT_ERROR)
+		return -1;
 	data_size = fdt_getprop_u32(fit, node, "data-size");
+	if (data_size == FDT_ERROR)
+		return -1;
 	load = fdt_getprop_u32(fit, node, "load");
 	debug("data_offset=%x, data_size=%x\n", data_offset, data_size);
 	spl_image->load_addr = load;
@@ -264,6 +271,10 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
 	}
 	fdt_offset = fdt_getprop_u32(fit, node, "data-offset");
 	fdt_len = fdt_getprop_u32(fit, node, "data-size");
+	if (fdt_offset == FDT_ERROR || fdt_len == FDT_ERROR) {
+		debug("%s: cannot load FDT data\n" __func__);
+		return -1;
+	}
 
 	/*
 	 * Read the device tree and place it after the image. There may be
-- 
2.8.2

[U-Boot] [PATCH v3 03/19] SPL: FIT: improve error handling

[Simon Glass]

Hi Andre,

On 31 March 2017 at 16:31, Andre Przywara <andre.przywara@arm.com> wrote:
> At the moment we ignore any errors due to missing FIT properties,
> instead go ahead and calculate our addresses with the -1 return value.
> Fix this and bail out if any of the mandatory properties are missing.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  common/spl/spl_fit.c | 15 +++++++++++++--
>  1 file changed, 13 insertions(+), 2 deletions(-)

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

nit below

>
> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> index a4ac27b..55da37a 100644
> --- a/common/spl/spl_fit.c
> +++ b/common/spl/spl_fit.c
> @@ -11,14 +11,17 @@
>  #include <libfdt.h>
>  #include <spl.h>
>
> +#define FDT_ERROR ((ulong)(-1))
> +
>  static ulong fdt_getprop_u32(const void *fdt, int node, const char *prop)
>  {
>         const u32 *cell;
>         int len;
>
>         cell = fdt_getprop(fdt, node, prop, &len);
> -       if (len != sizeof(*cell))
> -               return -1U;
> +       if (!cell || len != sizeof(*cell))
> +               return FDT_ERROR;
> +
>         return fdt32_to_cpu(*cell);
>  }
>
> @@ -221,7 +224,11 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
>
>         /* Get its information and set up the spl_image structure */
>         data_offset = fdt_getprop_u32(fit, node, "data-offset");
> +       if (data_offset == FDT_ERROR)
> +               return -1;
>         data_size = fdt_getprop_u32(fit, node, "data-size");
> +       if (data_size == FDT_ERROR)
> +               return -1;

Can you return a proper error number - this is -EPERM which doesn't seem right.

>         load = fdt_getprop_u32(fit, node, "load");
>         debug("data_offset=%x, data_size=%x\n", data_offset, data_size);
>         spl_image->load_addr = load;
> @@ -264,6 +271,10 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
>         }
>         fdt_offset = fdt_getprop_u32(fit, node, "data-offset");
>         fdt_len = fdt_getprop_u32(fit, node, "data-size");
> +       if (fdt_offset == FDT_ERROR || fdt_len == FDT_ERROR) {
> +               debug("%s: cannot load FDT data\n" __func__);
> +               return -1;
> +       }
>
>         /*
>          * Read the device tree and place it after the image. There may be
> --
> 2.8.2
>

Regards,
Simon

[U-Boot] [PATCH v3 04/19] SPL: FIT: factor out spl_load_fit_image()

[Andre Przywara]

At the moment we load two images from a FIT image: the actual U-Boot
image and the .dtb file. Both times we have very similar code, that deals
with alignment requirements the media we load from imposes upon us.
Factor out this code into a new function, which we just call twice.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 common/spl/spl_fit.c | 160 +++++++++++++++++++++++++--------------------------
 1 file changed, 78 insertions(+), 82 deletions(-)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 55da37a..cfcb1fe 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -158,19 +158,79 @@ static int get_aligned_image_size(struct spl_load_info *info, int data_size,
 	return (data_size + info->bl_len - 1) / info->bl_len;
 }
 
+/*
+ * spl_load_fit_image loads the image described in a certain FIT node.
+ * @info: points to information about the device to load data from
+ * @sector: the start sector of the FIT image on the device
+ * @fit: points to the flattened device tree blob describing the FIT image
+ * @base_offset: the beginning of the data area containing the actual
+ * 		 image data, relative to the beginning of the FIT
+ * @node: offset of the DT node describing the image to load (relative to @fit)
+ * @image_info: will be filled with information about the loaded image
+ * 		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.
+ *
+ * Returns an error value or 0 on success.
+ */
+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)
+{
+	ulong offset;
+	size_t length;
+	ulong load_addr, load_ptr;
+	void *src;
+	ulong overhead;
+	int nr_sectors;
+	int align_len = ARCH_DMA_MINALIGN - 1;
+
+	offset = fdt_getprop_u32(fit, node, "data-offset");
+	if (offset == FDT_ERROR)
+		return -ENOENT;
+	offset += base_offset;
+	length = fdt_getprop_u32(fit, node, "data-size");
+	if (length == FDT_ERROR)
+		return -ENOENT;
+	load_addr = fdt_getprop_u32(fit, node, "load");
+	if (load_addr == FDT_ERROR && image_info)
+		load_addr = image_info->load_addr;
+	load_ptr = (load_addr + align_len) & ~align_len;
+
+	overhead = get_aligned_image_overhead(info, offset);
+	nr_sectors = get_aligned_image_size(info, length, offset);
+
+	if (info->read(info, sector + get_aligned_image_offset(info, offset),
+		       nr_sectors, (void*)load_ptr) != nr_sectors)
+		return -EIO;
+	debug("image: dst=%lx, offset=%lx, size=%lx\n", load_ptr, offset,
+	      (unsigned long)length);
+
+	src = (void *)load_ptr + overhead;
+#ifdef CONFIG_SPL_FIT_IMAGE_POST_PROCESS
+	board_fit_image_post_process(&src, &length);
+#endif
+
+	memcpy((void*)load_addr, src, length);
+
+	if (image_info) {
+		image_info->load_addr = load_addr;
+		image_info->size = length;
+		image_info->entry_point = fdt_getprop_u32(fit, node, "entry");
+	}
+
+	return 0;
+}
+
 int spl_load_simple_fit(struct spl_image_info *spl_image,
 			struct spl_load_info *info, ulong sector, void *fit)
 {
 	int sectors;
-	ulong size, load;
+	ulong size;
 	unsigned long count;
-	int node, images;
-	void *load_ptr;
-	int fdt_offset, fdt_len;
-	int data_offset, data_size;
+	struct spl_image_info image_info;
+	int node, images, ret;
 	int base_offset, align_len = ARCH_DMA_MINALIGN - 1;
-	int src_sector;
-	void *dst, *src;
 
 	/*
 	 * Figure out where the external images start. This is the base for the
@@ -222,46 +282,13 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
 		return -1;
 	}
 
-	/* Get its information and set up the spl_image structure */
-	data_offset = fdt_getprop_u32(fit, node, "data-offset");
-	if (data_offset == FDT_ERROR)
-		return -1;
-	data_size = fdt_getprop_u32(fit, node, "data-size");
-	if (data_size == FDT_ERROR)
-		return -1;
-	load = fdt_getprop_u32(fit, node, "load");
-	debug("data_offset=%x, data_size=%x\n", data_offset, data_size);
-	spl_image->load_addr = load;
-	spl_image->entry_point = load;
-	spl_image->os = IH_OS_U_BOOT;
-
-	/*
-	 * Work out where to place the image. We read it so that the first
-	 * byte will be at 'load'. This may mean we need to load it starting
-	 * before then, since we can only read whole blocks.
-	 */
-	data_offset += base_offset;
-	sectors = get_aligned_image_size(info, data_size, data_offset);
-	load_ptr = (void *)load;
-	debug("U-Boot size %x, data %p\n", data_size, load_ptr);
-	dst = load_ptr;
-
-	/* Read the image */
-	src_sector = sector + get_aligned_image_offset(info, data_offset);
-	debug("Aligned image read: dst=%p, src_sector=%x, sectors=%x\n",
-	      dst, src_sector, sectors);
-	count = info->read(info, src_sector, sectors, dst);
-	if (count != sectors)
-		return -EIO;
-	debug("image: dst=%p, data_offset=%x, size=%x\n", dst, data_offset,
-	      data_size);
-	src = dst + get_aligned_image_overhead(info, data_offset);
+	/* Load the image and set up the spl_image structure */
+	ret = spl_load_fit_image(info, sector, fit, base_offset, node,
+				 spl_image);
+	if (ret)
+		return ret;
 
-#ifdef CONFIG_SPL_FIT_IMAGE_POST_PROCESS
-	board_fit_image_post_process((void **)&src, (size_t *)&data_size);
-#endif
-
-	memcpy(dst, src, data_size);
+	spl_image->os = IH_OS_U_BOOT;
 
 	/* Figure out which device tree the board wants to use */
 	node = spl_fit_get_image_node(fit, images, FIT_FDT_PROP, 0);
@@ -269,43 +296,12 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
 		debug("%s: cannot find FDT node\n", __func__);
 		return node;
 	}
-	fdt_offset = fdt_getprop_u32(fit, node, "data-offset");
-	fdt_len = fdt_getprop_u32(fit, node, "data-size");
-	if (fdt_offset == FDT_ERROR || fdt_len == FDT_ERROR) {
-		debug("%s: cannot load FDT data\n" __func__);
-		return -1;
-	}
 
 	/*
-	 * Read the device tree and place it after the image. There may be
-	 * some extra data before it since we can only read entire blocks.
-	 * And also align the destination address to ARCH_DMA_MINALIGN.
+	 * Read the device tree and place it after the image.
+	 * Align the destination address to ARCH_DMA_MINALIGN.
 	 */
-	dst = (void *)((load + data_size + align_len) & ~align_len);
-	fdt_offset += base_offset;
-	sectors = get_aligned_image_size(info, fdt_len, fdt_offset);
-	src_sector = sector + get_aligned_image_offset(info, fdt_offset);
-	count = info->read(info, src_sector, sectors, dst);
-	debug("Aligned fdt read: dst %p, src_sector = %x, sectors %x\n",
-	      dst, src_sector, sectors);
-	if (count != sectors)
-		return -EIO;
-
-	/*
-	 * Copy the device tree so that it starts immediately after the image.
-	 * After this we will have the U-Boot image and its device tree ready
-	 * for us to start.
-	 */
-	debug("fdt: dst=%p, data_offset=%x, size=%x\n", dst, fdt_offset,
-	      fdt_len);
-	src = dst + get_aligned_image_overhead(info, fdt_offset);
-	dst = load_ptr + data_size;
-
-#ifdef CONFIG_SPL_FIT_IMAGE_POST_PROCESS
-	board_fit_image_post_process((void **)&src, (size_t *)&fdt_len);
-#endif
-
-	memcpy(dst, src, fdt_len);
-
-	return 0;
+	image_info.load_addr = spl_image->load_addr + spl_image->size;
+	return spl_load_fit_image(info, sector, fit, base_offset, node,
+				  &image_info);
 }
-- 
2.8.2

[U-Boot] [PATCH v3 04/19] SPL: FIT: factor out spl_load_fit_image()

[Simon Glass]

On 31 March 2017 at 16:31, Andre Przywara <andre.przywara@arm.com> wrote:
> At the moment we load two images from a FIT image: the actual U-Boot
> image and the .dtb file. Both times we have very similar code, that deals
> with alignment requirements the media we load from imposes upon us.
> Factor out this code into a new function, which we just call twice.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  common/spl/spl_fit.c | 160 +++++++++++++++++++++++++--------------------------
>  1 file changed, 78 insertions(+), 82 deletions(-)
>

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

nit below

> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> index 55da37a..cfcb1fe 100644
> --- a/common/spl/spl_fit.c
> +++ b/common/spl/spl_fit.c
> @@ -158,19 +158,79 @@ static int get_aligned_image_size(struct spl_load_info *info, int data_size,
>         return (data_size + info->bl_len - 1) / info->bl_len;
>  }
>
> +/*
> + * spl_load_fit_image loads the image described in a certain FIT node.
> + * @info: points to information about the device to load data from
> + * @sector: the start sector of the FIT image on the device
> + * @fit: points to the flattened device tree blob describing the FIT image
> + * @base_offset: the beginning of the data area containing the actual
> + *              image data, relative to the beginning of the FIT
> + * @node: offset of the DT node describing the image to load (relative to @fit)
> + * @image_info: will be filled with information about the loaded image
> + *             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.
> + *
> + * Returns an error value or 0 on success.

@return 0 on success, or -ve error value

(is that right?)

[U-Boot] [PATCH v3 05/19] SPL: FIT: allow loading multiple images

[Andre Przywara]

So far we were not using the FIT image format to its full potential:
The SPL FIT loader was just loading the first image from the /images
node plus one of the listed DTBs.
Now with the refactored loader code it's easy to load an arbitrary
number of images in addition to the two mentioned above.
As described in the FIT image source file format description, iterate
over all images listed at the "loadables" property in the configuration
node and load every image at its desired location.
This allows to load any kind of images:
- firmware images to execute before U-Boot proper (for instance
  ARM Trusted Firmware (ATF))
- firmware images for management processors (SCP, arisc, ...)
- firmware images for devices like WiFi controllers
- bit files for FPGAs
- additional configuration data
- kernels and/or ramdisks
The actual usage of this feature would be platform and/or board specific.

Also update the FIT documentation to mention the new SPL feature.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lokesh Vutla <lokeshvuta@ti.com>
---
 common/spl/spl_fit.c     | 42 ++++++++++++++++++++++++++++++++++++++++--
 doc/uImage.FIT/howto.txt | 21 +++++++++++++++++++++
 2 files changed, 61 insertions(+), 2 deletions(-)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index cfcb1fe..edf4a43 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -231,6 +231,7 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
 	struct spl_image_info image_info;
 	int node, images, ret;
 	int base_offset, align_len = ARCH_DMA_MINALIGN - 1;
+	int index = 0;
 
 	/*
 	 * Figure out where the external images start. This is the base for the
@@ -275,6 +276,11 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
 	if (node < 0) {
 		debug("could not find firmware image, trying loadables...\n");
 		node = spl_fit_get_image_node(fit, images, "loadables", 0);
+		/*
+		 * If we pick the U-Boot image from "loadables", start at
+		 * the second image when later loading additional images.
+		 */
+		index = 1;
 	}
 	if (node < 0) {
 		debug("%s: Cannot find u-boot image node: %d\n",
@@ -302,6 +308,38 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
 	 * Align the destination address to ARCH_DMA_MINALIGN.
 	 */
 	image_info.load_addr = spl_image->load_addr + spl_image->size;
-	return spl_load_fit_image(info, sector, fit, base_offset, node,
-				  &image_info);
+	ret = spl_load_fit_image(info, sector, fit, base_offset, node,
+				 &image_info);
+	if (ret < 0)
+		return ret;
+
+	/* Now check if there are more images for us to load */
+	for (; ; index++) {
+		node = spl_fit_get_image_node(fit, images, "loadables", index);
+		if (node < 0)
+			break;
+
+		ret = spl_load_fit_image(info, sector, fit, base_offset, node,
+					 &image_info);
+		if (ret < 0)
+			continue;
+
+		/*
+		 * If the "firmware" image did not provide an entry point,
+		 * use the first valid entry point from the loadables.
+		 */
+		if (spl_image->entry_point == FDT_ERROR &&
+		    image_info.entry_point != FDT_ERROR)
+			spl_image->entry_point = image_info.entry_point;
+	}
+
+	/*
+	 * If a platform does not provide CONFIG_SYS_UBOOT_START, U-Boot's
+	 * Makefile will set it to 0 and it will end up as the entry point
+	 * here. What it actually means is: use the load address.
+	 */
+	if (spl_image->entry_point == FDT_ERROR || spl_image->entry_point == 0)
+		spl_image->entry_point = spl_image->load_addr;
+
+	return 0;
 }
diff --git a/doc/uImage.FIT/howto.txt b/doc/uImage.FIT/howto.txt
index 14e316f..2988a52 100644
--- a/doc/uImage.FIT/howto.txt
+++ b/doc/uImage.FIT/howto.txt
@@ -44,6 +44,27 @@ image source file     mkimage + dtc		  transfer to target
 	+	     ---------------> image file --------------------> bootm
 image data file(s)
 
+SPL usage
+---------
+
+The SPL can make use of the new image format as well, this traditionally
+is used to ship multiple device tree files within one image. Code in the SPL
+will choose the one matching the current board and append this to the
+U-Boot proper binary to be automatically used up by it.
+Aside from U-Boot proper and one device tree blob the SPL can load multiple,
+arbitrary image files as well. These binaries should be specified in their
+own subnode under the /images node, which should then be referenced from one or
+multiple /configurations subnodes. The required images must be enumerated in
+the "loadables" property as a list of strings.
+
+If a platform specific image source file (.its) is shipped with the U-Boot
+source, it can be specified using the CONFIG_SPL_FIT_SOURCE Kconfig symbol.
+In this case it will be automatically used by U-Boot's Makefile to generate
+the image.
+If a static source file is not flexible enough, CONFIG_SPL_FIT_GENERATOR
+can point to a script which generates this image source file during
+the build process. It gets passed a list of device tree files (taken from the
+CONFIG_OF_LIST symbol).
 
 Example 1 -- old-style (non-FDT) kernel booting
 -----------------------------------------------
-- 
2.8.2

[U-Boot] [PATCH v3 05/19] SPL: FIT: allow loading multiple images

[Lukasz Majewski]

Hi Andre ,

> So far we were not using the FIT image format to its full potential:
> The SPL FIT loader was just loading the first image from the /images
> node plus one of the listed DTBs.
> Now with the refactored loader code it's easy to load an arbitrary
> number of images in addition to the two mentioned above.
> As described in the FIT image source file format description, iterate
> over all images listed at the "loadables" property in the
> configuration node and load every image at its desired location.
> This allows to load any kind of images:
> - firmware images to execute before U-Boot proper (for instance
>   ARM Trusted Firmware (ATF))
> - firmware images for management processors (SCP, arisc, ...)
> - firmware images for devices like WiFi controllers
> - bit files for FPGAs
> - additional configuration data
> - kernels and/or ramdisks

Would it be possible to adopt this code to also load SDRAM controller
configuration data?

The issue here is that we need to do it really "early" in SPL, before
SDRAM configuration code (on TI for example).


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-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de

[U-Boot] [PATCH v3 05/19] SPL: FIT: allow loading multiple images

[Andre Przywara]

On 03/04/17 10:40, Lukasz Majewski wrote:
> Hi Andre ,
> 
>> So far we were not using the FIT image format to its full potential:
>> The SPL FIT loader was just loading the first image from the /images
>> node plus one of the listed DTBs.
>> Now with the refactored loader code it's easy to load an arbitrary
>> number of images in addition to the two mentioned above.
>> As described in the FIT image source file format description, iterate
>> over all images listed at the "loadables" property in the
>> configuration node and load every image at its desired location.
>> This allows to load any kind of images:
>> - firmware images to execute before U-Boot proper (for instance
>>   ARM Trusted Firmware (ATF))
>> - firmware images for management processors (SCP, arisc, ...)
>> - firmware images for devices like WiFi controllers
>> - bit files for FPGAs
>> - additional configuration data
>> - kernels and/or ramdisks
> 
> Would it be possible to adopt this code to also load SDRAM controller
> configuration data?

As it stands at the moment, this code is run when the SPL is finished
with initialising the platform and is about to load and hand over to
U-Boot proper.
It would need to be investigated if the device driver required to
actually load the FIT image works without DRAM being available (as in:
do we have enough heap and stack, for instance).
Also I am not sure the FIT (fdt) parsing code is really tuned for low
memory, since normally it runs with DRAM already available.

So while this doesn't sound impossible, it's probably some work ahead,
depending on the resource limitation you have in SPL on your platform.

> The issue here is that we need to do it really "early" in SPL, before
> SDRAM configuration code (on TI for example).

Yeah, I agree that this sounds tempting and I was thinking about this as
well already.
It would be nice to use the board detection code to select the right
DRAM parameters, we have this use case on sunxi boards as well (some
newer A64 based boards use LPDDR3, others use DDR3L).
So far I was thinking about introducing some auto-detection feature in
the DRAM init code to address this.

Cheers,
Andre.

[U-Boot] [PATCH v3 05/19] SPL: FIT: allow loading multiple images

[Dr. Philipp Tomsich]

> On 03 Apr 2017, at 12:05, Andre Przywara <andre.przywara@arm.com> wrote:
> 
> On 03/04/17 10:40, Lukasz Majewski wrote:
>> Hi Andre ,
>> 
>>> So far we were not using the FIT image format to its full potential:
>>> The SPL FIT loader was just loading the first image from the /images
>>> node plus one of the listed DTBs.
>>> Now with the refactored loader code it's easy to load an arbitrary
>>> number of images in addition to the two mentioned above.
>>> As described in the FIT image source file format description, iterate
>>> over all images listed at the "loadables" property in the
>>> configuration node and load every image at its desired location.
>>> This allows to load any kind of images:
>>> - firmware images to execute before U-Boot proper (for instance
>>>  ARM Trusted Firmware (ATF))
>>> - firmware images for management processors (SCP, arisc, ...)
>>> - firmware images for devices like WiFi controllers
>>> - bit files for FPGAs
>>> - additional configuration data
>>> - kernels and/or ramdisks
>> 
>> Would it be possible to adopt this code to also load SDRAM controller
>> configuration data?
> 
> As it stands at the moment, this code is run when the SPL is finished
> with initialising the platform and is about to load and hand over to
> U-Boot proper.
> It would need to be investigated if the device driver required to
> actually load the FIT image works without DRAM being available (as in:
> do we have enough heap and stack, for instance).
> Also I am not sure the FIT (fdt) parsing code is really tuned for low
> memory, since normally it runs with DRAM already available.
> 
> So while this doesn't sound impossible, it's probably some work ahead,
> depending on the resource limitation you have in SPL on your platform.

The more general solution would be to move towards having a TPL in
addition to the SPL…

Regards,
Philipp.

[U-Boot] [PATCH v3 05/19] SPL: FIT: allow loading multiple images

[Lukasz Majewski]

Hi Andre,

> 
> 
> On 03/04/17 10:40, Lukasz Majewski wrote:
> > Hi Andre ,
> > 
> >> So far we were not using the FIT image format to its full
> >> potential: The SPL FIT loader was just loading the first image
> >> from the /images node plus one of the listed DTBs.
> >> Now with the refactored loader code it's easy to load an arbitrary
> >> number of images in addition to the two mentioned above.
> >> As described in the FIT image source file format description,
> >> iterate over all images listed at the "loadables" property in the
> >> configuration node and load every image at its desired location.
> >> This allows to load any kind of images:
> >> - firmware images to execute before U-Boot proper (for instance
> >>   ARM Trusted Firmware (ATF))
> >> - firmware images for management processors (SCP, arisc, ...)
> >> - firmware images for devices like WiFi controllers
> >> - bit files for FPGAs
> >> - additional configuration data
> >> - kernels and/or ramdisks
> > 
> > Would it be possible to adopt this code to also load SDRAM
> > controller configuration data?
> 
> As it stands at the moment, this code is run when the SPL is finished
> with initialising the platform and is about to load and hand over to
> U-Boot proper.
> It would need to be investigated if the device driver required to
> actually load the FIT image works without DRAM being available (as in:
> do we have enough heap and stack, for instance).

It all must be done with "simple malloc" enabled, since access to the
config data requires SPI.

However, the I2C works without the need to use "malloc" (as it is done
with TI devices).

> Also I am not sure the FIT (fdt) parsing code is really tuned for low
> memory, since normally it runs with DRAM already available.
> 
> So while this doesn't sound impossible, it's probably some work ahead,
> depending on the resource limitation you have in SPL on your platform.

This is doable - I'm sure :-)

I'm just wondering if this could be added to this framework (to avoid
double FIT parsing) - but (please correct me if I'm wrong) it seems
conceptually different (@ different point in time we parse FIT and in
your case DRAM is a must have).

> 
> > The issue here is that we need to do it really "early" in SPL,
> > before SDRAM configuration code (on TI for example).
> 
> Yeah, I agree that this sounds tempting and I was thinking about this
> as well already.
> It would be nice to use the board detection code to select the right
> DRAM parameters, we have this use case on sunxi boards as well (some
> newer A64 based boards use LPDDR3, others use DDR3L).

Ok. So such facility would be needed sooner or latter.

> So far I was thinking about introducing some auto-detection feature in
> the DRAM init code to address this.

I can provide example from TI's playground (am57xx). They provide excel
sheet to calculate values for DRAM controller's registers -> the output
can be converted to binary blobs.

> 
> Cheers,
> Andre.


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-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de

[U-Boot] [PATCH v3 05/19] SPL: FIT: allow loading multiple images

[Simon Glass]

On 31 March 2017 at 16:31, Andre Przywara <andre.przywara@arm.com> wrote:
> So far we were not using the FIT image format to its full potential:
> The SPL FIT loader was just loading the first image from the /images
> node plus one of the listed DTBs.
> Now with the refactored loader code it's easy to load an arbitrary
> number of images in addition to the two mentioned above.
> As described in the FIT image source file format description, iterate
> over all images listed at the "loadables" property in the configuration
> node and load every image at its desired location.
> This allows to load any kind of images:
> - firmware images to execute before U-Boot proper (for instance
>   ARM Trusted Firmware (ATF))
> - firmware images for management processors (SCP, arisc, ...)
> - firmware images for devices like WiFi controllers
> - bit files for FPGAs
> - additional configuration data
> - kernels and/or ramdisks
> The actual usage of this feature would be platform and/or board specific.
>
> Also update the FIT documentation to mention the new SPL feature.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Reviewed-by: Lokesh Vutla <lokeshvuta@ti.com>
> ---
>  common/spl/spl_fit.c     | 42 ++++++++++++++++++++++++++++++++++++++++--
>  doc/uImage.FIT/howto.txt | 21 +++++++++++++++++++++
>  2 files changed, 61 insertions(+), 2 deletions(-)

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

It would be useful to have an example .its file showing how to use
this, in addition to the README change you did.

[U-Boot] [PATCH v3 06/19] Kconfig: fix SPL_FIT dependency

[Andre Przywara]

SPL_FIT obviously requires libfdt in SPL, so let Kconfig express that by
selecting SPL_OF_LIBFDT.
Also make the actual options that users want (SPL signature and SPL FIT
loading) visible in the menu and let them select the SPL_FIT as a
requirement.
Also remove the now redundant SPL_OF_LIBFDT from those Kconfigs that had
it in for the SPL FIT loading feature.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 Kconfig                      | 4 +++-
 configs/am335x_evm_defconfig | 1 -
 configs/evb-rk3399_defconfig | 1 -
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Kconfig b/Kconfig
index e0744d1..a2f45d3 100644
--- a/Kconfig
+++ b/Kconfig
@@ -208,15 +208,17 @@ config FIT_IMAGE_POST_PROCESS
 config SPL_FIT
 	bool "Support Flattened Image Tree within SPL"
 	depends on SPL
+	select SPL_OF_LIBFDT
 
 config SPL_FIT_SIGNATURE
 	bool "Enable signature verification of FIT firmware within SPL"
-	depends on SPL_FIT
 	depends on SPL_DM
+	select SPL_FIT
 	select SPL_RSA
 
 config SPL_LOAD_FIT
 	bool "Enable SPL loading U-Boot as a FIT"
+	select SPL_FIT
 	help
 	  Normally with the SPL framework a legacy image is generated as part
 	  of the build. This contains U-Boot along with information as to
diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig
index ab7b9aa..525d07e 100644
--- a/configs/am335x_evm_defconfig
+++ b/configs/am335x_evm_defconfig
@@ -57,4 +57,3 @@ CONFIG_G_DNL_MANUFACTURER="Texas Instruments"
 CONFIG_G_DNL_VENDOR_NUM=0x0451
 CONFIG_G_DNL_PRODUCT_NUM=0xd022
 CONFIG_RSA=y
-CONFIG_SPL_OF_LIBFDT=y
diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig
index bedc1fd..8cae666 100644
--- a/configs/evb-rk3399_defconfig
+++ b/configs/evb-rk3399_defconfig
@@ -4,7 +4,6 @@ CONFIG_ROCKCHIP_RK3399=y
 CONFIG_DEFAULT_DEVICE_TREE="rk3399-evb"
 CONFIG_FIT=y
 CONFIG_SPL_LOAD_FIT=y
-CONFIG_SPL_OF_LIBFDT=y
 CONFIG_SPL_ATF_SUPPORT=y
 CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x200
 CONFIG_SPL_ATF_TEXT_BASE=0x00010000
-- 
2.8.2

[U-Boot] [PATCH v3 07/19] tools: mksunxiboot: allow larger SPL binaries

[Andre Przywara]

mksunxiboot limits the size of the resulting SPL binaries to pretty
conservative values to cover all SoCs and all boot media (NAND).
It turns out that we have limit checks in place in the build process,
so mksunxiboot can be relaxed and allow packaging binaries up to the
actual 32KB the mask boot ROM actually imposes.
This allows to have a bigger SPL, which is crucial for AArch64 builds.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
 tools/mksunxiboot.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/mksunxiboot.c b/tools/mksunxiboot.c
index 0f0b003..111d74a 100644
--- a/tools/mksunxiboot.c
+++ b/tools/mksunxiboot.c
@@ -48,8 +48,8 @@ int gen_check_sum(struct boot_file_head *head_p)
 #define ALIGN(x, a) __ALIGN_MASK((x), (typeof(x))(a)-1)
 #define __ALIGN_MASK(x, mask) (((x)+(mask))&~(mask))
 
-#define SUN4I_SRAM_SIZE 0x7600	/* 0x7748+ is used by BROM */
-#define SRAM_LOAD_MAX_SIZE (SUN4I_SRAM_SIZE - sizeof(struct boot_file_head))
+#define SUNXI_SRAM_SIZE 0x8000	/* SoC with smaller size are limited before */
+#define SRAM_LOAD_MAX_SIZE (SUNXI_SRAM_SIZE - sizeof(struct boot_file_head))
 
 /*
  * BROM (at least on A10 and A20) requires NAND-images to be explicitly aligned
-- 
2.8.2

[U-Boot] [PATCH v3 08/19] armv8: SPL: only compile GIC code if needed

[Andre Przywara]

Not every SoC needs to set up the GIC interrupt controller, so link
think code only when the respective config option is set.
This shaves off some bytes from the SPL code size.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
 arch/arm/lib/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index b95e105..5733430 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -44,7 +44,9 @@ ifdef CONFIG_CPU_V7M
 obj-y	+= interrupts_m.o
 else ifdef CONFIG_ARM64
 obj-y	+= ccn504.o
+ifneq ($(CONFIG_GICV2)$(CONFIG_GICV3),)
 obj-y	+= gic_64.o
+endif
 obj-y	+= interrupts_64.o
 else
 obj-y	+= interrupts.o
-- 
2.8.2

[U-Boot] [PATCH v3 09/19] armv8: fsl: move ccn504 code into FSL Makefile

[Andre Przywara]

The generic ARMv8 assembly code contains routines for setting up
a CCN interconnect, though the Freescale SoCs are the only user.
Link this code only for Freescale targets, this saves some precious
bytes in the chronically tight SPL.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 arch/arm/lib/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 5733430..82154f6 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -43,7 +43,7 @@ obj-y	+= stack.o
 ifdef CONFIG_CPU_V7M
 obj-y	+= interrupts_m.o
 else ifdef CONFIG_ARM64
-obj-y	+= ccn504.o
+obj-$(CONFIG_FSL_LAYERSCAPE) += ccn504.o
 ifneq ($(CONFIG_GICV2)$(CONFIG_GICV3),)
 obj-y	+= gic_64.o
 endif
-- 
2.8.2

[U-Boot] [PATCH v3 10/19] sunxi: A64: move SPL stack to end of SRAM A2

[Andre Przywara]

The SPL stack is usually located at the end of SRAM A1, where it grows
towards the end of the SPL.
For the really big AArch64 binaries the stack overwrites code pretty
soon, so move the SPL stack to the end of SRAM A2, which is unused at this
time.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
 include/configs/sunxi-common.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 171cea2..b7eb95e 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -182,7 +182,12 @@
 #ifdef CONFIG_SUNXI_HIGH_SRAM
 #define CONFIG_SPL_TEXT_BASE		0x10040		/* sram start+header */
 #define CONFIG_SPL_MAX_SIZE		0x7fc0		/* 32 KiB */
+#ifdef CONFIG_ARM64
+/* end of SRAM A2 for now, as SRAM A1 is pretty tight for an ARM64 build */
+#define LOW_LEVEL_SRAM_STACK		0x00054000
+#else
 #define LOW_LEVEL_SRAM_STACK		0x00018000
+#endif /* !CONFIG_ARM64 */
 #else
 #define CONFIG_SPL_TEXT_BASE		0x40		/* sram start+header */
 #define CONFIG_SPL_MAX_SIZE		0x5fc0		/* 24KB on sun4i/sun7i */
-- 
2.8.2

[U-Boot] [PATCH v3 10/19] sunxi: A64: move SPL stack to end of SRAM A2

[Maxime Ripard]

On Fri, Mar 31, 2017 at 11:31:22PM +0100, Andre Przywara wrote:
> The SPL stack is usually located at the end of SRAM A1, where it grows
> towards the end of the SPL.
> For the really big AArch64 binaries the stack overwrites code pretty
> soon, so move the SPL stack to the end of SRAM A2, which is unused at this
> time.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Reviewed-by: Simon Glass <sjg@chromium.org>

Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170403/aad8c798/attachment.sig>

[U-Boot] [PATCH v3 11/19] sunxi: SPL: store RAM size in gd

[Andre Przywara]

The sunxi SPL was holding the detected RAM size in some local variable
only, so it wasn't accessible for other functions.
Store the value in gd->ram_size instead, so it can be used later on.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
 board/sunxi/board.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index b966012..a510422 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -480,7 +480,6 @@ void i2c_init_board(void)
 void sunxi_board_init(void)
 {
 	int power_failed = 0;
-	unsigned long ramsize;
 
 #ifdef CONFIG_SY8106A_POWER
 	power_failed = sy8106a_set_vout1(CONFIG_SY8106A_VOUT1_VOLT);
@@ -541,9 +540,9 @@ void sunxi_board_init(void)
 #endif
 #endif
 	printf("DRAM:");
-	ramsize = sunxi_dram_init();
-	printf(" %d MiB\n", (int)(ramsize >> 20));
-	if (!ramsize)
+	gd->ram_size = sunxi_dram_init();
+	printf(" %d MiB\n", (int)(gd->ram_size >> 20));
+	if (!gd->ram_size)
 		hang();
 
 	/*
-- 
2.8.2

[U-Boot] [PATCH v3 11/19] sunxi: SPL: store RAM size in gd

[Maxime Ripard]

On Fri, Mar 31, 2017 at 11:31:23PM +0100, Andre Przywara wrote:
> The sunxi SPL was holding the detected RAM size in some local variable
> only, so it wasn't accessible for other functions.
> Store the value in gd->ram_size instead, so it can be used later on.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Reviewed-by: Simon Glass <sjg@chromium.org>

Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170403/62cc2ece/attachment.sig>

[U-Boot] [PATCH v3 12/19] sunxi: SPL: add FIT config selector for Pine64 boards

[Andre Przywara]

For a board or platform to support FIT loading in the SPL, it has to
provide a board_fit_config_name_match() routine, which helps to select
one of possibly multiple DTBs contained in a FIT image.
Provide a simple function which chooses the DT name U-Boot was
configured with.
If the DT name is one of the two Pine64 versions, determine the exact
model by checking the DRAM size.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
 board/sunxi/board.c | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index a510422..2ddff28 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -725,3 +725,26 @@ int ft_board_setup(void *blob, bd_t *bd)
 #endif
 	return 0;
 }
+
+#ifdef CONFIG_SPL_LOAD_FIT
+int board_fit_config_name_match(const char *name)
+{
+	const char *cmp_str;
+
+#ifdef CONFIG_DEFAULT_DEVICE_TREE
+	cmp_str = CONFIG_DEFAULT_DEVICE_TREE;
+#else
+	return 0;
+#endif
+
+/* Differentiate the two Pine64 board DTs by their DRAM size. */
+	if (strstr(name, "-pine64") && strstr(cmp_str, "-pine64")) {
+		if ((gd->ram_size > 512 * 1024 * 1024))
+			return !strstr(name, "plus");
+		else
+			return !!strstr(name, "plus");
+	} else {
+		return strcmp(name, cmp_str);
+	}
+}
+#endif
-- 
2.8.2

[U-Boot] [PATCH v3 12/19] sunxi: SPL: add FIT config selector for Pine64 boards

[Maxime Ripard]

On Fri, Mar 31, 2017 at 11:31:24PM +0100, Andre Przywara wrote:
> For a board or platform to support FIT loading in the SPL, it has to
> provide a board_fit_config_name_match() routine, which helps to select
> one of possibly multiple DTBs contained in a FIT image.
> Provide a simple function which chooses the DT name U-Boot was
> configured with.
> If the DT name is one of the two Pine64 versions, determine the exact
> model by checking the DRAM size.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Reviewed-by: Simon Glass <sjg@chromium.org>

Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170403/d5f07117/attachment.sig>

[U-Boot] [PATCH v3 13/19] Makefile: add rules to generate SPL FIT images

[Andre Przywara]

Some platforms require more complex U-Boot images than we can easily
generate via the mkimage command line, for instance to load additional
image files.
Introduce a CONFIG_SPL_FIT_SOURCE and CONFIG_SPL_FIT_GENERATOR symbol,
which can either hold an .its source file describing the image layout,
or, in the second case, a generator tool (script) to create such
a source file. This script gets passed the list of device tree files
from the CONFIG_OF_LIST variable.
A platform or board can define either of those in their defconfig file
to allow an easy building of such an image.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 Kconfig  | 17 +++++++++++++++++
 Makefile | 20 ++++++++++++++++++++
 2 files changed, 37 insertions(+)

diff --git a/Kconfig b/Kconfig
index a2f45d3..5c82788 100644
--- a/Kconfig
+++ b/Kconfig
@@ -241,6 +241,23 @@ config SPL_FIT_IMAGE_POST_PROCESS
 	  injected into the FIT creation (i.e. the blobs would have been pre-
 	  processed before being added to the FIT image).
 
+config SPL_FIT_SOURCE
+	string ".its source file for U-Boot FIT image"
+	depends on SPL_FIT
+	help
+	  Specifies a (platform specific) FIT source file to generate the
+	  U-Boot FIT image. This could specify further image to load and/or
+	  execute.
+
+config SPL_FIT_GENERATOR
+	string ".its file generator script for U-Boot FIT image"
+	depends on SPL_FIT
+	help
+	  Specifies a (platform specific) script file to generate the FIT
+	  source file used to build the U-Boot FIT image file. This gets
+	  passed a list of supported device tree file stub names to
+	  include in the generated image.
+
 endif # FIT
 
 config OF_BOARD_SETUP
diff --git a/Makefile b/Makefile
index 539fb20..5ecf40f 100644
--- a/Makefile
+++ b/Makefile
@@ -827,6 +827,10 @@ quiet_cmd_mkimage = MKIMAGE $@
 cmd_mkimage = $(objtree)/tools/mkimage $(MKIMAGEFLAGS_$(@F)) -d $< $@ \
 	$(if $(KBUILD_VERBOSE:1=), >$(MKIMAGEOUTPUT))
 
+quiet_cmd_mkfitimage = MKIMAGE $@
+cmd_mkfitimage = $(objtree)/tools/mkimage $(MKIMAGEFLAGS_$(@F)) -f $(U_BOOT_ITS) -E $@ \
+	$(if $(KBUILD_VERBOSE:1=), >$(MKIMAGEOUTPUT))
+
 quiet_cmd_cat = CAT     $@
 cmd_cat = cat $(filter-out $(PHONY), $^) > $@
 
@@ -946,6 +950,19 @@ quiet_cmd_cpp_cfg = CFG     $@
 cmd_cpp_cfg = $(CPP) -Wp,-MD,$(depfile) $(cpp_flags) $(LDPPFLAGS) -ansi \
 	-DDO_DEPS_ONLY -D__ASSEMBLY__ -x assembler-with-cpp -P -dM -E -o $@ $<
 
+# 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))
+else
+ifneq ($(CONFIG_SPL_FIT_GENERATOR),"")
+U_BOOT_ITS := u-boot.its
+$(U_BOOT_ITS): FORCE
+	$(srctree)/$(CONFIG_SPL_FIT_GENERATOR) \
+	$(patsubst %,arch/$(ARCH)/dts/%.dtb,$(subst ",,$(CONFIG_OF_LIST))) > $@
+endif
+endif
+
 ifdef CONFIG_SPL_LOAD_FIT
 MKIMAGEFLAGS_u-boot.img = -f auto -A $(ARCH) -T firmware -C none -O u-boot \
 	-a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \
@@ -978,6 +995,9 @@ u-boot-dtb.img u-boot.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)
 
+u-boot.itb: u-boot-nodtb.bin dts/dt.dtb $(U_BOOT_ITS) FORCE
+	$(call if_changed,mkfitimage)
+
 u-boot-spl.kwb: u-boot.img spl/u-boot-spl.bin FORCE
 	$(call if_changed,mkimage)
 
-- 
2.8.2

[U-Boot] [PATCH v3 14/19] sunxi: 64-bit SoCs: introduce FIT generator script

[Andre Przywara]

Now that the Makefile can call a generator script to build a more
advanced FIT image, let's use this feature to address the needs of
Allwinner boards with 64-bit SoCs (A64 and H5).
The (DTB stripped) U-Boot binary and the ATF are static, but we allow
an arbitrary number of supported device trees to be passed.
The script enters both a DT entry in the /images node and the respective
subnode in /configurations to support all listed DTBs.

This requires to copy the ARM Trusted Firmware build (bl31.bin) into
the U-Boot source directory (or to create a symlink to it).

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
 board/sunxi/mksunxi_fit_atf.sh | 73 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 73 insertions(+)
 create mode 100755 board/sunxi/mksunxi_fit_atf.sh

diff --git a/board/sunxi/mksunxi_fit_atf.sh b/board/sunxi/mksunxi_fit_atf.sh
new file mode 100755
index 0000000..afa22e8
--- /dev/null
+++ b/board/sunxi/mksunxi_fit_atf.sh
@@ -0,0 +1,73 @@
+#!/bin/sh
+#
+# script to generate FIT image source for 64-bit sunxi boards with
+# ARM Trusted Firmware and multiple device trees (given on the command line)
+#
+# usage: $0 <dt_name> [<dt_name> [<dt_name] ...]
+
+cat << __HEADER_EOF
+/dts-v1/;
+
+/ {
+	description = "Configuration to load ATF before U-Boot";
+	#address-cells = <1>;
+
+	images {
+		uboot at 1 {
+			description = "U-Boot (64-bit)";
+			data = /incbin/("u-boot-nodtb.bin");
+			type = "standalone";
+			arch = "arm64";
+			compression = "none";
+			load = <0x4a000000>;
+		};
+		atf at 1 {
+			description = "ARM Trusted Firmware";
+			data = /incbin/("bl31.bin");
+			type = "firmware";
+			arch = "arm64";
+			compression = "none";
+			load = <0x44000>;
+			entry = <0x44000>;
+		};
+__HEADER_EOF
+
+cnt=1
+for dtname in $*
+do
+	cat << __FDT_IMAGE_EOF
+		fdt@$cnt {
+			description = "$(basename $dtname .dtb)";
+			data = /incbin/("$dtname");
+			type = "flat_dt";
+			compression = "none";
+		};
+__FDT_IMAGE_EOF
+	cnt=$((cnt+1))
+done
+
+cat << __CONF_HEADER_EOF
+	};
+	configurations {
+		default = "config at 1";
+
+__CONF_HEADER_EOF
+
+cnt=1
+for dtname in $*
+do
+	cat << __CONF_SECTION_EOF
+		config@$cnt {
+			description = "$(basename $dtname .dtb)";
+			firmware = "uboot at 1";
+			loadables = "atf@1";
+			fdt = "fdt@$cnt";
+		};
+__CONF_SECTION_EOF
+	cnt=$((cnt+1))
+done
+
+cat << __ITS_EOF
+	};
+};
+__ITS_EOF
-- 
2.8.2

[U-Boot] [PATCH v3 14/19] sunxi: 64-bit SoCs: introduce FIT generator script

[Maxime Ripard]

On Fri, Mar 31, 2017 at 11:31:26PM +0100, Andre Przywara wrote:
> Now that the Makefile can call a generator script to build a more
> advanced FIT image, let's use this feature to address the needs of
> Allwinner boards with 64-bit SoCs (A64 and H5).
> The (DTB stripped) U-Boot binary and the ATF are static, but we allow
> an arbitrary number of supported device trees to be passed.
> The script enters both a DT entry in the /images node and the respective
> subnode in /configurations to support all listed DTBs.
> 
> This requires to copy the ARM Trusted Firmware build (bl31.bin) into
> the U-Boot source directory (or to create a symlink to it).
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Reviewed-by: Simon Glass <sjg@chromium.org>

Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170403/d4bf8c0f/attachment.sig>

[U-Boot] [PATCH v3 15/19] sunxi: defconfig: add supported DT list for Pine64 and OrangePi PC 2

[Andre Przywara]

When a board uses a FIT image to load U-Boot proper, it requires a list
of supported device trees to be supplied, from which it chooses the
right one at runtime.
Add this list for the Pine64 and OrangePi PC2 board.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 configs/orangepi_pc2_defconfig | 1 +
 configs/pine64_plus_defconfig  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/orangepi_pc2_defconfig b/configs/orangepi_pc2_defconfig
index 19a5c2b..9f02049 100644
--- a/configs/orangepi_pc2_defconfig
+++ b/configs/orangepi_pc2_defconfig
@@ -5,6 +5,7 @@ CONFIG_SPL=y
 CONFIG_DRAM_CLK=672
 CONFIG_DRAM_ZQ=3881977
 CONFIG_DEFAULT_DEVICE_TREE="sun50i-h5-orangepi-pc2"
+CONFIG_OF_LIST="sun50i-h5-orangepi-pc2"
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
 CONFIG_CONSOLE_MUX=y
 # CONFIG_CMD_IMLS is not set
diff --git a/configs/pine64_plus_defconfig b/configs/pine64_plus_defconfig
index 92bda60..593e24a 100644
--- a/configs/pine64_plus_defconfig
+++ b/configs/pine64_plus_defconfig
@@ -3,6 +3,7 @@ CONFIG_ARCH_SUNXI=y
 CONFIG_MACH_SUN50I=y
 CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER=y
 CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pine64-plus"
+CONFIG_OF_LIST="sun50i-a64-pine64 sun50i-a64-pine64-plus"
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
 CONFIG_CONSOLE_MUX=y
 CONFIG_SPL=y
-- 
2.8.2

[U-Boot] [PATCH v3 15/19] sunxi: defconfig: add supported DT list for Pine64 and OrangePi PC 2

[Maxime Ripard]

On Fri, Mar 31, 2017 at 11:31:27PM +0100, Andre Przywara wrote:
> When a board uses a FIT image to load U-Boot proper, it requires a list
> of supported device trees to be supplied, from which it chooses the
> right one at runtime.
> Add this list for the Pine64 and OrangePi PC2 board.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  configs/orangepi_pc2_defconfig | 1 +
>  configs/pine64_plus_defconfig  | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/configs/orangepi_pc2_defconfig b/configs/orangepi_pc2_defconfig
> index 19a5c2b..9f02049 100644
> --- a/configs/orangepi_pc2_defconfig
> +++ b/configs/orangepi_pc2_defconfig
> @@ -5,6 +5,7 @@ CONFIG_SPL=y
>  CONFIG_DRAM_CLK=672
>  CONFIG_DRAM_ZQ=3881977
>  CONFIG_DEFAULT_DEVICE_TREE="sun50i-h5-orangepi-pc2"
> +CONFIG_OF_LIST="sun50i-h5-orangepi-pc2"

CONFIG_OF_LIST already defaults to CONFIG_DEFAULT_DEVICE_TREE, so you
don't need this change.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170403/fa4fbe7e/attachment.sig>

[U-Boot] [PATCH v3 16/19] sunxi: enable automatic FIT build for 64-bit SoCs

[Andre Przywara]

The Allwinner SoCs with 64-bit cores use an ARM Trusted Firmware binary,
which needs to be loaded alongside U-Boot proper.
Set the respective Kconfig options to let them select this feature and
also automatically build the FIT image.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 Kconfig                        | 1 +
 board/sunxi/Kconfig            | 4 ++++
 include/configs/sunxi-common.h | 4 ++++
 3 files changed, 9 insertions(+)

diff --git a/Kconfig b/Kconfig
index 5c82788..ffea4c3 100644
--- a/Kconfig
+++ b/Kconfig
@@ -252,6 +252,7 @@ config SPL_FIT_SOURCE
 config SPL_FIT_GENERATOR
 	string ".its file generator script for U-Boot FIT image"
 	depends on SPL_FIT
+	default "board/sunxi/mksunxi_fit_atf.sh" if SPL_LOAD_FIT && ARCH_SUNXI
 	help
 	  Specifies a (platform specific) script file to generate the FIT
 	  source file used to build the U-Boot FIT image file. This gets
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index 3e0e262..b629f3b 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -145,12 +145,16 @@ config MACH_SUN50I
 	select SUNXI_GEN_SUN6I
 	select SUNXI_HIGH_SRAM
 	select SUPPORT_SPL
+	select FIT
+	select SPL_LOAD_FIT
 
 config MACH_SUN50I_H5
 	bool "sun50i (Allwinner H5)"
 	select ARM64
 	select MACH_SUNXI_H3_H5
 	select SUNXI_HIGH_SRAM
+	select FIT
+	select SPL_LOAD_FIT
 
 endchoice
 
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index b7eb95e..1982063 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -32,6 +32,10 @@
 # define CONFIG_MACH_TYPE_COMPAT_REV	1
 #endif
 
+#ifdef CONFIG_ARM64
+#define CONFIG_BUILD_TARGET "u-boot.itb"
+#endif
+
 /* Serial & console */
 #define CONFIG_SYS_NS16550_SERIAL
 /* ns16550 reg in the low bits of cpu reg */
-- 
2.8.2

[U-Boot] [PATCH v3 16/19] sunxi: enable automatic FIT build for 64-bit SoCs

[Maxime Ripard]

On Fri, Mar 31, 2017 at 11:31:28PM +0100, Andre Przywara wrote:
> The Allwinner SoCs with 64-bit cores use an ARM Trusted Firmware binary,
> which needs to be loaded alongside U-Boot proper.
> Set the respective Kconfig options to let them select this feature and
> also automatically build the FIT image.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>

Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170403/2fe003d3/attachment.sig>

[U-Boot] [PATCH v3 17/19] sunxi: Store the device tree name in the SPL header

[Andre Przywara]

From: Siarhei Siamashka <siarhei.siamashka@gmail.com>

This patch updates the mksunxiboot tool to optionally add
the default device tree name string to the SPL header. This
information can be used by the firmware upgrade tools to
protect users from harming themselves by trying to upgrade
to an incompatible bootloader.

The primary use case here is a non-removable bootable media
(such as NAND, eMMC or SPI flash), which already may have
a properly working, but a little bit outdated bootloader
installed. For example, the user may download or build a
new U-Boot image for "Cubieboard", and then attemept to
install it on a "Cubieboard2" hardware by mistake as a
replacement for the already existing bootloader. If this
happens, the flash programming tool can identify this
problem and warn the user.

The size of the SPL header is also increased from 64 bytes
to 96 bytes to provide enough space for the device tree name
string.
[Andre: split patch to remove OF_LIST hash feature]

Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 arch/arm/include/asm/arch-sunxi/spl.h | 19 +++++++++++---
 include/configs/sunxi-common.h        |  8 +++---
 scripts/Makefile.spl                  |  3 ++-
 tools/mksunxiboot.c                   | 49 ++++++++++++++++++++++++++++++++---
 4 files changed, 67 insertions(+), 12 deletions(-)

diff --git a/arch/arm/include/asm/arch-sunxi/spl.h b/arch/arm/include/asm/arch-sunxi/spl.h
index 831d0c0..9358397 100644
--- a/arch/arm/include/asm/arch-sunxi/spl.h
+++ b/arch/arm/include/asm/arch-sunxi/spl.h
@@ -10,7 +10,7 @@
 
 #define BOOT0_MAGIC		"eGON.BT0"
 #define SPL_SIGNATURE		"SPL" /* marks "sunxi" SPL header */
-#define SPL_HEADER_VERSION	1
+#define SPL_HEADER_VERSION	2
 
 #ifdef CONFIG_SUNXI_HIGH_SRAM
 #define SPL_ADDR		0x10000
@@ -58,11 +58,24 @@ struct boot_file_head {
 	 * compatible format, ready to be imported via "env import -t".
 	 */
 	uint32_t fel_uEnv_length;
-	uint32_t reserved1[2];
+	/*
+	 * Offset of an ASCIIZ string (relative to the SPL header), which
+	 * contains the default device tree name (CONFIG_DEFAULT_DEVICE_TREE).
+	 * This is optional and may be set to NULL. Is intended to be used
+	 * by flash programming tools for providing nice informative messages
+	 * to the users.
+	 */
+	uint32_t dt_name_offset;
+	uint32_t reserved1;
 	uint32_t boot_media;		/* written here by the boot ROM */
-	uint32_t reserved2[5];		/* padding, align to 64 bytes */
+	/* A padding area (may be used for storing text strings) */
+	uint32_t string_pool[13];
+	/* The header must be a multiple of 32 bytes (for VBAR alignment) */
 };
 
+/* Compile time check to assure proper alignment of structure */
+typedef char boot_file_head_not_multiple_of_32[1 - 2*(sizeof(struct boot_file_head) % 32)];
+
 #define is_boot0_magic(addr)	(memcmp((void *)addr, BOOT0_MAGIC, 8) == 0)
 
 #endif
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 1982063..65f0f69 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -184,8 +184,8 @@
 #endif
 
 #ifdef CONFIG_SUNXI_HIGH_SRAM
-#define CONFIG_SPL_TEXT_BASE		0x10040		/* sram start+header */
-#define CONFIG_SPL_MAX_SIZE		0x7fc0		/* 32 KiB */
+#define CONFIG_SPL_TEXT_BASE		0x10060		/* sram start+header */
+#define CONFIG_SPL_MAX_SIZE		0x7fa0		/* 32 KiB */
 #ifdef CONFIG_ARM64
 /* end of SRAM A2 for now, as SRAM A1 is pretty tight for an ARM64 build */
 #define LOW_LEVEL_SRAM_STACK		0x00054000
@@ -193,8 +193,8 @@
 #define LOW_LEVEL_SRAM_STACK		0x00018000
 #endif /* !CONFIG_ARM64 */
 #else
-#define CONFIG_SPL_TEXT_BASE		0x40		/* sram start+header */
-#define CONFIG_SPL_MAX_SIZE		0x5fc0		/* 24KB on sun4i/sun7i */
+#define CONFIG_SPL_TEXT_BASE		0x60		/* sram start+header */
+#define CONFIG_SPL_MAX_SIZE		0x5fa0		/* 24KB on sun4i/sun7i */
 #define LOW_LEVEL_SRAM_STACK		0x00008000	/* End of sram */
 #endif
 
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index d01af3b..d134b74 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -294,7 +294,8 @@ $(obj)/$(SPL_BIN).sfp: $(obj)/$(SPL_BIN).bin FORCE
 	$(call if_changed,mkimage)
 
 quiet_cmd_mksunxiboot = MKSUNXI $@
-cmd_mksunxiboot = $(objtree)/tools/mksunxiboot $< $@
+cmd_mksunxiboot = $(objtree)/tools/mksunxiboot \
+			--default-dt $(CONFIG_DEFAULT_DEVICE_TREE) $< $@
 $(obj)/sunxi-spl.bin: $(obj)/$(SPL_BIN).bin FORCE
 	$(call if_changed,mksunxiboot)
 
diff --git a/tools/mksunxiboot.c b/tools/mksunxiboot.c
index 111d74a..db0f10e 100644
--- a/tools/mksunxiboot.c
+++ b/tools/mksunxiboot.c
@@ -70,11 +70,40 @@ int main(int argc, char *argv[])
 	struct boot_img img;
 	unsigned file_size;
 	int count;
+	char *tool_name = argv[0];
+	char *default_dt = NULL;
 
-	if (argc < 2) {
-		printf("\tThis program makes an input bin file to sun4i " \
-		       "bootable image.\n" \
-		       "\tUsage: %s input_file out_putfile\n", argv[0]);
+	/* a sanity check */
+	if ((sizeof(img.header) % 32) != 0) {
+		fprintf(stderr, "ERROR: the SPL header must be a multiple ");
+		fprintf(stderr, "of 32 bytes.\n");
+		return EXIT_FAILURE;
+	}
+
+	/* process optional command line switches */
+	while (argc >= 2 && argv[1][0] == '-') {
+		if (strcmp(argv[1], "--default-dt") == 0) {
+			if (argc >= 3) {
+				default_dt = argv[2];
+				argv += 2;
+				argc -= 2;
+				continue;
+			}
+			fprintf(stderr, "ERROR: no --default-dt arg\n");
+			return EXIT_FAILURE;
+		} else {
+			fprintf(stderr, "ERROR: bad option '%s'\n", argv[1]);
+			return EXIT_FAILURE;
+		}
+	}
+
+	if (argc < 3) {
+		printf("This program converts an input binary file to a sunxi bootable image.\n");
+		printf("\nUsage: %s [options] input_file output_file\n",
+		       tool_name);
+		printf("Where [options] may be:\n");
+		printf("  --default-dt arg         - 'arg' is the default device tree name\n");
+		printf("                             (CONFIG_DEFAULT_DEVICE_TREE).\n");
 		return EXIT_FAILURE;
 	}
 
@@ -122,6 +151,18 @@ int main(int argc, char *argv[])
 	memcpy(img.header.spl_signature, SPL_SIGNATURE, 3); /* "sunxi" marker */
 	img.header.spl_signature[3] = SPL_HEADER_VERSION;
 
+	if (default_dt) {
+		if (strlen(default_dt) + 1 <= sizeof(img.header.string_pool)) {
+			strcpy((char *)img.header.string_pool, default_dt);
+			img.header.dt_name_offset =
+				cpu_to_le32(offsetof(struct boot_file_head,
+						     string_pool));
+		} else {
+			printf("WARNING: The SPL header is too small\n");
+			printf("         and has no space to store the dt name.\n");
+		}
+	}
+
 	gen_check_sum(&img.header);
 
 	count = write(fd_out, &img, le32_to_cpu(img.header.length));
-- 
2.8.2

[U-Boot] [PATCH v3 18/19] sunxi: use SPL header DT name for FIT board matching

[Andre Przywara]

Now that we can store a DT name in the SPL header, use this string (if
available) when finding the right DT blob to load for U-Boot proper.
This allows a generic U-Boot (proper) image to be combined with a bunch
of supported DTs, with just the SPL (possibly only that string) to be
different.
Eventually this string can be written after the build process by some
firmware update tool.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 board/sunxi/board.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 2ddff28..714f8fd 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -729,13 +729,19 @@ int ft_board_setup(void *blob, bd_t *bd)
 #ifdef CONFIG_SPL_LOAD_FIT
 int board_fit_config_name_match(const char *name)
 {
-	const char *cmp_str;
+	struct boot_file_head *spl = (void *)(ulong)SPL_ADDR;
+	const char *cmp_str = (void *)(ulong)SPL_ADDR;
 
+	/* Check if there is a DT name stored in the SPL header and use that. */
+	if (spl->dt_name_offset) {
+		cmp_str += spl->dt_name_offset;
+	} else {
 #ifdef CONFIG_DEFAULT_DEVICE_TREE
-	cmp_str = CONFIG_DEFAULT_DEVICE_TREE;
+		cmp_str = CONFIG_DEFAULT_DEVICE_TREE;
 #else
-	return 0;
+		return 0;
 #endif
+	};
 
 /* Differentiate the two Pine64 board DTs by their DRAM size. */
 	if (strstr(name, "-pine64") && strstr(cmp_str, "-pine64")) {
-- 
2.8.2

[U-Boot] [PATCH v3 19/19] sunxi: update Pine64 README

[Andre Przywara]

With the DRAM init code and the SPL's ability to load the ATF binary as
well, we can now officially get rid of the boot0 boot method, which
involed a closed-source proprietary blob to be used.
Rework the Pine64 README file to document how to build the firmware.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 board/sunxi/README.pine64 | 177 ++++++++++++++++++++++++++++++----------------
 1 file changed, 115 insertions(+), 62 deletions(-)

diff --git a/board/sunxi/README.pine64 b/board/sunxi/README.pine64
index 5553415..41fb58e 100644
--- a/board/sunxi/README.pine64
+++ b/board/sunxi/README.pine64
@@ -8,75 +8,130 @@ This chip has ARM Cortex A-53 cores and thus can run both in AArch32
 in AArch32 mode and executes 32-bit code from the Boot ROM (BROM).
 This has some implications on U-Boot.
 
-Quick start
-============
-- Get hold of a boot0.img file (see below for more details).
-- Get the boot0img tool source from the tools directory in [1] and compile
-  that on your host.
-- Build U-Boot:
+Quick Start / Overview
+======================
+- Build the ARM Trusted Firmware binary (see "ARM Trusted firmware (ATF)" below)
+- Build U-Boot (see "SPL/U-Boot" below)
+- Transfer to an uSD card (see "microSD card" below)
+- Boot and enjoy!
+
+Building the firmware
+=====================
+
+The Allwinner A64 firmware consists of three parts: U-Boot's SPL, an
+ARM Trusted Firmware (ATF) build and the U-Boot proper.
+The SPL will load both ATF and U-Boot proper along with the right device
+tree blob (.dtb) and will pass execution to ATF (in EL3), which in turn will
+drop into the U-Boot proper (in EL2).
+As the ATF binary will become part of the U-Boot image file, you will need
+to build it first.
+
+ ARM Trusted firmware (ATF)
+----------------------------
+Checkout the "allwinner" branch from the github repository [1] and build it:
+$ export CROSS_COMPILE=aarch64-linux-gnu-
+$ make PLAT=sun50iw1p1 DEBUG=1 bl31
+  The resulting binary is build/sun50iw1p1/debug/bl31.bin. Copy this to the
+  root of the U-Boot source tree (or create a symbolic link).
+
+ SPL/U-Boot
+------------
+Both U-Boot proper and the SPL are using the 64-bit mode. As the boot ROM
+enters the SPL still in AArch32 secure SVC mode, there is some shim code to
+enter AArch64 very early. The rest of the SPL runs in AArch64 EL3.
+U-boot proper runs in EL2 and can load any AArch64 code, EFI applications or
+arm64 Linux kernel images (often named "Image") using the booti command.
+
+$ make clean
 $ export CROSS_COMPILE=aarch64-linux-gnu-
 $ make pine64_plus_defconfig
 $ make
-- You also need a compiled ARM Trusted Firmware (ATF) binary. Checkout the
-  "allwinner" branch from the github repository [2] and build it:
-$ export CROSS_COMPILE=aarch64-linux-gnu-
-$ make PLAT=sun50iw1p1 DEBUG=1 bl31
-  The resulting binary is build/sun50iw1p1/debug/bl31.bin.
 
-Now put an empty (or disposable) micro SD card in your card reader and learn
-its device file name, replacing /dev/sd<x> below with the result (that could
-be /dev/mmcblk<x> as well):
+This will build the SPL in spl/sunxi-spl.bin and a FIT image called u-boot.itb,
+which contains the rest of the firmware.
+
 
-$ ./boot0img --device /dev/sd<x> -e -u u-boot.bin -B boot0.img \
-	-d trampoline64:0x44000 -s bl31.bin -a 0x44008 -p 100
-(either copying the respective files to the working directory or specifying
-the paths directly)
+Boot process
+============
+The on-die BROM code will try several methods to load and execute the firmware.
+On the Pine64 this will result in the following boot order:
+1) Reading 32KB from sector 16 (@8K) of the microSD card to SRAM A1. If the
+BROM finds the magic "eGON" header in the first bytes, it will execute that
+code. If not, it will:
+2) Initialize the SPI0 controller and try to access a NOR flash connected to
+it (using the CS0 pin). If a flash chip is found, the BROM will load the
+first 32KB (from offset 0) into SRAM A1. Now it checks for the magic eGON
+header and will execute the code upon finding it. If not, it will:
+3) Initialize the USB OTG controller and will wait for a host to connect to
+it, speaking the Allwinner proprietary (but deciphered) "FEL" USB protocol.
+
+To boot the Pine64 board, you can use U-Boot and any of the described methods.
 
-This will create a new partition table (with a 100 MB FAT boot partition),
-copies boot0.img, ATF and U-Boot to the proper locations on the SD card and
-will fill in the magic Allwinner header to be recognized by boot0.
-Prefix the above call with "sudo" if you don't have write access to the
-uSD card. You can also use "-o output.img" instead of "--device /dev/sd<x>"
-to create an image file and "dd" that to the uSD card.
-Omitting the "-p" option will skip the partition table.
+FEL boot (USB OTG)
+------------------
+FEL is the name of the Allwinner defined USB boot protocol built in the
+mask ROM of most Allwinner SoCs. It allows to bootstrap a board solely
+by using the USB-OTG interface and a host port on another computer.
+As the FEL mode is controlled by the boot ROM, it expects to be running in
+AArch32. For now the AArch64 SPL cannot properly return into FEL mode, so the
+feature is disabled in the configuration at the moment.
 
-Now put this uSD card in the board and power it on. You should be greeted by
-the U-Boot prompt.
+microSD card
+------------
+Transfer the SPL and the U-Boot FIT image directly to an uSD card:
+# dd if=spl/sunxi-spl.bin of=/dev/sdx bs=8k seek=1
+# dd if=u-boot.itb of=/dev/sdx bs=8k seek=5
+# sync
+(replace /dev/sdx with you SD card device file name, which could be
+/dev/mmcblk[x] as well).
 
+Alternative you can concatenate the SPL and the U-Boot FIT image into a single
+file and transfer that instead:
+$ cat spl/sunxi-spl.bin u-boot.itb > u-boot-sunxi-with-spl.bin
+# dd if=u-boot-sunxi-with-spl.bin of=/dev/sdx bs=8k seek=1
 
-Main U-Boot
-============
-The main U-Boot proper is a real 64-bit ARMv8 port and runs entirely in the
-64-bit AArch64 mode. It can load any AArch64 code, EFI applications or arm64
-Linux kernel images (often named "Image") using the booti command.
-Launching 32-bit code and kernels is technically possible, though not without
-drawbacks (or hacks to avoid them) and currently not implemented.
+You can partition the microSD card, but leave the first MB unallocated (most
+partitioning tools will do this anyway).
 
-SPL support
-============
-The main task of the SPL support is to bring up the DRAM controller and make
-DRAM actually accessible. At the moment there is no documentation or source
-code available which would do this.
-There are currently two ways to overcome this situation: using a tainted 32-bit
-SPL (involving some hacks and resulting in a non-redistributable binary, thus
-not described here) or using the Allwinner boot0 blob.
-
-boot0 method
--------------
+NOR flash
+---------
+The Pine64 board can be booted via an SPI NOR flash chip connected to SPI0/CS0
+on the PI-2 headers. The SoPine module and the Pinebook notebook come with
+a SPI flash soldered already.
+Create the SPL and FIT image like described above for the SD card.
+Now connect either an "A to A" USB cable to the upper USB port on the Pine64
+or get an adaptor and use a regular A-microB cable connected to it.
+Remove a microSD card from the slot and power on the board.
+On your host computer download and build the sunxi-tools package[2], then
+use "sunxi-fel" to access the board:
+$ ./sunxi-fel ver -v -p
+This should give you an output starting with: AWUSBFEX soc=00001689(A64) ...
+Now use the sunxi-fel tool to write to the NOR flash:
+$ ./sunxi-fel spiflash-write 0 spl/sunxi-spl.bin
+$ ./sunxi-fel spiflash-write 32768 u-boot.itb
+Now boot the board without an SD card inserted and you should see the
+U-Boot prompt on the serial console.
+
+(Legacy) boot0 method
+---------------------
 boot0 is Allwiner's secondary program loader and it can be used as some kind
-of SPL replacement to get U-Boot up and running.
-The binary is a 32 KByte blob and contained on every Pine64 image distributed
-so far. It can be easily extracted from a micro SD card or an image file:
+of SPL replacement to get U-Boot up and running from an microSD card.
+For some time using boot0 was the only option to get the Pine64 booted.
+With working DRAM init code in U-Boot's SPL this is no longer necessary,
+but this method is described here for the sake of completeness.
+
+The boot0 binary is a 32 KByte blob and contained in the official Pine64 images
+distributed by Pine64 or Allwinner. It can be easily extracted from a micro
+SD card or an image file:
 # dd if=/dev/sd<x> of=boot0.bin bs=8k skip=1 count=4
 where /dev/sd<x> is the device name of the uSD card or the name of the image
 file. Apparently Allwinner allows re-distribution of this proprietary code
 as-is.
-For the time being this boot0 blob is the only redistributable way of making
-U-Boot work on the Pine64. Beside loading the various parts of the (original)
-firmware it also switches the core into AArch64 mode.
+This boot0 blob takes care of DRAM initialisation and loads the remaining
+firmware parts, then switches the core into AArch64 mode.
 The original boot0 code looks for U-Boot at a certain place on an uSD card
 (at 19096 KB), also it expects a header with magic bytes and a checksum.
-There is a tool called boot0img[1] which takes a boot0.bin image and a compiled
+There is a tool called boot0img[3] which takes a boot0.bin image and a compiled
 U-Boot binary (plus other binaries) and will populate that header accordingly.
 To make space for the magic header, the pine64_plus_defconfig will make sure
 there is sufficient space at the beginning of the U-Boot binary.
@@ -85,14 +140,12 @@ places on the uSD card and works around unused, but mandatory parts by using
 trampoline code. See the output of "boot0img -h" for more information.
 boot0img can also patch boot0 to avoid loading U-Boot from 19MB, instead
 fetching it from just behind the boot0 binary (-B option).
+$ ./boot0img -o firmware.img -B boot0.img -u u-boot-dtb.bin -e -s bl31.bin \
+-a 0x44008 -d trampoline64:0x44000
+Then write this image to a microSD card, replacing /dev/sdx with the right
+device file (see above):
+$ dd if=firmware.img of=/dev/sdx bs=8k seek=1
 
-FEL boot
-=========
-FEL is the name of the Allwinner defined USB boot protocol built-in the
-mask ROM of most Allwinner SoCs. It allows to bootstrap a board solely
-by using the USB-OTG interface and a host port on another computer.
-Since FEL boot does not work with boot0, it requires the libdram hack, which
-is not described here.
-
-[1] https://github.com/apritzel/pine64/
-[2] https://github.com/apritzel/arm-trusted-firmware.git
+[1] https://github.com/apritzel/arm-trusted-firmware.git
+[2] git://github.com/linux-sunxi/sunxi-tools.git
+[3] https://github.com/apritzel/pine64/
-- 
2.8.2

[U-Boot] [PATCH v3 19/19] sunxi: update Pine64 README

[Andreas Färber]

Hi Andre,

Thanks for your awesome work on getting things in shape!

Am 01.04.2017 um 00:31 schrieb Andre Przywara:
> +Quick Start / Overview
> +======================
> +- Build the ARM Trusted Firmware binary (see "ARM Trusted firmware (ATF)" below)
> +- Build U-Boot (see "SPL/U-Boot" below)
> +- Transfer to an uSD card (see "microSD card" below)
> +- Boot and enjoy!
> +
> +Building the firmware
> +=====================
> +
> +The Allwinner A64 firmware consists of three parts: U-Boot's SPL, an
> +ARM Trusted Firmware (ATF) build and the U-Boot proper.
> +The SPL will load both ATF and U-Boot proper along with the right device
> +tree blob (.dtb) and will pass execution to ATF (in EL3), which in turn will
> +drop into the U-Boot proper (in EL2).
> +As the ATF binary will become part of the U-Boot image file, you will need
> +to build it first.
> +
> + ARM Trusted firmware (ATF)

"Firmware"

> +----------------------------
> +Checkout the "allwinner" branch from the github repository [1] and build it:
> +$ export CROSS_COMPILE=aarch64-linux-gnu-
> +$ make PLAT=sun50iw1p1 DEBUG=1 bl31
> +  The resulting binary is build/sun50iw1p1/debug/bl31.bin. Copy this to the
> +  root of the U-Boot source tree (or create a symbolic link).

This sentence startled me - but luckily it does not need to be in the
_source_ directory, the U-Boot _build_ directory works just fine, too!
Care to revise the statement?

It would also be nice to be able to just set some BL31 variable with the
full path on the make command line, like ATF allows.

> +
> + SPL/U-Boot
> +------------
> +Both U-Boot proper and the SPL are using the 64-bit mode. As the boot ROM
> +enters the SPL still in AArch32 secure SVC mode, there is some shim code to
> +enter AArch64 very early. The rest of the SPL runs in AArch64 EL3.
> +U-boot proper runs in EL2 and can load any AArch64 code, EFI applications or

"U-Boot"

> +arm64 Linux kernel images (often named "Image") using the booti command.

You may want to clarify this sentence - booti only applies to the
latter, EFI applications would use "bootefi" and arbitrary code "go".
Maybe just drop the "using" part?

> +
> +$ make clean
>  $ export CROSS_COMPILE=aarch64-linux-gnu-
>  $ make pine64_plus_defconfig
>  $ make
[snip]

Build-testing this series with both pine64_plus_defconfig and
orangepi_pc2_defconfig, I ran into a ~1616 size overflow with gcc5. gcc6
worked okay. Would be helpful to document such requirements here.

For the Orange Pi PC 2, for this series:

Tested-by: Andreas Färber <afaerber@suse.de>

Orange Pi PC 2 will benefit from the $fdtfile patch I sent for Pine64,
tested there as well.

I note there is no README.orangepi_pc2. Should README.pine64 be renamed
to cover both boards, or were you planning to add a separate one?

Reason I ask is I tried unsuccessfully the Pine64 boot0.bin approach
(based on your extract_fw_blobs.sh) for orangepi_pc2 before, based on
current master branch, and it did not get me into U-Boot, unlike on the
Pine64, so some documentation somewhere would be good to have,
especially should this simplifying patchset miss the release again...

HELLO! BOOT0 is starting!
boot0 commit : 8
boot0 version : 4.0
set pll start
set pll end
rtc[0] value = 0x00000000
rtc[1] value = 0x00000000
rtc[2] value = 0x00000000
rtc[3] value = 0x00000000
rtc[4] value = 0x00000000
rtc[5] value = 0x00000000
DRAM BOOT DRIVE INFO: V0.6
the chip id is 0x00000001
the chip id is 0x00000001
the chip id is 0x00000001
the chip id is 0x00000001
the chip id is 0x00000001
axp not exist
DRAM CLK =672 MHZ
DRAM Type =3 (2:DDR2,3:DDR3,6:LPDDR2,7:LPDDR3)
DRAM zq value: 0x003b3bf9
DRAM SIZE =1024 M
DRAM simple test OK.
dram size =1024
card no is 0
sdcard 0 line count 4
[mmc]: mmc driver ver 2016-03-15 20:40
[mmc]: sdc0 spd mode error, 2
[mmc]: Wrong media type 0x00000000
[mmc]: ***Try SD card 0***
[mmc]: HSSDR52/SDR25 4 bit
[mmc]: 50000000 Hz
[mmc]: 30436 MB
[mmc]: ***SD/MMC 0 init OK!!!***
PANIC : sunxi_flash_init() error --2--,toc1 magic error
PANIC : sunxi_flash_init() error --2--,toc1 magic error
PANIC : sunxi_flash_init() error --0--
Ready to disable icache.

Possibly related is that the output from boot0img was significantly
larger than for Pine64? (same bl31.bin, other boot0.bin and u-boot.bin)

$ filesize orangepipc2.img
20013056
$ filesize pine64.img
499712

Searching for a how-to I also noticed that linux-sunxi.org still links
to a stale h5 branch from December (and that there is an spl-fit-v2
branch but none with the latest v3 code ;)).

Cheers,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

[U-Boot] [PATCH v3 19/19] sunxi: update Pine64 README

[André Przywara]

On 16/04/17 02:20, Andreas Färber wrote:

Hi Andreas,

thanks for the review!

> Thanks for your awesome work on getting things in shape!
> 
> Am 01.04.2017 um 00:31 schrieb Andre Przywara:
>> +Quick Start / Overview
>> +======================
>> +- Build the ARM Trusted Firmware binary (see "ARM Trusted firmware (ATF)" below)
>> +- Build U-Boot (see "SPL/U-Boot" below)
>> +- Transfer to an uSD card (see "microSD card" below)
>> +- Boot and enjoy!
>> +
>> +Building the firmware
>> +=====================
>> +
>> +The Allwinner A64 firmware consists of three parts: U-Boot's SPL, an
>> +ARM Trusted Firmware (ATF) build and the U-Boot proper.
>> +The SPL will load both ATF and U-Boot proper along with the right device
>> +tree blob (.dtb) and will pass execution to ATF (in EL3), which in turn will
>> +drop into the U-Boot proper (in EL2).
>> +As the ATF binary will become part of the U-Boot image file, you will need
>> +to build it first.
>> +
>> + ARM Trusted firmware (ATF)
> 
> "Firmware"
> 
>> +----------------------------
>> +Checkout the "allwinner" branch from the github repository [1] and build it:
>> +$ export CROSS_COMPILE=aarch64-linux-gnu-
>> +$ make PLAT=sun50iw1p1 DEBUG=1 bl31
>> +  The resulting binary is build/sun50iw1p1/debug/bl31.bin. Copy this to the
>> +  root of the U-Boot source tree (or create a symbolic link).
> 
> This sentence startled me - but luckily it does not need to be in the
> _source_ directory, the U-Boot _build_ directory works just fine, too!
> Care to revise the statement?

Well, these instructions are more for the uninitiated, I guess, so
tossing in a "build directory" is probably more confusing. I was
silently assuming that people building in a separate build directory can
read between the lines here. Let me see if I can find a wording which
makes everyone happy ;-)

> It would also be nice to be able to just set some BL31 variable with the
> full path on the make command line, like ATF allows.

Mmmh, that sounds like a good idea. Let me see how this can be integrated.

> 
>> +
>> + SPL/U-Boot
>> +------------
>> +Both U-Boot proper and the SPL are using the 64-bit mode. As the boot ROM
>> +enters the SPL still in AArch32 secure SVC mode, there is some shim code to
>> +enter AArch64 very early. The rest of the SPL runs in AArch64 EL3.
>> +U-boot proper runs in EL2 and can load any AArch64 code, EFI applications or
> 
> "U-Boot"
> 
>> +arm64 Linux kernel images (often named "Image") using the booti command.
> 
> You may want to clarify this sentence - booti only applies to the
> latter, EFI applications would use "bootefi" and arbitrary code "go".
> Maybe just drop the "using" part?
> 
>> +
>> +$ make clean
>>  $ export CROSS_COMPILE=aarch64-linux-gnu-
>>  $ make pine64_plus_defconfig
>>  $ make
> [snip]
> 
> Build-testing this series with both pine64_plus_defconfig and
> orangepi_pc2_defconfig, I ran into a ~1616 size overflow with gcc5. gcc6
> worked okay. Would be helpful to document such requirements here.

Can you say which version of GCC 5? I think I used GCC 5.3.0 for a while
and this was fine, but I need to re-check this.
But yes: GCC 4.9 is not up to the task ;-)

> 
> For the Orange Pi PC 2, for this series:
> 
> Tested-by: Andreas Färber <afaerber@suse.de>
> 
> Orange Pi PC 2 will benefit from the $fdtfile patch I sent for Pine64,
> tested there as well.
> 
> I note there is no README.orangepi_pc2. Should README.pine64 be renamed
> to cover both boards, or were you planning to add a separate one?

Yeah, I was stumbling upon this as well.
One problem is that I think I was pointing people to README.pine64 for
quite a while, so renaming this might break links or so.
Other problem is to find a decent alternative name. I tend to use
"sunxi64" if I talk about 64-bit Allwinner SoCs in general, but I am not
sure if that is too technical or not meaning much to people.
So I am open to suggestions.

> Reason I ask is I tried unsuccessfully the Pine64 boot0.bin approach
> (based on your extract_fw_blobs.sh) for orangepi_pc2 before, based on
> current master branch, and it did not get me into U-Boot, unlike on the
> Pine64, so some documentation somewhere would be good to have,
> especially should this simplifying patchset miss the release again...

The H5 boot0 changed quite a lot, so the A64 runes don't work anymore.
The way the different meta data of the firmware parts (ATF, U-Boot,
arisc) are stored is different. I really couldn't be bothered to rev-eng
and hack this dead end (again). And since we have the SPL code working
already this time, I thought we just go with the proper stuff.

Cheers,
Andre.

> HELLO! BOOT0 is starting!
> boot0 commit : 8
> boot0 version : 4.0
> set pll start
> set pll end
> rtc[0] value = 0x00000000
> rtc[1] value = 0x00000000
> rtc[2] value = 0x00000000
> rtc[3] value = 0x00000000
> rtc[4] value = 0x00000000
> rtc[5] value = 0x00000000
> DRAM BOOT DRIVE INFO: V0.6
> the chip id is 0x00000001
> the chip id is 0x00000001
> the chip id is 0x00000001
> the chip id is 0x00000001
> the chip id is 0x00000001
> axp not exist
> DRAM CLK =672 MHZ
> DRAM Type =3 (2:DDR2,3:DDR3,6:LPDDR2,7:LPDDR3)
> DRAM zq value: 0x003b3bf9
> DRAM SIZE =1024 M
> DRAM simple test OK.
> dram size =1024
> card no is 0
> sdcard 0 line count 4
> [mmc]: mmc driver ver 2016-03-15 20:40
> [mmc]: sdc0 spd mode error, 2
> [mmc]: Wrong media type 0x00000000
> [mmc]: ***Try SD card 0***
> [mmc]: HSSDR52/SDR25 4 bit
> [mmc]: 50000000 Hz
> [mmc]: 30436 MB
> [mmc]: ***SD/MMC 0 init OK!!!***
> PANIC : sunxi_flash_init() error --2--,toc1 magic error
> PANIC : sunxi_flash_init() error --2--,toc1 magic error
> PANIC : sunxi_flash_init() error --0--
> Ready to disable icache.
> 
> Possibly related is that the output from boot0img was significantly
> larger than for Pine64? (same bl31.bin, other boot0.bin and u-boot.bin)
> 
> $ filesize orangepipc2.img
> 20013056
> $ filesize pine64.img
> 499712
> 
> Searching for a how-to I also noticed that linux-sunxi.org still links
> to a stale h5 branch from December (and that there is an spl-fit-v2
> branch but none with the latest v3 code ;)).
> 
> Cheers,
> Andreas
> 

[U-Boot] [PATCH v3 19/19] sunxi: update Pine64 README

[Andreas Färber]

Am 18.04.2017 um 22:38 schrieb André Przywara:
> On 16/04/17 02:20, Andreas Färber wrote:
>> Build-testing this series with both pine64_plus_defconfig and
>> orangepi_pc2_defconfig, I ran into a ~1616 size overflow with gcc5. gcc6
>> worked okay. Would be helpful to document such requirements here.
> 
> Can you say which version of GCC 5? I think I used GCC 5.3.0 for a while
> and this was fine, but I need to re-check this.

Failure was with a Linaro GCC 5.1.

Working was Linaro GCC 6.3.1.

I would happily use our latest SUSE GCC 7.0.1 if only U-Boot had a
private libgcc for aarch64... :(
U-Boot tries to use -lgcc for the hello_world example (which I did not
find a way to suppress other than hacking the Makefile?) and for the
final u-boot.bin.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

[U-Boot] [PATCH v3 19/19] sunxi: update Pine64 README

[Dr. Philipp Tomsich]

> On 20 Apr 2017, at 00:21, Andreas Färber <afaerber@suse.de> wrote:
> 
> Am 18.04.2017 um 22:38 schrieb André Przywara:
>> On 16/04/17 02:20, Andreas Färber wrote:
>>> Build-testing this series with both pine64_plus_defconfig and
>>> orangepi_pc2_defconfig, I ran into a ~1616 size overflow with gcc5. gcc6
>>> worked okay. Would be helpful to document such requirements here.
>> 
>> Can you say which version of GCC 5? I think I used GCC 5.3.0 for a while
>> and this was fine, but I need to re-check this.
> 
> Failure was with a Linaro GCC 5.1.
> 
> Working was Linaro GCC 6.3.1.
> 
> I would happily use our latest SUSE GCC 7.0.1 if only U-Boot had a
> private libgcc for aarch64... :(
> U-Boot tries to use -lgcc for the hello_world example (which I did not
> find a way to suppress other than hacking the Makefile?) and for the
> final u-boot.bin.

Successfully tested with aarch64-unknown-elf based on GCC 6.1.0 and 6.3.0 

Regards,
Philipp.

[U-Boot] [PATCH v3 19/19] sunxi: update Pine64 README

[Tom Rini]

On Thu, Apr 20, 2017 at 12:21:41AM +0200, Andreas Färber wrote:
> Am 18.04.2017 um 22:38 schrieb André Przywara:
> > On 16/04/17 02:20, Andreas Färber wrote:
> >> Build-testing this series with both pine64_plus_defconfig and
> >> orangepi_pc2_defconfig, I ran into a ~1616 size overflow with gcc5. gcc6
> >> worked okay. Would be helpful to document such requirements here.
> > 
> > Can you say which version of GCC 5? I think I used GCC 5.3.0 for a while
> > and this was fine, but I need to re-check this.
> 
> Failure was with a Linaro GCC 5.1.
> 
> Working was Linaro GCC 6.3.1.
> 
> I would happily use our latest SUSE GCC 7.0.1 if only U-Boot had a
> private libgcc for aarch64... :(

With some quick hacking here, we could get away with adding
arch/arm/lib/dummy.S, with a comment of why (to have an empty lib.a be
generated) and then we could fake out the not-required libgcc.

The other way to go here would be to see what platforms really require
-lgcc and introduce another flag, CONFIG_USE_COMPILER_LIBGCC and then
allow for PLATFORM_LIBGCC to just be empty.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170419/acb01f63/attachment.sig>

[U-Boot] [PATCH v3 19/19] sunxi: update Pine64 README

[Simon Glass]

On 31 March 2017 at 16:31, Andre Przywara <andre.przywara@arm.com> wrote:
> With the DRAM init code and the SPL's ability to load the ATF binary as
> well, we can now officially get rid of the boot0 boot method, which
> involed a closed-source proprietary blob to be used.
> Rework the Pine64 README file to document how to build the firmware.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  board/sunxi/README.pine64 | 177 ++++++++++++++++++++++++++++++----------------
>  1 file changed, 115 insertions(+), 62 deletions(-)

Change log?

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

[U-Boot] [PATCH v3 19/19] sunxi: update Pine64 README

[Andreas Färber]

Am 01.04.2017 um 00:31 schrieb Andre Przywara:
> With the DRAM init code and the SPL's ability to load the ATF binary as
> well, we can now officially get rid of the boot0 boot method, which
> involed a closed-source proprietary blob to be used.

"involved"

> Rework the Pine64 README file to document how to build the firmware.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  board/sunxi/README.pine64 | 177 ++++++++++++++++++++++++++++++----------------
>  1 file changed, 115 insertions(+), 62 deletions(-)
> 
> diff --git a/board/sunxi/README.pine64 b/board/sunxi/README.pine64
> index 5553415..41fb58e 100644
> --- a/board/sunxi/README.pine64
> +++ b/board/sunxi/README.pine64
[...]
> +Alternative you can concatenate the SPL and the U-Boot FIT image into a single

"Alternatively"

> +file and transfer that instead:
[snip]

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

[U-Boot] [PATCH v3 00/19] SPL: extend FIT loading support

[Simon Glass]

Hi Andre,

On 31 March 2017 at 16:31, Andre Przywara <andre.przywara@arm.com> wrote:
> Some minor fixes version of the SPL FIT loading series and the respective
> patches to enable this feature on 64-bit Allwinner SoCs.
> There is a new patch (6/19) fixing the SPL_FIT dependencies, above all
> selecting SPL_OF_LIBFDT when SPL_FIT is enabled. This reduces the number
> of Kconfig symbols a board has to select for the SPL fit loading from
> four down to two, which leads to changes in the final patches enabling
> this feature. Compared to the previous version the SPL FIT loading
> is now selected in the Kconfig for both 64-bit sunxi SoCs, so there is
> less burden on each individual defconfig.
> Also following Olliver's suggestion a symbol in mksunxiboot has been renamed.
> ---
>
> The first five patches introduce the core of the extened SPL FIT loading
> support, see below for a description. Patch 6 fixes a Kconfig dependency
> to simplify the usage of this option.
> Patches 7-10 make some room in the sunxi 64-bit SPL to allow
> compiling in the FIT loading bits. Patch 11 and 12 let the SPL choose
> the proper DT from the FIT image.
> The next two patches add the infrastructure and an actual generator script,
> so the FIT image is automatically created at build time.
> Patches 14 and 15 enable the SPL FIT support for Allwinner 64-bit SoCs in
> general and for the Pine64 and OrangePi PC 2 in particular.
> The following two patches store a DT file name in the SPL header, so
> U-Boot can easily pick the proper DT when scanning the FIT image.
> The idea is that this DT name should stay with the board, ideally on
> eMMC or SPI flash. So both U-Boot and a firmware update tool could
> identify a board, updating with compatible firmware while keeping the
> DT name in place. Ideally a board vendor would once seed this name
> onto on-board storage like SPI flash.
> I kept those two patches in, as the work on replacing mksunxiboot with
> an mkimage extension is not ready yet. Feel free to drop those from
> the series if this is a problem.
> The final patch updates the Pine64 README file to document the current
> way of building U-Boot, which now includes the ARM Trusted Firmware build
> in its image.
>
> I would be delighted if that series can make it into the next release,
> as this finally enables the fully open source firmware for the 64-bit
> Allwinner SoCs (including the ATF binary).
>
> This series is based on sunxi/master, rebased upon origin/master.
>
> Cheers,
> Andre.
>
> -------
> Currently the FIT format is not used to its full potential in the SPL:
> It only loads the first image from the /images node and appends the
> proper FDT.
> Some boards and platforms would benefit from loading more images before
> starting U-Boot proper, notably Allwinner A64 and ARMv8 Rockchip boards,
> which use an ARM Trusted Firmware (ATF) image to be executed before U-Boot.
>
> This series tries to solve this in a board agnostic and generic way:
> We extend the SPL FIT loading scheme to allow loading multiple images.
> So apart from loading the image which is referenced by the "firmware"
> property in the respective configuration node and placing the DTB right
> behind it, we iterate over all strings in the "loadable" property.
> Each image referenced there will be loaded to its specified load address.
> The entry point U-Boot eventually branches to will be taken from the
> first image to explicitly provide the "entry" property, or, if none
> of them does so, from the load address of the "firmware" image.
> This keeps the scheme compatible with the FIT images our Makefile creates
> automatically at the moment.
> Apart from the already mentioned ATF scenario this opens up more usage
> scenarios, of which the commit message of patch 04/11 lists some.
> The remaining patches prepare ane finally enable this scheme for the 64-bit
> Allwinner boards.

Do you have change logs for these patches? I'm not sure which ones to
review or what has changed. Also if I previously reviewed one, can you
please retail the review tag?

Thanks,
Simon

[U-Boot] [PATCH v3 00/19] SPL: extend FIT loading support

[André Przywara]

On 31/03/17 23:43, Simon Glass wrote:
> Hi Andre,
> 
> On 31 March 2017 at 16:31, Andre Przywara <andre.przywara@arm.com> wrote:
>> Some minor fixes version of the SPL FIT loading series and the respective
>> patches to enable this feature on 64-bit Allwinner SoCs.
>> There is a new patch (6/19) fixing the SPL_FIT dependencies, above all
>> selecting SPL_OF_LIBFDT when SPL_FIT is enabled. This reduces the number
>> of Kconfig symbols a board has to select for the SPL fit loading from
>> four down to two, which leads to changes in the final patches enabling
>> this feature. Compared to the previous version the SPL FIT loading
>> is now selected in the Kconfig for both 64-bit sunxi SoCs, so there is
>> less burden on each individual defconfig.
>> Also following Olliver's suggestion a symbol in mksunxiboot has been renamed.
>> ---
>>
>> The first five patches introduce the core of the extened SPL FIT loading
>> support, see below for a description. Patch 6 fixes a Kconfig dependency
>> to simplify the usage of this option.
>> Patches 7-10 make some room in the sunxi 64-bit SPL to allow
>> compiling in the FIT loading bits. Patch 11 and 12 let the SPL choose
>> the proper DT from the FIT image.
>> The next two patches add the infrastructure and an actual generator script,
>> so the FIT image is automatically created at build time.
>> Patches 14 and 15 enable the SPL FIT support for Allwinner 64-bit SoCs in
>> general and for the Pine64 and OrangePi PC 2 in particular.
>> The following two patches store a DT file name in the SPL header, so
>> U-Boot can easily pick the proper DT when scanning the FIT image.
>> The idea is that this DT name should stay with the board, ideally on
>> eMMC or SPI flash. So both U-Boot and a firmware update tool could
>> identify a board, updating with compatible firmware while keeping the
>> DT name in place. Ideally a board vendor would once seed this name
>> onto on-board storage like SPI flash.
>> I kept those two patches in, as the work on replacing mksunxiboot with
>> an mkimage extension is not ready yet. Feel free to drop those from
>> the series if this is a problem.
>> The final patch updates the Pine64 README file to document the current
>> way of building U-Boot, which now includes the ARM Trusted Firmware build
>> in its image.
>>
>> I would be delighted if that series can make it into the next release,
>> as this finally enables the fully open source firmware for the 64-bit
>> Allwinner SoCs (including the ATF binary).
>>
>> This series is based on sunxi/master, rebased upon origin/master.
>>
>> Cheers,
>> Andre.
>>
>> -------
>> Currently the FIT format is not used to its full potential in the SPL:
>> It only loads the first image from the /images node and appends the
>> proper FDT.
>> Some boards and platforms would benefit from loading more images before
>> starting U-Boot proper, notably Allwinner A64 and ARMv8 Rockchip boards,
>> which use an ARM Trusted Firmware (ATF) image to be executed before U-Boot.
>>
>> This series tries to solve this in a board agnostic and generic way:
>> We extend the SPL FIT loading scheme to allow loading multiple images.
>> So apart from loading the image which is referenced by the "firmware"
>> property in the respective configuration node and placing the DTB right
>> behind it, we iterate over all strings in the "loadable" property.
>> Each image referenced there will be loaded to its specified load address.
>> The entry point U-Boot eventually branches to will be taken from the
>> first image to explicitly provide the "entry" property, or, if none
>> of them does so, from the load address of the "firmware" image.
>> This keeps the scheme compatible with the FIT images our Makefile creates
>> automatically at the moment.
>> Apart from the already mentioned ATF scenario this opens up more usage
>> scenarios, of which the commit message of patch 04/11 lists some.
>> The remaining patches prepare ane finally enable this scheme for the 64-bit
>> Allwinner boards.
> 
> Do you have change logs for these patches? I'm not sure which ones to
> review or what has changed. Also if I previously reviewed one, can you
> please retail the review tag?

Please review this version, it has only minor changes to v2 (see below).
You previously reviewed v1 (many thanks for that!), I put your RBs into
the patches 7,8,10,11,12,14 (in this series' counting).
I think the important patches are the first five for the SPL FIT rework
plus the Makefile patch (13/19) to generate the FIT image.

Changelog v1 .. v2:
- Add some function comments to spl_fit.c (patch 1-5)
- Improve error handling in SPL FIT code (patch 1-5)
- Fix bisectability (observing entry-point property)
- add documentation to doc/uImage.FIT/howto.txt
- fix Freescale CCN504 build failure
- (no changes in the last 10 patches)
- update README.pine64 (new last patch)
- add Reviewed-bys from Simon and Lokesh

Changelog v2 .. v3:
- new patch 06/19 to improve SPL_FIT Kconfig dependencies
- rename symbol in mksunxiboot (SUNXI_SRAM instead of SUN4I_SRAM)
- enable SPL_LOAD_FIT for all Allwinner A64 and H5 boards in Kconfig
- add only CONFIG_OF_LIST to defconfigs (patch 15/19)

HTH!

Cheers,
Andre.

[U-Boot] [PATCH v3 00/19] SPL: extend FIT loading support

[Simon Glass]

Hi Andre,

On 31 March 2017 at 17:21, André Przywara <andre.przywara@arm.com> wrote:
> On 31/03/17 23:43, Simon Glass wrote:
>> Hi Andre,
>>
>> On 31 March 2017 at 16:31, Andre Przywara <andre.przywara@arm.com> wrote:
>>> Some minor fixes version of the SPL FIT loading series and the respective
>>> patches to enable this feature on 64-bit Allwinner SoCs.
>>> There is a new patch (6/19) fixing the SPL_FIT dependencies, above all
>>> selecting SPL_OF_LIBFDT when SPL_FIT is enabled. This reduces the number
>>> of Kconfig symbols a board has to select for the SPL fit loading from
>>> four down to two, which leads to changes in the final patches enabling
>>> this feature. Compared to the previous version the SPL FIT loading
>>> is now selected in the Kconfig for both 64-bit sunxi SoCs, so there is
>>> less burden on each individual defconfig.
>>> Also following Olliver's suggestion a symbol in mksunxiboot has been renamed.
>>> ---
>>>
>>> The first five patches introduce the core of the extened SPL FIT loading
>>> support, see below for a description. Patch 6 fixes a Kconfig dependency
>>> to simplify the usage of this option.
>>> Patches 7-10 make some room in the sunxi 64-bit SPL to allow
>>> compiling in the FIT loading bits. Patch 11 and 12 let the SPL choose
>>> the proper DT from the FIT image.
>>> The next two patches add the infrastructure and an actual generator script,
>>> so the FIT image is automatically created at build time.
>>> Patches 14 and 15 enable the SPL FIT support for Allwinner 64-bit SoCs in
>>> general and for the Pine64 and OrangePi PC 2 in particular.
>>> The following two patches store a DT file name in the SPL header, so
>>> U-Boot can easily pick the proper DT when scanning the FIT image.
>>> The idea is that this DT name should stay with the board, ideally on
>>> eMMC or SPI flash. So both U-Boot and a firmware update tool could
>>> identify a board, updating with compatible firmware while keeping the
>>> DT name in place. Ideally a board vendor would once seed this name
>>> onto on-board storage like SPI flash.
>>> I kept those two patches in, as the work on replacing mksunxiboot with
>>> an mkimage extension is not ready yet. Feel free to drop those from
>>> the series if this is a problem.
>>> The final patch updates the Pine64 README file to document the current
>>> way of building U-Boot, which now includes the ARM Trusted Firmware build
>>> in its image.
>>>
>>> I would be delighted if that series can make it into the next release,
>>> as this finally enables the fully open source firmware for the 64-bit
>>> Allwinner SoCs (including the ATF binary).
>>>
>>> This series is based on sunxi/master, rebased upon origin/master.
>>>
>>> Cheers,
>>> Andre.
>>>
>>> -------
>>> Currently the FIT format is not used to its full potential in the SPL:
>>> It only loads the first image from the /images node and appends the
>>> proper FDT.
>>> Some boards and platforms would benefit from loading more images before
>>> starting U-Boot proper, notably Allwinner A64 and ARMv8 Rockchip boards,
>>> which use an ARM Trusted Firmware (ATF) image to be executed before U-Boot.
>>>
>>> This series tries to solve this in a board agnostic and generic way:
>>> We extend the SPL FIT loading scheme to allow loading multiple images.
>>> So apart from loading the image which is referenced by the "firmware"
>>> property in the respective configuration node and placing the DTB right
>>> behind it, we iterate over all strings in the "loadable" property.
>>> Each image referenced there will be loaded to its specified load address.
>>> The entry point U-Boot eventually branches to will be taken from the
>>> first image to explicitly provide the "entry" property, or, if none
>>> of them does so, from the load address of the "firmware" image.
>>> This keeps the scheme compatible with the FIT images our Makefile creates
>>> automatically at the moment.
>>> Apart from the already mentioned ATF scenario this opens up more usage
>>> scenarios, of which the commit message of patch 04/11 lists some.
>>> The remaining patches prepare ane finally enable this scheme for the 64-bit
>>> Allwinner boards.
>>
>> Do you have change logs for these patches? I'm not sure which ones to
>> review or what has changed. Also if I previously reviewed one, can you
>> please retail the review tag?
>
> Please review this version, it has only minor changes to v2 (see below).
> You previously reviewed v1 (many thanks for that!), I put your RBs into
> the patches 7,8,10,11,12,14 (in this series' counting).
> I think the important patches are the first five for the SPL FIT rework
> plus the Makefile patch (13/19) to generate the FIT image.
>
> Changelog v1 .. v2:
> - Add some function comments to spl_fit.c (patch 1-5)
> - Improve error handling in SPL FIT code (patch 1-5)
> - Fix bisectability (observing entry-point property)
> - add documentation to doc/uImage.FIT/howto.txt
> - fix Freescale CCN504 build failure
> - (no changes in the last 10 patches)
> - update README.pine64 (new last patch)
> - add Reviewed-bys from Simon and Lokesh
>
> Changelog v2 .. v3:
> - new patch 06/19 to improve SPL_FIT Kconfig dependencies
> - rename symbol in mksunxiboot (SUNXI_SRAM instead of SUN4I_SRAM)
> - enable SPL_LOAD_FIT for all Allwinner A64 and H5 boards in Kconfig
> - add only CONFIG_OF_LIST to defconfigs (patch 15/19)
>
> HTH!
>

OK thanks, yes that helps. If you do another rev, can you put the
change log with each patch? If you use patman it does this for you and
then creates a full change log in the cover letter.

Regards,
Simon