[U-Boot-Users] [PATCH] ColdFire: Fix UART baudrate at 115200

[U-Boot-Users] [PATCH] ColdFire: Fix UART baudrate at 115200

[Tsi-Chung.Liew]

From: TsiChung Liew <Tsi-Chung.Liew@freescale.com>

If bus frequency is larger than 133MHz, the UART cannot
output baudrate at 115200 correctly.

Signed-off-by: TsiChung Liew <Tsi-Chung.Liew@freescale.com>
---
 drivers/serial/mcfuart.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/serial/mcfuart.c b/drivers/serial/mcfuart.c
index 88f3eb1..fca76bd 100644
--- a/drivers/serial/mcfuart.c
+++ b/drivers/serial/mcfuart.c
@@ -64,7 +64,10 @@ int serial_init(void)
 
 	/* Setting up BaudRate */
 	counter = (u32) (gd->bus_clk / (gd->baudrate));
-	counter >>= 5;
+	counter = (counter + 31) >> 5;
+
+	if ((gd->bus_clk > 133333333) && (gd->baudrate >= 115200))
+		counter++;
 
 	/* write to CTUR: divide counter upper byte */
 	uart->ubg1 = (u8) ((counter & 0xff00) >> 8);
-- 
1.5.4.1

[U-Boot-Users] [PATCH] ColdFire: Fix UART baudrate at 115200

[Jerry Van Baren]

Tsi-Chung.Liew wrote:
> From: TsiChung Liew <Tsi-Chung.Liew@freescale.com>
> 
> If bus frequency is larger than 133MHz, the UART cannot
> output baudrate at 115200 correctly.
> 
> Signed-off-by: TsiChung Liew <Tsi-Chung.Liew@freescale.com>
> ---
>  drivers/serial/mcfuart.c |    5 ++++-
>  1 files changed, 4 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/serial/mcfuart.c b/drivers/serial/mcfuart.c
> index 88f3eb1..fca76bd 100644
> --- a/drivers/serial/mcfuart.c
> +++ b/drivers/serial/mcfuart.c
> @@ -64,7 +64,10 @@ int serial_init(void)
>  
>  	/* Setting up BaudRate */
>  	counter = (u32) (gd->bus_clk / (gd->baudrate));
> -	counter >>= 5;
> +	counter = (counter + 31) >> 5;
> +
> +	if ((gd->bus_clk > 133333333) && (gd->baudrate >= 115200))
> +		counter++;
>  
>  	/* write to CTUR: divide counter upper byte */
>  	uart->ubg1 = (u8) ((counter & 0xff00) >> 8);

