All of lore.kernel.org
 help / color / mirror / Atom feed
* [U-Boot] [PATCH v3] common: Fix load and entry addresses in FIT image
@ 2015-09-04 14:43 York Sun
  2015-09-09 18:07 ` Simon Glass
  0 siblings, 1 reply; 9+ messages in thread
From: York Sun @ 2015-09-04 14:43 UTC (permalink / raw)
  To: u-boot

FIT image supports more than 32 bits in addresses by using #address-cell
field. However the address length is not handled when parsing FIT images.
Beside, the variable used to host address has "ulong" type. It is OK for
the target, but not always enough for host tools such as mkimage. This
patch replaces "ulong" with "phys_addr_t" to make sure the address is
correct for both the target and the host.

Signed-off-by: York Sun <yorksun@freescale.com>

---

Changes in v3:
  Define PRIpa for host and target in common/image-fit.c so printf works
  properly for 32-, 64-bit targets and host tools.

Changes in v2:
  Make a common function for both load and entry addresses.
  Simplify calculation of addresses in a similar way as fdtdec_get_number()
  fdtdec_get_number() is not used, or too many files need to be included
    and/or twisted for host tool
  Continue to use %08llx for print format for load and entry addresses
    because %pa does not always work for host tool (mkimage)

 common/bootm.c     |   13 +++++----
 common/image-fit.c |   81 +++++++++++++++++++++++++++++-----------------------
 include/bootm.h    |    6 ++--
 include/image.h    |   12 +++++---
 4 files changed, 63 insertions(+), 49 deletions(-)

diff --git a/common/bootm.c b/common/bootm.c
index 667c934..0672e73 100644
--- a/common/bootm.c
+++ b/common/bootm.c
@@ -325,9 +325,9 @@ static int handle_decomp_error(int comp_type, size_t uncomp_size,
 	return BOOTM_ERR_RESET;
 }
 
-int bootm_decomp_image(int comp, ulong load, ulong image_start, int type,
-		       void *load_buf, void *image_buf, ulong image_len,
-		       uint unc_len, ulong *load_end)
+int bootm_decomp_image(int comp, phys_addr_t load, phys_addr_t image_start,
+		       int type, void *load_buf, void *image_buf,
+		       ulong image_len, uint unc_len, ulong *load_end)
 {
 	int ret = 0;
 
@@ -883,7 +883,8 @@ void memmove_wd(void *to, void *from, size_t len, ulong chunksz)
 static int bootm_host_load_image(const void *fit, int req_image_type)
 {
 	const char *fit_uname_config = NULL;
-	ulong data, len;
+	phys_addr_t *data = NULL;
+	ulong len;
 	bootm_headers_t images;
 	int noffset;
 	ulong load_end;
@@ -897,7 +898,7 @@ static int bootm_host_load_image(const void *fit, int req_image_type)
 	noffset = fit_image_load(&images, (ulong)fit,
 		NULL, &fit_uname_config,
 		IH_ARCH_DEFAULT, req_image_type, -1,
-		FIT_LOAD_IGNORED, &data, &len);
+		FIT_LOAD_IGNORED, data, &len);
 	if (noffset < 0)
 		return noffset;
 	if (fit_image_get_type(fit, noffset, &image_type)) {
@@ -912,7 +913,7 @@ static int bootm_host_load_image(const void *fit, int req_image_type)
 
 	/* Allow the image to expand by a factor of 4, should be safe */
 	load_buf = malloc((1 << 20) + len * 4);
-	ret = bootm_decomp_image(imape_comp, 0, data, image_type, load_buf,
+	ret = bootm_decomp_image(imape_comp, 0, *data, image_type, load_buf,
 				 (void *)data, len, CONFIG_SYS_BOOTM_LEN,
 				 &load_end);
 	free(load_buf);
diff --git a/common/image-fit.c b/common/image-fit.c
index 28f7aa8..2248692 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -13,12 +13,14 @@
 #include "mkimage.h"
 #include <image.h>
 #include <time.h>
+#define PRIpa "0x%08llx"
 #else
 #include <common.h>
 #include <errno.h>
 #include <mapmem.h>
 #include <asm/io.h>
 DECLARE_GLOBAL_DATA_PTR;
+#define PRIpa "0x%08lx"
 #endif /* !USE_HOSTCC*/
 
 #include <bootstage.h>
@@ -358,7 +360,7 @@ void fit_image_print(const void *fit, int image_noffset, const char *p)
 	char *desc;
 	uint8_t type, arch, os, comp;
 	size_t size;
-	ulong load, entry;
+	phys_addr_t load, entry;
 	const void *data;
 	int noffset;
 	int ndepth;
@@ -428,17 +430,17 @@ void fit_image_print(const void *fit, int image_noffset, const char *p)
 		if (ret)
 			printf("unavailable\n");
 		else
-			printf("0x%08lx\n", load);
+			printf(PRIpa "\n", load);
 	}
 
 	if ((type == IH_TYPE_KERNEL) || (type == IH_TYPE_STANDALONE) ||
 	    (type == IH_TYPE_RAMDISK)) {
-		fit_image_get_entry(fit, image_noffset, &entry);
+		ret = fit_image_get_entry(fit, image_noffset, &entry);
 		printf("%s  Entry Point:  ", p);
 		if (ret)
 			printf("unavailable\n");
 		else
-			printf("0x%08lx\n", entry);
+			printf(PRIpa "\n", entry);
 	}
 
 	/* Process all hash subnodes of the component image node */
@@ -675,11 +677,37 @@ int fit_image_get_comp(const void *fit, int noffset, uint8_t *comp)
 	return 0;
 }
 
+static int fit_image_get_address(const void *fit, int noffset, char *name,
+			  phys_addr_t *load)
+{
+	int len, cell_len;
+	const fdt32_t *cell;
+
+	cell = fdt_getprop(fit, noffset, name, &len);
+	if (cell == NULL) {
+		fit_get_debug(fit, noffset, name, len);
+		return -1;
+	}
+
+	if (len > sizeof(phys_addr_t)) {
+		printf("Unsupported %s address size\n", name);
+		return -1;
+	}
+
+	cell_len = len >> 2;
+	*load = 0;
+	while (cell_len--) {
+		*load = (*load << 32) | uimage_to_cpu(*cell);
+		cell++;
+	}
+
+	return 0;
+}
 /**
  * fit_image_get_load() - get load addr property for given component image node
  * @fit: pointer to the FIT format image header
  * @noffset: component image node offset
- * @load: pointer to the uint32_t, will hold load address
+ * @load: pointer to the phys_addr_t, will hold load address
  *
  * fit_image_get_load() finds load address property in a given component
  * image node. If the property is found, its value is returned to the caller.
@@ -688,26 +716,16 @@ int fit_image_get_comp(const void *fit, int noffset, uint8_t *comp)
  *     0, on success
  *     -1, on failure
  */
-int fit_image_get_load(const void *fit, int noffset, ulong *load)
+int fit_image_get_load(const void *fit, int noffset, phys_addr_t *load)
 {
-	int len;
-	const uint32_t *data;
-
-	data = fdt_getprop(fit, noffset, FIT_LOAD_PROP, &len);
-	if (data == NULL) {
-		fit_get_debug(fit, noffset, FIT_LOAD_PROP, len);
-		return -1;
-	}
-
-	*load = uimage_to_cpu(*data);
-	return 0;
+	return fit_image_get_address(fit, noffset, FIT_LOAD_PROP, load);
 }
 
 /**
  * fit_image_get_entry() - get entry point address property
  * @fit: pointer to the FIT format image header
  * @noffset: component image node offset
- * @entry: pointer to the uint32_t, will hold entry point address
+ * @entry: pointer to the phys_addr_t, will hold entry point address
  *
  * This gets the entry point address property for a given component image
  * node.
@@ -720,19 +738,9 @@ int fit_image_get_load(const void *fit, int noffset, ulong *load)
  *     0, on success
  *     -1, on failure
  */
-int fit_image_get_entry(const void *fit, int noffset, ulong *entry)
+int fit_image_get_entry(const void *fit, int noffset, phys_addr_t *entry)
 {
-	int len;
-	const uint32_t *data;
-
-	data = fdt_getprop(fit, noffset, FIT_ENTRY_PROP, &len);
-	if (data == NULL) {
-		fit_get_debug(fit, noffset, FIT_ENTRY_PROP, len);
-		return -1;
-	}
-
-	*entry = uimage_to_cpu(*data);
-	return 0;
+	return fit_image_get_address(fit, noffset, FIT_ENTRY_PROP, entry);
 }
 
 /**
@@ -1554,7 +1562,7 @@ static const char *fit_get_image_type_property(int type)
 int fit_image_load(bootm_headers_t *images, ulong addr,
 		   const char **fit_unamep, const char **fit_uname_configp,
 		   int arch, int image_type, int bootstage_id,
-		   enum fit_load_op load_op, ulong *datap, ulong *lenp)
+		   enum fit_load_op load_op, phys_addr_t *datap, ulong *lenp)
 {
 	int cfg_noffset, noffset;
 	const char *fit_uname;
@@ -1563,7 +1571,8 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
 	const void *buf;
 	size_t size;
 	int type_ok, os_ok;
-	ulong load, data, len;
+	phys_addr_t load;
+	ulong data, len;
 	uint8_t os;
 	const char *prop_name;
 	int ret;
@@ -1719,7 +1728,7 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
 		}
 	} else if (load_op != FIT_LOAD_OPTIONAL_NON_ZERO || load) {
 		ulong image_start, image_end;
-		ulong load_end;
+		phys_addr_t load_end;
 		void *dst;
 
 		/*
@@ -1736,8 +1745,8 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
 			return -EXDEV;
 		}
 
-		printf("   Loading %s from 0x%08lx to 0x%08lx\n",
-		       prop_name, data, load);
+		printf("   Loading %s from 0x%08lx to %08llx\n",
+		       prop_name, data, (uint64_t)load);
 
 		dst = map_sysmem(load, len);
 		memmove(dst, buf, len);
@@ -1756,7 +1765,7 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
 }
 
 int boot_get_setup_fit(bootm_headers_t *images, uint8_t arch,
-			ulong *setup_start, ulong *setup_len)
+			phys_addr_t *setup_start, ulong *setup_len)
 {
 	int noffset;
 	ulong addr;
diff --git a/include/bootm.h b/include/bootm.h
index 4981377..f280ace 100644
--- a/include/bootm.h
+++ b/include/bootm.h
@@ -69,8 +69,8 @@ void arch_preboot_os(void);
  * @unc_len:	Available space for decompression
  * @return 0 if OK, -ve on error (BOOTM_ERR_...)
  */
-int bootm_decomp_image(int comp, ulong load, ulong image_start, int type,
-		       void *load_buf, void *image_buf, ulong image_len,
-		       uint unc_len, ulong *load_end);
+int bootm_decomp_image(int comp, phys_addr_t load, phys_addr_t image_start,
+		       int type, void *load_buf, void *image_buf,
+		       ulong image_len, uint unc_len, ulong *load_end);
 
 #endif
diff --git a/include/image.h b/include/image.h
index 63c3d37..bc41ecb 100644
--- a/include/image.h
+++ b/include/image.h
@@ -33,11 +33,15 @@ struct lmb;
 #define IMAGE_ENABLE_IGNORE	0
 #define IMAGE_INDENT_STRING	""
 
+/* Be able to hold physical address */
+typedef unsigned long long phys_addr_t;
+
 #else
 
 #include <lmb.h>
 #include <asm/u-boot.h>
 #include <command.h>
+#include <linux/types.h>
 
 /* Take notice of the 'ignore' property for hashes */
 #define IMAGE_ENABLE_IGNORE	1
@@ -494,7 +498,7 @@ int boot_get_loadable(int argc, char * const argv[], bootm_headers_t *images,
 #endif /* !USE_HOSTCC */
 
 int boot_get_setup_fit(bootm_headers_t *images, uint8_t arch,
-		       ulong *setup_start, ulong *setup_len);
+		       phys_addr_t *setup_start, ulong *setup_len);
 
 /**
  * fit_image_load() - load an image from a FIT
@@ -529,7 +533,7 @@ int boot_get_setup_fit(bootm_headers_t *images, uint8_t arch,
 int fit_image_load(bootm_headers_t *images, ulong addr,
 		   const char **fit_unamep, const char **fit_uname_configp,
 		   int arch, int image_type, int bootstage_id,
-		   enum fit_load_op load_op, ulong *datap, ulong *lenp);
+		   enum fit_load_op load_op, phys_addr_t *datap, ulong *lenp);
 
 #ifndef USE_HOSTCC
 /**
@@ -840,8 +844,8 @@ int fit_image_get_os(const void *fit, int noffset, uint8_t *os);
 int fit_image_get_arch(const void *fit, int noffset, uint8_t *arch);
 int fit_image_get_type(const void *fit, int noffset, uint8_t *type);
 int fit_image_get_comp(const void *fit, int noffset, uint8_t *comp);
-int fit_image_get_load(const void *fit, int noffset, ulong *load);
-int fit_image_get_entry(const void *fit, int noffset, ulong *entry);
+int fit_image_get_load(const void *fit, int noffset, phys_addr_t *load);
+int fit_image_get_entry(const void *fit, int noffset, phys_addr_t *entry);
 int fit_image_get_data(const void *fit, int noffset,
 				const void **data, size_t *size);
 
-- 
1.7.9.5

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* [U-Boot] [PATCH v3] common: Fix load and entry addresses in FIT image
  2015-09-04 14:43 [U-Boot] [PATCH v3] common: Fix load and entry addresses in FIT image York Sun
@ 2015-09-09 18:07 ` Simon Glass
  2015-10-18 12:18   ` Simon Glass
  0 siblings, 1 reply; 9+ messages in thread
From: Simon Glass @ 2015-09-09 18:07 UTC (permalink / raw)
  To: u-boot

On Friday, 4 September 2015, York Sun <yorksun@freescale.com> wrote:
>
> FIT image supports more than 32 bits in addresses by using #address-cell
> field. However the address length is not handled when parsing FIT images.
> Beside, the variable used to host address has "ulong" type. It is OK for
> the target, but not always enough for host tools such as mkimage. This
> patch replaces "ulong" with "phys_addr_t" to make sure the address is
> correct for both the target and the host.
>
> Signed-off-by: York Sun <yorksun@freescale.com>
>
> ---
>
> Changes in v3:
>   Define PRIpa for host and target in common/image-fit.c so printf works
>   properly for 32-, 64-bit targets and host tools.
>
> Changes in v2:
>   Make a common function for both load and entry addresses.
>   Simplify calculation of addresses in a similar way as fdtdec_get_number()
>   fdtdec_get_number() is not used, or too many files need to be included
>     and/or twisted for host tool
>   Continue to use %08llx for print format for load and entry addresses
>     because %pa does not always work for host tool (mkimage)
>
>  common/bootm.c     |   13 +++++----
>  common/image-fit.c |   81 +++++++++++++++++++++++++++++-----------------------
>  include/bootm.h    |    6 ++--
>  include/image.h    |   12 +++++---
>  4 files changed, 63 insertions(+), 49 deletions(-)


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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [U-Boot] [PATCH v3] common: Fix load and entry addresses in FIT image
  2015-09-09 18:07 ` Simon Glass
