[U-Boot] [PATCH-ARM] CONFIG_SYS_HZ fix for ARM902T S3C24X0 Boards
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 }
On 16:33 Sat 05 Sep , 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(-)
Need to be test on trab or other but looks fine
Best Regards, J.
On Sat, 05 Sep 2009 16:33:13 +0100 "kevin.morfitt@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);@@ -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();} @@ -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@denx.de *********************************************************************
Dear "kevin.morfitt@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
On 07/09/2009 22:47, Wolfgang Denk wrote:
Dear "kevin.morfitt@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.
Dear "kevin.morfitt@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
On 07/09/2009 23:18, Wolfgang Denk wrote:
Dear "kevin.morfitt@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.
Dear kevin.morfitt,
2009/9/8 kevin.morfitt@fearnside-systems.co.uk kevin.morfitt@fearnside-systems.co.uk:
On 07/09/2009 23:18, Wolfgang Denk wrote:
Dear "kevin.morfitt@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.
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
applied to u-boot-samsung
thanks Minkyu Kang
participants (5)
-
Gary Jennejohn -
Jean-Christophe PLAGNIOL-VILLARD -
kevin.morfitt＠fearnside-systems.co.uk -
Minkyu Kang -
Wolfgang Denk