[U-Boot] [PATCH-ARM] CONFIG_SYS_HZ fix for ARM902T S3C24X0 Boards

[U-Boot] [PATCH-ARM] CONFIG_SYS_HZ fix for ARM902T S3C24X0 Boards

[kevin.morfitt at fearnside-systems.co.uk]

This sets CONFIG_SYS_HZ to 1000 for all boards that use the s3c2400 and
s3c2410 cpu's which fixes various problems such as the timeouts in tftp being
too short.

Tested on an Embest SBC2440-II Board with local u-boot patches as I don't
have any s3c2400 or s3c2410 boards but need this patch applying before I can
submit patches for the SBC2440-II Board. Also, ran MAKEALL for all ARM9 targets
and no new warnings or errors were found.

It was originally submitted on 21/06/2009 but didn't get into the 2009.08
release, and Jean-Pierre made one comment on the original patch (see
http://lists.denx.de/pipermail/u-boot/2009-July/055470.html). I've made two
changes to the original patch:
- it's been re-based to the current release
- I've re-named get_timer_raw() to get_ticks() in response to Jean-Pierre's comment

This affects the sbc2410, smdk2400, smdk2410 and trab boards. I've copied it
directly to the maintainers of all except the sbc2410 which doesn't have an
entry in MAINTAINERS.

Signed-off-by: Kevin Morfitt <kmorfitt@aselaptop-1.localdomain>
---
 cpu/arm920t/s3c24x0/timer.c |   36 ++++++++++++++++++++----------------
 include/configs/sbc2410x.h  |    4 +---
 include/configs/smdk2400.h  |    4 +---
 include/configs/smdk2410.h  |    4 +---
 include/configs/trab.h      |   12 +-----------
 5 files changed, 24 insertions(+), 36 deletions(-)

diff --git a/cpu/arm920t/s3c24x0/timer.c b/cpu/arm920t/s3c24x0/timer.c
index c8c7cdb..db472bf 100644
--- a/cpu/arm920t/s3c24x0/timer.c
+++ b/cpu/arm920t/s3c24x0/timer.c
@@ -39,6 +39,7 @@
 #endif

 int timer_load_val = 0;
+static ulong timer_clk;

 /* macro to read the 16 bit timer */
 static inline ulong READ_TIMER(void)
@@ -66,6 +67,7 @@ int timer_init (void)
 		 * @33.25MHz and 15625 @ 50 MHz
 		 */
 		timer_load_val = get_PCLK()/(2 * 16 * 100);
+		timer_clk = get_PCLK() / (2 * 16);
 	}
 	/* load value for 10 ms timeout */
 	lastdec = timers->TCNTB4 = timer_load_val;
@@ -100,13 +102,13 @@ void set_timer (ulong t)
 void udelay (unsigned long usec)
 {
 	ulong tmo;
-	ulong start = get_timer(0);
+	ulong start = get_ticks();

 	tmo = usec / 1000;
 	tmo *= (timer_load_val * 100);
 	tmo /= 1000;

-	while ((ulong)(get_timer_masked () - start) < tmo)
+	while ((ulong) (get_ticks() - start) < tmo)
 		/*NOP*/;
 }

@@ -119,18 +121,9 @@ void reset_timer_masked (void)

 ulong get_timer_masked (void)
 {
-	ulong now = READ_TIMER();
-
-	if (lastdec >= now) {
-		/* normal mode */
-		timestamp += lastdec - now;
-	} else {
-		/* we have an overflow ... */
-		timestamp += lastdec + timer_load_val - now;
-	}
-	lastdec = now;
+	ulong tmr = get_ticks();

-	return timestamp;
+	return tmr / (timer_clk / CONFIG_SYS_HZ);
 }

 void udelay_masked (unsigned long usec)
@@ -148,10 +141,10 @@ void udelay_masked (unsigned long usec)
 		tmo /= (1000*1000);
 	}

