[U-Boot] [PATCH 0/10] Provide inttypes.h to avoid 32/64 bit problems with printf()

[U-Boot] [PATCH 0/10] Provide inttypes.h to avoid 32/64 bit problems with printf()

[Simon Glass]

In quite a few situations we have to print a 64-bit value. Unfortunately
the type used for 64-bit can vary depending on the machine. For 64-bit
machines it might be 'long' and for 32-bit machines it might be
'long long'.

As a result we need to use either %ld or %lld depending on the architecture.
Add the inttypes.h header file to provide defines for this and clean up the
code to use these defines in a few places.

The stdint.h file is bundled with recent versions of gcc and it is generally
better to use this rather than our own versions. Add an option to use the
internal stdint.h file.


Gabe Black (2):
  Provide option to avoid defining a custom version of uintptr_t.
  Add some standard headers external code might need

Simon Glass (8):
  ext4: Use inttypes for printf() string
  Use uint64_t for time types
  Use uint64_t instead of u64 in put_dec()
  Tidy up data sizes and function comment in display_options
  x86: Use correct printf() format string for uintptr_t
  scsi: Use correct printf() format string for uintptr_t
  usb: Use correct printf() format string for uintptr_t
  test: Add a simple test to detected warnings with uint64_t, uintptr_t

 README                           |   5 +
 arch/sandbox/include/asm/types.h |   5 +
 arch/x86/include/asm/types.h     |   5 +
 arch/x86/lib/relocate.c          |   3 +-
 common/cmd_scsi.c                |   9 +-
 common/usb_storage.c             |  11 +-
 config.mk                        |   5 +
 fs/ext4/ext4_common.c            |   3 +-
 include/common.h                 |  19 ++-
 include/compiler.h               |  11 +-
 include/inttypes.h               | 287 +++++++++++++++++++++++++++++++++++++++
 include/linux/types.h            |   9 +-
 include/stdlib.h                 |  12 ++
 lib/display_options.c            |  14 +-
 lib/time.c                       |  12 +-
 lib/vsprintf.c                   |   2 +-
 test/stdint/int-types.c          |  13 ++
 test/stdint/test-includes.sh     |  58 ++++++++
 18 files changed, 450 insertions(+), 33 deletions(-)
 create mode 100644 include/inttypes.h
 create mode 100644 include/stdlib.h
 create mode 100644 test/stdint/int-types.c
 create mode 100755 test/stdint/test-includes.sh

-- 
2.1.0.rc2.206.gedb03e5

[U-Boot] [PATCH 01/10] Provide option to avoid defining a custom version of uintptr_t.

[Simon Glass]

From: Gabe Black <gabeblack@chromium.org>

There's a definition in stdint.h (provided by gcc) which will be more correct
if available.

Define CONFIG_USE_STDINT to use this feature, or USE_STDINT=1 on the 'make'
commmand.

This adjusts the settings for x86 and sandbox, with both have 64-bit options.

Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@google.com>
Rewritten to be an option, since stdint.h is often available only in glibc.
Changed to preserve a clear boundary between stdint and non-stdint
Signed-off-by: Simon Glass <sjg@chromium.org>

---

 README                           |  5 +++++
 arch/sandbox/include/asm/types.h |  5 +++++
 arch/x86/include/asm/types.h     |  5 +++++
 config.mk                        |  5 +++++
 include/compiler.h               | 11 ++++++++---
 include/linux/types.h            |  9 ++++++++-
 6 files changed, 36 insertions(+), 4 deletions(-)

diff --git a/README b/README
index 6ecb3e0..72e8db9 100644
--- a/README
+++ b/README
@@ -4055,6 +4055,11 @@ Configuration Settings:
 	be asserted. See doc/README.omap-reset-time for details on how
 	the value can be calulated on a given board.
 
+- CONFIG_USE_STDINT
+	If stdint.h is available with your toolchain you can define this
+	option to enable it. You can provide option 'USE_STDINT=1' when
+	building U-Boot to enable this.
+
 The following definitions that deal with the placement and management
 of environment data (variable area); in general, we support the
 following configurations:
diff --git a/arch/sandbox/include/asm/types.h b/arch/sandbox/include/asm/types.h
index 6d3eb1f..42c09e2 100644
--- a/arch/sandbox/include/asm/types.h
+++ b/arch/sandbox/include/asm/types.h
@@ -42,8 +42,13 @@ typedef unsigned short u16;
 typedef signed int s32;
 typedef unsigned int u32;
 
+#if !defined(CONFIG_USE_STDINT) || !defined(__INT64_TYPE__)
 typedef signed long long s64;
 typedef unsigned long long u64;
+#else
+typedef __INT64_TYPE__ s64;
+typedef __UINT64_TYPE__ u64;
+#endif
 
 #define BITS_PER_LONG	CONFIG_SANDBOX_BITS_PER_LONG
 
diff --git a/arch/x86/include/asm/types.h b/arch/x86/include/asm/types.h
index e9fde88..e272c90 100644
--- a/arch/x86/include/asm/types.h
+++ b/arch/x86/include/asm/types.h
@@ -36,8 +36,13 @@ typedef unsigned short u16;
 typedef signed int s32;
 typedef unsigned int u32;
 
+#if !defined(CONFIG_USE_STDINT) || !defined(__INT64_TYPE__)
 typedef signed long long s64;
 typedef unsigned long long u64;
+#else
+typedef __INT64_TYPE__ s64;
+typedef __UINT64_TYPE__ u64;
+#endif
 
 #define BITS_PER_LONG 32
 
diff --git a/config.mk b/config.mk
index 2157537..1ddfdbb 100644
--- a/config.mk
+++ b/config.mk
@@ -57,6 +57,11 @@ ifdef FTRACE
 PLATFORM_CPPFLAGS += -finstrument-functions -DFTRACE
 endif
 
+# Allow use of stdint.h if available
+ifneq ($(USE_STDINT),)
+PLATFORM_CPPFLAGS += -DCONFIG_USE_STDINT
+endif
+
 #########################################################################
 
 RELFLAGS := $(PLATFORM_RELFLAGS)
diff --git a/include/compiler.h b/include/compiler.h
index 2103602..47c296e 100644
--- a/include/compiler.h
+++ b/include/compiler.h
@@ -112,6 +112,14 @@ typedef unsigned int uint;
 
 #else /* !USE_HOSTCC */
 
+#ifdef CONFIG_USE_STDINT
+/* Provided by gcc. */
+#include <stdint.h>
+#else
+/* Type for `void *' pointers. */
+typedef unsigned long int uintptr_t;
+#endif
+
 #include <linux/string.h>
 #include <linux/types.h>
 #include <asm/byteorder.h>
@@ -128,9 +136,6 @@ typedef unsigned int uint;
 #define __WORDSIZE	32
 #endif
 
-/* Type for `void *' pointers. */
-typedef unsigned long int uintptr_t;
-
 #endif /* USE_HOSTCC */
 
 #define likely(x)	__builtin_expect(!!(x), 1)
diff --git a/include/linux/types.h b/include/linux/types.h
index 9aebc4e..c9a8d9a 100644
--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -104,7 +104,8 @@ typedef		__u8		uint8_t;
 typedef		__u16		uint16_t;
 typedef		__u32		uint32_t;
 
-#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
+#if defined(__GNUC__) && !defined(__STRICT_ANSI__) && \
+	(!defined(CONFIG_USE_STDINT) || !defined(__INT64_TYPE__))
 typedef		__u64		uint64_t;
 typedef		__u64		u_int64_t;
 typedef		__s64		int64_t;
@@ -112,6 +113,12 @@ typedef		__s64		int64_t;
 
 #endif /* __KERNEL_STRICT_NAMES */
 
+#if defined(CONFIG_USE_STDINT) && defined(__INT64_TYPE__)
+typedef		__UINT64_TYPE__	uint64_t;
+typedef		__UINT64_TYPE__	u_int64_t;
+typedef		__INT64_TYPE__		int64_t;
+#endif
+
 /*
  * Below are truly Linux-specific types that should never collide with
  * any application/library that wants linux/types.h.
-- 
2.1.0.rc2.206.gedb03e5

[U-Boot] [PATCH 02/10] Add some standard headers external code might need

[Simon Glass]

From: Gabe Black <gabeblack@chromium.org>

inttypes.h defines format specifiers for printf which work with data types of
particular sizes. stdlib.h is currently just a passthrough to malloc.h which
has declarations of the various *alloc functions.

Add the required #define to common.h so that these printf format specifiers
will be made available.

Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@google.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
(Replaced with a GPL version from glibc)

---

 include/common.h   |   3 +
 include/inttypes.h | 287 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 include/stdlib.h   |  12 +++
 3 files changed, 302 insertions(+)
 create mode 100644 include/inttypes.h
 create mode 100644 include/stdlib.h

diff --git a/include/common.h b/include/common.h
index d5020c8..d8584dd 100644
--- a/include/common.h
+++ b/include/common.h
@@ -86,6 +86,9 @@ typedef volatile unsigned char	vu_char;
 #include <flash.h>
 #include <image.h>
 
+/* Bring in printf format macros if inttypes.h is included */
+#define __STDC_FORMAT_MACROS
+
 #ifdef __LP64__
 #define CONFIG_SYS_SUPPORT_64BIT_DATA
 #endif
