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

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

[Andre Przywara]

This is an updated and slightly extended version of the SPL FIT loading
series I posted as an RFC some weeks ago.
I tried to fix all bugs that have been pointed out by the diligent
reviewers, also added patches to automatically build the FIT images.

The first patch is a bug fix for a regression introduced with -rc1.
I put this in there to allow people testing the series and to provide
an actual patch for this fix, which should make it still into 2017.03.
The next four patches introduce the core of the extened SPL FIT loading
support, see below for a description.
Patches 6-9 make some room in the sunxi 64-bit SPL to allow
compiling in the FIT loading bits. Patch 10 and 11 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 in the Pine64 and the
OrangePi PC 2 defconfigs.
The last two patches are new and eventually 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.

Let me know what you think!

Cheers,
Andre.

Based on top of sunxi/master (35affe7698e9).

-------
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 (15):
  SPL: FIT: refactor FDT loading
  SPL: FIT: rework U-Boot image loading
  SPL: FIT: factor out spl_load_fit_image()
  SPL: FIT: allow loading multiple images
  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: A64: Pine64: introduce FIT generator script
  sunxi: Pine64: defconfig: enable SPL FIT support
  sunxi: OrangePi-PC2: defconfig: enable SPL FIT support
  sunxi: use SPL header DT name for FIT board matching

Philipp Tomsich (1):
  armv8: spl: Call spl_relocate_stack_gd for ARMv8

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

 Kconfig                                    |  17 ++
 Makefile                                   |  20 +++
 arch/arm/cpu/armv8/fsl-layerscape/Makefile |   1 +
 arch/arm/include/asm/arch-sunxi/spl.h      |  19 ++-
 arch/arm/lib/Makefile                      |   3 +-
 arch/arm/lib/crt0_64.S                     |  14 +-
 board/sunxi/board.c                        |  36 ++++-
 board/sunxi/mksunxi_fit_atf.sh             |  73 +++++++++
 common/spl/spl_fit.c                       | 246 +++++++++++++++++------------
 configs/orangepi_pc2_defconfig             |   6 +
 configs/pine64_plus_defconfig              |   6 +
 include/configs/sunxi-common.h             |  17 +-
 scripts/Makefile.spl                       |   3 +-
 tools/mksunxiboot.c                        |  51 +++++-
 14 files changed, 387 insertions(+), 125 deletions(-)
 create mode 100755 board/sunxi/mksunxi_fit_atf.sh

-- 
2.8.2

[U-Boot] [PATCH 01/17] armv8: spl: Call spl_relocate_stack_gd for ARMv8

[Andre Przywara]

From: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

As part of the startup process for boards using the SPL, we need to
call spl_relocate_stack_gd. This is needed to set up malloc with its
DRAM buffer.
[Andre: fix comment]

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 arch/arm/lib/crt0_64.S | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/arm/lib/crt0_64.S b/arch/arm/lib/crt0_64.S
index 19c6a98..e59fd3e 100644
--- a/arch/arm/lib/crt0_64.S
+++ b/arch/arm/lib/crt0_64.S
@@ -109,8 +109,18 @@ relocation_return:
  */
 	bl	c_runtime_cpu_setup		/* still call old routine */
 #endif /* !CONFIG_SPL_BUILD */
-
-/* TODO: For SPL, call spl_relocate_stack_gd() to alloc stack relocation */
+#if defined(CONFIG_SPL_BUILD)
+	bl	spl_relocate_stack_gd           /* may return NULL */
+	/*
+	 * Perform 'sp = (x0 != NULL) ? x0 : sp' while working
+	 * around the constraint that most arm64 instructions cannot
+	 * have 'sp' as an operand.
+	 */
+	mov	x1, sp
+	cmp	x0, #0
+	csel	x0, x0, x1, ne
+	mov	sp, x0
+#endif
 
 /*
  * Clear BSS section
-- 
2.8.2

[U-Boot] [PATCH 02/17] 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>
---
 common/spl/spl_fit.c | 83 ++++++++++++++++++++++++++++++++--------------------
 1 file changed, 52 insertions(+), 31 deletions(-)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index aae556f..ba45e65 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -22,13 +22,11 @@ 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)
+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 +48,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 +238,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 02/17] SPL: FIT: refactor FDT loading

[Simon Glass]

Hi Andre,

On 28 February 2017 at 19:25, 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).

First I want to commend you on your excellent commit messages. For
example this one explains the current situation, the change your
commit performs and the motivation for that change. With these more
complicated / core pieces, it is very valuable and you are an example
to us all :-)

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

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

I think we need a pytest for this somewhere in this series. With
sandbox_spl we can run spl/u-boot-spl and it jumps to u-boot. Can we
use this to check that the right thing happens in a few simple cases?

>
> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> index aae556f..ba45e65 100644
> --- a/common/spl/spl_fit.c
> +++ b/common/spl/spl_fit.c
> @@ -22,13 +22,11 @@ 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)
> +static int spl_fit_find_config_node(const void *fdt)

Can you comment this function please? I should have done this myself.

>  {
> -       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 +48,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;

How about -ENOENT?

> +}
> +
> +static int spl_fit_select_index(const void *fit, int images, int *offsetp,
> +                               const char *type, int index)

And this one.

[U-Boot] [PATCH 02/17] SPL: FIT: refactor FDT loading

[Andre Przywara]

Hi Simon,

On 03/03/17 04:53, Simon Glass wrote:
> Hi Andre,
> 
> On 28 February 2017 at 19:25, 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).
> 
> First I want to commend you on your excellent commit messages. For
> example this one explains the current situation, the change your
> commit performs and the motivation for that change. With these more
> complicated / core pieces, it is very valuable and you are an example
> to us all :-)

Thank you very much, you made my day. That is a welcome departure from
the usual Linux ML communication style ;-)

And yes, will fix those things you mentioned below, though have to wrap
my mind about pytest first.


Now back into the rough waters of the Linux mailing lists ...

Cheers,
Andre.

> 
>>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>> ---
>>  common/spl/spl_fit.c | 83 ++++++++++++++++++++++++++++++++--------------------
>>  1 file changed, 52 insertions(+), 31 deletions(-).
> 
> Reviewed-by: Simon Glass <sjg@chromium.org>
> 
> I think we need a pytest for this somewhere in this series. With
> sandbox_spl we can run spl/u-boot-spl and it jumps to u-boot. Can we
> use this to check that the right thing happens in a few simple cases?
> 
>>
>> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
>> index aae556f..ba45e65 100644
>> --- a/common/spl/spl_fit.c
>> +++ b/common/spl/spl_fit.c
>> @@ -22,13 +22,11 @@ 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)
>> +static int spl_fit_find_config_node(const void *fdt)
> 
> Can you comment this function please? I should have done this myself.
> 
>>  {
>> -       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 +48,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;
> 
> How about -ENOENT?
> 
>> +}
>> +
>> +static int spl_fit_select_index(const void *fit, int images, int *offsetp,
>> +                               const char *type, int index)
> 
> And this one.
> 

[U-Boot] [PATCH 02/17] SPL: FIT: refactor FDT loading

[Simon Glass]

Hi Andre,

On 3 March 2017 at 04:09, Andre Przywara <andre.przywara@arm.com> wrote:
> Hi Simon,
>
> On 03/03/17 04:53, Simon Glass wrote:
>> Hi Andre,
>>
>> On 28 February 2017 at 19:25, 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).
>>
>> First I want to commend you on your excellent commit messages. For
>> example this one explains the current situation, the change your
>> commit performs and the motivation for that change. With these more
>> complicated / core pieces, it is very valuable and you are an example
>> to us all :-)
>
> Thank you very much, you made my day. That is a welcome departure from
> the usual Linux ML communication style ;-)
>
> And yes, will fix those things you mentioned below, though have to wrap
> my mind about pytest first.
>
>
> Now back into the rough waters of the Linux mailing lists ...

Godspeed - perhaps keep a beer by the computer to use in emergencies :-)

Regards,
Simon

[U-Boot] [PATCH 02/17] SPL: FIT: refactor FDT loading

[Lokesh Vutla]

On Wednesday 01 March 2017 07:55 AM, Andre Przywara 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>

Thanks and regards,
Lokesh

[U-Boot] [PATCH 03/17] 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>
---
 common/spl/spl_fit.c | 34 ++++++++++++++++++++--------------
 1 file changed, 20 insertions(+), 14 deletions(-)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index ba45e65..572a5db 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -55,14 +55,13 @@ 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)
+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
@@ -99,10 +98,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)
@@ -188,15 +184,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;
 	}
 
@@ -238,10 +241,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 03/17] SPL: FIT: rework U-Boot image loading

[Simon Glass]

On 28 February 2017 at 19:25, 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>
> ---
>  common/spl/spl_fit.c | 34 ++++++++++++++++++++--------------
>  1 file changed, 20 insertions(+), 14 deletions(-)

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

[U-Boot] [PATCH 03/17] SPL: FIT: rework U-Boot image loading

[Lokesh Vutla]

On Wednesday 01 March 2017 07:55 AM, Andre Przywara 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>

Thanks and regards,
Lokesh

[U-Boot] [PATCH 04/17] 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. Both times we have very similar code to deal with
alignment requirement 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 | 129 +++++++++++++++++++++++----------------------------
 1 file changed, 57 insertions(+), 72 deletions(-)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 572a5db..ad5ba15 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -18,7 +18,7 @@ static ulong fdt_getprop_u32(const void *fdt, int node, const char *prop)
 
 	cell = fdt_getprop(fdt, node, prop, &len);
 	if (len != sizeof(*cell))
-		return -1U;
+		return -1UL;
 	return fdt32_to_cpu(*cell);
 }
 
@@ -139,19 +139,63 @@ static int get_aligned_image_size(struct spl_load_info *info, int data_size,
 	return (data_size + info->bl_len - 1) / info->bl_len;
 }
 
+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, entry;
+	void *src;
+	ulong overhead;
+	int nr_sectors;
+	int align_len = ARCH_DMA_MINALIGN - 1;
+
+	offset = fdt_getprop_u32(fit, node, "data-offset") + base_offset;
+	length = fdt_getprop_u32(fit, node, "data-size");
+	load_addr = fdt_getprop_u32(fit, node, "load");
+	if (load_addr == -1UL && image_info)
+		load_addr = image_info->load_addr;
+	load_ptr = (load_addr + align_len) & ~align_len;
+	entry = fdt_getprop_u32(fit, node, "entry");
+
+	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;
+		if (entry == -1UL)
+			image_info->entry_point = load_addr;
+		else
+			image_info->entry_point = 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;
+	struct spl_image_info image_info;
 	int node, images;
-	void *load_ptr;
-	int fdt_offset, fdt_len;
-	int data_offset, data_size;
 	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
@@ -203,82 +247,23 @@ 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");
-	data_size = fdt_getprop_u32(fit, node, "data-size");
-	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;
+	/* Load the image and set up the spl_image structure */
+	spl_load_fit_image(info, sector, fit, base_offset, node, spl_image);
 	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);
