On 2.2.2018 12:01, Philipp Tomsich wrote:
> The fdt_record_loadable()-function was wedged between other functions
> that were guarded by ARCH_FIXUP_FDT_MEMORY.  This could lead to linker
> errors on some configurations.
> 
> With this change, fdt_record_loadable() is moved out of the
> ARCH_FIXUP_FDT_MEMORY guard (plus I tried to retain alphabetical
> ordering for functions by placing it appropriately).
> 
> References: 9f45aeb ("spl: fit: implement fdt_record_loadable")
> Signed-off-by: Philipp Tomsich <philipp.toms...@theobroma-systems.com>
> ---
> 
>  common/fdt_support.c | 78 
> ++++++++++++++++++++++++++--------------------------
>  1 file changed, 39 insertions(+), 39 deletions(-)
> 
> diff --git a/common/fdt_support.c b/common/fdt_support.c
> index 724452d..17623a1 100644
> --- a/common/fdt_support.c
> +++ b/common/fdt_support.c
> @@ -410,45 +410,6 @@ static int fdt_pack_reg(const void *fdt, void *buf, u64 
> *address, u64 *size,
>       return p - (char *)buf;
>  }
>  
> -int fdt_record_loadable(void *blob, u32 index, const char *name,
> -                     uintptr_t load_addr, u32 size, uintptr_t entry_point,
> -                     const char *type, const char *os)
> -{
> -     int err, node;
> -
> -     err = fdt_check_header(blob);
> -     if (err < 0) {
> -             printf("%s: %s\n", __func__, fdt_strerror(err));
> -             return err;
> -     }
> -
> -     /* find or create "/fit-images" node */
> -     node = fdt_find_or_add_subnode(blob, 0, "fit-images");
> -     if (node < 0)
> -                     return node;
> -
> -     /* find or create "/fit-images/<name>" node */
> -     node = fdt_find_or_add_subnode(blob, node, name);
> -     if (node < 0)
> -             return node;
> -
> -     /*
> -      * We record these as 32bit entities, possibly truncating addresses.
> -      * However, spl_fit.c is not 64bit safe either: i.e. we should not
> -      * have an issue here.
> -      */
> -     fdt_setprop_u32(blob, node, "load-addr", load_addr);
> -     if (entry_point != -1)
> -             fdt_setprop_u32(blob, node, "entry-point", entry_point);
> -     fdt_setprop_u32(blob, node, "size", size);
> -     if (type)
> -             fdt_setprop_string(blob, node, "type", type);
> -     if (os)
> -             fdt_setprop_string(blob, node, "os", os);
> -
> -     return node;
> -}
> -
>  #ifdef CONFIG_NR_DRAM_BANKS
>  #define MEMORY_BANKS_MAX CONFIG_NR_DRAM_BANKS
>  #else
> @@ -584,6 +545,45 @@ void fdt_fixup_ethernet(void *fdt)
>       }
>  }
>  
> +int fdt_record_loadable(void *blob, u32 index, const char *name,
> +                     uintptr_t load_addr, u32 size, uintptr_t entry_point,
> +                     const char *type, const char *os)
> +{
> +     int err, node;
> +
> +     err = fdt_check_header(blob);
> +     if (err < 0) {
> +             printf("%s: %s\n", __func__, fdt_strerror(err));
> +             return err;
> +     }
> +
> +     /* find or create "/fit-images" node */
> +     node = fdt_find_or_add_subnode(blob, 0, "fit-images");
> +     if (node < 0)
> +             return node;
> +
> +     /* find or create "/fit-images/<name>" node */
> +     node = fdt_find_or_add_subnode(blob, node, name);
> +     if (node < 0)
> +             return node;
> +
> +     /*
> +      * We record these as 32bit entities, possibly truncating addresses.
> +      * However, spl_fit.c is not 64bit safe either: i.e. we should not
> +      * have an issue here.
> +      */
> +     fdt_setprop_u32(blob, node, "load-addr", load_addr);
> +     if (entry_point != -1)
> +             fdt_setprop_u32(blob, node, "entry-point", entry_point);
> +     fdt_setprop_u32(blob, node, "size", size);
> +     if (type)
> +             fdt_setprop_string(blob, node, "type", type);
> +     if (os)
> +             fdt_setprop_string(blob, node, "os", os);
> +
> +     return node;
> +}
> +
>  /* Resize the fdt to its actual size + a bit of padding */
>  int fdt_shrink_to_minimum(void *blob, uint extrasize)
>  {
> 

Reported-by: Michal Simek <michal.si...@xilinx.com>
Tested-by: Michal Simek <michal.si...@xilinx.com>

Thanks,
Michal
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Reply via email to