diff --git a/include/inttypes.h b/include/inttypes.h
new file mode 100644
index 0000000..e2e569d
--- /dev/null
+++ b/include/inttypes.h
@@ -0,0 +1,287 @@
+/*
+ * Copyright (C) 1997-2001, 2004, 2007 Free Software Foundation, Inc.
+ *
+ * This file is taken from the GNU C Library v2.15, with the unimplemented
+ * functions removed and a few style fixes.
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ */
+
+/*
+ *	ISO C99: 7.8 Format conversion of integer types	<inttypes.h>
+ */
+
+#ifndef _INTTYPES_H
+#define _INTTYPES_H	1
+
+#include <linux/compiler.h>
+
+/* Get a definition for wchar_t.  But we must not define wchar_t itself.  */
+#ifndef ____gwchar_t_defined
+# ifdef __cplusplus
+#  define __gwchar_t wchar_t
+# elif defined __WCHAR_TYPE__
+typedef __WCHAR_TYPE__ __gwchar_t;
+# else
+#  define __need_wchar_t
+#  include <stddef.h>
+typedef wchar_t __gwchar_t;
+# endif
+# define ____gwchar_t_defined	1
+#endif
+
+
+/* The ISO C99 standard specifies that these macros must only be
+   defined if explicitly requested.  */
+#if !defined __cplusplus || defined __STDC_FORMAT_MACROS
+
+#ifdef CONFIG_USE_STDINT
+# if __WORDSIZE == 64
+#  define __PRI64_PREFIX	"l"
+#  define __PRIPTR_PREFIX	"l"
+# else
+#  define __PRI64_PREFIX	"ll"
+#  define __PRIPTR_PREFIX
+# endif
+#else
+/* linux/types.h always uses long long for 64-bit and long for uintptr_t */
+# define __PRI64_PREFIX	"ll"
+# define __PRIPTR_PREFIX	"l"
+#endif
+
+/* Macros for printing format specifiers.  */
+
+/* Decimal notation.  */
+# define PRId8		"d"
+# define PRId16		"d"
+# define PRId32		"d"
+# define PRId64		__PRI64_PREFIX "d"
+
+# define PRIdLEAST8	"d"
+# define PRIdLEAST16	"d"
+# define PRIdLEAST32	"d"
+# define PRIdLEAST64	__PRI64_PREFIX "d"
+
+# define PRIdFAST8	"d"
+# define PRIdFAST16	__PRIPTR_PREFIX "d"
+# define PRIdFAST32	__PRIPTR_PREFIX "d"
+# define PRIdFAST64	__PRI64_PREFIX "d"
+
+
+# define PRIi8		"i"
+# define PRIi16		"i"
+# define PRIi32		"i"
+# define PRIi64		__PRI64_PREFIX "i"
+
+# define PRIiLEAST8	"i"
+# define PRIiLEAST16	"i"
+# define PRIiLEAST32	"i"
+# define PRIiLEAST64	__PRI64_PREFIX "i"
+
+# define PRIiFAST8	"i"
+# define PRIiFAST16	__PRIPTR_PREFIX "i"
+# define PRIiFAST32	__PRIPTR_PREFIX "i"
+# define PRIiFAST64	__PRI64_PREFIX "i"
+
+/* Octal notation.  */
+# define PRIo8		"o"
+# define PRIo16		"o"
+# define PRIo32		"o"
+# define PRIo64		__PRI64_PREFIX "o"
+
+# define PRIoLEAST8	"o"
+# define PRIoLEAST16	"o"
+# define PRIoLEAST32	"o"
+# define PRIoLEAST64	__PRI64_PREFIX "o"
+
+# define PRIoFAST8	"o"
+# define PRIoFAST16	__PRIPTR_PREFIX "o"
+# define PRIoFAST32	__PRIPTR_PREFIX "o"
+# define PRIoFAST64	__PRI64_PREFIX "o"
+
+/* Unsigned integers.  */
+# define PRIu8		"u"
+# define PRIu16		"u"
+# define PRIu32		"u"
+# define PRIu64		__PRI64_PREFIX "u"
+
+# define PRIuLEAST8	"u"
+# define PRIuLEAST16	"u"
+# define PRIuLEAST32	"u"
+# define PRIuLEAST64	__PRI64_PREFIX "u"
+
+# define PRIuFAST8	"u"
+# define PRIuFAST16	__PRIPTR_PREFIX "u"
+# define PRIuFAST32	__PRIPTR_PREFIX "u"
+# define PRIuFAST64	__PRI64_PREFIX "u"
+
+/* lowercase hexadecimal notation.  */
+# define PRIx8		"x"
+# define PRIx16		"x"
+# define PRIx32		"x"
+# define PRIx64		__PRI64_PREFIX "x"
+
+# define PRIxLEAST8	"x"
+# define PRIxLEAST16	"x"
+# define PRIxLEAST32	"x"
+# define PRIxLEAST64	__PRI64_PREFIX "x"
+
+# define PRIxFAST8	"x"
+# define PRIxFAST16	__PRIPTR_PREFIX "x"
+# define PRIxFAST32	__PRIPTR_PREFIX "x"
+# define PRIxFAST64	__PRI64_PREFIX "x"
+
+/* UPPERCASE hexadecimal notation.  */
+# define PRIX8		"X"
+# define PRIX16		"X"
+# define PRIX32		"X"
+# define PRIX64		__PRI64_PREFIX "X"
+
+# define PRIXLEAST8	"X"
+# define PRIXLEAST16	"X"
+# define PRIXLEAST32	"X"
+# define PRIXLEAST64	__PRI64_PREFIX "X"
+
+# define PRIXFAST8	"X"
+# define PRIXFAST16	__PRIPTR_PREFIX "X"
+# define PRIXFAST32	__PRIPTR_PREFIX "X"
+# define PRIXFAST64	__PRI64_PREFIX "X"
+
+
+/* Macros for printing `intmax_t' and `uintmax_t'.  */
+# define PRIdMAX	__PRI64_PREFIX "d"
+# define PRIiMAX	__PRI64_PREFIX "i"
+# define PRIoMAX	__PRI64_PREFIX "o"
+# define PRIuMAX	__PRI64_PREFIX "u"
+# define PRIxMAX	__PRI64_PREFIX "x"
+# define PRIXMAX	__PRI64_PREFIX "X"
+
+
+/* Macros for printing `intptr_t' and `uintptr_t'.  */
+# define PRIdPTR	__PRIPTR_PREFIX "d"
+# define PRIiPTR	__PRIPTR_PREFIX "i"
+# define PRIoPTR	__PRIPTR_PREFIX "o"
+# define PRIuPTR	__PRIPTR_PREFIX "u"
+# define PRIxPTR	__PRIPTR_PREFIX "x"
+# define PRIXPTR	__PRIPTR_PREFIX "X"
+
+
+/* Macros for scanning format specifiers.  */
+
+/* Signed decimal notation.  */
+# define SCNd8		"hhd"
+# define SCNd16		"hd"
+# define SCNd32		"d"
+# define SCNd64		__PRI64_PREFIX "d"
+
+# define SCNdLEAST8	"hhd"
+# define SCNdLEAST16	"hd"
+# define SCNdLEAST32	"d"
+# define SCNdLEAST64	__PRI64_PREFIX "d"
+
+# define SCNdFAST8	"hhd"
+# define SCNdFAST16	__PRIPTR_PREFIX "d"
+# define SCNdFAST32	__PRIPTR_PREFIX "d"
+# define SCNdFAST64	__PRI64_PREFIX "d"
+
+/* Signed decimal notation.  */
+# define SCNi8		"hhi"
+# define SCNi16		"hi"
+# define SCNi32		"i"
+# define SCNi64		__PRI64_PREFIX "i"
+
+# define SCNiLEAST8	"hhi"
+# define SCNiLEAST16	"hi"
+# define SCNiLEAST32	"i"
+# define SCNiLEAST64	__PRI64_PREFIX "i"
+
+# define SCNiFAST8	"hhi"
+# define SCNiFAST16	__PRIPTR_PREFIX "i"
+# define SCNiFAST32	__PRIPTR_PREFIX "i"
+# define SCNiFAST64	__PRI64_PREFIX "i"
+
+/* Unsigned decimal notation.  */
+# define SCNu8		"hhu"
+# define SCNu16		"hu"
+# define SCNu32		"u"
+# define SCNu64		__PRI64_PREFIX "u"
+
+# define SCNuLEAST8	"hhu"
+# define SCNuLEAST16	"hu"
+# define SCNuLEAST32	"u"
+# define SCNuLEAST64	__PRI64_PREFIX "u"
+
+# define SCNuFAST8	"hhu"
+# define SCNuFAST16	__PRIPTR_PREFIX "u"
+# define SCNuFAST32	__PRIPTR_PREFIX "u"
+# define SCNuFAST64	__PRI64_PREFIX "u"
+
+/* Octal notation.  */
+# define SCNo8		"hho"
+# define SCNo16		"ho"
+# define SCNo32		"o"
+# define SCNo64		__PRI64_PREFIX "o"
+
+# define SCNoLEAST8	"hho"
+# define SCNoLEAST16	"ho"
+# define SCNoLEAST32	"o"
+# define SCNoLEAST64	__PRI64_PREFIX "o"
+
+# define SCNoFAST8	"hho"
+# define SCNoFAST16	__PRIPTR_PREFIX "o"
+# define SCNoFAST32	__PRIPTR_PREFIX "o"
+# define SCNoFAST64	__PRI64_PREFIX "o"
+
+/* Hexadecimal notation.  */
+# define SCNx8		"hhx"
+# define SCNx16		"hx"
+# define SCNx32		"x"
+# define SCNx64		__PRI64_PREFIX "x"
+
+# define SCNxLEAST8	"hhx"
+# define SCNxLEAST16	"hx"
+# define SCNxLEAST32	"x"
+# define SCNxLEAST64	__PRI64_PREFIX "x"
+
+# define SCNxFAST8	"hhx"
+# define SCNxFAST16	__PRIPTR_PREFIX "x"
+# define SCNxFAST32	__PRIPTR_PREFIX "x"
+# define SCNxFAST64	__PRI64_PREFIX "x"
+
+
+/* Macros for scanning `intmax_t' and `uintmax_t'.  */
+# define SCNdMAX	__PRI64_PREFIX "d"
+# define SCNiMAX	__PRI64_PREFIX "i"
+# define SCNoMAX	__PRI64_PREFIX "o"
+# define SCNuMAX	__PRI64_PREFIX "u"
+# define SCNxMAX	__PRI64_PREFIX "x"
+
+/* Macros for scaning `intptr_t' and `uintptr_t'.  */
+# define SCNdPTR	__PRIPTR_PREFIX "d"
+# define SCNiPTR	__PRIPTR_PREFIX "i"
+# define SCNoPTR	__PRIPTR_PREFIX "o"
+# define SCNuPTR	__PRIPTR_PREFIX "u"
+# define SCNxPTR	__PRIPTR_PREFIX "x"
+
+#endif	/* C++ && format macros */
+
+
+#if __WORDSIZE == 64
+
+/* We have to define the `uintmax_t' type using `ldiv_t'.  */
+typedef struct {
+	long int quot;		/* Quotient.  */
+	long int rem;		/* Remainder.  */
+} imaxdiv_t;
+
+#else
+
+/* We have to define the `uintmax_t' type using `lldiv_t'.  */
+typedef struct {
+	long long int quot;		/* Quotient.  */
+	long long int rem;		/* Remainder.  */
+} imaxdiv_t;
+
+#endif
+
+#endif /* inttypes.h */
diff --git a/include/stdlib.h b/include/stdlib.h
new file mode 100644
index 0000000..6bc7fbb
--- /dev/null
+++ b/include/stdlib.h
@@ -0,0 +1,12 @@
+/*
+ *  Copyright (C) 2013 Google Inc.
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ */
+
+#ifndef __STDLIB_H_
+#define __STDLIB_H_
+
+#include <malloc.h>
+
+#endif /* __STDLIB_H_ */
-- 
2.1.0.rc2.206.gedb03e5

[U-Boot] [PATCH 03/10] ext4: Use inttypes for printf() string

[Simon Glass]

On 64-bit platforms (like sandbox) 64-bit integers may be 'long' rather
than 'long long'. Use the inttypes header to avoid compiler warnings.

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

 fs/ext4/ext4_common.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c
index 33d69c9..cccc06a 100644
--- a/fs/ext4/ext4_common.c
+++ b/fs/ext4/ext4_common.c
@@ -22,6 +22,7 @@
 #include <common.h>
 #include <ext_common.h>
 #include <ext4fs.h>
+#include <inttypes.h>
 #include <malloc.h>
 #include <stddef.h>
 #include <linux/stat.h>
@@ -73,7 +74,7 @@ void put_ext4(uint64_t off, void *buf, uint32_t size)
 	if ((startblock + (size >> log2blksz)) >
 	    (part_offset + fs->total_sect)) {
 		printf("part_offset is " LBAFU "\n", part_offset);
-		printf("total_sector is %llu\n", fs->total_sect);
+		printf("total_sector is %" PRIu64 "\n", fs->total_sect);
 		printf("error: overflow occurs\n");
 		return;
 	}
-- 
2.1.0.rc2.206.gedb03e5

[U-Boot] [PATCH 04/10] Use uint64_t for time types

[Simon Glass]

Unfortunately 'unsigned long long' and 'uint64_t' are not necessarily
compatible on 64-bit machines. Use the correct typedef instead of
writing the supposed type out in full.

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

 include/common.h |  2 +-
 lib/time.c       | 12 ++++++------
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/include/common.h b/include/common.h
index d8584dd..02befa6 100644
--- a/include/common.h
+++ b/include/common.h
@@ -776,7 +776,7 @@ void	invalidate_dcache_all(void);
 void	invalidate_icache_all(void);
 
 /* arch/$(ARCH)/lib/ticks.S */
-unsigned long long get_ticks(void);
+uint64_t get_ticks(void);
 void	wait_ticks    (unsigned long);
 
 /* arch/$(ARCH)/lib/time.c */
diff --git a/lib/time.c b/lib/time.c
index c7b0264..fe43ccb 100644
--- a/lib/time.c
+++ b/lib/time.c
@@ -41,7 +41,7 @@ unsigned long notrace timer_read_counter(void)
 extern unsigned long __weak timer_read_counter(void);
 #endif
 
-unsigned long long __weak notrace get_ticks(void)
+uint64_t __weak notrace get_ticks(void)
 {
 	unsigned long now = timer_read_counter();
 
@@ -49,11 +49,11 @@ unsigned long long __weak notrace get_ticks(void)
 	if (now < gd->timebase_l)
 		gd->timebase_h++;
 	gd->timebase_l = now;
-	return ((unsigned long long)gd->timebase_h << 32) | gd->timebase_l;
+	return ((uint64_t)gd->timebase_h << 32) | gd->timebase_l;
 }
 
 /* Returns time in milliseconds */
-static unsigned long long notrace tick_to_time(unsigned long long tick)
+static uint64_t notrace tick_to_time(uint64_t tick)
 {
 	ulong div = get_tbclk();
 
@@ -78,9 +78,9 @@ unsigned long __weak notrace timer_get_us(void)
 	return tick_to_time(get_ticks() * 1000);
 }
 