-
-#ifdef CONFIG_SPL_FIT_IMAGE_POST_PROCESS
-	board_fit_image_post_process((void **)&src, (size_t *)&data_size);
-#endif
-
-	memcpy(dst, src, data_size);
-
 	/* Figure out which device tree the board wants to use */
 	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
-	 * some extra data before it since we can only read entire blocks.
-	 * And also 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.
+	 * Read the device tree and place it after the image.
+	 * Align the destination address to ARCH_DMA_MINALIGN.
 	 */
-	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);
+	image_info.load_addr = spl_image->load_addr + spl_image->size;
+	spl_load_fit_image(info, sector, fit, base_offset, node, &image_info);
 
 	return 0;
 }
-- 
2.8.2

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

[Andrew F. Davis]

On 02/28/2017 08:25 PM, Andre Przywara wrote:
> At the moment we load two images from a FIT image: the actual U-Boot
> image and the DTB. Both times we have very similar code to deal with
> alignment requirement 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>
> ---

Acked-by: Andrew F. Davis <afd@ti.com>

+Franklin,

This patch, and #12 look like something you would be interested in for
your 66AK2G0x work.

Andrew

>  common/spl/spl_fit.c | 129 +++++++++++++++++++++++----------------------------
>  1 file changed, 57 insertions(+), 72 deletions(-)
> 
> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> index 572a5db..ad5ba15 100644
> --- a/common/spl/spl_fit.c
> +++ b/common/spl/spl_fit.c
> @@ -18,7 +18,7 @@ static ulong fdt_getprop_u32(const void *fdt, int node, const char *prop)
>  
>  	cell = fdt_getprop(fdt, node, prop, &len);
>  	if (len != sizeof(*cell))
> -		return -1U;
> +		return -1UL;
>  	return fdt32_to_cpu(*cell);
>  }
>  
> @@ -139,19 +139,63 @@ static int get_aligned_image_size(struct spl_load_info *info, int data_size,
>  	return (data_size + info->bl_len - 1) / info->bl_len;
>  }
>  
> +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, entry;
> +	void *src;
> +	ulong overhead;
> +	int nr_sectors;
> +	int align_len = ARCH_DMA_MINALIGN - 1;
> +
> +	offset = fdt_getprop_u32(fit, node, "data-offset") + base_offset;
> +	length = fdt_getprop_u32(fit, node, "data-size");
> +	load_addr = fdt_getprop_u32(fit, node, "load");
> +	if (load_addr == -1UL && image_info)
> +		load_addr = image_info->load_addr;
> +	load_ptr = (load_addr + align_len) & ~align_len;
> +	entry = fdt_getprop_u32(fit, node, "entry");
> +
> +	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;
> +		if (entry == -1UL)
> +			image_info->entry_point = load_addr;
> +		else
> +			image_info->entry_point = 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;
> +	struct spl_image_info image_info;
>  	int node, images;
> -	void *load_ptr;
> -	int fdt_offset, fdt_len;
> -	int data_offset, data_size;
>  	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
> @@ -203,82 +247,23 @@ 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");
> -	data_size = fdt_getprop_u32(fit, node, "data-size");
> -	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;
> +	/* Load the image and set up the spl_image structure */
> +	spl_load_fit_image(info, sector, fit, base_offset, node, spl_image);
>  	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);
> -
> -#ifdef CONFIG_SPL_FIT_IMAGE_POST_PROCESS
> -	board_fit_image_post_process((void **)&src, (size_t *)&data_size);
> -#endif
> -
> -	memcpy(dst, src, data_size);
> -
>  	/* Figure out which device tree the board wants to use */
>  	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
> -	 * some extra data before it since we can only read entire blocks.
> -	 * And also 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.
> +	 * Read the device tree and place it after the image.
> +	 * Align the destination address to ARCH_DMA_MINALIGN.
>  	 */
> -	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);
> +	image_info.load_addr = spl_image->load_addr + spl_image->size;
> +	spl_load_fit_image(info, sector, fit, base_offset, node, &image_info);
>  
>  	return 0;
>  }
> 

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

