[U-Boot] [PATCH] [v3] fix print_size printing fractional gigabyte numbers on 32-bit platforms

[U-Boot] [PATCH] [v3] fix print_size printing fractional gigabyte numbers on 32-bit platforms

[Timur Tabi]

In print_size(), the math that calculates the fractional remainder of a number
used the same integer size as a physical address.  However, the "10 *" factor
of the algorithm means that a large number (e.g. 1.5GB) can overflow the
integer if we're running on a 32-bit system.  Therefore, we need to
disassociate this function from the size of a physical address.

Signed-off-by: Timur Tabi <timur@freescale.com>
---
 lib_generic/display_options.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib_generic/display_options.c b/lib_generic/display_options.c
index 2dc2567..08a7914 100644
--- a/lib_generic/display_options.c
+++ b/lib_generic/display_options.c
@@ -45,8 +45,8 @@ int display_options (void)
  */
 void print_size (phys_size_t size, const char *s)
 {
-	ulong m = 0, n;
-	phys_size_t d = 1 << 30;		/* 1 GB */
+	unsigned long m = 0, n;
+	unsigned long long d = 1 << 30; 	/* 1 GB */
 	char  c = 'G';
 
 	if (size < d) {			/* try MB */
-- 
1.6.5

[U-Boot] [PATCH] allow print_size to print large numbers on 32-bit systems

[Timur Tabi]

Modify print_size() so that it can accept numbers larger than 4GB on 32-bit
systems.

Signed-off-by: Timur Tabi <timur@freescale.com>
---
 include/common.h              |    2 +-
 lib_generic/display_options.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/common.h b/include/common.h
index a133e34..4e77727 100644
--- a/include/common.h
+++ b/include/common.h
@@ -218,7 +218,7 @@ void	hang		(void) __attribute__ ((noreturn));
 /* */
 phys_size_t initdram (int);
 int	display_options (void);
-void	print_size (phys_size_t, const char *);
+void	print_size(unsigned long long, const char *);
 int	print_buffer (ulong addr, void* data, uint width, uint count, uint linelen);
 
 /* common/main.c */
diff --git a/lib_generic/display_options.c b/lib_generic/display_options.c
index 08a7914..da17a62 100644
--- a/lib_generic/display_options.c
+++ b/lib_generic/display_options.c
@@ -43,7 +43,7 @@ int display_options (void)
  * xxx GB, or xxx.y GB as needed; allow for optional trailing string
  * (like "\n")
  */
-void print_size (phys_size_t size, const char *s)
+void print_size(unsigned long long size, const char *s)
 {
 	unsigned long m = 0, n;
 	unsigned long long d = 1 << 30; 	/* 1 GB */
-- 
1.6.5

[U-Boot] [PATCH] allow print_size to print large numbers on 32-bit systems

[Wolfgang Denk]

Dear Timur Tabi,

In message <1269990179-23666-2-git-send-email-timur@freescale.com> you wrote:
> Modify print_size() so that it can accept numbers larger than 4GB on 32-bit
> systems.
> 
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
>  include/common.h              |    2 +-
>  lib_generic/display_options.c |    2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

Hm... if we go so far, we should probably also prepare for bigger
prefixes, like printing TB ?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
You can observe a lot just by watchin'.                  - Yogi Berra

[U-Boot] [PATCH] allow print_size to print large numbers on 32-bit systems

[Timur Tabi]

Wolfgang Denk wrote:
> Dear Timur Tabi,
> 
> In message <1269990179-23666-2-git-send-email-timur@freescale.com> you wrote:
>> Modify print_size() so that it can accept numbers larger than 4GB on 32-bit
>> systems.
>>
>> Signed-off-by: Timur Tabi <timur@freescale.com>
>> ---
>>  include/common.h              |    2 +-
>>  lib_generic/display_options.c |    2 +-
>>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> Hm... if we go so far, we should probably also prepare for bigger
> prefixes, like printing TB ?

I suppose.  The purpose behind my patch was only to allow 32-bit systems to report when the board has 8GB of DDR.  I didn't see much need for anything else.  If you really think it's important, I can post an updated version of the patch.

-- 
Timur Tabi
Linux kernel developer at Freescale

[U-Boot] [PATCH] allow print_size to print large numbers on 32-bit systems

[Wolfgang Denk]

Dear Timur Tabi,

In message <4BBF8DC3.4090408@freescale.com> you wrote:
>
> > Hm... if we go so far, we should probably also prepare for bigger
> > prefixes, like printing TB ?
> 
> I suppose.  The purpose behind my patch was only to allow 32-bit systems to report when the board has 8GB of DDR.  I didn't see much need for anything else.  If you really think it's important, I can post an updated version of the patch.

If we make this change, we can probably use this function as well to
print the size of storage devices like NAND, USB Mass Storage, hard
disk drives, etc.  Eventually we can clean up some pieces of code
then...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Only in our dreams we are free.  The rest of the time we need  wages.
                                    - Terry Pratchett, _Wyrd Sisters_

[U-Boot] [PATCH] allow print_size to print large numbers on 32-bit systems

[Timur Tabi]

On Fri, Apr 9, 2010 at 3:40 PM, Wolfgang Denk <wd@denx.de> wrote:

> If we make this change, we can probably use this function as well to
> print the size of storage devices like NAND, USB Mass Storage, hard
> disk drives, etc. ?Eventually we can clean up some pieces of code
> then...

I'm working on it now.  I did notice something odd, though.  The
strings for sizes are GB, MB, and kB.  Why is the "k" lowercase?

-- 
Timur Tabi
Linux kernel developer at Freescale

[U-Boot] [PATCH] allow print_size to print large numbers on 32-bit systems

[Nick Thompson]

On 12/04/10 17:12, Timur Tabi wrote:
> On Fri, Apr 9, 2010 at 3:40 PM, Wolfgang Denk <wd@denx.de> wrote:
> 
>> If we make this change, we can probably use this function as well to
>> print the size of storage devices like NAND, USB Mass Storage, hard
>> disk drives, etc.  Eventually we can clean up some pieces of code
>> then...
> 
> I'm working on it now.  I did notice something odd, though.  The
> strings for sizes are GB, MB, and kB.  Why is the "k" lowercase?
> 

To differentiate from "K", which means 1000, rather than 1024.
Example Kg = 1000 grammes. kB = 1024 Bytes

Nick

[U-Boot] [PATCH] allow print_size to print large numbers on 32-bit systems

[Timur Tabi]

Nick Thompson wrote:

> To differentiate from "K", which means 1000, rather than 1024.

I don't think that's correct.  I understand the 1000/1024 debate, but my understanding is that

KB = 1000 bytes
KiB = 1024 bytes

(personally, I think the whole kibi-byte thing is stupid, and we should just say that K=1024 when talking about memory sizes, but whatever)

I've never seen K=1000 and k=1024.  Then why don't we do "mB" instead of MB?  By your logical, M=1000000 and m=1048576


-- 
Timur Tabi
Linux kernel developer at Freescale

[U-Boot] [PATCH] allow print_size to print large numbers on 32-bit systems

[Nick Thompson]

On 12/04/10 17:21, Timur Tabi wrote:
> Nick Thompson wrote:
> 
>> To differentiate from "K", which means 1000, rather than 1024.
> 
> I don't think that's correct.  I understand the 1000/1024 debate, but my understanding is that
> 
> KB = 1000 bytes
> KiB = 1024 bytes
> 
> (personally, I think the whole kibi-byte thing is stupid, and we should just say that K=1024 when talking about memory sizes, but whatever)
> 
> I've never seen K=1000 and k=1024.  Then why don't we do "mB" instead of MB?  By your logical, M=1000000 and m=1048576
> 

Hmm, yes, my bad. http://physics.nist.gov/cuu/Units/prefixes.html lists SI prefixes and "k" = 1000. "m" is milli of course. "K" is not used by SI, so might be free for 1024...?

Nick.

[U-Boot] [PATCH] allow print_size to print large numbers on 32-bit systems

[Wolfgang Denk]

Dear Nick Thompson,

In message <4BC34758.3050706@ge.com> you wrote:
>
> > I'm working on it now.  I did notice something odd, though.  The
> > strings for sizes are GB, MB, and kB.  Why is the "k" lowercase?
> 
> To differentiate from "K", which means 1000, rather than 1024.
> Example Kg = 1000 grammes. kB = 1024 Bytes

No, that's actually wrong. The official preffix for "kilo" (meaning
1000) is 'k', i. e. 1 kg = 1000 g.

The prefix for 1024 is "Ki".

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Intel's new motto: United we stand. Divided we fall!

[U-Boot] [PATCH] allow print_size to print large numbers on 32-bit systems

[Wolfgang Denk]

Dear Timur Tabi,

In message <x2ped82fe3e1004120912u313a0c4du533a91f292ceaccc@mail.gmail.com> you wrote:
> On Fri, Apr 9, 2010 at 3:40 PM, Wolfgang Denk <wd@denx.de> wrote:
> 
> > If we make this change, we can probably use this function as well to
> > print the size of storage devices like NAND, USB Mass Storage, hard
> > disk drives, etc. =A0Eventually we can clean up some pieces of code
> > then...
> 
> I'm working on it now.  I did notice something odd, though.  The
> strings for sizes are GB, MB, and kB.  Why is the "k" lowercase?

H[iy]st[oe]ric reasons, probably.

We should use standardized names now, i. e. GiB, MiB, KiB, etc.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Madness takes its toll. Please have exact change.

[U-Boot] [PATCH] allow print_size to print large numbers on 32-bit systems

[Timur Tabi]

Wolfgang Denk wrote:
> We should use standardized names now, i. e. GiB, MiB, KiB, etc.

Ugh.  I'm not sure everyone recognizes those acronyms.  I'm expecting a lot of people to say, "What the hell is MiB?  Men in Black?"

-- 
Timur Tabi
Linux kernel developer at Freescale

[U-Boot] [PATCH] allow print_size to print large numbers on 32-bit systems

[Wolfgang Denk]

Dear Timur Tabi,

In message <4BC36057.30805@freescale.com> you wrote:
> Wolfgang Denk wrote:
> > We should use standardized names now, i. e. GiB, MiB, KiB, etc.
> 
> Ugh.  I'm not sure everyone recognizes those acronyms.  I'm expecting a lot of people to say, "What the hell is MiB?  Men in Black?"

There are also people in the world who don't really understand what
mph or "gallons per horsepower-hour" (one of my favorites) are.

But these are the official standardized IEC binary prefixes, and we
should rather use these instead of anything else.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Machines take me by surprise with great frequency.      - Alan Turing

[U-Boot] [PATCH] allow print_size to print large numbers on 32-bit systems

[Scott Wood]

Timur Tabi wrote:
> Wolfgang Denk wrote:
>> We should use standardized names now, i. e. GiB, MiB, KiB, etc.
> 
> Ugh.  I'm not sure everyone recognizes those acronyms.  I'm expecting a lot of people to say, "What the hell is MiB?  Men in Black?"

It's used often enough (including many places in U-Boot already), and 
there's typically enough context, that I don't think too many would be 
confused.

It comes up early in the Google results for "kiB", "MiB", etc. for those 
who do find it unfamiliar.

-Scott

[U-Boot] [PATCH] allow print_size to print large numbers on 32-bit systems

[Timur Tabi]

Scott Wood wrote:
> It's used often enough (including many places in U-Boot already), and 
> there's typically enough context, that I don't think too many would be 
> confused.

I guess my objection that I think the whole idea is stupid doesn't count for much?  I'll do it if Wolfgang insists, but I honestly believe that there was no confusion and that the introduction of KiB and its ilk just makes things worse, not better.  No one is going to compare memory sizes in kilobytes with distances in kilometers and get confused.

-- 
Timur Tabi
Linux kernel developer at Freescale

[U-Boot] [PATCH] allow print_size to print large numbers on 32-bit systems

[Wolfgang Denk]

Dear Timur Tabi,

In message <4BC366DE.1000808@freescale.com> you wrote:
>
> I guess my objection that I think the whole idea is stupid doesn't count for much?  I'll do it if Wolfgang insists, but I honestly believe that there was no confusion and that the introduction of KiB and its ilk just makes things worse, not better.  No 
> one is going to compare memory sizes in kilobytes with distances in kilometers and get confused.

Well, there _is_ a lot of confusion

For example, how big is (ummm: was) a standard 3.5" floppy disk?

1.44 MB, right?

Well, actually it's 1474560 bytes, or 1440 * 1024 bytes.

So this "MB" here is 1000 * 1024 - which is complete nonsense.

Let's use the official standard units, please. We may not like them,
but at least they will not cause a $125 million Mars orbiter to
crash...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
All your people must learn before you can reach for the stars.
	-- Kirk, "The Gamesters of Triskelion", stardate 3259.2

[U-Boot] [PATCH] allow print_size to print large numbers on 32-bit systems

[Timur Tabi]

Wolfgang Denk wrote:
> For example, how big is (ummm: was) a standard 3.5" floppy disk?
> 
> 1.44 MB, right?
> 
> Well, actually it's 1474560 bytes, or 1440 * 1024 bytes.
> 
> So this "MB" here is 1000 * 1024 - which is complete nonsense.

This is bad example, because the size of a floppy is neither 1.44MB nor 1.44 MiB.

> Let's use the official standard units, please. We may not like them,
> but at least they will not cause a $125 million Mars orbiter to
> crash...

Alright.

-- 
Timur Tabi
Linux kernel developer at Freescale

[U-Boot] [PATCH] allow print_size to print large numbers on 32-bit systems

[Scott Wood]

Timur Tabi wrote:
> Wolfgang Denk wrote:
>> For example, how big is (ummm: was) a standard 3.5" floppy disk?
>>
>> 1.44 MB, right?
>>
>> Well, actually it's 1474560 bytes, or 1440 * 1024 bytes.
>>
>> So this "MB" here is 1000 * 1024 - which is complete nonsense.
> 
> This is bad example, because the size of a floppy is neither 1.44MB nor 1.44 MiB.

It's a good example, because it was a result of allowing prefixes like 
"MB" to be fuzzily defined.  If you give the marketers room to interpret 
fuzzy things in their favor, they'll use it.

-Scott

[U-Boot] [PATCH] [v3] fix print_size printing fractional gigabyte numbers on 32-bit platforms

[Wolfgang Denk]

Dear Timur Tabi,

In message <1269990179-23666-1-git-send-email-timur@freescale.com> you wrote:
> In print_size(), the math that calculates the fractional remainder of a number
> used the same integer size as a physical address.  However, the "10 *" factor
> of the algorithm means that a large number (e.g. 1.5GB) can overflow the
> integer if we're running on a 32-bit system.  Therefore, we need to
> disassociate this function from the size of a physical address.
> 
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
>  lib_generic/display_options.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)

Applied, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The reasonable man adapts himself to the world; the unreasonable  one
persists  in  trying  to  adapt  the  world to himself. Therefore all
progress depends on the unreasonable man."      - George Bernard Shaw

[U-Boot] [PATCH] [v3] fix print_size printing fractional gigabyte numbers on 32-bit platforms

[Timur Tabi]

On Fri, Apr 9, 2010 at 3:10 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Timur Tabi,
>
> In message <1269990179-23666-1-git-send-email-timur@freescale.com> you wrote:
>> In print_size(), the math that calculates the fractional remainder of a number
>> used the same integer size as a physical address. ?However, the "10 *" factor
>> of the algorithm means that a large number (e.g. 1.5GB) can overflow the
>> integer if we're running on a 32-bit system. ?Therefore, we need to
>> disassociate this function from the size of a physical address.
>>
>> Signed-off-by: Timur Tabi <timur@freescale.com>
>> ---
>> ?lib_generic/display_options.c | ? ?4 ++--
>> ?1 files changed, 2 insertions(+), 2 deletions(-)
>
> Applied, thanks.

I don't see this patch anywhere in http://git.denx.de/?p=u-boot.git.
Are you sure you applied it?

-- 
Timur Tabi
Linux kernel developer at Freescale