-	endtime = get_timer_masked () + tmo;
+	endtime = get_ticks() + tmo;

 	do {
-		ulong now = get_timer_masked ();
+		ulong now = get_ticks();
 		diff = endtime - now;
 	} while (diff >= 0);
 }
@@ -162,7 +155,18 @@ void udelay_masked (unsigned long usec)
  */
 unsigned long long get_ticks(void)
 {
-	return get_timer(0);
+	ulong now = READ_TIMER();
+
+	if (lastdec >= now) {
+		/* normal mode */
+		timestamp += lastdec - now;
+	} else {
+		/* we have an overflow ... */
+		timestamp += lastdec + timer_load_val - now;
+	}
+	lastdec = now;
+
+	return timestamp;
 }

 /*
diff --git a/include/configs/sbc2410x.h b/include/configs/sbc2410x.h
index f2ea926..e6886cf 100644
--- a/include/configs/sbc2410x.h
+++ b/include/configs/sbc2410x.h
@@ -139,9 +139,7 @@

 #define	CONFIG_SYS_LOAD_ADDR		0x33000000	/* default load address	*/

-/* the PWM TImer 4 uses a counter of 15625 for 10 ms, so we need */
-/* it to wrap 100 times (total 1562500) to get 1 sec. */
-#define	CONFIG_SYS_HZ			1562500
+#define	CONFIG_SYS_HZ			1000

 /* valid baudrates */
 #define CONFIG_SYS_BAUDRATE_TABLE	{ 9600, 19200, 38400, 57600, 115200 }
diff --git a/include/configs/smdk2400.h b/include/configs/smdk2400.h
index c234177..a1beb65 100644
--- a/include/configs/smdk2400.h
+++ b/include/configs/smdk2400.h
@@ -141,9 +141,7 @@

 #define	CONFIG_SYS_LOAD_ADDR		0x0cf00000	/* default load address	*/

-/* the PWM TImer 4 uses a counter of 15625 for 10 ms, so we need */
-/* it to wrap 100 times (total 1562500) to get 1 sec. */
-#define	CONFIG_SYS_HZ			1562500
+#define	CONFIG_SYS_HZ			1000

 /* valid baudrates */
 #define CONFIG_SYS_BAUDRATE_TABLE	{ 9600, 19200, 38400, 57600, 115200 }
diff --git a/include/configs/smdk2410.h b/include/configs/smdk2410.h
index d340098..c57751b 100644
--- a/include/configs/smdk2410.h
+++ b/include/configs/smdk2410.h
@@ -124,9 +124,7 @@

 #define	CONFIG_SYS_LOAD_ADDR		0x33000000	/* default load address	*/

-/* the PWM TImer 4 uses a counter of 15625 for 10 ms, so we need */
-/* it to wrap 100 times (total 1562500) to get 1 sec. */
-#define	CONFIG_SYS_HZ			1562500
+#define	CONFIG_SYS_HZ			1000

 /* valid baudrates */
 #define CONFIG_SYS_BAUDRATE_TABLE	{ 9600, 19200, 38400, 57600, 115200 }
diff --git a/include/configs/trab.h b/include/configs/trab.h
index 43c191b..97f30ce 100644
--- a/include/configs/trab.h
+++ b/include/configs/trab.h
@@ -320,17 +320,7 @@

 #define	CONFIG_SYS_LOAD_ADDR		0x0CF00000	/* default load address	*/

-#ifdef CONFIG_TRAB_50MHZ
-/* the PWM TImer 4 uses a counter of 15625 for 10 ms, so we need */
-/* it to wrap 100 times (total 1562500) to get 1 sec. */
-/* this should _really_ be calculated !! */
-#define	CONFIG_SYS_HZ			1562500
-#else
-/* the PWM TImer 4 uses a counter of 10390 for 10 ms, so we need */
-/* it to wrap 100 times (total 1039000) to get 1 sec. */
-/* this should _really_ be calculated !! */
-#define	CONFIG_SYS_HZ			1039000
-#endif
+#define	CONFIG_SYS_HZ			1000

 /* valid baudrates */
 #define CONFIG_SYS_BAUDRATE_TABLE	{ 9600, 19200, 38400, 57600, 115200 }