[Franklin S Cooper Jr]

On 03/03/2017 10:56 AM, Andrew F. Davis wrote:
> On 02/28/2017 08:25 PM, Andre Przywara wrote:
>> At the moment we load two images from a FIT image: the actual U-Boot
>> image and the DTB. Both times we have very similar code to deal with
>> alignment requirement 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>
>> ---
> 
> Acked-by: Andrew F. Davis <afd@ti.com>
> 
> +Franklin,
> 
> This patch, and #12 look like something you would be interested in for
> your 66AK2G0x work.

I don't see that much similarity between what I need versus what this
patchset is doing. Although it would be nice if these functions were
broken out since I end up needing it for U-boot (non SPL).
> 
> Andrew
> 
>>  common/spl/spl_fit.c | 129 +++++++++++++++++++++++----------------------------
>>  1 file changed, 57 insertions(+), 72 deletions(-)
>>
>> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
>> index 572a5db..ad5ba15 100644
>> --- a/common/spl/spl_fit.c
>> +++ b/common/spl/spl_fit.c
>> @@ -18,7 +18,7 @@ static ulong fdt_getprop_u32(const void *fdt, int node, const char *prop)
>>  
>>  	cell = fdt_getprop(fdt, node, prop, &len);
>>  	if (len != sizeof(*cell))
>> -		return -1U;
>> +		return -1UL;
>>  	return fdt32_to_cpu(*cell);
>>  }
>>  
>> @@ -139,19 +139,63 @@ static int get_aligned_image_size(struct spl_load_info *info, int data_size,
>>  	return (data_size + info->bl_len - 1) / info->bl_len;
>>  }
>>  
>> +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, entry;
>> +	void *src;
>> +	ulong overhead;
>> +	int nr_sectors;
>> +	int align_len = ARCH_DMA_MINALIGN - 1;
>> +
>> +	offset = fdt_getprop_u32(fit, node, "data-offset") + base_offset;
>> +	length = fdt_getprop_u32(fit, node, "data-size");
>> +	load_addr = fdt_getprop_u32(fit, node, "load");
>> +	if (load_addr == -1UL && image_info)
>> +		load_addr = image_info->load_addr;
>> +	load_ptr = (load_addr + align_len) & ~align_len;
>> +	entry = fdt_getprop_u32(fit, node, "entry");
>> +
>> +	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;
>> +		if (entry == -1UL)
>> +			image_info->entry_point = load_addr;
>> +		else
>> +			image_info->entry_point = 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;
>> +	struct spl_image_info image_info;
>>  	int node, images;
>> -	void *load_ptr;
>> -	int fdt_offset, fdt_len;
>> -	int data_offset, data_size;
>>  	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
>> @@ -203,82 +247,23 @@ 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");
>> -	data_size = fdt_getprop_u32(fit, node, "data-size");
>> -	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;
>> +	/* Load the image and set up the spl_image structure */
>> +	spl_load_fit_image(info, sector, fit, base_offset, node, spl_image);
>>  	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);
>> -
>> -#ifdef CONFIG_SPL_FIT_IMAGE_POST_PROCESS
>> -	board_fit_image_post_process((void **)&src, (size_t *)&data_size);
>> -#endif
>> -
>> -	memcpy(dst, src, data_size);
>> -
>>  	/* Figure out which device tree the board wants to use */
>>  	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
>> -	 * some extra data before it since we can only read entire blocks.
>> -	 * And also 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.
>> +	 * Read the device tree and place it after the image.
>> +	 * Align the destination address to ARCH_DMA_MINALIGN.
>>  	 */
>> -	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);
>> +	image_info.load_addr = spl_image->load_addr + spl_image->size;
>> +	spl_load_fit_image(info, sector, fit, base_offset, node, &image_info);
>>  
>>  	return 0;
>>  }
>>

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

[Simon Glass]

Hi Andre,

On 28 February 2017 at 19:25, 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. Both times we have very similar code to deal with
> alignment requirement 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 | 129 +++++++++++++++++++++++----------------------------
>  1 file changed, 57 insertions(+), 72 deletions(-)
>
> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> index 572a5db..ad5ba15 100644
> --- a/common/spl/spl_fit.c
> +++ b/common/spl/spl_fit.c
> @@ -18,7 +18,7 @@ static ulong fdt_getprop_u32(const void *fdt, int node, const char *prop)
>
>         cell = fdt_getprop(fdt, node, prop, &len);
>         if (len != sizeof(*cell))
> -               return -1U;
> +               return -1UL;

Looks like an unrelated change but I see you need it below, so OK.

>         return fdt32_to_cpu(*cell);
>  }
>
> @@ -139,19 +139,63 @@ static int get_aligned_image_size(struct spl_load_info *info, int data_size,
>         return (data_size + info->bl_len - 1) / info->bl_len;
>  }
>
> +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)

Please add a full comment to this one.

> +{
> +       ulong offset;
> +       size_t length;
> +       ulong load_addr, load_ptr, entry;
> +       void *src;
> +       ulong overhead;
> +       int nr_sectors;
> +       int align_len = ARCH_DMA_MINALIGN - 1;
> +
> +       offset = fdt_getprop_u32(fit, node, "data-offset") + base_offset;

I think you need to check that offset is not -1 first.

> +       length = fdt_getprop_u32(fit, node, "data-size");
> +       load_addr = fdt_getprop_u32(fit, node, "load");
> +       if (load_addr == -1UL && image_info)
> +               load_addr = image_info->load_addr;
> +       load_ptr = (load_addr + align_len) & ~align_len;
> +       entry = fdt_getprop_u32(fit, node, "entry");
> +
> +       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;
> +               if (entry == -1UL)
> +                       image_info->entry_point = load_addr;
> +               else
> +                       image_info->entry_point = 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;
> +       struct spl_image_info image_info;
>         int node, images;
> -       void *load_ptr;
> -       int fdt_offset, fdt_len;
> -       int data_offset, data_size;
>         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
> @@ -203,82 +247,23 @@ 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");
> -       data_size = fdt_getprop_u32(fit, node, "data-size");
> -       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;
> +       /* Load the image and set up the spl_image structure */
> +       spl_load_fit_image(info, sector, fit, base_offset, node, spl_image);

Check error return?

>         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);
> -
> -#ifdef CONFIG_SPL_FIT_IMAGE_POST_PROCESS
> -       board_fit_image_post_process((void **)&src, (size_t *)&data_size);
> -#endif
> -
> -       memcpy(dst, src, data_size);
> -
>         /* Figure out which device tree the board wants to use */
>         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
> -        * some extra data before it since we can only read entire blocks.
> -        * And also 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.
> +        * Read the device tree and place it after the image.
> +        * Align the destination address to ARCH_DMA_MINALIGN.
>          */
> -       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);
> +       image_info.load_addr = spl_image->load_addr + spl_image->size;
> +       spl_load_fit_image(info, sector, fit, base_offset, node, &image_info);