-static unsigned long long usec_to_tick(unsigned long usec)
+static uint64_t usec_to_tick(unsigned long usec)
 {
-	unsigned long long tick = usec;
+	uint64_t tick = usec;
 	tick *= get_tbclk();
 	do_div(tick, 1000000);
 	return tick;
@@ -88,7 +88,7 @@ static unsigned long long usec_to_tick(unsigned long usec)
 
 void __weak __udelay(unsigned long usec)
 {
-	unsigned long long tmp;
+	uint64_t tmp;
 
 	tmp = get_ticks() + usec_to_tick(usec);	/* get current timestamp */
 
-- 
2.1.0.rc2.206.gedb03e5

[U-Boot] [PATCH 05/10] Use uint64_t instead of u64 in put_dec()

[Simon Glass]

Use the correct type required by do_div().

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

 lib/vsprintf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 7ec758e..b585713 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -270,7 +270,7 @@ static char *put_dec_full(char *buf, unsigned q)
 	return buf;
 }
 /* No inlining helps gcc to use registers better */
-static noinline char *put_dec(char *buf, u64 num)
+static noinline char *put_dec(char *buf, uint64_t num)
 {
 	while (1) {
 		unsigned rem;
-- 
2.1.0.rc2.206.gedb03e5

[U-Boot] [PATCH 06/10] Tidy up data sizes and function comment in display_options

[Simon Glass]

Use inttypes.h and uint64_t to correct the code so that it will not issue
warnings on 64-bit machines where 'uint64_t' is 'unsigned long'.

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

 include/common.h      | 14 +++++++++++++-
 lib/display_options.c | 14 +++++---------
 2 files changed, 18 insertions(+), 10 deletions(-)

diff --git a/include/common.h b/include/common.h
index 02befa6..3ccde60 100644
--- a/include/common.h
+++ b/include/common.h
@@ -256,7 +256,19 @@ int	cpu_init(void);
 /* */
 phys_size_t initdram (int);
 int	display_options (void);
-void	print_size(unsigned long long, const char *);
+
+/**
+ * print_size() - Print a size with a suffic
+ *
+ * print sizes as "xxx KiB", "xxx.y KiB", "xxx MiB", "xxx.y MiB",
+ * xxx GiB, xxx.y GiB, etc as needed; allow for optional trailing string
+ * (like "\n")
+ *
+ * @size:	Size to print
+ * @suffix	String to print after the size
+ */
+void print_size(uint64_t size, const char *suffix);
+
 int print_buffer(ulong addr, const void *data, uint width, uint count,
 		 uint linelen);
 
diff --git a/lib/display_options.c b/lib/display_options.c
index 4c0c886..d5d17b2 100644
--- a/lib/display_options.c
+++ b/lib/display_options.c
@@ -7,6 +7,7 @@
 
 #include <config.h>
 #include <common.h>
+#include <inttypes.h>
 #include <version.h>
 #include <linux/ctype.h>
 #include <asm/io.h>
@@ -21,15 +22,10 @@ int display_options (void)
 	return 0;
 }
 
-/*
- * print sizes as "xxx KiB", "xxx.y KiB", "xxx MiB", "xxx.y MiB",
- * xxx GiB, xxx.y GiB, etc as needed; allow for optional trailing string
- * (like "\n")
- */
-void print_size(unsigned long long size, const char *s)
+void print_size(uint64_t size, const char *s)
 {
 	unsigned long m = 0, n;
-	unsigned long long f;
+	uint64_t f;
 	static const char names[] = {'E', 'P', 'T', 'G', 'M', 'K'};
 	unsigned long d = 10 * ARRAY_SIZE(names);
 	char c = 0;
@@ -43,7 +39,7 @@ void print_size(unsigned long long size, const char *s)
 	}
 
 	if (!c) {
-		printf("%llu Bytes%s", size, s);
+		printf("%" PRIu64 " Bytes%s", size, s);
 		return;
 	}
 
@@ -127,7 +123,7 @@ int print_buffer(ulong addr, const void *data, uint width, uint count,
 			else
 				x = lb.uc[i] = *(volatile uint8_t *)data;
 #ifdef CONFIG_SYS_SUPPORT_64BIT_DATA
-			printf(" %0*llx", width * 2, x);
+			printf(" %0*" PRIx64, width * 2, x);
 #else
 			printf(" %0*x", width * 2, x);
 #endif
-- 
2.1.0.rc2.206.gedb03e5

[U-Boot] [PATCH 07/10] x86: Use correct printf() format string for uintptr_t

[Simon Glass]

Use the inttypes header file to provide this.

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

 arch/x86/lib/relocate.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/lib/relocate.c b/arch/x86/lib/relocate.c
index 526daaf..faca38f 100644
--- a/arch/x86/lib/relocate.c
+++ b/arch/x86/lib/relocate.c
@@ -16,6 +16,7 @@
  */
 
 #include <common.h>
+#include <inttypes.h>
 #include <libfdt.h>
 #include <malloc.h>
 #include <asm/u-boot-x86.h>
@@ -94,7 +95,7 @@ int do_elf_reloc_fixups(void)
 				*offset_ptr_ram += gd->reloc_off;
 			} else {
 				debug("   %p: rom reloc %x, ram %p, value %x,"
-					" limit %lx\n", re_src,
+					" limit %" PRIXPTR "\n", re_src,
 					re_src->r_offset, offset_ptr_ram,
 					*offset_ptr_ram,
 					CONFIG_SYS_TEXT_BASE + size);
-- 
2.1.0.rc2.206.gedb03e5

[U-Boot] [PATCH 08/10] scsi: Use correct printf() format string for uintptr_t

[Simon Glass]

Use the inttypes header file to provide this.

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

 common/cmd_scsi.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/common/cmd_scsi.c b/common/cmd_scsi.c
index b3f7687..cbc107e 100644
--- a/common/cmd_scsi.c
+++ b/common/cmd_scsi.c
@@ -10,6 +10,7 @@
  */
 #include <common.h>
 #include <command.h>
+#include <inttypes.h>
 #include <asm/processor.h>
 #include <scsi.h>
 #include <image.h>
@@ -391,7 +392,7 @@ static ulong scsi_read(int device, lbaint_t blknr, lbaint_t blkcnt,
 			blks=0;
 		}
 		debug("scsi_read_ext: startblk " LBAF
-		      ", blccnt %x buffer %lx\n",
+		      ", blccnt %x buffer %" PRIXPTR "\n",
 		      start, smallblks, buf_addr);
 		if (scsi_exec(pccb) != true) {
 			scsi_print_error(pccb);
@@ -401,7 +402,7 @@ static ulong scsi_read(int device, lbaint_t blknr, lbaint_t blkcnt,
 		buf_addr+=pccb->datalen;
 	} while(blks!=0);
 	debug("scsi_read_ext: end startblk " LBAF
-	      ", blccnt %x buffer %lx\n", start, smallblks, buf_addr);
+	      ", blccnt %x buffer %" PRIXPTR "\n", start, smallblks, buf_addr);
 	return(blkcnt);
 }
 
@@ -445,7 +446,7 @@ static ulong scsi_write(int device, lbaint_t blknr,
 			start += blks;
 			blks = 0;
 		}
-		debug("%s: startblk " LBAF ", blccnt %x buffer %lx\n",
+		debug("%s: startblk " LBAF ", blccnt %x buffer %" PRIXPTR "\n",
 		      __func__, start, smallblks, buf_addr);
 		if (scsi_exec(pccb) != true) {
 			scsi_print_error(pccb);
@@ -454,7 +455,7 @@ static ulong scsi_write(int device, lbaint_t blknr,
 		}
 		buf_addr += pccb->datalen;
 	} while (blks != 0);
-	debug("%s: end startblk " LBAF ", blccnt %x buffer %lx\n",
+	debug("%s: end startblk " LBAF ", blccnt %x buffer %" PRIXPTR "\n",
 	      __func__, start, smallblks, buf_addr);
 	return blkcnt;
 }
-- 
2.1.0.rc2.206.gedb03e5

[U-Boot] [PATCH 09/10] usb: Use correct printf() format string for uintptr_t

[Simon Glass]

Use the inttypes header file to provide this.

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

 common/usb_storage.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/common/usb_storage.c b/common/usb_storage.c
index 6ac358d..eb7706c 100644
--- a/common/usb_storage.c
+++ b/common/usb_storage.c
@@ -33,6 +33,7 @@
 
 #include <common.h>
 #include <command.h>
+#include <inttypes.h>
 #include <asm/byteorder.h>
 #include <asm/processor.h>
 
@@ -1071,7 +1072,7 @@ unsigned long usb_stor_read(int device, lbaint_t blknr,
 	blks = blkcnt;
 
 	debug("\nusb_read: dev %d startblk " LBAF ", blccnt " LBAF
-	      " buffer %lx\n", device, start, blks, buf_addr);
+	      " buffer %" PRIxPTR "\n", device, start, blks, buf_addr);
 
 	do {
 		/* XXX need some comment here */
@@ -1101,7 +1102,7 @@ retry_it:
 	ss->flags &= ~USB_READY;
 
 	debug("usb_read: end startblk " LBAF
-	      ", blccnt %x buffer %lx\n",
+	      ", blccnt %x buffer %" PRIxPTR "\n",
 	      start, smallblks, buf_addr);
 
 	usb_disable_asynch(0); /* asynch transfer allowed */
@@ -1145,7 +1146,7 @@ unsigned long usb_stor_write(int device, lbaint_t blknr,
 	blks = blkcnt;
 
 	debug("\nusb_write: dev %d startblk " LBAF ", blccnt " LBAF
-	      " buffer %lx\n", device, start, blks, buf_addr);
+	      " buffer %" PRIxPTR "\n", device, start, blks, buf_addr);
 
 	do {
 		/* If write fails retry for max retry count else
@@ -1176,8 +1177,8 @@ retry_it:
 	} while (blks != 0);
 	ss->flags &= ~USB_READY;
 
-	debug("usb_write: end startblk " LBAF ", blccnt %x buffer %lx\n",
-	      start, smallblks, buf_addr);
+	debug("usb_write: end startblk " LBAF ", blccnt %x buffer %"
+	      PRIxPTR "\n", start, smallblks, buf_addr);
 
 	usb_disable_asynch(0); /* asynch transfer allowed */
 	if (blkcnt >= USB_MAX_XFER_BLK)
-- 
2.1.0.rc2.206.gedb03e5

[U-Boot] [PATCH 10/10] test: Add a simple test to detected warnings with uint64_t, uintptr_t

[Simon Glass]

These types are problematic because they are typically declared in a
non-standard way in U-Boot. For example, U-Boot uses 'long long' for
int64_t even on a 64-bit machine whereas stdint.h uses 'long'.
Similarly, U-Boot always uses 'long' for intptr_t whereas stdint.h mostly
uses 'int'.

This simple test script runs a few toolchains on a few archs to check for
warnings.

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

 test/stdint/int-types.c      | 13 ++++++++++
 test/stdint/test-includes.sh | 58 ++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 71 insertions(+)
 create mode 100644 test/stdint/int-types.c
 create mode 100755 test/stdint/test-includes.sh

diff --git a/test/stdint/int-types.c b/test/stdint/int-types.c
new file mode 100644
index 0000000..2660084
--- /dev/null
+++ b/test/stdint/int-types.c
@@ -0,0 +1,13 @@
+#include <common.h>
+#include <inttypes.h>
+
+int test_types(void)
+{
+	uintptr_t uintptr = 0;
+	uint64_t uint64 = 0;
+	u64 u64_val = 0;
+
+	printf("uintptr = %" PRIuPTR "\n", uintptr);
+	printf("uint64 = %" PRIu64 "\n", uint64);
+	printf("u64 = %" PRIu64 "\n", u64_val);
+}
diff --git a/test/stdint/test-includes.sh b/test/stdint/test-includes.sh
new file mode 100755
index 0000000..077bdc7
--- /dev/null
+++ b/test/stdint/test-includes.sh
@@ -0,0 +1,58 @@
+#!/bin/bash
+
+# Test script to check uintptr_t and 64-bit types for warnings
+#
+# It builds a few boards with different toolchains. If there are no warnings
+# then all is well.
+#
+# Usage:
+#
+# Make sure that your toolchains are correct at the bottom of this file
+#
+# Then:
+#	./test/stdint/test-includes.sh
+
+out=/tmp/test-includes.tmp
+
+try_test() {
+	local board=$1
+	local arch=$2
+	local soc=$3
+	local gcc=$4
+	local flags="$5"
+
+	echo $@
+	if ! which ${gcc} >/dev/null 2>&1; then
+		echo "Not found: ${gcc}"
+		return
+	fi
+
+	rm -rf ${out}
+	mkdir -p ${out}
+	touch ${out}/config.h
+	mkdir -p ${out}/generated
+	touch ${out}/generated/generic-asm-offsets.h
+	mkdir -p ${out}/include/asm
+	ln -s $(pwd)/arch/${arch}/include/asm/arch-${soc} \
+			${out}/include/asm/arch
+
+	cmd="${gcc} -c -D__KERNEL__ ${flags} \
+		-fno-builtin -ffreestanding \
+		-Iarch/${arch}/include \
+		-Iinclude \
+		-I${out} -I${out}/include \
+		-include configs/${board}.h test/stdint/int-types.c \
+		-o /dev/null"
+	$cmd
+}
+
+# Run a test with and without CONFIG_USE_STDINT
+try_both() {
+	try_test $@
+	try_test $@ -DCONFIG_USE_STDINT
+}
+
+# board arch soc path-to-gcc
+try_both sandbox sandbox - gcc
+try_both coreboot x86 - x86_64-linux-gnu-gcc
+try_both seaboard arm tegra20 /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.8-2013.08_linux/bin/arm-linux-gnueabihf-gcc
-- 
2.1.0.rc2.206.gedb03e5

[U-Boot] [PATCH 0/10] Provide inttypes.h to avoid 32/64 bit problems with printf()

[Simon Glass]

+Jeroen

Hi,

On 15 October 2014 04:38, Simon Glass <sjg@chromium.org> wrote:
> In quite a few situations we have to print a 64-bit value. Unfortunately
> the type used for 64-bit can vary depending on the machine. For 64-bit
> machines it might be 'long' and for 32-bit machines it might be
> 'long long'.
>
> As a result we need to use either %ld or %lld depending on the architecture.
> Add the inttypes.h header file to provide defines for this and clean up the
> code to use these defines in a few places.
>
> The stdint.h file is bundled with recent versions of gcc and it is generally
> better to use this rather than our own versions. Add an option to use the
> internal stdint.h file.
>
>
> Gabe Black (2):
>   Provide option to avoid defining a custom version of uintptr_t.
>   Add some standard headers external code might need
>
> Simon Glass (8):
>   ext4: Use inttypes for printf() string
>   Use uint64_t for time types
>   Use uint64_t instead of u64 in put_dec()
>   Tidy up data sizes and function comment in display_options
>   x86: Use correct printf() format string for uintptr_t
>   scsi: Use correct printf() format string for uintptr_t
>   usb: Use correct printf() format string for uintptr_t
>   test: Add a simple test to detected warnings with uint64_t, uintptr_t

Are there any comments on this series? I'm keen to clean up the
printf() types a bit. Also this simplifies building withe external
libraries, and with more work might reduce the difference between
U-Boot code in /tools and the rest of it.

>
>  README                           |   5 +
>  arch/sandbox/include/asm/types.h |   5 +
>  arch/x86/include/asm/types.h     |   5 +
>  arch/x86/lib/relocate.c          |   3 +-
>  common/cmd_scsi.c                |   9 +-
>  common/usb_storage.c             |  11 +-
>  config.mk                        |   5 +
>  fs/ext4/ext4_common.c            |   3 +-
>  include/common.h                 |  19 ++-
>  include/compiler.h               |  11 +-
>  include/inttypes.h               | 287 +++++++++++++++++++++++++++++++++++++++
>  include/linux/types.h            |   9 +-
>  include/stdlib.h                 |  12 ++
>  lib/display_options.c            |  14 +-
>  lib/time.c                       |  12 +-
>  lib/vsprintf.c                   |   2 +-
>  test/stdint/int-types.c          |  13 ++
>  test/stdint/test-includes.sh     |  58 ++++++++
>  18 files changed, 450 insertions(+), 33 deletions(-)
>  create mode 100644 include/inttypes.h
>  create mode 100644 include/stdlib.h
>  create mode 100644 test/stdint/int-types.c
>  create mode 100755 test/stdint/test-includes.sh
>
> --
> 2.1.0.rc2.206.gedb03e5
>

Regards,
Simon

[U-Boot] [PATCH 0/10] Provide inttypes.h to avoid 32/64 bit problems with printf()

[Jeroen Hofstee]

Hello Simon,

On 24-10-14 03:03, Simon Glass wrote:
> +Jeroen
>
> Hi,
>
> On 15 October 2014 04:38, Simon Glass <sjg@chromium.org> wrote:
>> In quite a few situations we have to print a 64-bit value. Unfortunately
>> the type used for 64-bit can vary depending on the machine. For 64-bit
>> machines it might be 'long' and for 32-bit machines it might be
>> 'long long'.
>>
>> As a result we need to use either %ld or %lld depending on the architecture.
>> Add the inttypes.h header file to provide defines for this and clean up the
>> code to use these defines in a few places.
>>
>> The stdint.h file is bundled with recent versions of gcc and it is generally
>> better to use this rather than our own versions. Add an option to use the
>> internal stdint.h file.
>>
>>
>> Gabe Black (2):
>>    Provide option to avoid defining a custom version of uintptr_t.
>>    Add some standard headers external code might need
>>
>> Simon Glass (8):
>>    ext4: Use inttypes for printf() string
>>    Use uint64_t for time types
>>    Use uint64_t instead of u64 in put_dec()
>>    Tidy up data sizes and function comment in display_options
>>    x86: Use correct printf() format string for uintptr_t
>>    scsi: Use correct printf() format string for uintptr_t
>>    usb: Use correct printf() format string for uintptr_t
>>    test: Add a simple test to detected warnings with uint64_t, uintptr_t
> Are there any comments on this series? I'm keen to clean up the
> printf() types a bit. Also this simplifies building withe external
> libraries, and with more work might reduce the difference between
> U-Boot code in /tools and the rest of it.

No comments from my side. clang seem to digest this fine.

Regards,
Jeroen

[U-Boot] [PATCH 0/10] Provide inttypes.h to avoid 32/64 bit problems with printf()

[Jeroen Hofstee]

Hi Simon, attempt two..

On 24-10-14 03:03, Simon Glass wrote:
> +Jeroen
>
> Hi,
>
> On 15 October 2014 04:38, Simon Glass <sjg@chromium.org> wrote:
>> In quite a few situations we have to print a 64-bit value. Unfortunately
>> the type used for 64-bit can vary depending on the machine. For 64-bit
>> machines it might be 'long' and for 32-bit machines it might be
>> 'long long'.
>>
>> As a result we need to use either %ld or %lld depending on the architecture.
>> Add the inttypes.h header file to provide defines for this and clean up the
>> code to use these defines in a few places.
>>
>> The stdint.h file is bundled with recent versions of gcc and it is generally
>> better to use this rather than our own versions. Add an option to use the
>> internal stdint.h file.
>>
>>
>> Gabe Black (2):
>>    Provide option to avoid defining a custom version of uintptr_t.
>>    Add some standard headers external code might need
>>
>> Simon Glass (8):
>>    ext4: Use inttypes for printf() string
>>    Use uint64_t for time types
>>    Use uint64_t instead of u64 in put_dec()
>>    Tidy up data sizes and function comment in display_options
>>    x86: Use correct printf() format string for uintptr_t
>>    scsi: Use correct printf() format string for uintptr_t
>>    usb: Use correct printf() format string for uintptr_t
>>    test: Add a simple test to detected warnings with uint64_t, uintptr_t
> Are there any comments on this series? I'm keen to clean up the
> printf() types a bit. Also this simplifies building withe external
> libraries, and with more work might reduce the difference between
> U-Boot code in /tools and the rest of it.

No comments from my side. clang seem to digest this fine.

Regards,
Jeroen

[U-Boot] [PATCH 0/10] Provide inttypes.h to avoid 32/64 bit problems with printf()

[Simon Glass]

Hi Jeroen,

On 24 October 2014 11:06, Jeroen Hofstee <jeroen@myspectrum.nl> wrote:
> Hi Simon, attempt two..
>
> On 24-10-14 03:03, Simon Glass wrote:
>>
>> +Jeroen
>>
>> Hi,
>>
>> On 15 October 2014 04:38, Simon Glass <sjg@chromium.org> wrote:
>>>
>>> In quite a few situations we have to print a 64-bit value. Unfortunately
>>> the type used for 64-bit can vary depending on the machine. For 64-bit
>>> machines it might be 'long' and for 32-bit machines it might be
>>> 'long long'.
>>>
>>> As a result we need to use either %ld or %lld depending on the
>>> architecture.
>>> Add the inttypes.h header file to provide defines for this and clean up
>>> the
>>> code to use these defines in a few places.
>>>
>>> The stdint.h file is bundled with recent versions of gcc and it is
>>> generally
>>> better to use this rather than our own versions. Add an option to use the
>>> internal stdint.h file.
>>>
>>>
>>> Gabe Black (2):
>>>    Provide option to avoid defining a custom version of uintptr_t.
>>>    Add some standard headers external code might need
>>>
>>> Simon Glass (8):
>>>    ext4: Use inttypes for printf() string
>>>    Use uint64_t for time types
>>>    Use uint64_t instead of u64 in put_dec()
>>>    Tidy up data sizes and function comment in display_options
>>>    x86: Use correct printf() format string for uintptr_t
>>>    scsi: Use correct printf() format string for uintptr_t
>>>    usb: Use correct printf() format string for uintptr_t
>>>    test: Add a simple test to detected warnings with uint64_t, uintptr_t
>>
>> Are there any comments on this series? I'm keen to clean up the
>> printf() types a bit. Also this simplifies building withe external
>> libraries, and with more work might reduce the difference between
>> U-Boot code in /tools and the rest of it.
>
>
> No comments from my side. clang seem to digest this fine.

OK that's good. Thanks for trying it out.

Regards,
Simon

[U-Boot] [U-Boot, 01/10] Provide option to avoid defining a custom version of uintptr_t.

[Tom Rini]

On Wed, Oct 15, 2014 at 04:38:30AM -0600, Simon Glass wrote:

> From: Gabe Black <gabeblack@chromium.org>
> 
> There's a definition in stdint.h (provided by gcc) which will be more correct
> if available.
> 
> Define CONFIG_USE_STDINT to use this feature, or USE_STDINT=1 on the 'make'
> commmand.
> 
> This adjusts the settings for x86 and sandbox, with both have 64-bit options.
> 
> Signed-off-by: Gabe Black <gabeblack@google.com>
> Reviewed-by: Gabe Black <gabeblack@chromium.org>
> Tested-by: Gabe Black <gabeblack@chromium.org>
> Reviewed-by: Bill Richardson <wfrichar@google.com>
> Rewritten to be an option, since stdint.h is often available only in glibc.
> Changed to preserve a clear boundary between stdint and non-stdint
> Signed-off-by: Simon Glass <sjg@chromium.org>

Applied to u-boot/master, thanks!

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

[U-Boot] [U-Boot, 02/10] Add some standard headers external code might need

[Tom Rini]

On Wed, Oct 15, 2014 at 04:38:31AM -0600, Simon Glass wrote:

> From: Gabe Black <gabeblack@chromium.org>
> 
> inttypes.h defines format specifiers for printf which work with data types of
> particular sizes. stdlib.h is currently just a passthrough to malloc.h which
> has declarations of the various *alloc functions.
> 
> Add the required #define to common.h so that these printf format specifiers
> will be made available.
> 
> Signed-off-by: Gabe Black <gabeblack@google.com>
> Reviewed-by: Gabe Black <gabeblack@chromium.org>
> Tested-by: Gabe Black <gabeblack@chromium.org>
> Reviewed-by: Bill Richardson <wfrichar@google.com>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> (Replaced with a GPL version from glibc)

Applied to u-boot/master, thanks!

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

[U-Boot] [U-Boot,03/10] ext4: Use inttypes for printf() string

[Tom Rini]

On Wed, Oct 15, 2014 at 04:38:32AM -0600, Simon Glass wrote:

> On 64-bit platforms (like sandbox) 64-bit integers may be 'long' rather
> than 'long long'. Use the inttypes header to avoid compiler warnings.
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>

Applied to u-boot/master, thanks!

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

[U-Boot] [U-Boot,04/10] Use uint64_t for time types

[Tom Rini]

On Wed, Oct 15, 2014 at 04:38:33AM -0600, Simon Glass wrote:

> Unfortunately 'unsigned long long' and 'uint64_t' are not necessarily
> compatible on 64-bit machines. Use the correct typedef instead of
> writing the supposed type out in full.
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>

Applied to u-boot/master, thanks!

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

[U-Boot] [U-Boot, 05/10] Use uint64_t instead of u64 in put_dec()

[Tom Rini]

On Wed, Oct 15, 2014 at 04:38:34AM -0600, Simon Glass wrote:

> Use the correct type required by do_div().
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>

Applied to u-boot/master, thanks!

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

[U-Boot] [U-Boot, 06/10] Tidy up data sizes and function comment in display_options

[Tom Rini]

On Wed, Oct 15, 2014 at 04:38:35AM -0600, Simon Glass wrote:

> Use inttypes.h and uint64_t to correct the code so that it will not issue
> warnings on 64-bit machines where 'uint64_t' is 'unsigned long'.
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>

Applied to u-boot/master, thanks!

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

[U-Boot] [U-Boot, 07/10] x86: Use correct printf() format string for uintptr_t

[Tom Rini]

On Wed, Oct 15, 2014 at 04:38:36AM -0600, Simon Glass wrote:

> Use the inttypes header file to provide this.
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>

Applied to u-boot/master, thanks!

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

[U-Boot] [U-Boot, 08/10] scsi: Use correct printf() format string for uintptr_t

[Tom Rini]

On Wed, Oct 15, 2014 at 04:38:37AM -0600, Simon Glass wrote:

> Use the inttypes header file to provide this.
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>

Applied to u-boot/master, thanks!

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

[U-Boot] [U-Boot, 09/10] usb: Use correct printf() format string for uintptr_t

[Tom Rini]

On Wed, Oct 15, 2014 at 04:38:38AM -0600, Simon Glass wrote:

> Use the inttypes header file to provide this.
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>

Applied to u-boot/master, thanks!

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

[U-Boot] [U-Boot, 10/10] test: Add a simple test to detected warnings with uint64_t, uintptr_t

[Tom Rini]

On Wed, Oct 15, 2014 at 04:38:39AM -0600, Simon Glass wrote:

> These types are problematic because they are typically declared in a
> non-standard way in U-Boot. For example, U-Boot uses 'long long' for
> int64_t even on a 64-bit machine whereas stdint.h uses 'long'.
> Similarly, U-Boot always uses 'long' for intptr_t whereas stdint.h mostly
> uses 'int'.
> 
> This simple test script runs a few toolchains on a few archs to check for
> warnings.
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>

Applied to u-boot/master, thanks!

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

[U-Boot] [PATCH 02/10] Add some standard headers external code might need

[Masahiro YAMADA]

Hi Gabe, Simon,


2014-10-15 19:38 GMT+09:00 Simon Glass <sjg@chromium.org>:
> From: Gabe Black <gabeblack@chromium.org>
>
> inttypes.h defines format specifiers for printf which work with data types of
> particular sizes. stdlib.h is currently just a passthrough to malloc.h which
> has declarations of the various *alloc functions.
>
> Add the required #define to common.h so that these printf format specifiers
> will be made available.
>
> Signed-off-by: Gabe Black <gabeblack@google.com>
> Reviewed-by: Gabe Black <gabeblack@chromium.org>
> Tested-by: Gabe Black <gabeblack@chromium.org>
> Reviewed-by: Bill Richardson <wfrichar@google.com>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> (Replaced with a GPL version from glibc)
>
[snip]
> diff --git a/include/stdlib.h b/include/stdlib.h
> new file mode 100644
> index 0000000..6bc7fbb
> --- /dev/null
> +++ b/include/stdlib.h
> @@ -0,0 +1,12 @@
> +/*
> + *  Copyright (C) 2013 Google Inc.
> + *
> + * SPDX-License-Identifier:    GPL-2.0+
> + */
> +
> +#ifndef __STDLIB_H_
> +#define __STDLIB_H_
> +
> +#include <malloc.h>
> +
> +#endif /* __STDLIB_H_ */
> --
> 2.1.0.rc2.206.gedb03e5


This patch is not clear to me.

Why do we need include/stdlib.h ?





-- 
Best Regards
Masahiro Yamada

[U-Boot] [PATCH 02/10] Add some standard headers external code might need

[Simon Glass]

Hi Masahiro,

On 28 October 2014 10:25, Masahiro YAMADA <yamada.m@jp.panasonic.com> wrote:
>
> Hi Gabe, Simon,
>
>
> 2014-10-15 19:38 GMT+09:00 Simon Glass <sjg@chromium.org>:
> > From: Gabe Black <gabeblack@chromium.org>
> >
> > inttypes.h defines format specifiers for printf which work with data types of
> > particular sizes. stdlib.h is currently just a passthrough to malloc.h which
> > has declarations of the various *alloc functions.
> >
> > Add the required #define to common.h so that these printf format specifiers
> > will be made available.
> >
> > Signed-off-by: Gabe Black <gabeblack@google.com>
> > Reviewed-by: Gabe Black <gabeblack@chromium.org>
> > Tested-by: Gabe Black <gabeblack@chromium.org>
> > Reviewed-by: Bill Richardson <wfrichar@google.com>
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > (Replaced with a GPL version from glibc)
> >
> [snip]
> > diff --git a/include/stdlib.h b/include/stdlib.h
> > new file mode 100644
> > index 0000000..6bc7fbb
> > --- /dev/null
> > +++ b/include/stdlib.h
> > @@ -0,0 +1,12 @@
> > +/*
> > + *  Copyright (C) 2013 Google Inc.
> > + *
> > + * SPDX-License-Identifier:    GPL-2.0+
> > + */
> > +
> > +#ifndef __STDLIB_H_
> > +#define __STDLIB_H_
> > +
> > +#include <malloc.h>
> > +
> > +#endif /* __STDLIB_H_ */
> > --
> > 2.1.0.rc2.206.gedb03e5
>
>
> This patch is not clear to me.
>
> Why do we need include/stdlib.h ?

This makes the U-Boot environment more similar to that used by other
software, so we can more easily build it without lots of glue files.
Normally stdlib.h defines malloc() and friends.

Regards,
Simon

[U-Boot] [PATCH 02/10] Add some standard headers external code might need

[Masahiro YAMADA]

Hi Simon,


2014-10-29 1:29 GMT+09:00 Simon Glass <sjg@chromium.org>:
> Hi Masahiro,
>
> On 28 October 2014 10:25, Masahiro YAMADA <yamada.m@jp.panasonic.com> wrote:
>>
>> Hi Gabe, Simon,
>>
>>
>> 2014-10-15 19:38 GMT+09:00 Simon Glass <sjg@chromium.org>:
>> > From: Gabe Black <gabeblack@chromium.org>
>> >
>> > inttypes.h defines format specifiers for printf which work with data types of
>> > particular sizes. stdlib.h is currently just a passthrough to malloc.h which
>> > has declarations of the various *alloc functions.
>> >
>> > Add the required #define to common.h so that these printf format specifiers
>> > will be made available.
>> >
>> > Signed-off-by: Gabe Black <gabeblack@google.com>
>> > Reviewed-by: Gabe Black <gabeblack@chromium.org>
>> > Tested-by: Gabe Black <gabeblack@chromium.org>
>> > Reviewed-by: Bill Richardson <wfrichar@google.com>
>> > Signed-off-by: Simon Glass <sjg@chromium.org>
>> > (Replaced with a GPL version from glibc)
>> >
>> [snip]
>> > diff --git a/include/stdlib.h b/include/stdlib.h
>> > new file mode 100644
>> > index 0000000..6bc7fbb
>> > --- /dev/null
>> > +++ b/include/stdlib.h
>> > @@ -0,0 +1,12 @@
>> > +/*
>> > + *  Copyright (C) 2013 Google Inc.
>> > + *
>> > + * SPDX-License-Identifier:    GPL-2.0+
>> > + */
>> > +
>> > +#ifndef __STDLIB_H_
>> > +#define __STDLIB_H_
>> > +
>> > +#include <malloc.h>
>> > +
>> > +#endif /* __STDLIB_H_ */
>> > --
>> > 2.1.0.rc2.206.gedb03e5
>>
>>
>> This patch is not clear to me.
>>
>> Why do we need include/stdlib.h ?
>
> This makes the U-Boot environment more similar to that used by other
> software, so we can more easily build it without lots of glue files.
> Normally stdlib.h defines malloc() and friends.

I am not happy about this.

Our right direction is to make U-Boot environment more similar to the
Kernel, I think.

stdlib.h shouldn't appear in bare metal code.



-- 
Best Regards
Masahiro Yamada

[U-Boot] [PATCH 02/10] Add some standard headers external code might need

[Simon Glass]

Hi Masahiro,

On 28 October 2014 10:38, Masahiro YAMADA <yamada.m@jp.panasonic.com> wrote:
> Hi Simon,
>
>
> 2014-10-29 1:29 GMT+09:00 Simon Glass <sjg@chromium.org>:
>> Hi Masahiro,
>>
>> On 28 October 2014 10:25, Masahiro YAMADA <yamada.m@jp.panasonic.com> wrote:
>>>
>>> Hi Gabe, Simon,
>>>
>>>
>>> 2014-10-15 19:38 GMT+09:00 Simon Glass <sjg@chromium.org>:
>>> > From: Gabe Black <gabeblack@chromium.org>
>>> >
>>> > inttypes.h defines format specifiers for printf which work with data types of
>>> > particular sizes. stdlib.h is currently just a passthrough to malloc.h which
>>> > has declarations of the various *alloc functions.
>>> >
>>> > Add the required #define to common.h so that these printf format specifiers
>>> > will be made available.
>>> >
>>> > Signed-off-by: Gabe Black <gabeblack@google.com>
>>> > Reviewed-by: Gabe Black <gabeblack@chromium.org>
>>> > Tested-by: Gabe Black <gabeblack@chromium.org>
>>> > Reviewed-by: Bill Richardson <wfrichar@google.com>
>>> > Signed-off-by: Simon Glass <sjg@chromium.org>
>>> > (Replaced with a GPL version from glibc)
>>> >
>>> [snip]
>>> > diff --git a/include/stdlib.h b/include/stdlib.h
>>> > new file mode 100644
>>> > index 0000000..6bc7fbb
>>> > --- /dev/null
>>> > +++ b/include/stdlib.h
>>> > @@ -0,0 +1,12 @@
>>> > +/*
>>> > + *  Copyright (C) 2013 Google Inc.
>>> > + *
>>> > + * SPDX-License-Identifier:    GPL-2.0+
>>> > + */
>>> > +
>>> > +#ifndef __STDLIB_H_
>>> > +#define __STDLIB_H_
>>> > +
>>> > +#include <malloc.h>
>>> > +
>>> > +#endif /* __STDLIB_H_ */
>>> > --
>>> > 2.1.0.rc2.206.gedb03e5
>>>
>>>
>>> This patch is not clear to me.
>>>
>>> Why do we need include/stdlib.h ?
>>
>> This makes the U-Boot environment more similar to that used by other
>> software, so we can more easily build it without lots of glue files.
>> Normally stdlib.h defines malloc() and friends.
>
> I am not happy about this.
>
> Our right direction is to make U-Boot environment more similar to the
> Kernel, I think.
>
> stdlib.h shouldn't appear in bare metal code.

That's right, we don't want to include this in U-Boot itself. But if
you look at things in tools/ they include stdlib.h. With this header
available, we can more easily compile external code into U-Boot.

Regards,
Simon

[U-Boot] [PATCH 02/10] Add some standard headers external code might need

[Jeroen Hofstee]

Hello Simon,

On 28-10-14 18:33, Simon Glass wrote:
> Hi Masahiro,
>
> On 28 October 2014 10:38, Masahiro YAMADA <yamada.m@jp.panasonic.com> wrote:
>> Hi Simon,
>>
>>
>> 2014-10-29 1:29 GMT+09:00 Simon Glass <sjg@chromium.org>:
>>> Hi Masahiro,
>>>
>>> On 28 October 2014 10:25, Masahiro YAMADA <yamada.m@jp.panasonic.com> wrote:
>>>> Hi Gabe, Simon,
>>>>
>>>>
>>>> 2014-10-15 19:38 GMT+09:00 Simon Glass <sjg@chromium.org>:
>>>>> From: Gabe Black <gabeblack@chromium.org>
>>>>>
>>>>> inttypes.h defines format specifiers for printf which work with data types of
>>>>> particular sizes. stdlib.h is currently just a passthrough to malloc.h which
>>>>> has declarations of the various *alloc functions.
>>>>>
>>>>> Add the required #define to common.h so that these printf format specifiers
>>>>> will be made available.
>>>>>
>>>>> Signed-off-by: Gabe Black <gabeblack@google.com>
>>>>> Reviewed-by: Gabe Black <gabeblack@chromium.org>
>>>>> Tested-by: Gabe Black <gabeblack@chromium.org>
>>>>> Reviewed-by: Bill Richardson <wfrichar@google.com>
>>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>>>> (Replaced with a GPL version from glibc)
>>>>>
>>>> [snip]
>>>>> diff --git a/include/stdlib.h b/include/stdlib.h
>>>>> new file mode 100644
>>>>> index 0000000..6bc7fbb
>>>>> --- /dev/null
>>>>> +++ b/include/stdlib.h
>>>>> @@ -0,0 +1,12 @@
>>>>> +/*
>>>>> + *  Copyright (C) 2013 Google Inc.
>>>>> + *
>>>>> + * SPDX-License-Identifier:    GPL-2.0+
>>>>> + */
>>>>> +
>>>>> +#ifndef __STDLIB_H_
>>>>> +#define __STDLIB_H_
>>>>> +
>>>>> +#include <malloc.h>
>>>>> +
>>>>> +#endif /* __STDLIB_H_ */
>>>>> --
>>>>> 2.1.0.rc2.206.gedb03e5
>>>>
>>>> This patch is not clear to me.
>>>>
>>>> Why do we need include/stdlib.h ?
>>> This makes the U-Boot environment more similar to that used by other
>>> software, so we can more easily build it without lots of glue files.
>>> Normally stdlib.h defines malloc() and friends.
>> I am not happy about this.
>>
>> Our right direction is to make U-Boot environment more similar to the
>> Kernel, I think.
>>
>> stdlib.h shouldn't appear in bare metal code.
> That's right, we don't want to include this in U-Boot itself. But if
> you look at things in tools/ they include stdlib.h. With this header
> available, we can more easily compile external code into U-Boot.

So is it intended as fallback if the host doesn't have a stdlib.h?

Regards,
Jeroen

[U-Boot] [PATCH 02/10] Add some standard headers external code might need

[Simon Glass]

Hi,

On 28 October 2014 11:46, Jeroen Hofstee <jeroen@myspectrum.nl> wrote:
> Hello Simon,
>
>
> On 28-10-14 18:33, Simon Glass wrote:
>>
>> Hi Masahiro,
>>
>> On 28 October 2014 10:38, Masahiro YAMADA <yamada.m@jp.panasonic.com>
>> wrote:
>>>
>>> Hi Simon,
>>>
>>>
>>> 2014-10-29 1:29 GMT+09:00 Simon Glass <sjg@chromium.org>:
>>>>
>>>> Hi Masahiro,
>>>>
>>>> On 28 October 2014 10:25, Masahiro YAMADA <yamada.m@jp.panasonic.com>
>>>> wrote:
>>>>>
>>>>> Hi Gabe, Simon,
>>>>>
>>>>>
>>>>> 2014-10-15 19:38 GMT+09:00 Simon Glass <sjg@chromium.org>:
>>>>>>
>>>>>> From: Gabe Black <gabeblack@chromium.org>
>>>>>>
>>>>>> inttypes.h defines format specifiers for printf which work with data
>>>>>> types of
>>>>>> particular sizes. stdlib.h is currently just a passthrough to malloc.h
>>>>>> which
>>>>>> has declarations of the various *alloc functions.
>>>>>>
>>>>>> Add the required #define to common.h so that these printf format
>>>>>> specifiers
>>>>>> will be made available.
>>>>>>
>>>>>> Signed-off-by: Gabe Black <gabeblack@google.com>
>>>>>> Reviewed-by: Gabe Black <gabeblack@chromium.org>
>>>>>> Tested-by: Gabe Black <gabeblack@chromium.org>
>>>>>> Reviewed-by: Bill Richardson <wfrichar@google.com>
>>>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>>>>> (Replaced with a GPL version from glibc)
>>>>>>
>>>>> [snip]
>>>>>>
>>>>>> diff --git a/include/stdlib.h b/include/stdlib.h
>>>>>> new file mode 100644
>>>>>> index 0000000..6bc7fbb
>>>>>> --- /dev/null
>>>>>> +++ b/include/stdlib.h
>>>>>> @@ -0,0 +1,12 @@
>>>>>> +/*
>>>>>> + *  Copyright (C) 2013 Google Inc.
>>>>>> + *
>>>>>> + * SPDX-License-Identifier:    GPL-2.0+
>>>>>> + */
>>>>>> +
>>>>>> +#ifndef __STDLIB_H_
>>>>>> +#define __STDLIB_H_
>>>>>> +
>>>>>> +#include <malloc.h>
>>>>>> +
>>>>>> +#endif /* __STDLIB_H_ */
>>>>>> --
>>>>>> 2.1.0.rc2.206.gedb03e5
>>>>>
>>>>>
>>>>> This patch is not clear to me.
>>>>>
>>>>> Why do we need include/stdlib.h ?
>>>>
>>>> This makes the U-Boot environment more similar to that used by other
>>>> software, so we can more easily build it without lots of glue files.
>>>> Normally stdlib.h defines malloc() and friends.
>>>
>>> I am not happy about this.
>>>
>>> Our right direction is to make U-Boot environment more similar to the
>>> Kernel, I think.
>>>
>>> stdlib.h shouldn't appear in bare metal code.
>>
>> That's right, we don't want to include this in U-Boot itself. But if
>> you look at things in tools/ they include stdlib.h. With this header
>> available, we can more easily compile external code into U-Boot.
>
>
> So is it intended as fallback if the host doesn't have a stdlib.h?

Not really, more that for things that expect that header (and
inttypes.h which was also added) they can get it without needing
special #ifdefs for U-Boot.

Regards,
Simon

[U-Boot] [PATCH 02/10] Add some standard headers external code might need

[Masahiro YAMADA]

Hi Simon,

2014-10-29 3:24 GMT+09:00 Simon Glass <sjg@chromium.org>:
> Hi,
>
> On 28 October 2014 11:46, Jeroen Hofstee <jeroen@myspectrum.nl> wrote:
>> Hello Simon,
>>
>>
>> On 28-10-14 18:33, Simon Glass wrote:
>>>
>>> Hi Masahiro,
>>>
>>> On 28 October 2014 10:38, Masahiro YAMADA <yamada.m@jp.panasonic.com>
>>> wrote:
>>>>
>>>> Hi Simon,
>>>>
>>>>
>>>> 2014-10-29 1:29 GMT+09:00 Simon Glass <sjg@chromium.org>:
>>>>>
>>>>> Hi Masahiro,
>>>>>
>>>>> On 28 October 2014 10:25, Masahiro YAMADA <yamada.m@jp.panasonic.com>
>>>>> wrote:
>>>>>>
>>>>>> Hi Gabe, Simon,
>>>>>>
>>>>>>
>>>>>> 2014-10-15 19:38 GMT+09:00 Simon Glass <sjg@chromium.org>:
>>>>>>>
>>>>>>> From: Gabe Black <gabeblack@chromium.org>
>>>>>>>
>>>>>>> inttypes.h defines format specifiers for printf which work with data
>>>>>>> types of
>>>>>>> particular sizes. stdlib.h is currently just a passthrough to malloc.h
>>>>>>> which
>>>>>>> has declarations of the various *alloc functions.
>>>>>>>
>>>>>>> Add the required #define to common.h so that these printf format
>>>>>>> specifiers
>>>>>>> will be made available.
>>>>>>>
>>>>>>> Signed-off-by: Gabe Black <gabeblack@google.com>
>>>>>>> Reviewed-by: Gabe Black <gabeblack@chromium.org>
>>>>>>> Tested-by: Gabe Black <gabeblack@chromium.org>
>>>>>>> Reviewed-by: Bill Richardson <wfrichar@google.com>
>>>>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>>>>>> (Replaced with a GPL version from glibc)
>>>>>>>
>>>>>> [snip]
>>>>>>>
>>>>>>> diff --git a/include/stdlib.h b/include/stdlib.h
>>>>>>> new file mode 100644
>>>>>>> index 0000000..6bc7fbb
>>>>>>> --- /dev/null
>>>>>>> +++ b/include/stdlib.h
>>>>>>> @@ -0,0 +1,12 @@
>>>>>>> +/*
>>>>>>> + *  Copyright (C) 2013 Google Inc.
>>>>>>> + *
>>>>>>> + * SPDX-License-Identifier:    GPL-2.0+
>>>>>>> + */
>>>>>>> +
>>>>>>> +#ifndef __STDLIB_H_
>>>>>>> +#define __STDLIB_H_
>>>>>>> +
>>>>>>> +#include <malloc.h>
>>>>>>> +
>>>>>>> +#endif /* __STDLIB_H_ */
>>>>>>> --
>>>>>>> 2.1.0.rc2.206.gedb03e5
>>>>>>
>>>>>>
>>>>>> This patch is not clear to me.
>>>>>>
>>>>>> Why do we need include/stdlib.h ?
>>>>>
>>>>> This makes the U-Boot environment more similar to that used by other
>>>>> software, so we can more easily build it without lots of glue files.
>>>>> Normally stdlib.h defines malloc() and friends.
>>>>
>>>> I am not happy about this.
>>>>
>>>> Our right direction is to make U-Boot environment more similar to the
>>>> Kernel, I think.
>>>>
>>>> stdlib.h shouldn't appear in bare metal code.
>>>
>>> That's right, we don't want to include this in U-Boot itself. But if
>>> you look at things in tools/ they include stdlib.h. With this header
>>> available, we can more easily compile external code into U-Boot.
>>
>>
>> So is it intended as fallback if the host doesn't have a stdlib.h?
>
> Not really, more that for things that expect that header (and
> inttypes.h which was also added) they can get it without needing
> special #ifdefs for U-Boot.
>


Sorry, I still don't get it.
Could you explain user cases?




-- 
Best Regards
Masahiro Yamada

[U-Boot] [PATCH 02/10] Add some standard headers external code might need

[Simon Glass]

Hi Masahiro,

On 29 October 2014 08:06, Masahiro YAMADA <yamada.m@jp.panasonic.com> wrote:
> Hi Simon,
>
> 2014-10-29 3:24 GMT+09:00 Simon Glass <sjg@chromium.org>:
>> Hi,
>>
>> On 28 October 2014 11:46, Jeroen Hofstee <jeroen@myspectrum.nl> wrote:
>>> Hello Simon,
>>>
>>>
>>> On 28-10-14 18:33, Simon Glass wrote:
>>>>
>>>> Hi Masahiro,
>>>>
>>>> On 28 October 2014 10:38, Masahiro YAMADA <yamada.m@jp.panasonic.com>
>>>> wrote:
>>>>>
>>>>> Hi Simon,
>>>>>
>>>>>
>>>>> 2014-10-29 1:29 GMT+09:00 Simon Glass <sjg@chromium.org>:
>>>>>>
>>>>>> Hi Masahiro,
>>>>>>
>>>>>> On 28 October 2014 10:25, Masahiro YAMADA <yamada.m@jp.panasonic.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Gabe, Simon,
>>>>>>>
>>>>>>>
>>>>>>> 2014-10-15 19:38 GMT+09:00 Simon Glass <sjg@chromium.org>:
>>>>>>>>
>>>>>>>> From: Gabe Black <gabeblack@chromium.org>
>>>>>>>>
>>>>>>>> inttypes.h defines format specifiers for printf which work with data
>>>>>>>> types of
>>>>>>>> particular sizes. stdlib.h is currently just a passthrough to malloc.h
>>>>>>>> which
>>>>>>>> has declarations of the various *alloc functions.
>>>>>>>>
>>>>>>>> Add the required #define to common.h so that these printf format
>>>>>>>> specifiers
>>>>>>>> will be made available.
>>>>>>>>
>>>>>>>> Signed-off-by: Gabe Black <gabeblack@google.com>
>>>>>>>> Reviewed-by: Gabe Black <gabeblack@chromium.org>
>>>>>>>> Tested-by: Gabe Black <gabeblack@chromium.org>
>>>>>>>> Reviewed-by: Bill Richardson <wfrichar@google.com>
>>>>>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>>>>>>> (Replaced with a GPL version from glibc)
>>>>>>>>
>>>>>>> [snip]
>>>>>>>>
>>>>>>>> diff --git a/include/stdlib.h b/include/stdlib.h
>>>>>>>> new file mode 100644
>>>>>>>> index 0000000..6bc7fbb
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/include/stdlib.h
>>>>>>>> @@ -0,0 +1,12 @@
>>>>>>>> +/*
>>>>>>>> + *  Copyright (C) 2013 Google Inc.
>>>>>>>> + *
>>>>>>>> + * SPDX-License-Identifier:    GPL-2.0+
>>>>>>>> + */
>>>>>>>> +
>>>>>>>> +#ifndef __STDLIB_H_
>>>>>>>> +#define __STDLIB_H_
>>>>>>>> +
>>>>>>>> +#include <malloc.h>
>>>>>>>> +
>>>>>>>> +#endif /* __STDLIB_H_ */
>>>>>>>> --
>>>>>>>> 2.1.0.rc2.206.gedb03e5
>>>>>>>
>>>>>>>
>>>>>>> This patch is not clear to me.
>>>>>>>
>>>>>>> Why do we need include/stdlib.h ?
>>>>>>
>>>>>> This makes the U-Boot environment more similar to that used by other
>>>>>> software, so we can more easily build it without lots of glue files.
>>>>>> Normally stdlib.h defines malloc() and friends.
>>>>>
>>>>> I am not happy about this.
>>>>>
>>>>> Our right direction is to make U-Boot environment more similar to the
>>>>> Kernel, I think.
>>>>>
>>>>> stdlib.h shouldn't appear in bare metal code.
>>>>
>>>> That's right, we don't want to include this in U-Boot itself. But if
>>>> you look at things in tools/ they include stdlib.h. With this header
>>>> available, we can more easily compile external code into U-Boot.
>>>
>>>
>>> So is it intended as fallback if the host doesn't have a stdlib.h?
>>
>> Not really, more that for things that expect that header (and
>> inttypes.h which was also added) they can get it without needing
>> special #ifdefs for U-Boot.
>>
>
>
> Sorry, I still don't get it.
> Could you explain user cases?

If you have a C file which has '#include <stdlib.h> in it, because it
builds in another project as well as U-Boot, and needs mallloc(), then
you want to build it with U-Boot and include <common.h>, etc. then you
need U-Boot to have stdlib.h, or add a dummy stdlib.h in that project.
I am trying to make is easier for this case. This is a minor point,
but little fish-hooks can be frustrating.

Regards,
Simon

[U-Boot] [PATCH 02/10] Add some standard headers external code might need

[Masahiro Yamada]

Hi Simon,



On Wed, 29 Oct 2014 19:43:26 -0600
Simon Glass <sjg@chromium.org> wrote:

> Hi Masahiro,
> 
> On 29 October 2014 08:06, Masahiro YAMADA <yamada.m@jp.panasonic.com> wrote:
> > Hi Simon,
> >
> > 2014-10-29 3:24 GMT+09:00 Simon Glass <sjg@chromium.org>:
> >> Hi,
> >>
> >> On 28 October 2014 11:46, Jeroen Hofstee <jeroen@myspectrum.nl> wrote:
> >>> Hello Simon,
> >>>
> >>>
> >>> On 28-10-14 18:33, Simon Glass wrote:
> >>>>
> >>>> Hi Masahiro,
> >>>>
> >>>> On 28 October 2014 10:38, Masahiro YAMADA <yamada.m@jp.panasonic.com>
> >>>> wrote:
> >>>>>
> >>>>> Hi Simon,
> >>>>>
> >>>>>
> >>>>> 2014-10-29 1:29 GMT+09:00 Simon Glass <sjg@chromium.org>:
> >>>>>>
> >>>>>> Hi Masahiro,
> >>>>>>
> >>>>>> On 28 October 2014 10:25, Masahiro YAMADA <yamada.m@jp.panasonic.com>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> Hi Gabe, Simon,
> >>>>>>>
> >>>>>>>
> >>>>>>> 2014-10-15 19:38 GMT+09:00 Simon Glass <sjg@chromium.org>:
> >>>>>>>>
> >>>>>>>> From: Gabe Black <gabeblack@chromium.org>
> >>>>>>>>
> >>>>>>>> inttypes.h defines format specifiers for printf which work with data
> >>>>>>>> types of
> >>>>>>>> particular sizes. stdlib.h is currently just a passthrough to malloc.h
> >>>>>>>> which
> >>>>>>>> has declarations of the various *alloc functions.
> >>>>>>>>
> >>>>>>>> Add the required #define to common.h so that these printf format
> >>>>>>>> specifiers
> >>>>>>>> will be made available.
> >>>>>>>>
> >>>>>>>> Signed-off-by: Gabe Black <gabeblack@google.com>
> >>>>>>>> Reviewed-by: Gabe Black <gabeblack@chromium.org>
> >>>>>>>> Tested-by: Gabe Black <gabeblack@chromium.org>
> >>>>>>>> Reviewed-by: Bill Richardson <wfrichar@google.com>
> >>>>>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
> >>>>>>>> (Replaced with a GPL version from glibc)
> >>>>>>>>
> >>>>>>> [snip]
> >>>>>>>>
> >>>>>>>> diff --git a/include/stdlib.h b/include/stdlib.h
> >>>>>>>> new file mode 100644
> >>>>>>>> index 0000000..6bc7fbb
> >>>>>>>> --- /dev/null
> >>>>>>>> +++ b/include/stdlib.h
> >>>>>>>> @@ -0,0 +1,12 @@
> >>>>>>>> +/*
> >>>>>>>> + *  Copyright (C) 2013 Google Inc.
> >>>>>>>> + *
> >>>>>>>> + * SPDX-License-Identifier:    GPL-2.0+
> >>>>>>>> + */
> >>>>>>>> +
> >>>>>>>> +#ifndef __STDLIB_H_
> >>>>>>>> +#define __STDLIB_H_
> >>>>>>>> +
> >>>>>>>> +#include <malloc.h>
> >>>>>>>> +
> >>>>>>>> +#endif /* __STDLIB_H_ */
> >>>>>>>> --
> >>>>>>>> 2.1.0.rc2.206.gedb03e5
> >>>>>>>
> >>>>>>>
> >>>>>>> This patch is not clear to me.
> >>>>>>>
> >>>>>>> Why do we need include/stdlib.h ?
> >>>>>>
> >>>>>> This makes the U-Boot environment more similar to that used by other
> >>>>>> software, so we can more easily build it without lots of glue files.
> >>>>>> Normally stdlib.h defines malloc() and friends.
> >>>>>
> >>>>> I am not happy about this.
> >>>>>
> >>>>> Our right direction is to make U-Boot environment more similar to the
> >>>>> Kernel, I think.
> >>>>>
> >>>>> stdlib.h shouldn't appear in bare metal code.
> >>>>
> >>>> That's right, we don't want to include this in U-Boot itself. But if
> >>>> you look at things in tools/ they include stdlib.h. With this header
> >>>> available, we can more easily compile external code into U-Boot.
> >>>
> >>>
> >>> So is it intended as fallback if the host doesn't have a stdlib.h?
> >>
> >> Not really, more that for things that expect that header (and
> >> inttypes.h which was also added) they can get it without needing
> >> special #ifdefs for U-Boot.
> >>
> >
> >
> > Sorry, I still don't get it.
> > Could you explain user cases?
> 
> If you have a C file which has '#include <stdlib.h> in it, because it
> builds in another project as well as U-Boot, and needs mallloc(), then
> you want to build it with U-Boot and include <common.h>, etc. then you
> need U-Boot to have stdlib.h, or add a dummy stdlib.h in that project.
> I am trying to make is easier for this case. This is a minor point,
> but little fish-hooks can be frustrating.
> 

I understand what you want to do,
but I am not sure if this is a right decision.

Mixing the same header name sometimes causes a mess.



Best Regards
Masahiro Yamada

[U-Boot] [PATCH 02/10] Add some standard headers external code might need

[Simon Glass]

Hi Masahiro,

On 30 October 2014 01:53, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote:
> Hi Simon,
>
>
>
> On Wed, 29 Oct 2014 19:43:26 -0600
> Simon Glass <sjg@chromium.org> wrote:
>
>> Hi Masahiro,
>>
>> On 29 October 2014 08:06, Masahiro YAMADA <yamada.m@jp.panasonic.com> wrote:
>> > Hi Simon,
>> >
>> > 2014-10-29 3:24 GMT+09:00 Simon Glass <sjg@chromium.org>:
>> >> Hi,
>> >>
>> >> On 28 October 2014 11:46, Jeroen Hofstee <jeroen@myspectrum.nl> wrote:
>> >>> Hello Simon,
>> >>>
>> >>>
>> >>> On 28-10-14 18:33, Simon Glass wrote:
>> >>>>
>> >>>> Hi Masahiro,
>> >>>>
>> >>>> On 28 October 2014 10:38, Masahiro YAMADA <yamada.m@jp.panasonic.com>
>> >>>> wrote:
>> >>>>>
>> >>>>> Hi Simon,
>> >>>>>
>> >>>>>
>> >>>>> 2014-10-29 1:29 GMT+09:00 Simon Glass <sjg@chromium.org>:
>> >>>>>>
>> >>>>>> Hi Masahiro,
>> >>>>>>
>> >>>>>> On 28 October 2014 10:25, Masahiro YAMADA <yamada.m@jp.panasonic.com>
>> >>>>>> wrote:
>> >>>>>>>
>> >>>>>>> Hi Gabe, Simon,
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 2014-10-15 19:38 GMT+09:00 Simon Glass <sjg@chromium.org>:
>> >>>>>>>>
>> >>>>>>>> From: Gabe Black <gabeblack@chromium.org>
>> >>>>>>>>
>> >>>>>>>> inttypes.h defines format specifiers for printf which work with data
>> >>>>>>>> types of
>> >>>>>>>> particular sizes. stdlib.h is currently just a passthrough to malloc.h
>> >>>>>>>> which
>> >>>>>>>> has declarations of the various *alloc functions.
>> >>>>>>>>
>> >>>>>>>> Add the required #define to common.h so that these printf format
>> >>>>>>>> specifiers
>> >>>>>>>> will be made available.
>> >>>>>>>>
>> >>>>>>>> Signed-off-by: Gabe Black <gabeblack@google.com>
>> >>>>>>>> Reviewed-by: Gabe Black <gabeblack@chromium.org>
>> >>>>>>>> Tested-by: Gabe Black <gabeblack@chromium.org>
>> >>>>>>>> Reviewed-by: Bill Richardson <wfrichar@google.com>
>> >>>>>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>> >>>>>>>> (Replaced with a GPL version from glibc)
>> >>>>>>>>
>> >>>>>>> [snip]
>> >>>>>>>>
>> >>>>>>>> diff --git a/include/stdlib.h b/include/stdlib.h
>> >>>>>>>> new file mode 100644
>> >>>>>>>> index 0000000..6bc7fbb
>> >>>>>>>> --- /dev/null
>> >>>>>>>> +++ b/include/stdlib.h
>> >>>>>>>> @@ -0,0 +1,12 @@
>> >>>>>>>> +/*
>> >>>>>>>> + *  Copyright (C) 2013 Google Inc.
>> >>>>>>>> + *
>> >>>>>>>> + * SPDX-License-Identifier:    GPL-2.0+
>> >>>>>>>> + */
>> >>>>>>>> +
>> >>>>>>>> +#ifndef __STDLIB_H_
>> >>>>>>>> +#define __STDLIB_H_
>> >>>>>>>> +
>> >>>>>>>> +#include <malloc.h>
>> >>>>>>>> +
>> >>>>>>>> +#endif /* __STDLIB_H_ */
>> >>>>>>>> --
>> >>>>>>>> 2.1.0.rc2.206.gedb03e5
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> This patch is not clear to me.
>> >>>>>>>
>> >>>>>>> Why do we need include/stdlib.h ?
>> >>>>>>
>> >>>>>> This makes the U-Boot environment more similar to that used by other
>> >>>>>> software, so we can more easily build it without lots of glue files.
>> >>>>>> Normally stdlib.h defines malloc() and friends.
>> >>>>>
>> >>>>> I am not happy about this.
>> >>>>>
>> >>>>> Our right direction is to make U-Boot environment more similar to the
>> >>>>> Kernel, I think.
>> >>>>>
>> >>>>> stdlib.h shouldn't appear in bare metal code.
>> >>>>
>> >>>> That's right, we don't want to include this in U-Boot itself. But if
>> >>>> you look at things in tools/ they include stdlib.h. With this header
>> >>>> available, we can more easily compile external code into U-Boot.
>> >>>
>> >>>
>> >>> So is it intended as fallback if the host doesn't have a stdlib.h?
>> >>
>> >> Not really, more that for things that expect that header (and
>> >> inttypes.h which was also added) they can get it without needing
>> >> special #ifdefs for U-Boot.
>> >>
>> >
>> >
>> > Sorry, I still don't get it.
>> > Could you explain user cases?
>>
>> If you have a C file which has '#include <stdlib.h> in it, because it
>> builds in another project as well as U-Boot, and needs mallloc(), then
>> you want to build it with U-Boot and include <common.h>, etc. then you
>> need U-Boot to have stdlib.h, or add a dummy stdlib.h in that project.
>> I am trying to make is easier for this case. This is a minor point,
>> but little fish-hooks can be frustrating.
>>
>
> I understand what you want to do,
> but I am not sure if this is a right decision.
>
> Mixing the same header name sometimes causes a mess.

That's true although I don't really see a big issue here.

IMO image.c and the like suffer from having two sets of headers - one
for building in U-Boot and one for building outside. I thought maybe
the solution was do have a section in common.h to deal with the
differences, but then when I looked more I wasn't sure it was an
improvement...

Regards,
Simon

[U-Boot] [PATCH 04/10] Use uint64_t for time types

[Masahiro YAMADA]

Hi Simon,


2014-10-15 19:38 GMT+09:00 Simon Glass <sjg@chromium.org>:
> Unfortunately 'unsigned long long' and 'uint64_t' are not necessarily
> compatible on 64-bit machines. Use the correct typedef instead of
> writing the supposed type out in full.

I doubt this statement.

I think "unsigned long long" always has 64bit width.

(C specification guarantees that the width of "unsigned long long"
is greater or equal to 64 bit)

Could you tell me which toolchain violates it?




-- 
Best Regards
Masahiro Yamada

[U-Boot] [PATCH 08/10] scsi: Use correct printf() format string for uintptr_t

[Masahiro YAMADA]

2014-10-15 19:38 GMT+09:00 Simon Glass <sjg@chromium.org>:
> Use the inttypes header file to provide this.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
>  common/cmd_scsi.c | 9 +++++----
>  1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/common/cmd_scsi.c b/common/cmd_scsi.c
> index b3f7687..cbc107e 100644
> --- a/common/cmd_scsi.c
> +++ b/common/cmd_scsi.c
> @@ -10,6 +10,7 @@
>   */
>  #include <common.h>
>  #include <command.h>
> +#include <inttypes.h>
>  #include <asm/processor.h>
>  #include <scsi.h>
>  #include <image.h>
> @@ -391,7 +392,7 @@ static ulong scsi_read(int device, lbaint_t blknr, lbaint_t blkcnt,
>                         blks=0;
>                 }
>                 debug("scsi_read_ext: startblk " LBAF
> -                     ", blccnt %x buffer %lx\n",
> +                     ", blccnt %x buffer %" PRIXPTR "\n",
>                       start, smallblks, buf_addr);


The root cause of the problem is to use uintptr_t provided by
the compiler.

"unsigned long" can store a pointer whether it is 32bit or 64bit system.
(I have never seen LLP64 on Unix-like 64bit system.)



-- 
Best Regards
Masahiro Yamada

[U-Boot] [PATCH 04/10] Use uint64_t for time types

[Simon Glass]

Hi Masahiro,

On 15 December 2014 at 09:55, Masahiro YAMADA <yamada.m@jp.panasonic.com> wrote:
> Hi Simon,
>
>
> 2014-10-15 19:38 GMT+09:00 Simon Glass <sjg@chromium.org>:
>> Unfortunately 'unsigned long long' and 'uint64_t' are not necessarily
>> compatible on 64-bit machines. Use the correct typedef instead of
>> writing the supposed type out in full.
>
> I doubt this statement.
>
> I think "unsigned long long" always has 64bit width.
>
> (C specification guarantees that the width of "unsigned long long"
> is greater or equal to 64 bit)
>
> Could you tell me which toolchain violates it?

Some compilers use 'unsigned long' and some use 'unsigned long long'.
I think that is the core of the problem.

We don't have a problem with unsigned long long not being at least
64-bit. I wonder whether some toolchains use 128-bit for this?

Regards,
Simon

[U-Boot] [PATCH 04/10] Use uint64_t for time types

[Masahiro YAMADA]

Hi Simon,


2014-12-16 3:38 GMT+09:00 Simon Glass <sjg@chromium.org>:
> Hi Masahiro,
>
> On 15 December 2014 at 09:55, Masahiro YAMADA <yamada.m@jp.panasonic.com> wrote:
>> Hi Simon,
>>
>>
>> 2014-10-15 19:38 GMT+09:00 Simon Glass <sjg@chromium.org>:
>>> Unfortunately 'unsigned long long' and 'uint64_t' are not necessarily
>>> compatible on 64-bit machines. Use the correct typedef instead of
>>> writing the supposed type out in full.
>>
>> I doubt this statement.
>>
>> I think "unsigned long long" always has 64bit width.
>>
>> (C specification guarantees that the width of "unsigned long long"
>> is greater or equal to 64 bit)
>>
>> Could you tell me which toolchain violates it?
>
> Some compilers use 'unsigned long' and some use 'unsigned long long'.
> I think that is the core of the problem.
>
> We don't have a problem with unsigned long long not being at least
> 64-bit. I wonder whether some toolchains use 128-bit for this?

That is not my point.

"unsigned long long" has 64-bit width whether on 32bit compilers
or 64bit compilers or whatever.


We should always hard-code the definition:
  typedef  unsigned long long  uint64_t;

That's all.  We can always use "%llx" for printing uint64_t or u64.
(and this is what U-boot (and Linux) had used until you broke the consistency.)


If we include <stdint.h>, you are right.  It is the beginning of nightmare.
Some compilers use  "unsigned long" for uint64_t and some use
"unsigned long long"
for uint64_t.

What did it buy us?

You just introduced unreadability by using PRIu64  for printing 64bit
width variables.




Best Regards
Masahiro Yamada

[U-Boot] [PATCH 04/10] Use uint64_t for time types

[Simon Glass]

Hi Masahiro,

On 15 December 2014 at 18:38, Masahiro YAMADA <yamada.m@jp.panasonic.com> wrote:
>
> Hi Simon,
>
>
> 2014-12-16 3:38 GMT+09:00 Simon Glass <sjg@chromium.org>:
> > Hi Masahiro,
> >
> > On 15 December 2014 at 09:55, Masahiro YAMADA <yamada.m@jp.panasonic.com> wrote:
> >> Hi Simon,
> >>
> >>
> >> 2014-10-15 19:38 GMT+09:00 Simon Glass <sjg@chromium.org>:
> >>> Unfortunately 'unsigned long long' and 'uint64_t' are not necessarily
> >>> compatible on 64-bit machines. Use the correct typedef instead of
> >>> writing the supposed type out in full.
> >>
> >> I doubt this statement.
> >>
> >> I think "unsigned long long" always has 64bit width.
> >>
> >> (C specification guarantees that the width of "unsigned long long"
> >> is greater or equal to 64 bit)
> >>
> >> Could you tell me which toolchain violates it?
> >
> > Some compilers use 'unsigned long' and some use 'unsigned long long'.
> > I think that is the core of the problem.
> >
> > We don't have a problem with unsigned long long not being at least
> > 64-bit. I wonder whether some toolchains use 128-bit for this?
>
> That is not my point.
>
> "unsigned long long" has 64-bit width whether on 32bit compilers
> or 64bit compilers or whatever.

I think that might be true at least for gcc. But in principle a 64-bit
machine should use 128-bit for long long.

>
>
> We should always hard-code the definition:
>   typedef  unsigned long long  uint64_t;
>
> That's all.  We can always use "%llx" for printing uint64_t or u64.
> (and this is what U-boot (and Linux) had used until you broke the consistency.)
>
>
> If we include <stdint.h>, you are right.  It is the beginning of nightmare.
> Some compilers use  "unsigned long" for uint64_t and some use
> "unsigned long long"
> for uint64_t.
>
> What did it buy us?
>
> You just introduced unreadability by using PRIu64  for printing 64bit
> width variables.

I have also hit this problem with m68k and one other compiler in
U-Boot. Is it because these compilers are broken, or something else?

Regards,
Simon

[U-Boot] [PATCH 04/10] Use uint64_t for time types

[Masahiro Yamada]

Hi Simon,



On Tue, 16 Dec 2014 21:38:34 -0700
Simon Glass <sjg@chromium.org> wrote:

> Hi Masahiro,
> 
> On 15 December 2014 at 18:38, Masahiro YAMADA <yamada.m@jp.panasonic.com> wrote:
> >
> > Hi Simon,
> >
> >
> > 2014-12-16 3:38 GMT+09:00 Simon Glass <sjg@chromium.org>:
> > > Hi Masahiro,
> > >
> > > On 15 December 2014 at 09:55, Masahiro YAMADA <yamada.m@jp.panasonic.com> wrote:
> > >> Hi Simon,
> > >>
> > >>
> > >> 2014-10-15 19:38 GMT+09:00 Simon Glass <sjg@chromium.org>:
> > >>> Unfortunately 'unsigned long long' and 'uint64_t' are not necessarily
> > >>> compatible on 64-bit machines. Use the correct typedef instead of
> > >>> writing the supposed type out in full.
> > >>
> > >> I doubt this statement.
> > >>
> > >> I think "unsigned long long" always has 64bit width.
> > >>
> > >> (C specification guarantees that the width of "unsigned long long"
> > >> is greater or equal to 64 bit)
> > >>
> > >> Could you tell me which toolchain violates it?
> > >
> > > Some compilers use 'unsigned long' and some use 'unsigned long long'.
> > > I think that is the core of the problem.
> > >
> > > We don't have a problem with unsigned long long not being at least
> > > 64-bit. I wonder whether some toolchains use 128-bit for this?
> >
> > That is not my point.
> >
> > "unsigned long long" has 64-bit width whether on 32bit compilers
> > or 64bit compilers or whatever.
> 
> I think that might be true at least for gcc. But in principle a 64-bit
> machine should use 128-bit for long long.

128-bit variable?  Are you kidding?

I am not talking about "in principle" things, but talking
about real compilers.

So, on which compiler do you have problems?
For instance, please?



> >
> >
> > We should always hard-code the definition:
> >   typedef  unsigned long long  uint64_t;
> >
> > That's all.  We can always use "%llx" for printing uint64_t or u64.
> > (and this is what U-boot (and Linux) had used until you broke the consistency.)
> >
> >
> > If we include <stdint.h>, you are right.  It is the beginning of nightmare.
> > Some compilers use  "unsigned long" for uint64_t and some use
> > "unsigned long long"
> > for uint64_t.
> >
> > What did it buy us?
> >
> > You just introduced unreadability by using PRIu64  for printing 64bit
> > width variables.
> 
> I have also hit this problem with m68k and one other compiler in
> U-Boot. Is it because these compilers are broken, or something else?


I guess you are mentioning "size_t" problem on m68k.
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/188121/focus=188932

If so, you are already confused.

"size_t" is another problem that should be discussed separetely.


Notice
 [1] uint32_t, int32_t, uint64_t, int64_t, uintptr_t are provided by <stdint.h>
 [2] PRIx32, PRIx64, PRId32, PRId64 etc. are provided by <inttypes.h>
 [3] size_t is provided by <stddef.h>


We are talking about [1] and [2].

And also notice [1] and [2] should be provided by the same compiler to work correctly.

[3] should not be mixed up with [1].


If you are interested in the topic about the conflict between "size_t" type and "%z",
I can introduce you another thread.

But I am not showing that, in case this discussion goes wrong.




Best Regards
Masahiro Yamada