This doesn't look right at all.  It looks like you are patching up 
integer math problems by using different bad math and then special 
casing the result.  (In the metal working world, this is known as 
"measure with a micrometer, mark with chalk, cut with a torch, and grind 
to fit.")

Part A:
-------
 >  	counter = (u32) (gd->bus_clk / (gd->baudrate));

If you want this to be more accurate, you should round it:

 >  	counter = (u32) ((gd->bus_clk + (gd->baudrate / 2)) / (gd->baudrate));

Part B:
-------
 > +	counter = (counter + 31) >> 5;

This is not rounding properly, it is doing a "ceiling".

 > +	counter = (counter + 16) >> 5;

Part C:
-------

 > +	if ((gd->bus_clk > 133333333) && (gd->baudrate >= 115200))
 > +		counter++;

This looks totally bogus.  I very strongly suspect you need this because 
the above parts A: and B: are not rounding the division math properly, 
resulting in a wrong divisor *for your configuration*.  While the above 
conditional may result in the correct divisor *for your configuration,* 
it probably will be wrong for some finite set of *other* configurations.

If I got my algebra correct and my parenthesis balanced, I believe the 
above is trying to calculate the following formula:
	counter = (u32) (
		((gd->bus_clk + (gd->baudrate / 2) +
		 (gd->baudrate * 16))
		/ (gd->baudrate * 32);

Note, however, that (gd->baudrate / 2) is going to be relatively small 
compared to gd->bus_clk and (gd->baudrate * 16), so I suspect that the 
above formula could be changed to the following formula with no 
significant impact in accuracy:
	counter = (u32) (
		((gd->bus_clk + (gd->baudrate * 16))
		/ (gd->baudrate * 32);

Hmmmm, checking the math with 133e6 for the bus rate with full precision 
math (i.e. a calculator), I get a divisor value of 36.08 (truncated to 
an integer => 36).  Your hack-math results in a divisor of 38.  The last 
formula I proposed above  result in a divisor of 36.58 (truncated to an 
integer => 36).  That checks.

Real math    => 36.08
Hack-math    => 38    (109375 baud => 5.1% off)
Last formula => 36    (115451 baud => 0.2% off)

For 160e6 bus frequency:
Real math    => 43.40
Hack-math    => 44    (113636 baud => 1.4% off)
Last formula => 43    (116279 baud => 0.1% off)

I don't see how your formula works (well, actually it works but only 
because async serial can handle ~10% error).  In fact, it looks to me 
that your "correction" actually results in *more* error than the 
original calculation *without* rounding.  What is your actual bus speed? 
  What are to using on the other end of the serial line - I'm wondering 
if your receiver end is substantially off, causing a stack-up error that 
is causing your problem???  Is your board hardware marginal at 115200 
baud - what does it look like on a scope???

Best regards,
gvb

[U-Boot-Users] [PATCH] ColdFire: Fix UART baudrate at 115200

[Liew Tsi Chung]

Jerry,

	The calculation you provided does not work, I tried it before.
The best approach is reverse calculation after finding the closer
counter (or divider), then find the smaller gap to the bus frequency.

Using the calculation without the fix: counter = ((bus_freq / baudrate)
+ 31 )/ 32
Bus freq 140Mhz and baudrate 115200

counter = ((140000000 / 115200) + 31) / 32
counter = 38

However, the 38 divider shows partial garbage message when output to the
terminal.

Now, perform reverse calculation to obtain bus frequency.
bus_freq = ((counter * 32) - 31) * 115200

bus_freq = ((38 * 32) - 31) * 115200
bus_freq = 136512000
diff = 140000000 - 136512000 = 3488000

counter	bus_freq	diff
=======	=========	=======
36		129139200	way too off!
37		132825600	7174400
38		136512000	3488000
39		140198400	198400	<=== Work at this counter! Small
diff.
40		143884800	3884800

Regards,
TsiChung


-----Original Message-----
From: Jerry Van Baren [mailto:gerald.vanbaren@ge.com] 
Sent: Wednesday, May 28, 2008 1:45 PM
To: Liew Tsi Chung
Cc: U-Boot-Users; Wolfgang Denx; Rigby John
Subject: Re: [U-Boot-Users] [PATCH] ColdFire: Fix UART baudrate at
115200

Tsi-Chung.Liew wrote:
> From: TsiChung Liew <Tsi-Chung.Liew@freescale.com>
> 
> If bus frequency is larger than 133MHz, the UART cannot output 
> baudrate at 115200 correctly.
> 
> Signed-off-by: TsiChung Liew <Tsi-Chung.Liew@freescale.com>
> ---
>  drivers/serial/mcfuart.c |    5 ++++-
>  1 files changed, 4 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/serial/mcfuart.c b/drivers/serial/mcfuart.c index

> 88f3eb1..fca76bd 100644
> --- a/drivers/serial/mcfuart.c
> +++ b/drivers/serial/mcfuart.c
> @@ -64,7 +64,10 @@ int serial_init(void)
>  
>  	/* Setting up BaudRate */
>  	counter = (u32) (gd->bus_clk / (gd->baudrate));
> -	counter >>= 5;
> +	counter = (counter + 31) >> 5;
> +
> +	if ((gd->bus_clk > 133333333) && (gd->baudrate >= 115200))
> +		counter++;
>  
>  	/* write to CTUR: divide counter upper byte */
>  	uart->ubg1 = (u8) ((counter & 0xff00) >> 8);

This doesn't look right at all.  It looks like you are patching up
integer math problems by using different bad math and then special
casing the result.  (In the metal working world, this is known as
"measure with a micrometer, mark with chalk, cut with a torch, and grind
to fit.")

Part A:
-------
 >  	counter = (u32) (gd->bus_clk / (gd->baudrate));

If you want this to be more accurate, you should round it:

 >  	counter = (u32) ((gd->bus_clk + (gd->baudrate / 2)) /
(gd->baudrate));

Part B:
-------
 > +	counter = (counter + 31) >> 5;

This is not rounding properly, it is doing a "ceiling".

 > +	counter = (counter + 16) >> 5;

Part C:
-------

 > +	if ((gd->bus_clk > 133333333) && (gd->baudrate >= 115200))
 > +		counter++;

This looks totally bogus.  I very strongly suspect you need this because
the above parts A: and B: are not rounding the division math properly,
resulting in a wrong divisor *for your configuration*.  While the above
conditional may result in the correct divisor *for your configuration,*
it probably will be wrong for some finite set of *other* configurations.

If I got my algebra correct and my parenthesis balanced, I believe the
above is trying to calculate the following formula:
	counter = (u32) (
		((gd->bus_clk + (gd->baudrate / 2) +
		 (gd->baudrate * 16))
		/ (gd->baudrate * 32);

Note, however, that (gd->baudrate / 2) is going to be relatively small
compared to gd->bus_clk and (gd->baudrate * 16), so I suspect that the
above formula could be changed to the following formula with no
significant impact in accuracy:
	counter = (u32) (
		((gd->bus_clk + (gd->baudrate * 16))
		/ (gd->baudrate * 32);

Hmmmm, checking the math with 133e6 for the bus rate with full precision
math (i.e. a calculator), I get a divisor value of 36.08 (truncated to
an integer => 36).  Your hack-math results in a divisor of 38.  The last
formula I proposed above  result in a divisor of 36.58 (truncated to an
integer => 36).  That checks.

Real math    => 36.08
Hack-math    => 38    (109375 baud => 5.1% off)
Last formula => 36    (115451 baud => 0.2% off)

For 160e6 bus frequency:
Real math    => 43.40
Hack-math    => 44    (113636 baud => 1.4% off)
Last formula => 43    (116279 baud => 0.1% off)

I don't see how your formula works (well, actually it works but only
because async serial can handle ~10% error).  In fact, it looks to me
that your "correction" actually results in *more* error than the
original calculation *without* rounding.  What is your actual bus speed?

  What are to using on the other end of the serial line - I'm wondering
if your receiver end is substantially off, causing a stack-up error that
is causing your problem???  Is your board hardware marginal at 115200
baud - what does it look like on a scope???

Best regards,
gvb

[U-Boot-Users] [PATCH] ColdFire: Fix UART baudrate at 115200

[Jerry Van Baren]

Liew Tsi Chung wrote:
> Jerry,
> 
> 	The calculation you provided does not work, I tried it before.
> The best approach is reverse calculation after finding the closer
> counter (or divider), then find the smaller gap to the bus frequency.
> 
> Using the calculation without the fix: counter = ((bus_freq / baudrate)
> + 31 )/ 32

Where are you getting the +31 from?  Is this in the User's Manual?

> Bus freq 140Mhz and baudrate 115200
> 
> counter = ((140000000 / 115200) + 31) / 32
> counter = 38
> 
> However, the 38 divider shows partial garbage message when output to the
> terminal.
> 
> Now, perform reverse calculation to obtain bus frequency.
> bus_freq = ((counter * 32) - 31) * 115200

Computations are for mathematicians.  Real engineers measure the actual 
frequency.  ;-)

If you change the " - 31" to " - 42", your computations will result in a 
different divisor.  Why are you subtracting what appears to be an 
arbitrary number (31)?

> bus_freq = ((38 * 32) - 31) * 115200
> bus_freq = 136512000
> diff = 140000000 - 136512000 = 3488000
> 
> counter	bus_freq	diff
> =======	=========	=======
> 36		129139200	way too off!
> 37		132825600	7174400
> 38		136512000	3488000
> 39		140198400	198400	<=== Work@this counter! Small
> diff.
> 40		143884800	3884800
> 
> Regards,
> TsiChung

Are you sure your input frequency is 140MHz and not 144MHZ???  Have you 
read the itty-bitty numbers on the crystal?  Have you put a scope on it 
and actually measured it?  Never trust those hardware people.  ;-)

Looking at the MFC5407 (arbitrarily, not knowing what processor you 
have), the dividers are as expected and *do not* match your "- 31" 
calculations.  They have a simple example and simple math that matches 
(no "- 31").

Hmmm, the MFC5407 has a max CLKIN (and thus bus clock) of 54MHz.  You 
must have a different flavor.  MFC548x maxes at 50MHz.  What processor 
are you using?  Ahh, MFC5249 has a 140MHz bus.  Still is a straight 
forward divide-by n*32, no "- 31".

gvb

> -----Original Message-----
> From: Jerry Van Baren [mailto:gerald.vanbaren at ge.com] 
> Sent: Wednesday, May 28, 2008 1:45 PM
> To: Liew Tsi Chung
> Cc: U-Boot-Users; Wolfgang Denx; Rigby John
> Subject: Re: [U-Boot-Users] [PATCH] ColdFire: Fix UART baudrate at
> 115200
> 
> Tsi-Chung.Liew wrote:
>> From: TsiChung Liew <Tsi-Chung.Liew@freescale.com>
>>
>> If bus frequency is larger than 133MHz, the UART cannot output 
>> baudrate at 115200 correctly.
>>
>> Signed-off-by: TsiChung Liew <Tsi-Chung.Liew@freescale.com>
>> ---
>>  drivers/serial/mcfuart.c |    5 ++++-
>>  1 files changed, 4 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/serial/mcfuart.c b/drivers/serial/mcfuart.c index
> 
>> 88f3eb1..fca76bd 100644
>> --- a/drivers/serial/mcfuart.c
>> +++ b/drivers/serial/mcfuart.c
>> @@ -64,7 +64,10 @@ int serial_init(void)
>>  
>>  	/* Setting up BaudRate */
>>  	counter = (u32) (gd->bus_clk / (gd->baudrate));
>> -	counter >>= 5;
>> +	counter = (counter + 31) >> 5;
>> +
>> +	if ((gd->bus_clk > 133333333) && (gd->baudrate >= 115200))
>> +		counter++;
>>  
>>  	/* write to CTUR: divide counter upper byte */
>>  	uart->ubg1 = (u8) ((counter & 0xff00) >> 8);
> 
> This doesn't look right at all.  It looks like you are patching up
> integer math problems by using different bad math and then special
> casing the result.  (In the metal working world, this is known as
> "measure with a micrometer, mark with chalk, cut with a torch, and grind
> to fit.")
> 
> Part A:
> -------
>  >  	counter = (u32) (gd->bus_clk / (gd->baudrate));
> 
> If you want this to be more accurate, you should round it:
> 
>  >  	counter = (u32) ((gd->bus_clk + (gd->baudrate / 2)) /
> (gd->baudrate));
> 
> Part B:
> -------
>  > +	counter = (counter + 31) >> 5;
> 
> This is not rounding properly, it is doing a "ceiling".
> 
>  > +	counter = (counter + 16) >> 5;
> 
> Part C:
> -------
> 
>  > +	if ((gd->bus_clk > 133333333) && (gd->baudrate >= 115200))
>  > +		counter++;
> 
> This looks totally bogus.  I very strongly suspect you need this because
> the above parts A: and B: are not rounding the division math properly,
> resulting in a wrong divisor *for your configuration*.  While the above
> conditional may result in the correct divisor *for your configuration,*
> it probably will be wrong for some finite set of *other* configurations.
> 
> If I got my algebra correct and my parenthesis balanced, I believe the
> above is trying to calculate the following formula:
> 	counter = (u32) (
> 		((gd->bus_clk + (gd->baudrate / 2) +
> 		 (gd->baudrate * 16))
> 		/ (gd->baudrate * 32);
> 
> Note, however, that (gd->baudrate / 2) is going to be relatively small
> compared to gd->bus_clk and (gd->baudrate * 16), so I suspect that the
> above formula could be changed to the following formula with no
> significant impact in accuracy:
> 	counter = (u32) (
> 		((gd->bus_clk + (gd->baudrate * 16))
> 		/ (gd->baudrate * 32);
> 
> Hmmmm, checking the math with 133e6 for the bus rate with full precision
> math (i.e. a calculator), I get a divisor value of 36.08 (truncated to
> an integer => 36).  Your hack-math results in a divisor of 38.  The last
> formula I proposed above  result in a divisor of 36.58 (truncated to an
> integer => 36).  That checks.
> 
> Real math    => 36.08
> Hack-math    => 38    (109375 baud => 5.1% off)
> Last formula => 36    (115451 baud => 0.2% off)
> 
> For 160e6 bus frequency:
> Real math    => 43.40
> Hack-math    => 44    (113636 baud => 1.4% off)
> Last formula => 43    (116279 baud => 0.1% off)
> 
> I don't see how your formula works (well, actually it works but only
> because async serial can handle ~10% error).  In fact, it looks to me
> that your "correction" actually results in *more* error than the
> original calculation *without* rounding.  What is your actual bus speed?
> 
>   What are to using on the other end of the serial line - I'm wondering
> if your receiver end is substantially off, causing a stack-up error that
> is causing your problem???  Is your board hardware marginal at 115200
> baud - what does it look like on a scope???
> 
> Best regards,
> gvb
> 

[U-Boot-Users] [PATCH] ColdFire: Fix UART baudrate at 115200

[Liew Tsi Chung]

> Where are you getting the +31 from?  Is this in the User's Manual?
No in user's manual. The +31 is rounding up purpose.

> Computations are for mathematicians.  Real engineers measure the
actual frequency.  ;-)
Agree.

> If you change the " - 31" to " - 42", your computations will result in
a different divisor.  
> Why are you subtracting what appears to be an arbitrary number (31)?
Can't use 42 when the user's manual spec the divisor is 32. The "- 31"
comes from counter = ((bus_freq / baudrate) + 31) / 32. Using the same
calculation as mentioned here to find out bus_freq. bus_freq = ((counter
* 32) - 31) * baudrate.

> Are you sure your input frequency is 140MHz and not 144MHZ???  Have
you read the itty-bitty 
> numbers on the crystal?  Have you put a scope on it and actually
measured it?  Never trust 
> those hardware people.  ;-)
Actually, the bus freq is 70Mhz, 140Mhz is cpu freq (scope measurement).
The input freq (crystal/oscillator) not always 1 to 1 ratio. Take
M5253EVBE for example, the input clk is 11Mhz. Then, it multiply up and
divide down for CPU and bus frequency.

> Looking at the MFC5407 (arbitrarily, not knowing what processor you
have), the dividers are 
> as expected and *do not* match your "- 31" 
> calculations.  They have a simple example and simple math that matches
(no "- 31").

> Hmmm, the MFC5407 has a max CLKIN (and thus bus clock) of 54MHz.  You
must have a different 
> flavor.  MFC548x maxes at 50MHz.
> What processor are you using?
52x2, 532x, 547x_8x, 5445x. The 5253EVB is having the issue where the
calculation does not apply if baudrate is 115200.

> Ahh, MFC5249 has a 140MHz bus.  Still is a straight forward divide-by
n*32, no "- 31".
I thought the same too, but the 140Mhz is cpu freq.

Regards,
TsiChung

[U-Boot-Users] [PATCH] ColdFire: Fix UART baudrate at 115200

[Jerry Van Baren]

Liew Tsi Chung wrote:
>> Where are you getting the +31 from?  Is this in the User's Manual?
> No in user's manual. The +31 is rounding up purpose.

The formula (n + 31) / 32 is *NOT ROUNDING* the answer, it is doing a 
"ceiling" function.  You need to add 1/2 the divisor to *ROUND*, i.e. (n 
+ 16) / 32.

>> Computations are for mathematicians.  Real engineers measure the
> actual frequency.  ;-)
> Agree.
> 
>> If you change the " - 31" to " - 42", your computations will result in
> a different divisor.  
>> Why are you subtracting what appears to be an arbitrary number (31)?
> Can't use 42 when the user's manual spec the divisor is 32. The "- 31"
> comes from counter = ((bus_freq / baudrate) + 31) / 32. Using the same
> calculation as mentioned here to find out bus_freq. bus_freq = ((counter
> * 32) - 31) * baudrate.

The 42 is an obscure reference to the Hitchhiker's Guide to the Galaxy - 
the answer to the question of life, the universe and everything.  In 
other words, it is a totally arbitrary number.  Your use of +31 is not a 
*ROUNDING*, it is *CEILING* and thus I claim it is arbitrary, especially 
with the +1 to the divisor if your baud rate is suppose to be 115200 
baud.  You don't understand your hardware (if it makes you feel better, 
neither do I, but it is important that *you* understand it).

>> Are you sure your input frequency is 140MHz and not 144MHZ???  Have
> you read the itty-bitty 
>> numbers on the crystal?  Have you put a scope on it and actually
> measured it?  Never trust 
>> those hardware people.  ;-)
> Actually, the bus freq is 70Mhz, 140Mhz is cpu freq (scope measurement).
> The input freq (crystal/oscillator) not always 1 to 1 ratio. Take
> M5253EVBE for example, the input clk is 11Mhz. Then, it multiply up and
> divide down for CPU and bus frequency.

This *REALLY* makes your formula wrong.  According to the MCF5253 
Reference Manual Eqn. 15-1, the baud rate is
   fsys / (32 * divisor)
and fsys is 70MHz, *NOT* 140MHz.

baud = SysClk / (32 * divisor)

divisor = (70e6 / 32) / baud

divisor = 2187500 / 115200

divisor = 18.99 => 19

To *round*, add 1/2 the desired baud rate

divisor = ((70e6 / 32) * (baud / 2)) / baud

divisor = (2187500 + 57600) / 115200

divisor = 19.5 => integer truncation => 19

----

This means gd->bus_clk is *70MHz* (1/2 the CPU frequency), *NOT* 140MHz 
as you assume (note that this matches the Reference Manual).

I return to my contention:

Note, however, that (gd->baudrate / 2) is going to be relatively small
compared to gd->bus_clk and (gd->baudrate * 16), so I suspect that the
above formula could be changed to the following formula with no
significant impact in accuracy:
	counter = (u32) (
		((gd->bus_clk + (gd->baudrate * 16))
		/ (gd->baudrate * 32);

Simplifying the *32 factor to match my formula above:

	counter = (u32) (
		((gd->bus_clk / 32) + (gd->baudrate / 2))
		/ gd->baudrate);

	counter = ((70e6 / 32) + (115200 / 2)) / 115200
	counter = 19   (after inter truncation)

Note that, without adding (baudrate / 2) - rounding, the above formula 
results in a divisor of 18 rather than the proper 19.  THIS IS YOUR 
PROBLEM and also what your fix should be.

If you rounded properly, the baud rate calculation would work without 
all the magic.

Here is what your change actually does:

  	/* Setting up BaudRate */
	counter = (u32) (gd->bus_clk / (gd->baudrate));
This divide is doing an integer truncation and you are losing 
significant digits.
   70e6 / 115200 = 607.64 => integer truncation = 607

	counter = (counter + 31) >> 5;
This is "ceiling", but you've already lost the digits due to the 
previous divide with integer truncation (no rounding).
   (607 + 31) / 32 = 19.9 => integer truncation = 19

You get lucky and get the right answer even though you don't deserve it. ;-)

	if ((gd->bus_clk > 133333333) && (gd->baudrate >= 115200))
		counter++;
This is totally bogus.  gd->bus_clk == 70e6 so this is *always false.*

>> Looking at the MFC5407 (arbitrarily, not knowing what processor you
> have), the dividers are 
>> as expected and *do not* match your "- 31" 
>> calculations.  They have a simple example and simple math that matches
> (no "- 31").
> 
>> Hmmm, the MFC5407 has a max CLKIN (and thus bus clock) of 54MHz.  You
> must have a different 
>> flavor.  MFC548x maxes at 50MHz.
>> What processor are you using?
> 52x2, 532x, 547x_8x, 5445x. The 5253EVB is having the issue where the
> calculation does not apply if baudrate is 115200.
> 
>> Ahh, MFC5249 has a 140MHz bus.  Still is a straight forward divide-by
> n*32, no "- 31".
> I thought the same too, but the 140Mhz is cpu freq.

It is clocked by the System Clock, not CPU frequency.  The CPU frequency 
is 2x the System Clock.

> Regards,
> TsiChung

HTH,
gvb

[U-Boot-Users] [PATCH] ColdFire: Fix UART baudrate at 115200

[Liew Tsi Chung]

I see your point. I use your formula if you have not other comments.

Regards,
TsiChung 

-----Original Message-----
From: Jerry Van Baren [mailto:gvb.uboot at gmail.com] 
Sent: Wednesday, May 28, 2008 10:57 PM
To: Liew Tsi Chung
Cc: Jerry Van Baren; U-Boot-Users; Wolfgang Denx; Rigby John
Subject: Re: [U-Boot-Users] [PATCH] ColdFire: Fix UART baudrate at
115200

Liew Tsi Chung wrote:
>> Where are you getting the +31 from?  Is this in the User's Manual?
> No in user's manual. The +31 is rounding up purpose.

The formula (n + 31) / 32 is *NOT ROUNDING* the answer, it is doing a
"ceiling" function.  You need to add 1/2 the divisor to *ROUND*, i.e. (n

+ 16) / 32.

>> Computations are for mathematicians.  Real engineers measure the
> actual frequency.  ;-)
> Agree.
> 
>> If you change the " - 31" to " - 42", your computations will result
in
> a different divisor.  
>> Why are you subtracting what appears to be an arbitrary number (31)?
> Can't use 42 when the user's manual spec the divisor is 32. The "- 31"
> comes from counter = ((bus_freq / baudrate) + 31) / 32. Using the same
> calculation as mentioned here to find out bus_freq. bus_freq =
((counter
> * 32) - 31) * baudrate.

The 42 is an obscure reference to the Hitchhiker's Guide to the Galaxy -

the answer to the question of life, the universe and everything.  In 
other words, it is a totally arbitrary number.  Your use of +31 is not a

*ROUNDING*, it is *CEILING* and thus I claim it is arbitrary, especially

with the +1 to the divisor if your baud rate is suppose to be 115200 
baud.  You don't understand your hardware (if it makes you feel better, 
neither do I, but it is important that *you* understand it).

>> Are you sure your input frequency is 140MHz and not 144MHZ???  Have
> you read the itty-bitty 
>> numbers on the crystal?  Have you put a scope on it and actually
> measured it?  Never trust 
>> those hardware people.  ;-)
> Actually, the bus freq is 70Mhz, 140Mhz is cpu freq (scope
measurement).
> The input freq (crystal/oscillator) not always 1 to 1 ratio. Take
> M5253EVBE for example, the input clk is 11Mhz. Then, it multiply up
and
> divide down for CPU and bus frequency.

This *REALLY* makes your formula wrong.  According to the MCF5253 
Reference Manual Eqn. 15-1, the baud rate is
   fsys / (32 * divisor)
and fsys is 70MHz, *NOT* 140MHz.

baud = SysClk / (32 * divisor)

divisor = (70e6 / 32) / baud

divisor = 2187500 / 115200

divisor = 18.99 => 19

To *round*, add 1/2 the desired baud rate

divisor = ((70e6 / 32) * (baud / 2)) / baud

divisor = (2187500 + 57600) / 115200

divisor = 19.5 => integer truncation => 19

----

This means gd->bus_clk is *70MHz* (1/2 the CPU frequency), *NOT* 140MHz 
as you assume (note that this matches the Reference Manual).

I return to my contention:

Note, however, that (gd->baudrate / 2) is going to be relatively small
compared to gd->bus_clk and (gd->baudrate * 16), so I suspect that the
above formula could be changed to the following formula with no
significant impact in accuracy:
	counter = (u32) (
		((gd->bus_clk + (gd->baudrate * 16))
		/ (gd->baudrate * 32);

Simplifying the *32 factor to match my formula above:

	counter = (u32) (
		((gd->bus_clk / 32) + (gd->baudrate / 2))
		/ gd->baudrate);

	counter = ((70e6 / 32) + (115200 / 2)) / 115200
	counter = 19   (after inter truncation)

Note that, without adding (baudrate / 2) - rounding, the above formula 
results in a divisor of 18 rather than the proper 19.  THIS IS YOUR 
PROBLEM and also what your fix should be.

If you rounded properly, the baud rate calculation would work without 
all the magic.

Here is what your change actually does:

  	/* Setting up BaudRate */
	counter = (u32) (gd->bus_clk / (gd->baudrate));
This divide is doing an integer truncation and you are losing 
significant digits.
   70e6 / 115200 = 607.64 => integer truncation = 607

	counter = (counter + 31) >> 5;
This is "ceiling", but you've already lost the digits due to the 
previous divide with integer truncation (no rounding).
   (607 + 31) / 32 = 19.9 => integer truncation = 19

You get lucky and get the right answer even though you don't deserve it.
;-)

	if ((gd->bus_clk > 133333333) && (gd->baudrate >= 115200))
		counter++;
This is totally bogus.  gd->bus_clk == 70e6 so this is *always false.*

>> Looking at the MFC5407 (arbitrarily, not knowing what processor you
> have), the dividers are 
>> as expected and *do not* match your "- 31" 
>> calculations.  They have a simple example and simple math that
matches
> (no "- 31").
> 
>> Hmmm, the MFC5407 has a max CLKIN (and thus bus clock) of 54MHz.  You
> must have a different 
>> flavor.  MFC548x maxes at 50MHz.
>> What processor are you using?
> 52x2, 532x, 547x_8x, 5445x. The 5253EVB is having the issue where the
> calculation does not apply if baudrate is 115200.
> 
>> Ahh, MFC5249 has a 140MHz bus.  Still is a straight forward divide-by
> n*32, no "- 31".
> I thought the same too, but the 140Mhz is cpu freq.

It is clocked by the System Clock, not CPU frequency.  The CPU frequency

is 2x the System Clock.

> Regards,
> TsiChung

HTH,
gvb