Check error return?

>
>         return 0;
>  }
> --
> 2.8.2
>

Regards,
Simon

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

[Lokesh Vutla]

On Wednesday 01 March 2017 07:55 AM, Andre Przywara wrote:
> At the moment we load two images from a FIT image: the actual U-Boot
> image and the DTB. Both times we have very similar code to deal with
> alignment requirement 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>


Reviewed-by: Lokesh Vutla <lokeshvuta@ti.com>

Thanks and regards,
Lokesh

[U-Boot] [PATCH 05/17] 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.

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

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index ad5ba15..5583e09 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -178,10 +178,7 @@ static int spl_load_fit_image(struct spl_load_info *info, ulong sector,
 	if (image_info) {
 		image_info->load_addr = load_addr;
 		image_info->size = length;
-		if (entry == -1UL)
-			image_info->entry_point = load_addr;
-		else
-			image_info->entry_point = entry;
+		image_info->entry_point = entry;
 	}
 
 	return 0;
@@ -196,6 +193,7 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
 	struct spl_image_info image_info;
 	int node, images;
 	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
@@ -240,6 +238,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",
@@ -265,5 +268,26 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
 	image_info.load_addr = spl_image->load_addr + spl_image->size;
 	spl_load_fit_image(info, sector, fit, base_offset, node, &image_info);
 
+	/* 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;
+
+		spl_load_fit_image(info, sector, fit, base_offset, node,
+				   &image_info);
+
+		/*
+		 * If the "firmware" image did not provide an entry point,
+		 * use the first valid entry point from the loadables.
+		 */
+		if (spl_image->entry_point == -1UL &&
+		    image_info.entry_point != -1UL)
+			spl_image->entry_point = image_info.entry_point;
+	}
+
+	if (spl_image->entry_point == -1UL || spl_image->entry_point == 0)
+		spl_image->entry_point = spl_image->load_addr;
+
 	return 0;
 }
-- 
2.8.2

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

[Simon Glass]

Hi Andre,

On 28 February 2017 at 19:25, 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.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  common/spl/spl_fit.c | 32 ++++++++++++++++++++++++++++----
>  1 file changed, 28 insertions(+), 4 deletions(-)
>
> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> index ad5ba15..5583e09 100644
> --- a/common/spl/spl_fit.c
> +++ b/common/spl/spl_fit.c
> @@ -178,10 +178,7 @@ static int spl_load_fit_image(struct spl_load_info *info, ulong sector,
>         if (image_info) {
>                 image_info->load_addr = load_addr;
>                 image_info->size = length;
> -               if (entry == -1UL)
> -                       image_info->entry_point = load_addr;
> -               else
> -                       image_info->entry_point = entry;
> +               image_info->entry_point = entry;

Need to update function comment to indicate that it can put -1 in here.

>         }
>
>         return 0;
> @@ -196,6 +193,7 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
>         struct spl_image_info image_info;
>         int node, images;
>         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
> @@ -240,6 +238,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",
> @@ -265,5 +268,26 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
>         image_info.load_addr = spl_image->load_addr + spl_image->size;
>         spl_load_fit_image(info, sector, fit, base_offset, node, &image_info);
>
> +       /* 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;
> +
> +               spl_load_fit_image(info, sector, fit, base_offset, node,
> +                                  &image_info);

Error check?

> +
> +               /*
> +                * If the "firmware" image did not provide an entry point,
> +                * use the first valid entry point from the loadables.
> +                */
> +               if (spl_image->entry_point == -1UL &&
> +                   image_info.entry_point != -1UL)
> +                       spl_image->entry_point = image_info.entry_point;
> +       }
> +
> +       if (spl_image->entry_point == -1UL || spl_image->entry_point == 0)

Why does 0 mean there is no entry point? I suppose that is safe, but
would anyone use this?

> +               spl_image->entry_point = spl_image->load_addr;
> +
>         return 0;
>  }
> --
> 2.8.2
>

Regards,
Simon

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

[André Przywara]

On 08/03/17 21:00, Simon Glass wrote:
> Hi Andre,
> 
> On 28 February 2017 at 19:25, 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.
>>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>> ---
>>  common/spl/spl_fit.c | 32 ++++++++++++++++++++++++++++----
>>  1 file changed, 28 insertions(+), 4 deletions(-)
>>
>> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
>> index ad5ba15..5583e09 100644
>> --- a/common/spl/spl_fit.c
>> +++ b/common/spl/spl_fit.c
>> @@ -178,10 +178,7 @@ static int spl_load_fit_image(struct spl_load_info *info, ulong sector,
>>         if (image_info) {
>>                 image_info->load_addr = load_addr;
>>                 image_info->size = length;
>> -               if (entry == -1UL)
>> -                       image_info->entry_point = load_addr;
>> -               else
>> -                       image_info->entry_point = entry;
>> +               image_info->entry_point = entry;
> 
> Need to update function comment to indicate that it can put -1 in here.
> 
>>         }
>>
>>         return 0;
>> @@ -196,6 +193,7 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
>>         struct spl_image_info image_info;
>>         int node, images;
>>         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
>> @@ -240,6 +238,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",
>> @@ -265,5 +268,26 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
>>         image_info.load_addr = spl_image->load_addr + spl_image->size;
>>         spl_load_fit_image(info, sector, fit, base_offset, node, &image_info);
>>
>> +       /* 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;
>> +
>> +               spl_load_fit_image(info, sector, fit, base_offset, node,
>> +                                  &image_info);
> 
> Error check?
> 
>> +
>> +               /*
>> +                * If the "firmware" image did not provide an entry point,
>> +                * use the first valid entry point from the loadables.
>> +                */
>> +               if (spl_image->entry_point == -1UL &&
>> +                   image_info.entry_point != -1UL)
>> +                       spl_image->entry_point = image_info.entry_point;
>> +       }
>> +
>> +       if (spl_image->entry_point == -1UL || spl_image->entry_point == 0)
> 
> Why does 0 mean there is no entry point? I suppose that is safe, but
> would anyone use this?

So this is due to U-Boot's own Makefile, which sets
CONFIG_SYS_UBOOT_START to 0 if it isn't already defined. This then gets
passed on to mkimage -f auto as the -e argument.
So today's FIT images have 0 as an entry point - a least on sunxi.  As I
wanted to retain compatibility with that, I added this check.
Maybe sunxi (and other platforms?) should explicitly define the entry
point to avoid it being set to 0, or we should default to the load
address as the fallback in absence of such an explicit definition.

In any case I wanted to keep existing u-boot.img files booting, so I
added this safe guard here to do "the right thing (tm)".

I added a comment there to point this out.

Cheers,
Andre.

>> +               spl_image->entry_point = spl_image->load_addr;
>> +
>>         return 0;
>>  }
>> --
>> 2.8.2
>>
> 
> Regards,
> Simon
> 

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

[Simon Glass]

Hi Andre,