@ 2015-10-18 12:18   ` Simon Glass
  2015-10-18 23:15     ` Simon Glass
  0 siblings, 1 reply; 9+ messages in thread
From: Simon Glass @ 2015-10-18 12:18 UTC (permalink / raw)
  To: u-boot

On 9 September 2015 at 12:07, Simon Glass <sjg@chromium.org> wrote:
>
> On Friday, 4 September 2015, York Sun <yorksun@freescale.com> wrote:
> >
> > FIT image supports more than 32 bits in addresses by using #address-cell
> > field. However the address length is not handled when parsing FIT images.
> > Beside, the variable used to host address has "ulong" type. It is OK for
> > the target, but not always enough for host tools such as mkimage. This
> > patch replaces "ulong" with "phys_addr_t" to make sure the address is
> > correct for both the target and the host.
> >
> > Signed-off-by: York Sun <yorksun@freescale.com>
> >
> > ---
> >
> > Changes in v3:
> >   Define PRIpa for host and target in common/image-fit.c so printf works
> >   properly for 32-, 64-bit targets and host tools.
> >
> > Changes in v2:
> >   Make a common function for both load and entry addresses.
> >   Simplify calculation of addresses in a similar way as fdtdec_get_number()
> >   fdtdec_get_number() is not used, or too many files need to be included
> >     and/or twisted for host tool
> >   Continue to use %08llx for print format for load and entry addresses
> >     because %pa does not always work for host tool (mkimage)
> >
> >  common/bootm.c     |   13 +++++----
> >  common/image-fit.c |   81 +++++++++++++++++++++++++++++-----------------------
> >  include/bootm.h    |    6 ++--
> >  include/image.h    |   12 +++++---
> >  4 files changed, 63 insertions(+), 49 deletions(-)
>

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [U-Boot] [PATCH v3] common: Fix load and entry addresses in FIT image
  2015-10-18 12:18   ` Simon Glass
@ 2015-10-18 23:15     ` Simon Glass
  2015-10-19 17:30       ` York Sun
  0 siblings, 1 reply; 9+ messages in thread
From: Simon Glass @ 2015-10-18 23:15 UTC (permalink / raw)
  To: u-boot

Hi,

On 18 October 2015 at 06:18, Simon Glass <sjg@chromium.org> wrote:
> On 9 September 2015 at 12:07, Simon Glass <sjg@chromium.org> wrote:
>>
>> On Friday, 4 September 2015, York Sun <yorksun@freescale.com> wrote:
>> >
>> > FIT image supports more than 32 bits in addresses by using #address-cell
>> > field. However the address length is not handled when parsing FIT images.
>> > Beside, the variable used to host address has "ulong" type. It is OK for
>> > the target, but not always enough for host tools such as mkimage. This
>> > patch replaces "ulong" with "phys_addr_t" to make sure the address is
>> > correct for both the target and the host.
>> >
>> > Signed-off-by: York Sun <yorksun@freescale.com>
>> >
>> > ---
>> >
>> > Changes in v3:
>> >   Define PRIpa for host and target in common/image-fit.c so printf works
>> >   properly for 32-, 64-bit targets and host tools.
>> >
>> > Changes in v2:
>> >   Make a common function for both load and entry addresses.
>> >   Simplify calculation of addresses in a similar way as fdtdec_get_number()
>> >   fdtdec_get_number() is not used, or too many files need to be included
>> >     and/or twisted for host tool
>> >   Continue to use %08llx for print format for load and entry addresses
>> >     because %pa does not always work for host tool (mkimage)
>> >
>> >  common/bootm.c     |   13 +++++----
>> >  common/image-fit.c |   81 +++++++++++++++++++++++++++++-----------------------
>> >  include/bootm.h    |    6 ++--
>> >  include/image.h    |   12 +++++---
>> >  4 files changed, 63 insertions(+), 49 deletions(-)
>>
>
> Acked-by: Simon Glass <sjg@chromium.org>

Unfortunately this produces lots of warnings on sandbox. Can you
please take a look?

/usr/local/google/c/cosarm/src/third_party/u-boot/files/common/bootm.c:
In function ?bootm_find_os?:
/usr/local/google/c/cosarm/src/third_party/u-boot/files/common/bootm.c:146:12:
warning: passing argument 3 of ?fit_image_get_load? from incompatible
pointer type [enabled by default]
            &images.os.load)) {
            ^
In file included from
/usr/local/google/c/cosarm/src/third_party/u-boot/files/include/common.h:82:0,
                 from
/usr/local/google/c/cosarm/src/third_party/u-boot/files/common/bootm.c:9:
/usr/local/google/c/cosarm/src/third_party/u-boot/files/include/image.h:851:5:
note: expected ?phys_addr_t *? but argument is of type ?ulong *?
 int fit_image_get_load(const void *fit, int noffset, phys_addr_t *load);
     ^

Regards,
Simon

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [U-Boot] [PATCH v3] common: Fix load and entry addresses in FIT image
  2015-10-18 23:15     ` Simon Glass