-- 
1.6.0.6

[U-Boot] [PATCH-ARM] CONFIG_SYS_HZ fix for ARM902T S3C24X0 Boards

[Jean-Christophe PLAGNIOL-VILLARD]

On 16:33 Sat 05 Sep     , kevin.morfitt at fearnside-systems.co.uk wrote:
> This sets CONFIG_SYS_HZ to 1000 for all boards that use the s3c2400 and
> s3c2410 cpu's which fixes various problems such as the timeouts in tftp being
> too short.
> 
> Tested on an Embest SBC2440-II Board with local u-boot patches as I don't
> have any s3c2400 or s3c2410 boards but need this patch applying before I can
> submit patches for the SBC2440-II Board. Also, ran MAKEALL for all ARM9 targets
> and no new warnings or errors were found.
> 
> It was originally submitted on 21/06/2009 but didn't get into the 2009.08
> release, and Jean-Pierre made one comment on the original patch (see
> http://lists.denx.de/pipermail/u-boot/2009-July/055470.html). I've made two
> changes to the original patch:
> - it's been re-based to the current release
> - I've re-named get_timer_raw() to get_ticks() in response to Jean-Pierre's comment
> 
> This affects the sbc2410, smdk2400, smdk2410 and trab boards. I've copied it
> directly to the maintainers of all except the sbc2410 which doesn't have an
> entry in MAINTAINERS.
> 
> Signed-off-by: Kevin Morfitt <kmorfitt@aselaptop-1.localdomain>
> ---
>  cpu/arm920t/s3c24x0/timer.c |   36 ++++++++++++++++++++----------------
>  include/configs/sbc2410x.h  |    4 +---
>  include/configs/smdk2400.h  |    4 +---
>  include/configs/smdk2410.h  |    4 +---
>  include/configs/trab.h      |   12 +-----------
>  5 files changed, 24 insertions(+), 36 deletions(-)
Need to be test on trab or other but looks fine

Best Regards,
J.

[U-Boot] [PATCH-ARM] CONFIG_SYS_HZ fix for ARM902T S3C24X0 Boards

[Gary Jennejohn]

On Sat, 05 Sep 2009 16:33:13 +0100
"kevin.morfitt at fearnside-systems.co.uk" <kevin.morfitt@fearnside-systems.co.uk> wrote:

> This sets CONFIG_SYS_HZ to 1000 for all boards that use the s3c2400 and
> s3c2410 cpu's which fixes various problems such as the timeouts in tftp being
> too short.
> 
> Tested on an Embest SBC2440-II Board with local u-boot patches as I don't
> have any s3c2400 or s3c2410 boards but need this patch applying before I can
> submit patches for the SBC2440-II Board. Also, ran MAKEALL for all ARM9 targets
> and no new warnings or errors were found.
> 
> It was originally submitted on 21/06/2009 but didn't get into the 2009.08
> release, and Jean-Pierre made one comment on the original patch (see
> http://lists.denx.de/pipermail/u-boot/2009-July/055470.html). I've made two
> changes to the original patch:
> - it's been re-based to the current release
> - I've re-named get_timer_raw() to get_ticks() in response to Jean-Pierre's comment
> 
> This affects the sbc2410, smdk2400, smdk2410 and trab boards. I've copied it
> directly to the maintainers of all except the sbc2410 which doesn't have an
> entry in MAINTAINERS.
> 
> Signed-off-by: Kevin Morfitt <kmorfitt@aselaptop-1.localdomain>
> ---
>  cpu/arm920t/s3c24x0/timer.c |   36 ++++++++++++++++++++----------------
>  include/configs/sbc2410x.h  |    4 +---
>  include/configs/smdk2400.h  |    4 +---
>  include/configs/smdk2410.h  |    4 +---
>  include/configs/trab.h      |   12 +-----------
>  5 files changed, 24 insertions(+), 36 deletions(-)
> 
> diff --git a/cpu/arm920t/s3c24x0/timer.c b/cpu/arm920t/s3c24x0/timer.c
> index c8c7cdb..db472bf 100644
> --- a/cpu/arm920t/s3c24x0/timer.c
> +++ b/cpu/arm920t/s3c24x0/timer.c
> @@ -39,6 +39,7 @@
>  #endif
> 
>  int timer_load_val = 0;
> +static ulong timer_clk;
> 
>  /* macro to read the 16 bit timer */
>  static inline ulong READ_TIMER(void)
> @@ -66,6 +67,7 @@ int timer_init (void)
>  		 * @33.25MHz and 15625 @ 50 MHz
>  		 */
>  		timer_load_val = get_PCLK()/(2 * 16 * 100);
> +		timer_clk = get_PCLK() / (2 * 16);
>  	}
>  	/* load value for 10 ms timeout */
>  	lastdec = timers->TCNTB4 = timer_load_val;
> @@ -100,13 +102,13 @@ void set_timer (ulong t)
>  void udelay (unsigned long usec)
>  {
>  	ulong tmo;
> -	ulong start = get_timer(0);
> +	ulong start = get_ticks();
> 
>  	tmo = usec / 1000;
>  	tmo *= (timer_load_val * 100);
>  	tmo /= 1000;
> 
> -	while ((ulong)(get_timer_masked () - start) < tmo)
> +	while ((ulong) (get_ticks() - start) < tmo)
>  		/*NOP*/;
>  }
> 
> @@ -119,18 +121,9 @@ void reset_timer_masked (void)
> 
>  ulong get_timer_masked (void)
>  {
> -	ulong now = READ_TIMER();
> -
> -	if (lastdec >= now) {
> -		/* normal mode */
> -		timestamp += lastdec - now;
> -	} else {
> -		/* we have an overflow ... */
> -		timestamp += lastdec + timer_load_val - now;
> -	}
> -	lastdec = now;
> +	ulong tmr = get_ticks();
> 
> -	return timestamp;
> +	return tmr / (timer_clk / CONFIG_SYS_HZ);
>  }
> 
>  void udelay_masked (unsigned long usec)
> @@ -148,10 +141,10 @@ void udelay_masked (unsigned long usec)
>  		tmo /= (1000*1000);
>  	}
> 
> -	endtime = get_timer_masked () + tmo;
> +	endtime = get_ticks() + tmo;
> 
>  	do {
> -		ulong now = get_timer_masked ();
> +		ulong now = get_ticks();
>  		diff = endtime - now;
>  	} while (diff >= 0);
>  }
> @@ -162,7 +155,18 @@ void udelay_masked (unsigned long usec)
>   */
>  unsigned long long get_ticks(void)
>  {
> -	return get_timer(0);
> +	ulong now = READ_TIMER();
> +
> +	if (lastdec >= now) {
> +		/* normal mode */
> +		timestamp += lastdec - now;
> +	} else {
> +		/* we have an overflow ... */
> +		timestamp += lastdec + timer_load_val - now;
> +	}
> +	lastdec = now;
> +
> +	return timestamp;
>  }
> 
>  /*
> diff --git a/include/configs/sbc2410x.h b/include/configs/sbc2410x.h
> index f2ea926..e6886cf 100644
> --- a/include/configs/sbc2410x.h
> +++ b/include/configs/sbc2410x.h
> @@ -139,9 +139,7 @@
> 
>  #define	CONFIG_SYS_LOAD_ADDR		0x33000000	/* default load address	*/
> 
> -/* the PWM TImer 4 uses a counter of 15625 for 10 ms, so we need */
> -/* it to wrap 100 times (total 1562500) to get 1 sec. */
> -#define	CONFIG_SYS_HZ			1562500
> +#define	CONFIG_SYS_HZ			1000
> 
>  /* valid baudrates */
>  #define CONFIG_SYS_BAUDRATE_TABLE	{ 9600, 19200, 38400, 57600, 115200 }
> diff --git a/include/configs/smdk2400.h b/include/configs/smdk2400.h
> index c234177..a1beb65 100644
> --- a/include/configs/smdk2400.h
> +++ b/include/configs/smdk2400.h
> @@ -141,9 +141,7 @@
> 
>  #define	CONFIG_SYS_LOAD_ADDR		0x0cf00000	/* default load address	*/
> 
> -/* the PWM TImer 4 uses a counter of 15625 for 10 ms, so we need */
> -/* it to wrap 100 times (total 1562500) to get 1 sec. */
> -#define	CONFIG_SYS_HZ			1562500
> +#define	CONFIG_SYS_HZ			1000
> 
>  /* valid baudrates */
>  #define CONFIG_SYS_BAUDRATE_TABLE	{ 9600, 19200, 38400, 57600, 115200 }
> diff --git a/include/configs/smdk2410.h b/include/configs/smdk2410.h
> index d340098..c57751b 100644
> --- a/include/configs/smdk2410.h
> +++ b/include/configs/smdk2410.h
> @@ -124,9 +124,7 @@
> 
>  #define	CONFIG_SYS_LOAD_ADDR		0x33000000	/* default load address	*/
> 
> -/* the PWM TImer 4 uses a counter of 15625 for 10 ms, so we need */
> -/* it to wrap 100 times (total 1562500) to get 1 sec. */
> -#define	CONFIG_SYS_HZ			1562500
> +#define	CONFIG_SYS_HZ			1000
> 
>  /* valid baudrates */
>  #define CONFIG_SYS_BAUDRATE_TABLE	{ 9600, 19200, 38400, 57600, 115200 }
> diff --git a/include/configs/trab.h b/include/configs/trab.h
> index 43c191b..97f30ce 100644
> --- a/include/configs/trab.h
> +++ b/include/configs/trab.h
> @@ -320,17 +320,7 @@
> 
>  #define	CONFIG_SYS_LOAD_ADDR		0x0CF00000	/* default load address	*/
> 
> -#ifdef CONFIG_TRAB_50MHZ
> -/* the PWM TImer 4 uses a counter of 15625 for 10 ms, so we need */
> -/* it to wrap 100 times (total 1562500) to get 1 sec. */
> -/* this should _really_ be calculated !! */
> -#define	CONFIG_SYS_HZ			1562500
> -#else
> -/* the PWM TImer 4 uses a counter of 10390 for 10 ms, so we need */
> -/* it to wrap 100 times (total 1039000) to get 1 sec. */
> -/* this should _really_ be calculated !! */
> -#define	CONFIG_SYS_HZ			1039000
> -#endif
> +#define	CONFIG_SYS_HZ			1000
> 
>  /* valid baudrates */
>  #define CONFIG_SYS_BAUDRATE_TABLE	{ 9600, 19200, 38400, 57600, 115200 }
> -- 
> 1.6.0.6