On 26 March 2017 at 19:19, André Przywara <andre.przywara@arm.com> wrote:
> On 08/03/17 21:00, Simon Glass wrote:
>> Hi Andre,
>>
>> On 28 February 2017 at 19:25, 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.
>>>
>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>> ---
>>>  common/spl/spl_fit.c | 32 ++++++++++++++++++++++++++++----
>>>  1 file changed, 28 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
>>> index ad5ba15..5583e09 100644
>>> --- a/common/spl/spl_fit.c
>>> +++ b/common/spl/spl_fit.c
>>> @@ -178,10 +178,7 @@ static int spl_load_fit_image(struct spl_load_info *info, ulong sector,
>>>         if (image_info) {
>>>                 image_info->load_addr = load_addr;
>>>                 image_info->size = length;
>>> -               if (entry == -1UL)
>>> -                       image_info->entry_point = load_addr;
>>> -               else
>>> -                       image_info->entry_point = entry;
>>> +               image_info->entry_point = entry;
>>
>> Need to update function comment to indicate that it can put -1 in here.
>>
>>>         }
>>>
>>>         return 0;
>>> @@ -196,6 +193,7 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
>>>         struct spl_image_info image_info;
>>>         int node, images;
>>>         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
>>> @@ -240,6 +238,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",
>>> @@ -265,5 +268,26 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
>>>         image_info.load_addr = spl_image->load_addr + spl_image->size;
>>>         spl_load_fit_image(info, sector, fit, base_offset, node, &image_info);
>>>
>>> +       /* 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;
>>> +
>>> +               spl_load_fit_image(info, sector, fit, base_offset, node,
>>> +                                  &image_info);
>>
>> Error check?
>>
>>> +
>>> +               /*
>>> +                * If the "firmware" image did not provide an entry point,
>>> +                * use the first valid entry point from the loadables.
>>> +                */
>>> +               if (spl_image->entry_point == -1UL &&
>>> +                   image_info.entry_point != -1UL)
>>> +                       spl_image->entry_point = image_info.entry_point;
>>> +       }
>>> +
>>> +       if (spl_image->entry_point == -1UL || spl_image->entry_point == 0)
>>
>> Why does 0 mean there is no entry point? I suppose that is safe, but
>> would anyone use this?
>
> So this is due to U-Boot's own Makefile, which sets
> CONFIG_SYS_UBOOT_START to 0 if it isn't already defined. This then gets
> passed on to mkimage -f auto as the -e argument.
> So today's FIT images have 0 as an entry point - a least on sunxi.  As I
> wanted to retain compatibility with that, I added this check.
> Maybe sunxi (and other platforms?) should explicitly define the entry
> point to avoid it being set to 0, or we should default to the load
> address as the fallback in absence of such an explicit definition.
>
> In any case I wanted to keep existing u-boot.img files booting, so I
> added this safe guard here to do "the right thing (tm)".

I very much doubt that 0 is needed as a default, so it should be OK to
break that. I'm almost certain there is no test to verify it.
Sometimes there are wierd things in the code that we should try to
drop.

>
> I added a comment there to point this out.
>
> Cheers,
> Andre.

Regards,
Simon

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

[Lokesh Vutla]

On Wednesday 01 March 2017 07:55 AM, Andre Przywara 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.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>


Reviewed-by: Lokesh Vutla <lokeshvuta@ti.com>

Thanks and regards,
Lokesh

[U-Boot] [PATCH 06/17] 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>
---
 tools/mksunxiboot.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/mksunxiboot.c b/tools/mksunxiboot.c
index 0f0b003..6bb649c 100644
--- a/tools/mksunxiboot.c
+++ b/tools/mksunxiboot.c
@@ -48,7 +48,7 @@ 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 SUN4I_SRAM_SIZE 0x8000	/* SoC with smaller size are limited before */
 #define SRAM_LOAD_MAX_SIZE (SUN4I_SRAM_SIZE - sizeof(struct boot_file_head))
 
 /*
-- 
2.8.2

[U-Boot] [PATCH 06/17] tools: mksunxiboot: allow larger SPL binaries

[Simon Glass]

On 28 February 2017 at 19:25, Andre Przywara <andre.przywara@arm.com> wrote:
> 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>
> ---
>  tools/mksunxiboot.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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

[U-Boot] [linux-sunxi] [PATCH 06/17] tools: mksunxiboot: allow larger SPL binaries

[Olliver Schinagl]

Hey Andre,

On 01-03-17 03:25, Andre Przywara wrote:
> 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>
> ---
>  tools/mksunxiboot.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/mksunxiboot.c b/tools/mksunxiboot.c
> index 0f0b003..6bb649c 100644
> --- a/tools/mksunxiboot.c
> +++ b/tools/mksunxiboot.c
> @@ -48,7 +48,7 @@ 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 SUN4I_SRAM_SIZE 0x8000	/* SoC with smaller size are limited before */
This seems a little scary, but besides that, you need to rename the 
define to SUNXI imo too then.

SUN4I, SUN5I and SUN7I (I think) all have the 24K limit imposed by the 
BROM. Only the later gens have a 32k limit. Since it is nice to have a 
single binary for all, name the define as SUNXI too I think. As a 
comment, I would put the responsibility elsewhere (instead of making it 
an assumption).

With that said, why do we have to check it at all then, other then to 
give a warning? The size is limited before already, right?

Olliver
>  #define SRAM_LOAD_MAX_SIZE (SUN4I_SRAM_SIZE - sizeof(struct boot_file_head))
>
>  /*
>

[U-Boot] [linux-sunxi] [PATCH 06/17] tools: mksunxiboot: allow larger SPL binaries

[Andre Przywara]

Hi Olliver,

thanks for having a look.

On 29/03/17 15:43, Olliver Schinagl wrote:
> Hey Andre,
> 
> On 01-03-17 03:25, Andre Przywara wrote:
>> 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>
>> ---
>>  tools/mksunxiboot.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/tools/mksunxiboot.c b/tools/mksunxiboot.c
>> index 0f0b003..6bb649c 100644
>> --- a/tools/mksunxiboot.c
>> +++ b/tools/mksunxiboot.c
>> @@ -48,7 +48,7 @@ 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 SUN4I_SRAM_SIZE 0x8000    /* SoC with smaller size are
>> limited before */
> This seems a little scary,

It is indeed (that's why I moved the SPL stack away in a later patch),
but we really need it.

> but besides that, you need to rename the
> define to SUNXI imo too then.

OK.

> SUN4I, SUN5I and SUN7I (I think) all have the 24K limit imposed by the
> BROM. Only the later gens have a 32k limit. Since it is nice to have a
> single binary for all, name the define as SUNXI too I think. As a
> comment, I would put the responsibility elsewhere (instead of making it
> an assumption).

What my admittedly clumsy comment wanted to say is that U-Boot's linker
script puts the 24K limit in place for those SoCs already. So we fail
much earlier, so at least from a U-Boot point of view this is fine.

> With that said, why do we have to check it at all then, other then to
> give a warning? The size is limited before already, right?

Frankly I didn't want to tinker with mksunxiboot too much, especially
since I added mksunxiboot's functionality already to mkimage (in a local
branch here).
But this is a separate series and I wanted to not hold this series back
any longer.

Cheers,
Andre.