@ 2015-10-19 17:30       ` York Sun
  2015-10-29 17:16         ` Simon Glass
  0 siblings, 1 reply; 9+ messages in thread
From: York Sun @ 2015-10-19 17:30 UTC (permalink / raw)
  To: u-boot



On 10/18/2015 04:15 PM, Simon Glass wrote:
> Hi,
> 
> On 18 October 2015 at 06:18, Simon Glass <sjg@chromium.org> wrote:
>> On 9 September 2015 at 12:07, Simon Glass <sjg@chromium.org> wrote:
>>>
>>> On Friday, 4 September 2015, York Sun <yorksun@freescale.com> wrote:
>>>>
>>>> FIT image supports more than 32 bits in addresses by using #address-cell
>>>> field. However the address length is not handled when parsing FIT images.
>>>> Beside, the variable used to host address has "ulong" type. It is OK for
>>>> the target, but not always enough for host tools such as mkimage. This
>>>> patch replaces "ulong" with "phys_addr_t" to make sure the address is
>>>> correct for both the target and the host.
>>>>
>>>> Signed-off-by: York Sun <yorksun@freescale.com>
>>>>
>>>> ---
>>>>
>>>> Changes in v3:
>>>>   Define PRIpa for host and target in common/image-fit.c so printf works
>>>>   properly for 32-, 64-bit targets and host tools.
>>>>
>>>> Changes in v2:
>>>>   Make a common function for both load and entry addresses.
>>>>   Simplify calculation of addresses in a similar way as fdtdec_get_number()
>>>>   fdtdec_get_number() is not used, or too many files need to be included
>>>>     and/or twisted for host tool
>>>>   Continue to use %08llx for print format for load and entry addresses
>>>>     because %pa does not always work for host tool (mkimage)
>>>>
>>>>  common/bootm.c     |   13 +++++----
>>>>  common/image-fit.c |   81 +++++++++++++++++++++++++++++-----------------------
>>>>  include/bootm.h    |    6 ++--
>>>>  include/image.h    |   12 +++++---
>>>>  4 files changed, 63 insertions(+), 49 deletions(-)
>>>
>>
>> Acked-by: Simon Glass <sjg@chromium.org>
> 
> Unfortunately this produces lots of warnings on sandbox. Can you
> please take a look?
> 
> /usr/local/google/c/cosarm/src/third_party/u-boot/files/common/bootm.c:
> In function ?bootm_find_os?:
> /usr/local/google/c/cosarm/src/third_party/u-boot/files/common/bootm.c:146:12:
> warning: passing argument 3 of ?fit_image_get_load? from incompatible
> pointer type [enabled by default]
>             &images.os.load)) {
>             ^
> In file included from
> /usr/local/google/c/cosarm/src/third_party/u-boot/files/include/common.h:82:0,
>                  from
> /usr/local/google/c/cosarm/src/third_party/u-boot/files/common/bootm.c:9:
> /usr/local/google/c/cosarm/src/third_party/u-boot/files/include/image.h:851:5:
> note: expected ?phys_addr_t *? but argument is of type ?ulong *?
>  int fit_image_get_load(const void *fit, int noffset, phys_addr_t *load);
>      ^

Simon,

This warning is buried by tons of other warnings when compiling sandbox. I
believe it is caused by the typedef of phys_addr_t for sandbox. How about a fix
like this?

diff --git a/arch/sandbox/include/asm/types.h b/arch/sandbox/include/asm/types.h
index 42c09e2..c3bb76e 100644
--- a/arch/sandbox/include/asm/types.h
+++ b/arch/sandbox/include/asm/types.h
@@ -53,8 +53,8 @@ typedef __UINT64_TYPE__ u64;
 #define BITS_PER_LONG  CONFIG_SANDBOX_BITS_PER_LONG

 typedef unsigned long dma_addr_t;
-typedef u32 phys_addr_t;
-typedef u32 phys_size_t;
+typedef unsigned long phys_addr_t;
+typedef unsigned long phys_size_t;

 #endif /* __KERNEL__ */


York

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* [U-Boot] [PATCH v3] common: Fix load and entry addresses in FIT image
  2015-10-19 17:30       ` York Sun
@ 2015-10-29 17:16         ` Simon Glass
  2015-10-29 17:21           ` York Sun
  0 siblings, 1 reply; 9+ messages in thread
From: Simon Glass @ 2015-10-29 17:16 UTC (permalink / raw)
  To: u-boot

Hi York,

On 19 October 2015 at 11:30, York Sun <yorksun@freescale.com> wrote:
>
>
> On 10/18/2015 04:15 PM, Simon Glass wrote:
>> Hi,
>>
>> On 18 October 2015 at 06:18, Simon Glass <sjg@chromium.org> wrote:
>>> On 9 September 2015 at 12:07, Simon Glass <sjg@chromium.org> wrote:
>>>>
>>>> On Friday, 4 September 2015, York Sun <yorksun@freescale.com> wrote:
>>>>>
>>>>> FIT image supports more than 32 bits in addresses by using #address-cell
>>>>> field. However the address length is not handled when parsing FIT images.
>>>>> Beside, the variable used to host address has "ulong" type. It is OK for
>>>>> the target, but not always enough for host tools such as mkimage. This
>>>>> patch replaces "ulong" with "phys_addr_t" to make sure the address is
>>>>> correct for both the target and the host.
>>>>>
>>>>> Signed-off-by: York Sun <yorksun@freescale.com>
>>>>>
>>>>> ---
>>>>>
>>>>> Changes in v3:
>>>>>   Define PRIpa for host and target in common/image-fit.c so printf works
>>>>>   properly for 32-, 64-bit targets and host tools.
>>>>>
>>>>> Changes in v2:
>>>>>   Make a common function for both load and entry addresses.
>>>>>   Simplify calculation of addresses in a similar way as fdtdec_get_number()
>>>>>   fdtdec_get_number() is not used, or too many files need to be included
>>>>>     and/or twisted for host tool
>>>>>   Continue to use %08llx for print format for load and entry addresses
>>>>>     because %pa does not always work for host tool (mkimage)
>>>>>
>>>>>  common/bootm.c     |   13 +++++----
>>>>>  common/image-fit.c |   81 +++++++++++++++++++++++++++++-----------------------
>>>>>  include/bootm.h    |    6 ++--
>>>>>  include/image.h    |   12 +++++---
>>>>>  4 files changed, 63 insertions(+), 49 deletions(-)
>>>>
>>>
>>> Acked-by: Simon Glass <sjg@chromium.org>
>>
>> Unfortunately this produces lots of warnings on sandbox. Can you
>> please take a look?
>>
>> /usr/local/google/c/cosarm/src/third_party/u-boot/files/common/bootm.c:
>> In function ?bootm_find_os?:
>> /usr/local/google/c/cosarm/src/third_party/u-boot/files/common/bootm.c:146:12:
>> warning: passing argument 3 of ?fit_image_get_load? from incompatible
>> pointer type [enabled by default]
>>             &images.os.load)) {
>>             ^
>> In file included from
>> /usr/local/google/c/cosarm/src/third_party/u-boot/files/include/common.h:82:0,
>>                  from
>> /usr/local/google/c/cosarm/src/third_party/u-boot/files/common/bootm.c:9:
>> /usr/local/google/c/cosarm/src/third_party/u-boot/files/include/image.h:851:5:
>> note: expected ?phys_addr_t *? but argument is of type ?ulong *?
>>  int fit_image_get_load(const void *fit, int noffset, phys_addr_t *load);
>>      ^
>
> Simon,
>
> This warning is buried by tons of other warnings when compiling sandbox. I
> believe it is caused by the typedef of phys_addr_t for sandbox. How about a fix
> like this?
>
> diff --git a/arch/sandbox/include/asm/types.h b/arch/sandbox/include/asm/types.h
> index 42c09e2..c3bb76e 100644
> --- a/arch/sandbox/include/asm/types.h
> +++ b/arch/sandbox/include/asm/types.h
> @@ -53,8 +53,8 @@ typedef __UINT64_TYPE__ u64;
>  #define BITS_PER_LONG  CONFIG_SANDBOX_BITS_PER_LONG
>
>  typedef unsigned long dma_addr_t;
> -typedef u32 phys_addr_t;
> -typedef u32 phys_size_t;
> +typedef unsigned long phys_addr_t;
> +typedef unsigned long phys_size_t;

Sandbox is supposed to use a 32-bit memory model regardless of the
host. What other warnings do you see? I don't see any when I build it.

>
>  #endif /* __KERNEL__ */
>
>
> York

Regards,
Simon

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [U-Boot] [PATCH v3] common: Fix load and entry addresses in FIT image
  2015-10-29 17:16         ` Simon Glass
@ 2015-10-29 17:21           ` York Sun
  2015-11-06 12:06             ` Simon Glass
  0 siblings, 1 reply; 9+ messages in thread
From: York Sun @ 2015-10-29 17:21 UTC (permalink / raw)
  To: u-boot



On 10/29/2015 10:16 AM, Simon Glass wrote:
> Hi York,
> 
> On 19 October 2015 at 11:30, York Sun <yorksun@freescale.com> wrote:
>>
>>
>> On 10/18/2015 04:15 PM, Simon Glass wrote:
>>> Hi,
>>>
>>> On 18 October 2015 at 06:18, Simon Glass <sjg@chromium.org> wrote:
>>>> On 9 September 2015 at 12:07, Simon Glass <sjg@chromium.org> wrote:
>>>>>
>>>>> On Friday, 4 September 2015, York Sun <yorksun@freescale.com> wrote:
>>>>>>
>>>>>> FIT image supports more than 32 bits in addresses by using #address-cell
>>>>>> field. However the address length is not handled when parsing FIT images.
>>>>>> Beside, the variable used to host address has "ulong" type. It is OK for
>>>>>> the target, but not always enough for host tools such as mkimage. This
>>>>>> patch replaces "ulong" with "phys_addr_t" to make sure the address is
>>>>>> correct for both the target and the host.
>>>>>>
>>>>>> Signed-off-by: York Sun <yorksun@freescale.com>
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> Changes in v3:
>>>>>>   Define PRIpa for host and target in common/image-fit.c so printf works
>>>>>>   properly for 32-, 64-bit targets and host tools.
>>>>>>
>>>>>> Changes in v2:
>>>>>>   Make a common function for both load and entry addresses.
>>>>>>   Simplify calculation of addresses in a similar way as fdtdec_get_number()
>>>>>>   fdtdec_get_number() is not used, or too many files need to be included
>>>>>>     and/or twisted for host tool
>>>>>>   Continue to use %08llx for print format for load and entry addresses
>>>>>>     because %pa does not always work for host tool (mkimage)
>>>>>>
>>>>>>  common/bootm.c     |   13 +++++----
>>>>>>  common/image-fit.c |   81 +++++++++++++++++++++++++++++-----------------------
>>>>>>  include/bootm.h    |    6 ++--
>>>>>>  include/image.h    |   12 +++++---
>>>>>>  4 files changed, 63 insertions(+), 49 deletions(-)
>>>>>
>>>>
>>>> Acked-by: Simon Glass <sjg@chromium.org>
>>>
>>> Unfortunately this produces lots of warnings on sandbox. Can you
>>> please take a look?
>>>
>>> /usr/local/google/c/cosarm/src/third_party/u-boot/files/common/bootm.c:
>>> In function ?bootm_find_os?:
>>> /usr/local/google/c/cosarm/src/third_party/u-boot/files/common/bootm.c:146:12:
>>> warning: passing argument 3 of ?fit_image_get_load? from incompatible
>>> pointer type [enabled by default]
>>>             &images.os.load)) {
>>>             ^
>>> In file included from
>>> /usr/local/google/c/cosarm/src/third_party/u-boot/files/include/common.h:82:0,
>>>                  from
>>> /usr/local/google/c/cosarm/src/third_party/u-boot/files/common/bootm.c:9:
>>> /usr/local/google/c/cosarm/src/third_party/u-boot/files/include/image.h:851:5:
>>> note: expected ?phys_addr_t *? but argument is of type ?ulong *?
>>>  int fit_image_get_load(const void *fit, int noffset, phys_addr_t *load);
>>>      ^
>>
>> Simon,
>>
>> This warning is buried by tons of other warnings when compiling sandbox. I
>> believe it is caused by the typedef of phys_addr_t for sandbox. How about a fix
>> like this?
>>
>> diff --git a/arch/sandbox/include/asm/types.h b/arch/sandbox/include/asm/types.h
>> index 42c09e2..c3bb76e 100644
>> --- a/arch/sandbox/include/asm/types.h
>> +++ b/arch/sandbox/include/asm/types.h
>> @@ -53,8 +53,8 @@ typedef __UINT64_TYPE__ u64;
>>  #define BITS_PER_LONG  CONFIG_SANDBOX_BITS_PER_LONG
>>
>>  typedef unsigned long dma_addr_t;
>> -typedef u32 phys_addr_t;
>> -typedef u32 phys_size_t;
>> +typedef unsigned long phys_addr_t;
>> +typedef unsigned long phys_size_t;
> 
> Sandbox is supposed to use a 32-bit memory model regardless of the
> host. What other warnings do you see? I don't see any when I build it.
> 

Maybe I did something wrong. Here is my log

$ make sandbox_defconfig
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/kconfig/conf.o
  SHIPPED scripts/kconfig/zconf.tab.c
  SHIPPED scripts/kconfig/zconf.lex.c
  SHIPPED scripts/kconfig/zconf.hash.c
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
#
# configuration written to .config
#
$ make -s -j8
disk/part_efi.c: In function ?alloc_read_gpt_entries?:
disk/part_efi.c:752:2: warning: format ?%zu? expects argument of type ?size_t?,
but argument 5 has type ?long unsigned int? [-Wformat]
disk/part_efi.c:765:4: warning: format ?%zX? expects argument of type ?size_t?,
but argument 3 has type ?long unsigned int? [-Wformat]
drivers/mtd/spi/sf.c: In function ?spi_flash_read_write?:
drivers/mtd/spi/sf.c:30:3: warning: format ?%zu? expects argument of type
?size_t?, but argument 2 has type ?long unsigned int? [-Wformat]
drivers/mtd/spi/sf.c:36:4: warning: format ?%zu? expects argument of type
?size_t?, but argument 2 has type ?long unsigned int? [-Wformat]
drivers/mtd/spi/sf_ops.c: In function ?spi_flash_cmd_write_ops?:
drivers/mtd/spi/sf_ops.c:343:3: warning: format ?%zu? expects argument of type
?size_t?, but argument 7 has type ?long unsigned int? [-Wformat]
drivers/mtd/spi/sf_ops.c: In function ?sst_write_wp?:
drivers/mtd/spi/sf_ops.c:538:2: warning: format ?%zu? expects argument of type
?size_t?, but argument 3 has type ?long unsigned int? [-Wformat]
drivers/mtd/spi/sf_ops.c:538:2: warning: format ?%zx? expects argument of type
?size_t?, but argument 4 has type ?long unsigned int? [-Wformat]
drivers/mtd/spi/sf_ops.c: In function ?sst_write_bp?:
drivers/mtd/spi/sf_ops.c:569:2: warning: format ?%zu? expects argument of type
?size_t?, but argument 3 has type ?long unsigned int? [-Wformat]
drivers/mtd/spi/sf_ops.c:569:2: warning: format ?%zx? expects argument of type
?size_t?, but argument 4 has type ?long unsigned int? [-Wformat]
drivers/tpm/tpm-uclass.c: In function ?tpm_xfer?:
drivers/tpm/tpm-uclass.c:92:3: warning: format ?%zx? expects argument of type
?size_t?, but argument 3 has type ?long unsigned int? [-Wformat]
drivers/tpm/tpm_tis_sandbox.c: In function ?sandbox_tpm_xfer?:
drivers/tpm/tpm_tis_sandbox.c:152:9: warning: format ?%zd? expects argument of
type ?signed size_t?, but argument 2 has type ?size_t? [-Wformat]
drivers/tpm/tpm_tis_sandbox.c:152:9: warning: format ?%zd? expects argument of
type ?signed size_t?, but argument 3 has type ?size_t? [-Wformat]
common/cmd_pxe.c: In function ?format_mac_pxe?:
common/cmd_pxe.c:68:3: warning: format ?%zd? expects argument of type ?signed
size_t?, but argument 2 has type ?size_t? [-Wformat]
common/cmd_pxe.c: In function ?get_bootfile_path?:
common/cmd_pxe.c:114:5: warning: format ?%zd? expects argument of type ?signed
size_t?, but argument 2 has type ?size_t? [-Wformat]
common/cmd_pxe.c:114:5: warning: format ?%zd? expects argument of type ?signed
size_t?, but argument 3 has type ?size_t? [-Wformat]
common/cmd_pxe.c: In function ?label_boot?:
common/cmd_pxe.c:690:11: warning: format ?%zd? expects argument of type ?signed
size_t?, but argument 2 has type ?__kernel_size_t? [-Wformat]
common/cmd_pxe.c:690:11: warning: format ?%zd? expects argument of type ?signed
size_t?, but argument 3 has type ?__kernel_size_t? [-Wformat]
common/cmd_pxe.c:690:11: warning: format ?%zd? expects argument of type ?signed
size_t?, but argument 4 has type ?__kernel_size_t? [-Wformat]
common/cmd_sf.c: In function ?spi_flash_update_block?:
common/cmd_sf.c:174:2: warning: format ?%zx? expects argument of type ?size_t?,
but argument 4 has type ?long unsigned int? [-Wformat]
common/cmd_sf.c:181:3: warning: format ?%zx? expects argument of type ?size_t?,
but argument 3 has type ?long unsigned int? [-Wformat]
common/cmd_sf.c: In function ?spi_flash_update?:
common/cmd_sf.c:236:9: warning: format ?%zu? expects argument of type ?size_t?,
but argument 2 has type ?long unsigned int? [-Wformat]
common/cmd_sf.c:254:9: warning: format ?%zu? expects argument of type ?size_t?,
but argument 2 has type ?long unsigned int? [-Wformat]
common/cmd_sf.c:254:9: warning: format ?%zu? expects argument of type ?size_t?,
but argument 3 has type ?long unsigned int? [-Wformat]
common/cmd_sf.c: In function ?do_spi_flash_read_write?:
common/cmd_sf.c:307:10: warning: format ?%zu? expects argument of type ?size_t?,
but argument 2 has type ?long unsigned int? [-Wformat]
common/cmd_sf.c: In function ?do_spi_flash_erase?:
common/cmd_sf.c:346:9: warning: format ?%zu? expects argument of type ?size_t?,
but argument 2 has type ?ulong? [-Wformat]
common/cmd_nvedit.c: In function ?do_env_export?:
common/cmd_nvedit.c:929:3: warning: format ?%zX? expects argument of type
?size_t?, but argument 3 has type ?long unsigned int? [-Wformat]
common/cmd_nvedit.c: In function ?do_env_import?:
common/cmd_nvedit.c:1062:3: warning: format ?%zu? expects argument of type
?size_t?, but argument 2 has type ?long unsigned int? [-Wformat]
common/cmd_nvedit.c:1062:3: warning: format ?%zX? expects argument of type
?size_t?, but argument 3 has type ?long unsigned int? [-Wformat]
common/malloc_simple.c: In function ?malloc_simple?:
common/malloc_simple.c:22:2: warning: format ?%zx? expects argument of type
?size_t?, but argument 3 has type ?long unsigned int? [-Wformat]
lib/lzma/LzmaTools.c: In function ?lzmaBuffToBuffDecompress?:
lib/lzma/LzmaTools.c:94:5: warning: format ?%zx? expects argument of type
?size_t?, but argument 2 has type ?SizeT? [-Wformat]
lib/lzma/LzmaTools.c:95:5: warning: format ?%zx? expects argument of type
?size_t?, but argument 2 has type ?SizeT? [-Wformat]
lib/lzma/LzmaTools.c:115:5: warning: format ?%zx? expects argument of type
?size_t?, but argument 2 has type ?SizeT? [-Wformat]
common/cli_simple.c: In function ?cli_simple_process_macros?:
common/cli_simple.c:73:2: warning: format ?%zd? expects argument of type ?signed
size_t?, but argument 2 has type ?__kernel_size_t? [-Wformat]
common/cli_simple.c:162:2: warning: format ?%zd? expects argument of type
?signed size_t?, but argument 2 has type ?__kernel_size_t? [-Wformat]
lib/lz4_wrapper.c: In function ?ulz4fn?:
lib/lz4_wrapper.c:111:18: warning: comparison of distinct pointer types lacks a
cast [enabled by default]
lib/hashtable.c: In function ?hexport_r?:
lib/hashtable.c:605:2: warning: format ?%zu? expects argument of type ?size_t?,
but argument 5 has type ?long unsigned int? [-Wformat]
lib/hashtable.c:661:5: warning: format ?%zu? expects argument of type ?size_t?,
but argument 2 has type ?long unsigned int? [-Wformat]
lib/hashtable.c:661:5: warning: format ?%zu? expects argument of type ?size_t?,
but argument 3 has type ?long unsigned int? [-Wformat]
lib/hashtable.c: In function ?himport_r?:
lib/hashtable.c:793:3: warning: format ?%zu? expects argument of type ?size_t?,
but argument 2 has type ?long unsigned int? [-Wformat]

I don't need to specify ARCH or CROSS_COMPILE to build sandbox, do I?

York

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [U-Boot] [PATCH v3] common: Fix load and entry addresses in FIT image
  2015-10-29 17:21           ` York Sun
@ 2015-11-06 12:06             ` Simon Glass
  2015-11-06 17:14               ` York Sun
  0 siblings, 1 reply; 9+ messages in thread
From: Simon Glass @ 2015-11-06 12:06 UTC (permalink / raw)
  To: u-boot

Hi York,

On 29 October 2015 at 11:21, York Sun <yorksun@freescale.com> wrote:
>
>
> On 10/29/2015 10:16 AM, Simon Glass wrote:
>> Hi York,
>>
>> On 19 October 2015 at 11:30, York Sun <yorksun@freescale.com> wrote:
>>>
>>>
>>> On 10/18/2015 04:15 PM, Simon Glass wrote:
>>>> Hi,
>>>>
>>>> On 18 October 2015 at 06:18, Simon Glass <sjg@chromium.org> wrote:
>>>>> On 9 September 2015 at 12:07, Simon Glass <sjg@chromium.org> wrote:
>>>>>>
>>>>>> On Friday, 4 September 2015, York Sun <yorksun@freescale.com> wrote:
>>>>>>>
>>>>>>> FIT image supports more than 32 bits in addresses by using #address-cell
>>>>>>> field. However the address length is not handled when parsing FIT images.
>>>>>>> Beside, the variable used to host address has "ulong" type. It is OK for
>>>>>>> the target, but not always enough for host tools such as mkimage. This
>>>>>>> patch replaces "ulong" with "phys_addr_t" to make sure the address is
>>>>>>> correct for both the target and the host.
>>>>>>>
>>>>>>> Signed-off-by: York Sun <yorksun@freescale.com>
>>>>>>>
>>>>>>> ---
>>>>>>>
>>>>>>> Changes in v3:
>>>>>>>   Define PRIpa for host and target in common/image-fit.c so printf works
>>>>>>>   properly for 32-, 64-bit targets and host tools.
>>>>>>>
>>>>>>> Changes in v2:
>>>>>>>   Make a common function for both load and entry addresses.
>>>>>>>   Simplify calculation of addresses in a similar way as fdtdec_get_number()
>>>>>>>   fdtdec_get_number() is not used, or too many files need to be included
>>>>>>>     and/or twisted for host tool
>>>>>>>   Continue to use %08llx for print format for load and entry addresses
>>>>>>>     because %pa does not always work for host tool (mkimage)
>>>>>>>
>>>>>>>  common/bootm.c     |   13 +++++----
>>>>>>>  common/image-fit.c |   81 +++++++++++++++++++++++++++++-----------------------
>>>>>>>  include/bootm.h    |    6 ++--
>>>>>>>  include/image.h    |   12 +++++---
>>>>>>>  4 files changed, 63 insertions(+), 49 deletions(-)
>>>>>>
>>>>>
>>>>> Acked-by: Simon Glass <sjg@chromium.org>
>>>>
>>>> Unfortunately this produces lots of warnings on sandbox. Can you
>>>> please take a look?
>>>>
>>>> /usr/local/google/c/cosarm/src/third_party/u-boot/files/common/bootm.c:
>>>> In function ?bootm_find_os?:
>>>> /usr/local/google/c/cosarm/src/third_party/u-boot/files/common/bootm.c:146:12:
>>>> warning: passing argument 3 of ?fit_image_get_load? from incompatible
>>>> pointer type [enabled by default]
>>>>             &images.os.load)) {
>>>>             ^
>>>> In file included from
>>>> /usr/local/google/c/cosarm/src/third_party/u-boot/files/include/common.h:82:0,
>>>>                  from
>>>> /usr/local/google/c/cosarm/src/third_party/u-boot/files/common/bootm.c:9:
>>>> /usr/local/google/c/cosarm/src/third_party/u-boot/files/include/image.h:851:5:
>>>> note: expected ?phys_addr_t *? but argument is of type ?ulong *?
>>>>  int fit_image_get_load(const void *fit, int noffset, phys_addr_t *load);
>>>>      ^
>>>
>>> Simon,
>>>
>>> This warning is buried by tons of other warnings when compiling sandbox. I
>>> believe it is caused by the typedef of phys_addr_t for sandbox. How about a fix
>>> like this?
>>>
>>> diff --git a/arch/sandbox/include/asm/types.h b/arch/sandbox/include/asm/types.h
>>> index 42c09e2..c3bb76e 100644
>>> --- a/arch/sandbox/include/asm/types.h
>>> +++ b/arch/sandbox/include/asm/types.h
>>> @@ -53,8 +53,8 @@ typedef __UINT64_TYPE__ u64;
>>>  #define BITS_PER_LONG  CONFIG_SANDBOX_BITS_PER_LONG
>>>
>>>  typedef unsigned long dma_addr_t;
>>> -typedef u32 phys_addr_t;
>>> -typedef u32 phys_size_t;
>>> +typedef unsigned long phys_addr_t;
>>> +typedef unsigned long phys_size_t;
>>
>> Sandbox is supposed to use a 32-bit memory model regardless of the
>> host. What other warnings do you see? I don't see any when I build it.
>>
>
> Maybe I did something wrong. Here is my log
>
> $ make sandbox_defconfig
>   HOSTCC  scripts/basic/fixdep
>   HOSTCC  scripts/kconfig/conf.o
>   SHIPPED scripts/kconfig/zconf.tab.c
>   SHIPPED scripts/kconfig/zconf.lex.c
>   SHIPPED scripts/kconfig/zconf.hash.c
>   HOSTCC  scripts/kconfig/zconf.tab.o
>   HOSTLD  scripts/kconfig/conf
> #
> # configuration written to .config
> #
> $ make -s -j8
> disk/part_efi.c: In function ?alloc_read_gpt_entries?:
> disk/part_efi.c:752:2: warning: format ?%zu? expects argument of type ?size_t?,
> but argument 5 has type ?long unsigned int? [-Wformat]
> disk/part_efi.c:765:4: warning: format ?%zX? expects argument of type ?size_t?,
> but argument 3 has type ?long unsigned int? [-Wformat]
> drivers/mtd/spi/sf.c: In function ?spi_flash_read_write?:
> drivers/mtd/spi/sf.c:30:3: warning: format ?%zu? expects argument of type
> ?size_t?, but argument 2 has type ?long unsigned int? [-Wformat]
> drivers/mtd/spi/sf.c:36:4: warning: format ?%zu? expects argument of type
> ?size_t?, but argument 2 has type ?long unsigned int? [-Wformat]
> drivers/mtd/spi/sf_ops.c: In function ?spi_flash_cmd_write_ops?:
> drivers/mtd/spi/sf_ops.c:343:3: warning: format ?%zu? expects argument of type
> ?size_t?, but argument 7 has type ?long unsigned int? [-Wformat]
> drivers/mtd/spi/sf_ops.c: In function ?sst_write_wp?:
> drivers/mtd/spi/sf_ops.c:538:2: warning: format ?%zu? expects argument of type
> ?size_t?, but argument 3 has type ?long unsigned int? [-Wformat]
> drivers/mtd/spi/sf_ops.c:538:2: warning: format ?%zx? expects argument of type
> ?size_t?, but argument 4 has type ?long unsigned int? [-Wformat]
> drivers/mtd/spi/sf_ops.c: In function ?sst_write_bp?:
> drivers/mtd/spi/sf_ops.c:569:2: warning: format ?%zu? expects argument of type
> ?size_t?, but argument 3 has type ?long unsigned int? [-Wformat]
> drivers/mtd/spi/sf_ops.c:569:2: warning: format ?%zx? expects argument of type
> ?size_t?, but argument 4 has type ?long unsigned int? [-Wformat]
> drivers/tpm/tpm-uclass.c: In function ?tpm_xfer?:
> drivers/tpm/tpm-uclass.c:92:3: warning: format ?%zx? expects argument of type
> ?size_t?, but argument 3 has type ?long unsigned int? [-Wformat]
> drivers/tpm/tpm_tis_sandbox.c: In function ?sandbox_tpm_xfer?:
> drivers/tpm/tpm_tis_sandbox.c:152:9: warning: format ?%zd? expects argument of
> type ?signed size_t?, but argument 2 has type ?size_t? [-Wformat]
> drivers/tpm/tpm_tis_sandbox.c:152:9: warning: format ?%zd? expects argument of
> type ?signed size_t?, but argument 3 has type ?size_t? [-Wformat]
> common/cmd_pxe.c: In function ?format_mac_pxe?:
> common/cmd_pxe.c:68:3: warning: format ?%zd? expects argument of type ?signed
> size_t?, but argument 2 has type ?size_t? [-Wformat]
> common/cmd_pxe.c: In function ?get_bootfile_path?:
> common/cmd_pxe.c:114:5: warning: format ?%zd? expects argument of type ?signed
> size_t?, but argument 2 has type ?size_t? [-Wformat]
> common/cmd_pxe.c:114:5: warning: format ?%zd? expects argument of type ?signed
> size_t?, but argument 3 has type ?size_t? [-Wformat]
> common/cmd_pxe.c: In function ?label_boot?:
> common/cmd_pxe.c:690:11: warning: format ?%zd? expects argument of type ?signed
> size_t?, but argument 2 has type ?__kernel_size_t? [-Wformat]
> common/cmd_pxe.c:690:11: warning: format ?%zd? expects argument of type ?signed
> size_t?, but argument 3 has type ?__kernel_size_t? [-Wformat]
> common/cmd_pxe.c:690:11: warning: format ?%zd? expects argument of type ?signed
> size_t?, but argument 4 has type ?__kernel_size_t? [-Wformat]
> common/cmd_sf.c: In function ?spi_flash_update_block?:
> common/cmd_sf.c:174:2: warning: format ?%zx? expects argument of type ?size_t?,
> but argument 4 has type ?long unsigned int? [-Wformat]
> common/cmd_sf.c:181:3: warning: format ?%zx? expects argument of type ?size_t?,
> but argument 3 has type ?long unsigned int? [-Wformat]
> common/cmd_sf.c: In function ?spi_flash_update?:
> common/cmd_sf.c:236:9: warning: format ?%zu? expects argument of type ?size_t?,
> but argument 2 has type ?long unsigned int? [-Wformat]
> common/cmd_sf.c:254:9: warning: format ?%zu? expects argument of type ?size_t?,
> but argument 2 has type ?long unsigned int? [-Wformat]
> common/cmd_sf.c:254:9: warning: format ?%zu? expects argument of type ?size_t?,
> but argument 3 has type ?long unsigned int? [-Wformat]
> common/cmd_sf.c: In function ?do_spi_flash_read_write?:
> common/cmd_sf.c:307:10: warning: format ?%zu? expects argument of type ?size_t?,
> but argument 2 has type ?long unsigned int? [-Wformat]
> common/cmd_sf.c: In function ?do_spi_flash_erase?:
> common/cmd_sf.c:346:9: warning: format ?%zu? expects argument of type ?size_t?,
> but argument 2 has type ?ulong? [-Wformat]
> common/cmd_nvedit.c: In function ?do_env_export?:
> common/cmd_nvedit.c:929:3: warning: format ?%zX? expects argument of type
> ?size_t?, but argument 3 has type ?long unsigned int? [-Wformat]
> common/cmd_nvedit.c: In function ?do_env_import?:
> common/cmd_nvedit.c:1062:3: warning: format ?%zu? expects argument of type
> ?size_t?, but argument 2 has type ?long unsigned int? [-Wformat]
> common/cmd_nvedit.c:1062:3: warning: format ?%zX? expects argument of type
> ?size_t?, but argument 3 has type ?long unsigned int? [-Wformat]
> common/malloc_simple.c: In function ?malloc_simple?:
> common/malloc_simple.c:22:2: warning: format ?%zx? expects argument of type
> ?size_t?, but argument 3 has type ?long unsigned int? [-Wformat]
> lib/lzma/LzmaTools.c: In function ?lzmaBuffToBuffDecompress?:
> lib/lzma/LzmaTools.c:94:5: warning: format ?%zx? expects argument of type
> ?size_t?, but argument 2 has type ?SizeT? [-Wformat]
> lib/lzma/LzmaTools.c:95:5: warning: format ?%zx? expects argument of type
> ?size_t?, but argument 2 has type ?SizeT? [-Wformat]
> lib/lzma/LzmaTools.c:115:5: warning: format ?%zx? expects argument of type
> ?size_t?, but argument 2 has type ?SizeT? [-Wformat]
> common/cli_simple.c: In function ?cli_simple_process_macros?:
> common/cli_simple.c:73:2: warning: format ?%zd? expects argument of type ?signed
> size_t?, but argument 2 has type ?__kernel_size_t? [-Wformat]
> common/cli_simple.c:162:2: warning: format ?%zd? expects argument of type
> ?signed size_t?, but argument 2 has type ?__kernel_size_t? [-Wformat]
> lib/lz4_wrapper.c: In function ?ulz4fn?:
> lib/lz4_wrapper.c:111:18: warning: comparison of distinct pointer types lacks a
> cast [enabled by default]
> lib/hashtable.c: In function ?hexport_r?:
> lib/hashtable.c:605:2: warning: format ?%zu? expects argument of type ?size_t?,
> but argument 5 has type ?long unsigned int? [-Wformat]
> lib/hashtable.c:661:5: warning: format ?%zu? expects argument of type ?size_t?,
> but argument 2 has type ?long unsigned int? [-Wformat]
> lib/hashtable.c:661:5: warning: format ?%zu? expects argument of type ?size_t?,
> but argument 3 has type ?long unsigned int? [-Wformat]
> lib/hashtable.c: In function ?himport_r?:
> lib/hashtable.c:793:3: warning: format ?%zu? expects argument of type ?size_t?,
> but argument 2 has type ?long unsigned int? [-Wformat]
>
> I don't need to specify ARCH or CROSS_COMPILE to build sandbox, do I?

No. I just tried the same procedure and get no warnings. I am using a
64-bit Ubuntu machine. What kind of platform are you using?

Regards,
Simon

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [U-Boot] [PATCH v3] common: Fix load and entry addresses in FIT image
  2015-11-06 12:06             ` Simon Glass
@ 2015-11-06 17:14               ` York Sun
  0 siblings, 0 replies; 9+ messages in thread
From: York Sun @ 2015-11-06 17:14 UTC (permalink / raw)
  To: u-boot



On 11/06/2015 04:06 AM, Simon Glass wrote:
> Hi York,
> 
> On 29 October 2015 at 11:21, York Sun <yorksun@freescale.com> wrote:
>>
>>
>> On 10/29/2015 10:16 AM, Simon Glass wrote:
>>> Hi York,
>>>
>>> On 19 October 2015 at 11:30, York Sun <yorksun@freescale.com> wrote:
>>>>
>>>>
>>>> On 10/18/2015 04:15 PM, Simon Glass wrote:
>>>>> Hi,
>>>>>
>>>>> On 18 October 2015 at 06:18, Simon Glass <sjg@chromium.org> wrote:
>>>>>> On 9 September 2015 at 12:07, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>
>>>>>>> On Friday, 4 September 2015, York Sun <yorksun@freescale.com> wrote:
>>>>>>>>
>>>>>>>> FIT image supports more than 32 bits in addresses by using #address-cell
>>>>>>>> field. However the address length is not handled when parsing FIT images.
>>>>>>>> Beside, the variable used to host address has "ulong" type. It is OK for
>>>>>>>> the target, but not always enough for host tools such as mkimage. This
>>>>>>>> patch replaces "ulong" with "phys_addr_t" to make sure the address is
>>>>>>>> correct for both the target and the host.
>>>>>>>>
>>>>>>>> Signed-off-by: York Sun <yorksun@freescale.com>
>>>>>>>>
>>>>>>>> ---
>>>>>>>>
>>>>>>>> Changes in v3:
>>>>>>>>   Define PRIpa for host and target in common/image-fit.c so printf works
>>>>>>>>   properly for 32-, 64-bit targets and host tools.
>>>>>>>>
>>>>>>>> Changes in v2:
>>>>>>>>   Make a common function for both load and entry addresses.
>>>>>>>>   Simplify calculation of addresses in a similar way as fdtdec_get_number()
>>>>>>>>   fdtdec_get_number() is not used, or too many files need to be included
>>>>>>>>     and/or twisted for host tool
>>>>>>>>   Continue to use %08llx for print format for load and entry addresses
>>>>>>>>     because %pa does not always work for host tool (mkimage)
>>>>>>>>
>>>>>>>>  common/bootm.c     |   13 +++++----
>>>>>>>>  common/image-fit.c |   81 +++++++++++++++++++++++++++++-----------------------
>>>>>>>>  include/bootm.h    |    6 ++--
>>>>>>>>  include/image.h    |   12 +++++---
>>>>>>>>  4 files changed, 63 insertions(+), 49 deletions(-)
>>>>>>>
>>>>>>
>>>>>> Acked-by: Simon Glass <sjg@chromium.org>
>>>>>
>>>>> Unfortunately this produces lots of warnings on sandbox. Can you
>>>>> please take a look?
>>>>>
>>>>> /usr/local/google/c/cosarm/src/third_party/u-boot/files/common/bootm.c:
>>>>> In function ?bootm_find_os?:
>>>>> /usr/local/google/c/cosarm/src/third_party/u-boot/files/common/bootm.c:146:12:
>>>>> warning: passing argument 3 of ?fit_image_get_load? from incompatible
>>>>> pointer type [enabled by default]
>>>>>             &images.os.load)) {
>>>>>             ^
>>>>> In file included from
>>>>> /usr/local/google/c/cosarm/src/third_party/u-boot/files/include/common.h:82:0,
>>>>>                  from
>>>>> /usr/local/google/c/cosarm/src/third_party/u-boot/files/common/bootm.c:9:
>>>>> /usr/local/google/c/cosarm/src/third_party/u-boot/files/include/image.h:851:5:
>>>>> note: expected ?phys_addr_t *? but argument is of type ?ulong *?
>>>>>  int fit_image_get_load(const void *fit, int noffset, phys_addr_t *load);
>>>>>      ^
>>>>
>>>> Simon,
>>>>
>>>> This warning is buried by tons of other warnings when compiling sandbox. I
>>>> believe it is caused by the typedef of phys_addr_t for sandbox. How about a fix
>>>> like this?
>>>>
>>>> diff --git a/arch/sandbox/include/asm/types.h b/arch/sandbox/include/asm/types.h
>>>> index 42c09e2..c3bb76e 100644
>>>> --- a/arch/sandbox/include/asm/types.h
>>>> +++ b/arch/sandbox/include/asm/types.h
>>>> @@ -53,8 +53,8 @@ typedef __UINT64_TYPE__ u64;
>>>>  #define BITS_PER_LONG  CONFIG_SANDBOX_BITS_PER_LONG
>>>>
>>>>  typedef unsigned long dma_addr_t;
>>>> -typedef u32 phys_addr_t;
>>>> -typedef u32 phys_size_t;
>>>> +typedef unsigned long phys_addr_t;
>>>> +typedef unsigned long phys_size_t;
>>>
>>> Sandbox is supposed to use a 32-bit memory model regardless of the
>>> host. What other warnings do you see? I don't see any when I build it.
>>>
>>
>> Maybe I did something wrong. Here is my log
>>
>> $ make sandbox_defconfig
>>   HOSTCC  scripts/basic/fixdep
>>   HOSTCC  scripts/kconfig/conf.o
>>   SHIPPED scripts/kconfig/zconf.tab.c
>>   SHIPPED scripts/kconfig/zconf.lex.c
>>   SHIPPED scripts/kconfig/zconf.hash.c
>>   HOSTCC  scripts/kconfig/zconf.tab.o
>>   HOSTLD  scripts/kconfig/conf
>> #
>> # configuration written to .config
>> #
>> $ make -s -j8
>> disk/part_efi.c: In function ?alloc_read_gpt_entries?:
>> disk/part_efi.c:752:2: warning: format ?%zu? expects argument of type ?size_t?,
>> but argument 5 has type ?long unsigned int? [-Wformat]
>> disk/part_efi.c:765:4: warning: format ?%zX? expects argument of type ?size_t?,
>> but argument 3 has type ?long unsigned int? [-Wformat]
>> drivers/mtd/spi/sf.c: In function ?spi_flash_read_write?:
>> drivers/mtd/spi/sf.c:30:3: warning: format ?%zu? expects argument of type
>> ?size_t?, but argument 2 has type ?long unsigned int? [-Wformat]
>> drivers/mtd/spi/sf.c:36:4: warning: format ?%zu? expects argument of type
>> ?size_t?, but argument 2 has type ?long unsigned int? [-Wformat]
>> drivers/mtd/spi/sf_ops.c: In function ?spi_flash_cmd_write_ops?:
>> drivers/mtd/spi/sf_ops.c:343:3: warning: format ?%zu? expects argument of type
>> ?size_t?, but argument 7 has type ?long unsigned int? [-Wformat]
>> drivers/mtd/spi/sf_ops.c: In function ?sst_write_wp?:
>> drivers/mtd/spi/sf_ops.c:538:2: warning: format ?%zu? expects argument of type
>> ?size_t?, but argument 3 has type ?long unsigned int? [-Wformat]
>> drivers/mtd/spi/sf_ops.c:538:2: warning: format ?%zx? expects argument of type
>> ?size_t?, but argument 4 has type ?long unsigned int? [-Wformat]
>> drivers/mtd/spi/sf_ops.c: In function ?sst_write_bp?:
>> drivers/mtd/spi/sf_ops.c:569:2: warning: format ?%zu? expects argument of type
>> ?size_t?, but argument 3 has type ?long unsigned int? [-Wformat]
>> drivers/mtd/spi/sf_ops.c:569:2: warning: format ?%zx? expects argument of type
>> ?size_t?, but argument 4 has type ?long unsigned int? [-Wformat]
>> drivers/tpm/tpm-uclass.c: In function ?tpm_xfer?:
>> drivers/tpm/tpm-uclass.c:92:3: warning: format ?%zx? expects argument of type
>> ?size_t?, but argument 3 has type ?long unsigned int? [-Wformat]
>> drivers/tpm/tpm_tis_sandbox.c: In function ?sandbox_tpm_xfer?:
>> drivers/tpm/tpm_tis_sandbox.c:152:9: warning: format ?%zd? expects argument of
>> type ?signed size_t?, but argument 2 has type ?size_t? [-Wformat]
>> drivers/tpm/tpm_tis_sandbox.c:152:9: warning: format ?%zd? expects argument of
>> type ?signed size_t?, but argument 3 has type ?size_t? [-Wformat]
>> common/cmd_pxe.c: In function ?format_mac_pxe?:
>> common/cmd_pxe.c:68:3: warning: format ?%zd? expects argument of type ?signed
>> size_t?, but argument 2 has type ?size_t? [-Wformat]
>> common/cmd_pxe.c: In function ?get_bootfile_path?:
>> common/cmd_pxe.c:114:5: warning: format ?%zd? expects argument of type ?signed
>> size_t?, but argument 2 has type ?size_t? [-Wformat]
>> common/cmd_pxe.c:114:5: warning: format ?%zd? expects argument of type ?signed
>> size_t?, but argument 3 has type ?size_t? [-Wformat]
>> common/cmd_pxe.c: In function ?label_boot?:
>> common/cmd_pxe.c:690:11: warning: format ?%zd? expects argument of type ?signed
>> size_t?, but argument 2 has type ?__kernel_size_t? [-Wformat]
>> common/cmd_pxe.c:690:11: warning: format ?%zd? expects argument of type ?signed
>> size_t?, but argument 3 has type ?__kernel_size_t? [-Wformat]
>> common/cmd_pxe.c:690:11: warning: format ?%zd? expects argument of type ?signed
>> size_t?, but argument 4 has type ?__kernel_size_t? [-Wformat]
>> common/cmd_sf.c: In function ?spi_flash_update_block?:
>> common/cmd_sf.c:174:2: warning: format ?%zx? expects argument of type ?size_t?,
>> but argument 4 has type ?long unsigned int? [-Wformat]
>> common/cmd_sf.c:181:3: warning: format ?%zx? expects argument of type ?size_t?,
>> but argument 3 has type ?long unsigned int? [-Wformat]
>> common/cmd_sf.c: In function ?spi_flash_update?:
>> common/cmd_sf.c:236:9: warning: format ?%zu? expects argument of type ?size_t?,
>> but argument 2 has type ?long unsigned int? [-Wformat]
>> common/cmd_sf.c:254:9: warning: format ?%zu? expects argument of type ?size_t?,
>> but argument 2 has type ?long unsigned int? [-Wformat]
>> common/cmd_sf.c:254:9: warning: format ?%zu? expects argument of type ?size_t?,
>> but argument 3 has type ?long unsigned int? [-Wformat]
>> common/cmd_sf.c: In function ?do_spi_flash_read_write?:
>> common/cmd_sf.c:307:10: warning: format ?%zu? expects argument of type ?size_t?,
>> but argument 2 has type ?long unsigned int? [-Wformat]
>> common/cmd_sf.c: In function ?do_spi_flash_erase?:
>> common/cmd_sf.c:346:9: warning: format ?%zu? expects argument of type ?size_t?,
>> but argument 2 has type ?ulong? [-Wformat]
>> common/cmd_nvedit.c: In function ?do_env_export?:
>> common/cmd_nvedit.c:929:3: warning: format ?%zX? expects argument of type
>> ?size_t?, but argument 3 has type ?long unsigned int? [-Wformat]
>> common/cmd_nvedit.c: In function ?do_env_import?:
>> common/cmd_nvedit.c:1062:3: warning: format ?%zu? expects argument of type
>> ?size_t?, but argument 2 has type ?long unsigned int? [-Wformat]
>> common/cmd_nvedit.c:1062:3: warning: format ?%zX? expects argument of type
>> ?size_t?, but argument 3 has type ?long unsigned int? [-Wformat]
>> common/malloc_simple.c: In function ?malloc_simple?:
>> common/malloc_simple.c:22:2: warning: format ?%zx? expects argument of type
>> ?size_t?, but argument 3 has type ?long unsigned int? [-Wformat]
>> lib/lzma/LzmaTools.c: In function ?lzmaBuffToBuffDecompress?:
>> lib/lzma/LzmaTools.c:94:5: warning: format ?%zx? expects argument of type
>> ?size_t?, but argument 2 has type ?SizeT? [-Wformat]
>> lib/lzma/LzmaTools.c:95:5: warning: format ?%zx? expects argument of type
>> ?size_t?, but argument 2 has type ?SizeT? [-Wformat]
>> lib/lzma/LzmaTools.c:115:5: warning: format ?%zx? expects argument of type
>> ?size_t?, but argument 2 has type ?SizeT? [-Wformat]
>> common/cli_simple.c: In function ?cli_simple_process_macros?:
>> common/cli_simple.c:73:2: warning: format ?%zd? expects argument of type ?signed
>> size_t?, but argument 2 has type ?__kernel_size_t? [-Wformat]
>> common/cli_simple.c:162:2: warning: format ?%zd? expects argument of type
>> ?signed size_t?, but argument 2 has type ?__kernel_size_t? [-Wformat]
>> lib/lz4_wrapper.c: In function ?ulz4fn?:
>> lib/lz4_wrapper.c:111:18: warning: comparison of distinct pointer types lacks a
>> cast [enabled by default]
>> lib/hashtable.c: In function ?hexport_r?:
>> lib/hashtable.c:605:2: warning: format ?%zu? expects argument of type ?size_t?,
>> but argument 5 has type ?long unsigned int? [-Wformat]
>> lib/hashtable.c:661:5: warning: format ?%zu? expects argument of type ?size_t?,
>> but argument 2 has type ?long unsigned int? [-Wformat]
>> lib/hashtable.c:661:5: warning: format ?%zu? expects argument of type ?size_t?,
>> but argument 3 has type ?long unsigned int? [-Wformat]
>> lib/hashtable.c: In function ?himport_r?:
>> lib/hashtable.c:793:3: warning: format ?%zu? expects argument of type ?size_t?,
>> but argument 2 has type ?long unsigned int? [-Wformat]
>>
>> I don't need to specify ARCH or CROSS_COMPILE to build sandbox, do I?
> 
> No. I just tried the same procedure and get no warnings. I am using a
> 64-bit Ubuntu machine. What kind of platform are you using?

I am using 32-bit Ubuntu.

York

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2015-11-06 17:14 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-09-04 14:43 [U-Boot] [PATCH v3] common: Fix load and entry addresses in FIT image York Sun
2015-09-09 18:07 ` Simon Glass
2015-10-18 12:18   ` Simon Glass
2015-10-18 23:15     ` Simon Glass
2015-10-19 17:30       ` York Sun
2015-10-29 17:16         ` Simon Glass
2015-10-29 17:21           ` York Sun
2015-11-06 12:06             ` Simon Glass
2015-11-06 17:14               ` York Sun

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.