I don't have any hardware to test this on, but I strongly suspect that
your changes break get_tbclk() for SMDK2400 and TRAB.

It looks like the correct fix would be to remove all the idef's and
simply set tbclk = CONFIG_SYS_HZ for all boards in get_tbclk().

---
Gary Jennejohn
*********************************************************************
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
*********************************************************************

[U-Boot] [PATCH-ARM] CONFIG_SYS_HZ fix for ARM902T S3C24X0 Boards

[Wolfgang Denk]

Dear "kevin.morfitt at fearnside-systems.co.uk",

In message <4AA284B9.8030009@fearnside-systems.co.uk> you wrote:
> This sets CONFIG_SYS_HZ to 1000 for all boards that use the s3c2400 and
> s3c2410 cpu's which fixes various problems such as the timeouts in tftp being
> too short.

I still wonder if this is really an issue. Some s3c2400 based boards
have been in production use for several years, with volumes of many
thousands of devices per year. Yet no TFTP timeout issues have been
reported ever.

> This affects the sbc2410, smdk2400, smdk2410 and trab boards. I've copied it
> directly to the maintainers of all except the sbc2410 which doesn't have an
> entry in MAINTAINERS.

I tested it on trab, and I don't see any changes - both U-Boot and
Linux still work as they always used to work.