> Olliver
>>  #define SRAM_LOAD_MAX_SIZE (SUN4I_SRAM_SIZE - sizeof(struct
>> boot_file_head))
>>
>>  /*
>>

[U-Boot] [PATCH 07/17] 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>
---
 arch/arm/lib/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 166fa9e..71de1ca 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 07/17] armv8: SPL: only compile GIC code if needed

[Simon Glass]

On 28 February 2017 at 19:25, Andre Przywara <andre.przywara@arm.com> wrote:
> 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>
> ---
>  arch/arm/lib/Makefile | 2 ++
>  1 file changed, 2 insertions(+)

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

[U-Boot] [PATCH 08/17] 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/cpu/armv8/fsl-layerscape/Makefile | 1 +
 arch/arm/lib/Makefile                      | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
index c9ab93e..ca09973 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
@@ -7,6 +7,7 @@
 obj-y += cpu.o
 obj-y += lowlevel.o
 obj-y += soc.o
+obj-y += ccn504.o
 obj-$(CONFIG_MP) += mp.o
 obj-$(CONFIG_OF_LIBFDT) += fdt.o
 obj-$(CONFIG_SPL) += spl.o
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 71de1ca..60ffb4a 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -43,7 +43,6 @@ obj-y	+= stack.o
 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
-- 
2.8.2

[U-Boot] [PATCH 08/17] armv8: fsl: move ccn504 code into FSL Makefile

[Simon Glass]

Hi Andre,

On 28 February 2017 at 19:25, Andre Przywara <andre.przywara@arm.com> wrote:
> 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/cpu/armv8/fsl-layerscape/Makefile | 1 +
>  arch/arm/lib/Makefile                      | 1 -
>  2 files changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
> index c9ab93e..ca09973 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
> @@ -7,6 +7,7 @@
>  obj-y += cpu.o
>  obj-y += lowlevel.o
>  obj-y += soc.o
> +obj-y += ccn504.o

Don't you need to move the file into the same directory?

>  obj-$(CONFIG_MP) += mp.o
>  obj-$(CONFIG_OF_LIBFDT) += fdt.o
>  obj-$(CONFIG_SPL) += spl.o
> diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
> index 71de1ca..60ffb4a 100644
> --- a/arch/arm/lib/Makefile
> +++ b/arch/arm/lib/Makefile
> @@ -43,7 +43,6 @@ obj-y += stack.o
>  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
> --
> 2.8.2
>

Regards,
Simon

[U-Boot] [PATCH 08/17] armv8: fsl: move ccn504 code into FSL Makefile

[André Przywara]

On 08/03/17 21:01, Simon Glass wrote:
> Hi Andre,
> 
> On 28 February 2017 at 19:25, Andre Przywara <andre.przywara@arm.com> wrote:
>> 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/cpu/armv8/fsl-layerscape/Makefile | 1 +
>>  arch/arm/lib/Makefile                      | 1 -
>>  2 files changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
>> index c9ab93e..ca09973 100644
>> --- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
>> +++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
>> @@ -7,6 +7,7 @@
>>  obj-y += cpu.o
>>  obj-y += lowlevel.o
>>  obj-y += soc.o
>> +obj-y += ccn504.o
> 
> Don't you need to move the file into the same directory?

Mmmh, good point, somehow this slipped through.
So I'd rather guard this with CONFIG_FSL_LAYERSCAPE in the original
Makefile and hope for some consolidation should a second user appear.

Cheers,
Andre.

> 
>>  obj-$(CONFIG_MP) += mp.o
>>  obj-$(CONFIG_OF_LIBFDT) += fdt.o
>>  obj-$(CONFIG_SPL) += spl.o
>> diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
>> index 71de1ca..60ffb4a 100644
>> --- a/arch/arm/lib/Makefile
>> +++ b/arch/arm/lib/Makefile
>> @@ -43,7 +43,6 @@ obj-y += stack.o
>>  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
>> --
>> 2.8.2
>>
> 
> Regards,
> Simon
> 

[U-Boot] [PATCH 09/17] 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>
---
 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 5fe886b..37c4a4d 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -186,7 +186,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 09/17] sunxi: A64: move SPL stack to end of SRAM A2

[Simon Glass]

On 28 February 2017 at 19:25, Andre Przywara <andre.przywara@arm.com> 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>
> ---
>  include/configs/sunxi-common.h | 5 +++++
>  1 file changed, 5 insertions(+)

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

[U-Boot] [PATCH 10/17] 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>
---
 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 10/17] sunxi: SPL: store RAM size in gd

[Simon Glass]

On 28 February 2017 at 19:25, Andre Przywara <andre.przywara@arm.com> 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>
> ---
>  board/sunxi/board.c | 7 +++----
>  1 file changed, 3 insertions(+), 4 deletions(-)

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

[U-Boot] [PATCH 11/17] 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>
---
 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] [linux-sunxi] [PATCH 11/17] sunxi: SPL: add FIT config selector for Pine64 boards

[Icenowy Zheng]

01.03.2017, 10:26, "Andre Przywara" <andre.przywara@arm.com>:
> 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.
>

I think we shouldn't have is specially for Pine64 here, but make a framework
for other boards that can be easily checked.

Then make Pine64 series the first user of this framework.

> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  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
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[U-Boot] [linux-sunxi] [PATCH 11/17] sunxi: SPL: add FIT config selector for Pine64 boards

[André Przywara]

On 01/03/17 03:03, Icenowy Zheng wrote:
> 
> 
> 01.03.2017, 10:26, "Andre Przywara" <andre.przywara@arm.com>:
>> 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.
>>
> 
> I think we shouldn't have is specially for Pine64 here, but make a framework
> for other boards that can be easily checked.
> 
> Then make Pine64 series the first user of this framework.

Well, actually this whole board_fit_config_name_match() *is* the
framework to differentiate boards at runtime. I don't see a reason why
we should make it more complicated than it already is.
With that last patch in the series we leave it to the SPL header to
select the board.

So it's really just the two different Pine64 models that need extra hand
holding here.

So I would hold off the magic framework until we know that we really
need it (a second user) and *what* we really need.

Cheers,
Andre.

> 
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>> ---
>>  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
>>
>> --
>> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/listinfo/u-boot
> 

[U-Boot] [PATCH 11/17] sunxi: SPL: add FIT config selector for Pine64 boards

[Simon Glass]

On 28 February 2017 at 19:25, Andre Przywara <andre.przywara@arm.com> 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>
> ---
>  board/sunxi/board.c | 23 +++++++++++++++++++++++
>  1 file changed, 23 insertions(+)

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

[U-Boot] [PATCH 12/17] 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 81b4226..f3e4243 100644
--- a/Kconfig
+++ b/Kconfig
@@ -238,6 +238,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 38b42da..e09b0d9 100644
--- a/Makefile
+++ b/Makefile
@@ -826,6 +826,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), $^) > $@
 
@@ -945,6 +949,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) \
@@ -977,6 +994,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 12/17] Makefile: add rules to generate SPL FIT images

[Andrew F. Davis]

On 02/28/2017 08:25 PM, Andre Przywara wrote:
> 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>
> ---

Acked-by: Andrew F. Davis <afd@ti.com>

>  Kconfig  | 17 +++++++++++++++++
>  Makefile | 20 ++++++++++++++++++++
>  2 files changed, 37 insertions(+)
> 
> diff --git a/Kconfig b/Kconfig
> index 81b4226..f3e4243 100644
> --- a/Kconfig
> +++ b/Kconfig
> @@ -238,6 +238,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 38b42da..e09b0d9 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -826,6 +826,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), $^) > $@
>  
> @@ -945,6 +949,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) \
> @@ -977,6 +994,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)
>  
> 

[U-Boot] [PATCH 12/17] Makefile: add rules to generate SPL FIT images

[Simon Glass]

On 28 February 2017 at 19:25, Andre Przywara <andre.przywara@arm.com> wrote:
> 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(+)

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

But please can you mention this in the documentation at doc/uImage.FIT?

[U-Boot] [PATCH 13/17] sunxi: A64: Pine64: 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 A64 boards.
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>
---
 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 13/17] sunxi: A64: Pine64: introduce FIT generator script

[Simon Glass]

On 28 February 2017 at 19:25, Andre Przywara <andre.przywara@arm.com> 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 A64 boards.
> 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>
> ---
>  board/sunxi/mksunxi_fit_atf.sh | 73 ++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 73 insertions(+)
>  create mode 100755 board/sunxi/mksunxi_fit_atf.sh

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

[U-Boot] [PATCH 14/17] sunxi: Pine64: defconfig: enable SPL FIT support

[Andre Przywara]

The Pine64 (and all other 64-bit Allwinner boards) need to load an
ARM Trusted Firmware image beside the actual U-Boot proper.
This can now be easily achieved by using the just extended SPL FIT
loading support, so enable it in the Pine64 defconfig.
Also add the FIT image as a build target to 64-bit sunxi board to
trigger the respective Makefile rules.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 configs/pine64_plus_defconfig  | 6 ++++++
 include/configs/sunxi-common.h | 4 ++++
 2 files changed, 10 insertions(+)

diff --git a/configs/pine64_plus_defconfig b/configs/pine64_plus_defconfig
index 7c7d86f..2b47157 100644
--- a/configs/pine64_plus_defconfig
+++ b/configs/pine64_plus_defconfig
@@ -3,9 +3,14 @@ CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER=y
 CONFIG_ARCH_SUNXI=y
 CONFIG_MACH_SUN50I=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
+CONFIG_FIT=y
+CONFIG_SPL_FIT=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_OF_LIBFDT=y
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
 # CONFIG_CMD_FPGA is not set
@@ -14,3 +19,4 @@ CONFIG_SPL=y
 # CONFIG_SPL_EFI_PARTITION is not set
 CONFIG_SUN8I_EMAC=y
 CONFIG_USB_EHCI_HCD=y
+CONFIG_SPL_FIT_GENERATOR="board/sunxi/mksunxi_fit_atf.sh"
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 37c4a4d..06d03d4 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -39,6 +39,10 @@
 #define CONFIG_SYS_THUMB_BUILD	/* Thumbs mode to save space in SPL */
 #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 14/17] sunxi: Pine64: defconfig: enable SPL FIT support

