[U-Boot-Users] [PATCH] Make sleep shell command is reliable for all architectures

[U-Boot-Users] [PATCH] Make sleep shell command is reliable for all architectures

[Jason McMullan]

On some architectures (MIPS is a good example), the timebase
rolls over every few seconds. This patch alters the 'sleep'
shell command to use a total counter of the udelay(100)
sleeps instead of an end time marker to determine the end
of the sleep, making the 'sleep' command capable of sleeping
for any number of seconds on all architectures.

Signed-off-by: Jason McMullan <mcmullan@netapp.com>
---
 common/cmd_misc.c |   10 +++++++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/common/cmd_misc.c b/common/cmd_misc.c
index 126b538..2b84896 100644
--- a/common/cmd_misc.c
+++ b/common/cmd_misc.c
@@ -29,7 +29,6 @@
 
 int do_sleep (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 {
-	ulong start = get_timer(0);
 	ulong delay;
 
 	if (argc != 2) {
@@ -37,13 +36,18 @@ int do_sleep (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 		return 1;
 	}
 
-	delay = simple_strtoul(argv[1], NULL, 10) * CFG_HZ;
+	/* Sleep in 100ms increments, as some the time base of
+	 * some architectures can roll over after only a few
+	 * seconds (MIPS is a good example of this)
+	 */
+	delay = simple_strtoul(argv[1], NULL, 10) * 10;
 
-	while (get_timer(start) < delay) {
+	while (delay > 0) {
 		if (ctrlc ()) {
 			return (-1);
 		}
 		udelay (100);
+		delay--;
 	}
 
 	return 0;
-- 
1.5.4.3

[U-Boot-Users] [PATCH] Make sleep shell command is reliable for all architectures

[Wolfgang Denk]

In message <20080520140054.9565865407@mcmullan-linux.hq.netapp.com> you wrote:
> On some architectures (MIPS is a good example), the timebase
> rolls over every few seconds. This patch alters the 'sleep'

Well, even if this happens, it should not cause get_timer()  to  show
such problems. get_timer() returns an "unsigned long" and is counting
in milliseconds, so a wrap-around should take about 50 days.

> shell command to use a total counter of the udelay(100)
> sleeps instead of an end time marker to determine the end
> of the sleep, making the 'sleep' command capable of sleeping
> for any number of seconds on all architectures.

I tend to reject this patch because I think we should fix  the  cause
of  the  problems  rather than the symptoms - there are more areas in
the code that rely on sane behaviour of the get_timer() functione.

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 goal of science is to build better mousetraps. The goal of nature
is to build better mice.

[U-Boot-Users] [PATCH] Make sleep shell command is reliablefor all architectures

[McMullan, Jason]

On Tue, 2008-05-20 at 16:23 +0200, Wolfgang Denk wrote:
> Well, even if this happens, it should not cause get_timer()  to  show
> such problems. get_timer() returns an "unsigned long" and is counting
> in milliseconds, so a wrap-around should take about 50 days.

Yes, but get_timer() is not guaranteed to return 0 to MAX_ULONG, as
far as I can tell.

On MIPS (even after my CFG_HZ patch), get_timer() will only return
0 to 14316 on a 300MHZ machine, as the 32-bit MIPS tick timer that
forms the MIPS time base wraps to 0 after 14.316 seconds.

> I tend to reject this patch because I think we should fix  the  cause
> of  the  problems  rather than the symptoms - there are more areas in
> the code that rely on sane behaviour of the get_timer() functione.

Well, then we've got a big problem on MIPS.


Jason McMullan
MTS SW
System Firmware

NetApp
724.741.5011    Fax
724.741.5166    Direct
412.656.3519    Mobile
jason.mcmullan at netapp.com
www.netapp.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080520/7a74a3a1/attachment.pgp 

[U-Boot-Users] [PATCH] Make sleep shell command is reliablefor all architectures

[Scott Wood]

McMullan, Jason wrote:
> On Tue, 2008-05-20 at 16:23 +0200, Wolfgang Denk wrote:
>> Well, even if this happens, it should not cause get_timer()  to  show
>> such problems. get_timer() returns an "unsigned long" and is counting
>> in milliseconds, so a wrap-around should take about 50 days.
> 
> Yes, but get_timer() is not guaranteed to return 0 to MAX_ULONG, as
> far as I can tell.
> 
> On MIPS (even after my CFG_HZ patch), get_timer() will only return
> 0 to 14316 on a 300MHZ machine, as the 32-bit MIPS tick timer that
> forms the MIPS time base wraps to 0 after 14.316 seconds.
> 
>> I tend to reject this patch because I think we should fix  the  cause
>> of  the  problems  rather than the symptoms - there are more areas in
>> the code that rely on sane behaviour of the get_timer() functione.
> 
> Well, then we've got a big problem on MIPS.

This can be fixed by maintaining the upper bits of the timebase in 
software, as long we can guarantee that get_timer() is called at least 
once per wraparound.  That is, remember the last value, and if the new 
value is less than the old value, increment the upper word.

-Scott

[U-Boot-Users] [PATCH] Make sleep shell command is reliablefor all architectures

[Wolfgang Denk]

In message <1211295950.3617.17.camel@mcmullan-linux.cifs.lab.netapp.com> you wrote:
> 
> Yes, but get_timer() is not guaranteed to return 0 to MAX_ULONG, as
> far as I can tell.

I'm not sure what you mean by that statement.

> On MIPS (even after my CFG_HZ patch), get_timer() will only return
> 0 to 14316 on a 300MHZ machine, as the 32-bit MIPS tick timer that
> forms the MIPS time base wraps to 0 after 14.316 seconds.

That's a bug in the MIPS implementation, then.

> Well, then we've got a big problem on MIPS.

A fixable one, I hope.

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 nice thing about  standards  is that there are  so many to choose
from.                                           - Andrew S. Tanenbaum