Tested-by: Wolfgang Denk <wd2denx.de>

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-ARM] CONFIG_SYS_HZ fix for ARM902T S3C24X0 Boards

[kevin.morfitt at fearnside-systems.co.uk]

On 07/09/2009 22:47, Wolfgang Denk wrote:
> Dear "kevin.morfitt at fearnside-systems.co.uk",
> 
> In message <4AA284B9.8030009@fearnside-systems.co.uk> you wrote:
>> This sets CONFIG_SYS_HZ to 1000 for all boards that use the s3c2400 and
>> s3c2410 cpu's which fixes various problems such as the timeouts in tftp being
>> too short.
> 
> I still wonder if this is really an issue. Some s3c2400 based boards
> have been in production use for several years, with volumes of many
> thousands of devices per year. Yet no TFTP timeout issues have been
> reported ever.
> 
>> This affects the sbc2410, smdk2400, smdk2410 and trab boards. I've copied it
>> directly to the maintainers of all except the sbc2410 which doesn't have an
>> entry in MAINTAINERS.
> 
> I tested it on trab, and I don't see any changes - both U-Boot and
> Linux still work as they always used to work.
> 
> Tested-by: Wolfgang Denk <wd2denx.de>
> 
> Best regards,
> 
> Wolfgang Denk
> 