[Maxime Ripard]

Hi Andre,

On Wed, Mar 01, 2017 at 02:25:26AM +0000, Andre Przywara wrote:
> The Pine64 (and all other 64-bit Allwinner boards) need to load an
> ARM Trusted Firmware image beside the actual U-Boot proper.
> This can now be easily achieved by using the just extended SPL FIT
> loading support, so enable it in the Pine64 defconfig.
> Also add the FIT image as a build target to 64-bit sunxi board to
> trigger the respective Makefile rules.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  configs/pine64_plus_defconfig  | 6 ++++++
>  include/configs/sunxi-common.h | 4 ++++
>  2 files changed, 10 insertions(+)
> 
> diff --git a/configs/pine64_plus_defconfig b/configs/pine64_plus_defconfig
> index 7c7d86f..2b47157 100644
> --- a/configs/pine64_plus_defconfig
> +++ b/configs/pine64_plus_defconfig
> @@ -3,9 +3,14 @@ CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER=y
>  CONFIG_ARCH_SUNXI=y
>  CONFIG_MACH_SUN50I=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
> +CONFIG_FIT=y
> +CONFIG_SPL_FIT=y
> +CONFIG_SPL_LOAD_FIT=y
> +CONFIG_SPL_OF_LIBFDT=y

I'm not sure we want to force down that support to all our users.

We should definitely make that easy (basically just switching on an
option), for example a few selects here might be good. But switching
that on, and only for a few boards seems both weird and inconsistent.

>  # CONFIG_CMD_IMLS is not set
>  # CONFIG_CMD_FLASH is not set
>  # CONFIG_CMD_FPGA is not set
> @@ -14,3 +19,4 @@ CONFIG_SPL=y
>  # CONFIG_SPL_EFI_PARTITION is not set
>  CONFIG_SUN8I_EMAC=y
>  CONFIG_USB_EHCI_HCD=y
> +CONFIG_SPL_FIT_GENERATOR="board/sunxi/mksunxi_fit_atf.sh"

And that could be a default value.

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/20170301/7c120ab7/attachment.sig>

[U-Boot] [PATCH 15/17] sunxi: OrangePi-PC2: defconfig: enable SPL FIT support

[Andre Przywara]

Enable the SPL FIT support and the FIT generator script for the
OrangePi PC2 board, as it also need to load an ATF binary.

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

diff --git a/configs/orangepi_pc2_defconfig b/configs/orangepi_pc2_defconfig
index 19a5c2b..8a2d289 100644
--- a/configs/orangepi_pc2_defconfig
+++ b/configs/orangepi_pc2_defconfig
@@ -5,6 +5,12 @@ 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_FIT=y
+CONFIG_SPL_FIT=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_OF_LIBFDT=y
+CONFIG_SPL_FIT_GENERATOR="board/sunxi/mksunxi_fit_atf.sh"
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
 CONFIG_CONSOLE_MUX=y
 # CONFIG_CMD_IMLS is not set
-- 
2.8.2

[U-Boot] [PATCH 15/17] sunxi: OrangePi-PC2: defconfig: enable SPL FIT support

[Simon Glass]

On 28 February 2017 at 19:25, Andre Przywara <andre.przywara@arm.com> wrote:
> Enable the SPL FIT support and the FIT generator script for the
> OrangePi PC2 board, as it also need to load an ATF binary.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  configs/orangepi_pc2_defconfig | 6 ++++++
>  1 file changed, 6 insertions(+)

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

[U-Boot] [PATCH 16/17] 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 06d03d4..e37bf6a 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -188,8 +188,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
@@ -197,8 +197,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 b52f996..fe827ce 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -285,7 +285,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 6bb649c..4ac2791 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 16/17] sunxi: Store the device tree name in the SPL header

[Simon Glass]

Hi Andre,

On 28 February 2017 at 19:25, Andre Przywara <andre.przywara@arm.com> wrote:
> 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(-)

Can this code move into mkimage as a new image type? This is what
rockchip does. It feels like this tool should be subsumed. If that
doesn't work, perhaps binman?

- Simon

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

[André Przywara]

On 08/03/17 21:01, Simon Glass wrote:

Hi Simon,

many thanks for the review, finally found some time to look at this.
I have finished the needed rework (including documentation) and will
post something after some testing and some sleep ;-)

> On 28 February 2017 at 19:25, Andre Przywara <andre.przywara@arm.com> wrote:
>> 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(-)
> 
> Can this code move into mkimage as a new image type? This is what
> rockchip does. It feels like this tool should be subsumed. If that
> doesn't work, perhaps binman?

Interesting, I wasn't aware that mkimage can do more than legacy and
FIT. Indeed that sounds useful, especially as mkimage seems to be
packaged separately and is available in some distros.

So I hacked something up, but that needs some more love.
I am tempted to drop (or split) this patch from this series for now,
since this extension here and the move to mkimage could be treated
separately from the SPL FIT code.

