SPL: extend FIT loading support

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 <[email protected]>

Reviewed-by Lokesh Vutla <[email protected]>

---
 common/spl/spl_fit.c | 88 ++++++++++++++++++++++++++++++++++------------------
 1 file changed, 57 insertions(+), 31 deletions(-)

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 <[email protected]>

Reviewed-by Lokesh Vutla <[email protected]>

---
 common/spl/spl_fit.c | 88 ++++++++++++++++++++++++++++++++++------------------
 1 file changed, 57 insertions(+), 31 deletions(-)

common/spl/spl_fit.c +57 -32

index aae556f..bf9fbb6 100644
@@ -22,13 +22,16 @@ static ulong fdt_getprop_u32(const void *fdt, int node, const char *prop)
        return fdt32_to_cpu(*cell);
 }
 
-static int spl_fit_select_fdt(const void *fdt, int images, int *fdt_offsetp)
+/*
+ * Iterate over all /configurations subnodes and call a platform specific
+ * function to find the matching configuration.
+ * Returns the node offset.
+ */
+static int spl_fit_find_config_node(const void *fdt)
 {
-       const char *name, *fdt_name;
-       int conf, node, fdt_node;
-       int len;
+       const char *name;
+       int conf, node, len;
 
-       *fdt_offsetp = 0;
        conf = fdt_path_offset(fdt, FIT_CONFS_PATH);
        if (conf < 0) {
                debug("%s: Cannot find /configurations node: %d\n", __func__,

@@ -50,39 +53,61 @@ static int spl_fit_select_fdt(const void *fdt, int images, int *fdt_offsetp)
                        continue;
 
                debug("Selecting config '%s'", name);
-               fdt_name = fdt_getprop(fdt, node, FIT_FDT_PROP, &len);
-               if (!fdt_name) {
-                       debug("%s: Cannot find fdt name property: %d\n",
-                             __func__, len);
-                       return -EINVAL;
-               }
 
-               debug(", fdt '%s'\n", fdt_name);
-               fdt_node = fdt_subnode_offset(fdt, images, fdt_name);
-               if (fdt_node < 0) {
-                       debug("%s: Cannot find fdt node '%s': %d\n",
-                             __func__, fdt_name, fdt_node);
-                       return -EINVAL;
+               return node;
+       }
+
+       return -1;
+}
+
+static int spl_fit_select_index(const void *fit, int images, int *offsetp,
+                               const char *type, int index)
+{
+       const char *name, *str;
+       int node, conf_node;
+       int len, i;
+
+       *offsetp = 0;
+       conf_node = spl_fit_find_config_node(fit);
+       if (conf_node < 0) {
+#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
+               printf("No matching DT out of these options:\n");
+               for (node = fdt_first_subnode(fit, conf_node);
+                    node >= 0;
+                    node = fdt_next_subnode(fit, node)) {
+                       name = fdt_getprop(fit, node, "description", &len);
+                       printf("   %s\n", name);
                }
+#endif
+               return -ENOENT;
+       }
 
-               *fdt_offsetp = fdt_getprop_u32(fdt, fdt_node, "data-offset");
-               len = fdt_getprop_u32(fdt, fdt_node, "data-size");
-               debug("FIT: Selected '%s'\n", name);
+       name = fdt_getprop(fit, conf_node, type, &len);
+       if (!name) {
+               debug("cannot find property '%s': %d\n", type, len);
+               return -EINVAL;
+       }
 
-               return len;
+       str = name;
+       for (i = 0; i < index; i++) {
+               str = strchr(str, '\0') + 1;
+               if (!str || (str - name >= len)) {
+                       debug("no string for index %d\n", index);
+                       return -E2BIG;
+               }
        }
 
-#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
-       printf("No matching DT out of these options:\n");
-       for (node = fdt_first_subnode(fdt, conf);
-            node >= 0;
-            node = fdt_next_subnode(fdt, node)) {
-               name = fdt_getprop(fdt, node, "description", &len);
-               printf("   %s\n", name);
+       debug("%s: '%s'\n", type, str);
+       node = fdt_subnode_offset(fit, images, str);
+       if (node < 0) {
+               debug("cannot find image node '%s': %d\n", str, node);
+               return -EINVAL;
        }
-#endif
 
-       return -ENOENT;
+       *offsetp = fdt_getprop_u32(fit, node, "data-offset");
+       len = fdt_getprop_u32(fit, node, "data-size");
+
+       return len;
 }
 
 static int get_aligned_image_offset(struct spl_load_info *info, int offset)

@@ -218,7 +243,8 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
        memcpy(dst, src, data_size);
 
        /* Figure out which device tree the board wants to use */
-       fdt_len = spl_fit_select_fdt(fit, images, &fdt_offset);
+       fdt_len = spl_fit_select_index(fit, images, &fdt_offset,
+                                      FIT_FDT_PROP, 0);
        if (fdt_len < 0)
                return fdt_len;
 
--

2.8.2

_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
https://lists.denx.de/listinfo/u-boot

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 <[email protected]>

Reviewed-by Lokesh Vutla <[email protected]>

---
 common/spl/spl_fit.c | 45 +++++++++++++++++++++++++++++++--------------
 1 file changed, 31 insertions(+), 14 deletions(-)

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

Signed-off-by Andre Przywara <[email protected]>

---
 common/spl/spl_fit.c | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

common/spl/spl_fit.c +5 -2

index a4ac27b..55da37a 100644
@@ -11,14 +11,17 @@
 #include <libfdt.h>
 #include <spl.h>
 
+#define FDT_ERROR ((ulong)(-1))
+
 static ulong fdt_getprop_u32(const void *fdt, int node, const char *prop)
 {
        const u32 *cell;
        int len;
 
        cell = fdt_getprop(fdt, node, prop, &len);
-       if (len != sizeof(*cell))
-               return -1U;
+       if (!cell || len != sizeof(*cell))
+               return FDT_ERROR;
+
        return fdt32_to_cpu(*cell);
 }
 

common/spl/spl_fit.c +4 -1

        load = fdt_getprop_u32(fit, node, "load");
        debug("data_offset=%x, data_size=%x\n", data_offset, data_size);
        spl_image->load_addr = load;

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

2.8.2

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

Signed-off-by Andre Przywara <[email protected]>

---
 common/spl/spl_fit.c | 160 +++++++++++++++++++++++++--------------------------
 1 file changed, 78 insertions(+), 82 deletions(-)

common/spl/spl_fit.c +4 -0

index 55da37a..cfcb1fe 100644
@@ -158,19 +158,79 @@ static int get_aligned_image_size(struct spl_load_info *info, int data_size,
        return (data_size + info->bl_len - 1) / info->bl_len;
 }
 
+/*
+ * spl_load_fit_image loads the image described in a certain FIT node.
+ * @info: points to information about the device to load data from
+ * @sector: the start sector of the FIT image on the device

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

Hi Andre ,

Quoted 8 lines

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.

Quoted 8 lines

This allows to load any kind of images:
- firmware images to execute before U-Boot proper (for instance ARM Trusted Firmware (ATF))
- firmware images for management processors (SCP, arisc, ...)
- firmware images for devices like WiFi controllers
- bit files for FPGAs
- additional configuration data
- kernels and/or ramdisks

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

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

Quoted 19 lines · Lukasz Majewski

Hi Andre ,

Quoted 8 lines

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.

Quoted 8 lines

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

Quoted 2 lines

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

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

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

Quoted 19 lines

Hi Andre ,

Quoted 8 lines

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.

Quoted 8 lines

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

Quoted 2 lines

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

As it stands at the moment, this code is run when the SPL is finished with initialising the platform and is about to load and hand over to U-Boot proper.
It would need to be investigated if the device driver required to actually load the FIT image works without DRAM being available (as in:
do we have enough heap and stack, for instance).

Also I am not sure the FIT (fdt) parsing code is really tuned for low memory, since normally it runs with DRAM already available.

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

Quoted 3 lines

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

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

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

Cheers,
Andre.

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

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

Signed-off-by Andre Przywara <[email protected]>

Reviewed-by Lokesh Vutla <[email protected]>

---
 common/spl/spl_fit.c     | 42 ++++++++++++++++++++++++++++++++++++++++--
 doc/uImage.FIT/howto.txt | 21 +++++++++++++++++++++
 2 files changed, 61 insertions(+), 2 deletions(-)

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 <[email protected]>

Reviewed-by Simon Glass <[email protected]>

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 <[email protected]>

Reviewed-by Simon Glass <[email protected]>

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 <[email protected]>

Reviewed-by Simon Glass <[email protected]>

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

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

Signed-off-by Andre Przywara <[email protected]>

Reviewed-by Simon Glass <[email protected]>

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

Signed-off-by Andre Przywara <[email protected]>

---
 configs/orangepi_pc2_defconfig | 1 +
 configs/pine64_plus_defconfig  | 1 +
 2 files changed, 2 insertions(+)

configs/orangepi_pc2_defconfig +0 -0

index 19a5c2b..9f02049 100644

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

Signed-off-by Andre Przywara <[email protected]>

board/sunxi/README.pine64 +9 -0

+Quick Start / Overview
+======================
+- Build the ARM Trusted Firmware binary (see "ARM Trusted firmware (ATF)" below)
+- Build U-Boot (see "SPL/U-Boot" below)
+- Transfer to an uSD card (see "microSD card" below)
+- Boot and enjoy!
+
+Building the firmware
+=====================

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

+
+$ make clean

 $ export CROSS_COMPILE=aarch64-linux-gnu-
 $ make pine64_plus_defconfig
 $ make

Thanks for your awesome work on getting things in shape!

Am 01.04.2017 um 00:31 schrieb Andre Przywara:

Quoted 9 lines

board/sunxi/README.pine64 +9 -0

+Quick Start / Overview
+======================
+- Build the ARM Trusted Firmware binary (see "ARM Trusted firmware (ATF)" below)
+- Build U-Boot (see "SPL/U-Boot" below)
+- Transfer to an uSD card (see "microSD card" below)
+- Boot and enjoy!
+
+Building the firmware
+=====================

board/sunxi/README.pine64 This chip has ARM Cortex A-53 cores and thus can run both in AArch32 · line 29

Quoted 10 lines

board/sunxi/README.pine64 +10 -0

+
+The Allwinner A64 firmware consists of three parts: U-Boot's SPL, an
+ARM Trusted Firmware (ATF) build and the U-Boot proper.
+The SPL will load both ATF and U-Boot proper along with the right device
+tree blob (.dtb) and will pass execution to ATF (in EL3), which in turn will
+drop into the U-Boot proper (in EL2).
+As the ATF binary will become part of the U-Boot image file, you will need
+to build it first.
+
+ ARM Trusted firmware (ATF)

"Firmware"

board/sunxi/README.pine64 This chip has ARM Cortex A-53 cores and thus can run both in AArch32 · line 35

Quoted 6 lines

+----------------------------

board/sunxi/README.pine64 +5 -0

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

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

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

board/sunxi/README.pine64 This chip has ARM Cortex A-53 cores and thus can run both in AArch32 · line 42

Quoted 8 lines

board/sunxi/README.pine64 +7 -0

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

"U-Boot"

Quoted 1 line

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

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

Quoted 5 lines

+
+$ make clean

 $ export CROSS_COMPILE=aarch64-linux-gnu-
 $ make pine64_plus_defconfig
 $ make

[snip]

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

For the Orange Pi PC 2, for this series:

Tested-by Andreas Färber <[email protected]>

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

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

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

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

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

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

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

Cheers,
Andreas

Quoted 3 lines

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

Can you say which version of GCC 5? I think I used GCC 5.3.0 for a while and this was fine, but I need to re-check this.

Am 18.04.2017 um 22:38 schrieb André Przywara:

Quoted 7 lines · Andreas Färber

Quoted 3 lines

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

Can you say which version of GCC 5? I think I used GCC 5.3.0 for a while and this was fine, but I need to re-check this.

Failure was with a Linaro GCC 5.1.

Working was Linaro GCC 6.3.1.

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

Am 18.04.2017 um 22:38 schrieb André Przywara:

Quoted 7 lines · Andreas Färber

Quoted 3 lines

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

Can you say which version of GCC 5? I think I used GCC 5.3.0 for a while and this was fine, but I need to re-check this.

Failure was with a Linaro GCC 5.1.

Working was Linaro GCC 6.3.1.

I would happily use our latest SUSE GCC 7.0.1 if only U-Boot had a private libgcc for aarch64... :(

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

Signed-off-by Andre Przywara <[email protected]>

---
 board/sunxi/README.pine64 | 177 ++++++++++++++++++++++++++++++----------------
 1 file changed, 115 insertions(+), 62 deletions(-)

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

Rework the Pine64 README file to document how to build the firmware.

Signed-off-by Andre Przywara <[email protected]>

---
 board/sunxi/README.pine64 | 177 ++++++++++++++++++++++++++++++----------------
 1 file changed, 115 insertions(+), 62 deletions(-)

board/sunxi/README.pine64 +0 -0

index 5553415..41fb58e 100644

+Alternative you can concatenate the SPL and the U-Boot FIT image into a single

+file and transfer that instead:

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

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

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

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

Cheers,
Andre.

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

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

Hi Andre,

Quoted 53 lines · Andre Przywara

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

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

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

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

Cheers,
Andre.

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

Quoted 15 lines

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

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

Quoted 72 lines · Simon Glass

Hi Andre,

Quoted 53 lines · Andre Przywara

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

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

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

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

Cheers,
Andre.

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

Quoted 15 lines

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.

Quoted 3 lines

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

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

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

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

HTH!