I think there were no problems because CONFIG_SYS_HZ was set to values that
worked for each of the s3c24x0 boards. I only submitted the patch because my
first attempt at a patch for the Embest SBC2440-II was NAK-ed because I'd set
CONFIG_SYS_HZ to the original sbc2410x setting of 1562500 (which worked) - there
was a global change going through to set CONFIG_SYS_HZ to 1000 for all boards
though I'm not sure what the reason was.

I'm happy to withdraw the patch if it's OK to set CONFIG_SYS_HZ to a different
value than 1000?


__________ Information from ESET NOD32 Antivirus, version of virus signature database 4403 (20090907) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

[U-Boot] [PATCH-ARM] CONFIG_SYS_HZ fix for ARM902T S3C24X0 Boards

[Wolfgang Denk]

Dear "kevin.morfitt at fearnside-systems.co.uk",

In message <4AA583AC.3050401@fearnside-systems.co.uk> you wrote:
> 
> > In message <4AA284B9.8030009@fearnside-systems.co.uk> you wrote:
> >> This sets CONFIG_SYS_HZ to 1000 for all boards that use the s3c2400 and
> >> s3c2410 cpu's which fixes various problems such as the timeouts in tftp being
> >> too short.
> > 
> > I still wonder if this is really an issue. Some s3c2400 based boards
> > have been in production use for several years, with volumes of many
> > thousands of devices per year. Yet no TFTP timeout issues have been
> > reported ever.
...
> I think there were no problems because CONFIG_SYS_HZ was set to values that
> worked for each of the s3c24x0 boards. I only submitted the patch because my

I'm confused - above you write "various problems such as the timeouts
in tftp being too short", now you write: "there were no problems".

Which one is correct?

> I'm happy to withdraw the patch if it's OK to set CONFIG_SYS_HZ to a different
> value than 1000?

CONFIG_SYS_HZ is a constant with the value 1000. Board that use
different values shall be fixed.

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
Severe culture shock results when experts from another protocol suite
[...] try to read OSI documents. The term "osified" is used to  refer
to  such  documents. [...] Any relationship to the word "ossified" is
purely intentional.                                - Marshall T. Rose

[U-Boot] [PATCH-ARM] CONFIG_SYS_HZ fix for ARM902T S3C24X0 Boards

[kevin.morfitt at fearnside-systems.co.uk]