Cheers,
Andre.

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

[Simon Glass]

Hi Andre,

On 26 March 2017 at 19:18, André Przywara <andre.przywara@arm.com> wrote:
> On 08/03/17 21:01, Simon Glass wrote:
>
> Hi Simon,
>
> many thanks for the review, finally found some time to look at this.
> I have finished the needed rework (including documentation) and will
> post something after some testing and some sleep ;-)
>
>> On 28 February 2017 at 19:25, Andre Przywara <andre.przywara@arm.com> wrote:
>>> 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(-)
>>
>> Can this code move into mkimage as a new image type? This is what
>> rockchip does. It feels like this tool should be subsumed. If that
>> doesn't work, perhaps binman?
>
> Interesting, I wasn't aware that mkimage can do more than legacy and
> FIT. Indeed that sounds useful, especially as mkimage seems to be
> packaged separately and is available in some distros.
>
> So I hacked something up, but that needs some more love.
> I am tempted to drop (or split) this patch from this series for now,
> since this extension here and the move to mkimage could be treated
> separately from the SPL FIT code.

Yes that's fine, whatever works for you. I like using mkimage since it
is supposed to me the tool we use to make binary files (with binman as
a way of building the whole firmware image).

Regards,
SImon

[U-Boot] [PATCH 17/17] 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 17/17] sunxi: use SPL header DT name for FIT board matching

[Simon Glass]

On 28 February 2017 at 19:25, Andre Przywara <andre.przywara@arm.com> wrote:
> 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.

Or perhaps placed in the device tree attached to SPL, if there is one.

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

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

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

[Kever Yang]

Hi Andre,

     I have test this patch set on rk3399 with ATF support.

For patch 2~5, you can add:
Tested-by: Kever Yang <kever.yang@rock-chips.com>

Thanks,
- Kever
On 03/01/2017 10:25 AM, Andre Przywara wrote:
> This is an updated and slightly extended version of the SPL FIT loading
> series I posted as an RFC some weeks ago.
> I tried to fix all bugs that have been pointed out by the diligent
> reviewers, also added patches to automatically build the FIT images.
>
> The first patch is a bug fix for a regression introduced with -rc1.
> I put this in there to allow people testing the series and to provide
> an actual patch for this fix, which should make it still into 2017.03.
> The next four patches introduce the core of the extened SPL FIT loading
> support, see below for a description.
> Patches 6-9 make some room in the sunxi 64-bit SPL to allow
> compiling in the FIT loading bits. Patch 10 and 11 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 in the Pine64 and the
> OrangePi PC 2 defconfigs.
> The last two patches are new and eventually 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.
>
> Let me know what you think!
>
> Cheers,
> Andre.
>
> Based on top of sunxi/master (35affe7698e9).
>
> -------
> 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 (15):
>    SPL: FIT: refactor FDT loading
>    SPL: FIT: rework U-Boot image loading
>    SPL: FIT: factor out spl_load_fit_image()
>    SPL: FIT: allow loading multiple images
>    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: A64: Pine64: introduce FIT generator script
>    sunxi: Pine64: defconfig: enable SPL FIT support
>    sunxi: OrangePi-PC2: defconfig: enable SPL FIT support
>    sunxi: use SPL header DT name for FIT board matching
>
> Philipp Tomsich (1):
>    armv8: spl: Call spl_relocate_stack_gd for ARMv8
>
> Siarhei Siamashka (1):
>    sunxi: Store the device tree name in the SPL header
>
>   Kconfig                                    |  17 ++
>   Makefile                                   |  20 +++
>   arch/arm/cpu/armv8/fsl-layerscape/Makefile |   1 +
>   arch/arm/include/asm/arch-sunxi/spl.h      |  19 ++-
>   arch/arm/lib/Makefile                      |   3 +-
>   arch/arm/lib/crt0_64.S                     |  14 +-
>   board/sunxi/board.c                        |  36 ++++-
>   board/sunxi/mksunxi_fit_atf.sh             |  73 +++++++++
>   common/spl/spl_fit.c                       | 246 +++++++++++++++++------------
>   configs/orangepi_pc2_defconfig             |   6 +
>   configs/pine64_plus_defconfig              |   6 +
>   include/configs/sunxi-common.h             |  17 +-
>   scripts/Makefile.spl                       |   3 +-
>   tools/mksunxiboot.c                        |  51 +++++-
>   14 files changed, 387 insertions(+), 125 deletions(-)
>   create mode 100755 board/sunxi/mksunxi_fit_atf.sh
>

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

[Dr. Philipp Tomsich]

Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

> On 01 Mar 2017, at 03:25, Andre Przywara <andre.przywara@arm.com> wrote:
> 
> This is an updated and slightly extended version of the SPL FIT loading
> series I posted as an RFC some weeks ago.
> I tried to fix all bugs that have been pointed out by the diligent
> reviewers, also added patches to automatically build the FIT images.
> 
> The first patch is a bug fix for a regression introduced with -rc1.
> I put this in there to allow people testing the series and to provide
> an actual patch for this fix, which should make it still into 2017.03.
> The next four patches introduce the core of the extened SPL FIT loading
> support, see below for a description.
> Patches 6-9 make some room in the sunxi 64-bit SPL to allow
> compiling in the FIT loading bits. Patch 10 and 11 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 in the Pine64 and the
> OrangePi PC 2 defconfigs.
> The last two patches are new and eventually 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.
> 
> Let me know what you think!
> 
> Cheers,
> Andre.
> 
> Based on top of sunxi/master (35affe7698e9).
> 
> -------
> 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 (15):
>  SPL: FIT: refactor FDT loading
>  SPL: FIT: rework U-Boot image loading
>  SPL: FIT: factor out spl_load_fit_image()
>  SPL: FIT: allow loading multiple images
>  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: A64: Pine64: introduce FIT generator script
>  sunxi: Pine64: defconfig: enable SPL FIT support
>  sunxi: OrangePi-PC2: defconfig: enable SPL FIT support
>  sunxi: use SPL header DT name for FIT board matching
> 
> Philipp Tomsich (1):
>  armv8: spl: Call spl_relocate_stack_gd for ARMv8
> 
> Siarhei Siamashka (1):
>  sunxi: Store the device tree name in the SPL header
> 
> Kconfig                                    |  17 ++
> Makefile                                   |  20 +++
> arch/arm/cpu/armv8/fsl-layerscape/Makefile |   1 +
> arch/arm/include/asm/arch-sunxi/spl.h      |  19 ++-
> arch/arm/lib/Makefile                      |   3 +-
> arch/arm/lib/crt0_64.S                     |  14 +-
> board/sunxi/board.c                        |  36 ++++-
> board/sunxi/mksunxi_fit_atf.sh             |  73 +++++++++
> common/spl/spl_fit.c                       | 246 +++++++++++++++++------------
> configs/orangepi_pc2_defconfig             |   6 +
> configs/pine64_plus_defconfig              |   6 +
> include/configs/sunxi-common.h             |  17 +-
> scripts/Makefile.spl                       |   3 +-
> tools/mksunxiboot.c                        |  51 +++++-
> 14 files changed, 387 insertions(+), 125 deletions(-)
> create mode 100755 board/sunxi/mksunxi_fit_atf.sh
> 
> --
> 2.8.2
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170314/629e490e/attachment.sig>