On 07/09/2009 23:18, Wolfgang Denk wrote:
> Dear "kevin.morfitt at fearnside-systems.co.uk",
> 
> In message <4AA583AC.3050401@fearnside-systems.co.uk> you wrote:
>>> In message <4AA284B9.8030009@fearnside-systems.co.uk> you wrote:
>>>> This sets CONFIG_SYS_HZ to 1000 for all boards that use the s3c2400 and
>>>> s3c2410 cpu's which fixes various problems such as the timeouts in tftp being
>>>> too short.
>>> I still wonder if this is really an issue. Some s3c2400 based boards
>>> have been in production use for several years, with volumes of many
>>> thousands of devices per year. Yet no TFTP timeout issues have been
>>> reported ever.
> ...
>> I think there were no problems because CONFIG_SYS_HZ was set to values that
>> worked for each of the s3c24x0 boards. I only submitted the patch because my
> 
> I'm confused - above you write "various problems such as the timeouts
> in tftp being too short", now you write: "there were no problems".
> 
> Which one is correct?
> 

When I ported the SBC2440-II Board based on the existing sbc2410x code without
applying this patch the tftp timeouts were too short. When I apply this patch as
part of the SBC2440-II port the tftp timeouts are OK.

I haven't got any other s3c24x0 boards so I don't know whether they do have tftp
timeout problems or not, I only know that I saw them on my SBC2440-II port. My
comment "there were no problems" was based on you saying "Yet no TFTP timeout
issues have been reported ever".

Best Regards
Kevin Morfitt

>> I'm happy to withdraw the patch if it's OK to set CONFIG_SYS_HZ to a different
>> value than 1000?
> 
> CONFIG_SYS_HZ is a constant with the value 1000. Board that use
> different values shall be fixed.
> 
> Best regards,
> 
> Wolfgang Denk
> 



__________ Information from ESET NOD32 Antivirus, version of virus signature database 4403 (20090907) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

[U-Boot] [PATCH-ARM] CONFIG_SYS_HZ fix for ARM902T S3C24X0 Boards

[Minkyu Kang]

Dear kevin.morfitt,

2009/9/8 kevin.morfitt at fearnside-systems.co.uk
<kevin.morfitt@fearnside-systems.co.uk>:
>
>
> On 07/09/2009 23:18, Wolfgang Denk wrote:
>> Dear "kevin.morfitt at fearnside-systems.co.uk",
>>
>> In message <4AA583AC.3050401@fearnside-systems.co.uk> you wrote:
>>>> In message <4AA284B9.8030009@fearnside-systems.co.uk> you wrote:
>>>>> This sets CONFIG_SYS_HZ to 1000 for all boards that use the s3c2400 and
>>>>> s3c2410 cpu's which fixes various problems such as the timeouts in tftp being
>>>>> too short.
>>>> I still wonder if this is really an issue. Some s3c2400 based boards
>>>> have been in production use for several years, with volumes of many
>>>> thousands of devices per year. Yet no TFTP timeout issues have been
>>>> reported ever.
>> ...
>>> I think there were no problems because CONFIG_SYS_HZ was set to values that
>>> worked for each of the s3c24x0 boards. I only submitted the patch because my
>>
>> I'm confused - above you write "various problems such as the timeouts
>> in tftp being too short", now you write: "there were no problems".
>>
>> Which one is correct?
>>
>
> When I ported the SBC2440-II Board based on the existing sbc2410x code without
> applying this patch the tftp timeouts were too short. When I apply this patch as
> part of the SBC2440-II port the tftp timeouts are OK.
>
> I haven't got any other s3c24x0 boards so I don't know whether they do have tftp
> timeout problems or not, I only know that I saw them on my SBC2440-II port. My
> comment "there were no problems" was based on you saying "Yet no TFTP timeout
> issues have been reported ever".
>
> Best Regards
> Kevin Morfitt
>
>>> I'm happy to withdraw the patch if it's OK to set CONFIG_SYS_HZ to a different
>>> value than 1000?
>>
>> CONFIG_SYS_HZ is a constant with the value 1000. Board that use
>> different values shall be fixed.
>>
>> Best regards,
>>
>> Wolfgang Denk
>>
>
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus signature database 4403 (20090907) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>

applied to u-boot-samsung

thanks
Minkyu Kang
-- 
from. prom.
www.promsoft.net