[U-Boot] U-Boot Timer Qualification

[U-Boot] U-Boot Timer Qualification

[Jean-Christophe PLAGNIOL-VILLARD]

Hi all,

	For all Timer modification a minimun of qualification is mandatory
	as it will impact a lots of part of u-boot.

	So for this purpose I'll propose you to use one of this two approche
	to report the precition of your timer or update

	1) Clock generation Mesurement

	Tools needed: Scope or Frequency metter

	In this approch you will use a gpio to generate a 1Khz and at 1Mhz or
	it's maximun generated clock frequency

	before generate one of this clock you will need to known your GPIO and
	system latency. For this purpose you will generate a clock at your
	maximum speed as this algo

	set_gpio_as_output(gpio);

	while(1) {
		set_gpio_value(gpio, 1);
		set_gpio_value(gpio, 0);
	}

	after measure the clock (hg_clock) you will it's latency

	now you will try to generate the 1Khz clock
	to known the precision of your timer at 1ms

	while(1) {
		set_gpio_value(gpio, 1);
		udelay(1000);
		set_gpio_value(gpio, 0);
	}

	now measure the frequency of the clock

	the last step is now calculate your precision

	hg_clock = measured max speed generated clock

	ms_clock = measured 1Khz generated clock

	p = (1 / 1000 - (1 / hg_clock + 1 / ms_clock)) * 1000

	depending on max generated clock you can known your precision
	as 1us or less

	2) Watch mesurement

	measured with stop-watch on 100s delay

	x = measured time

	p = (100 - x) / 100


Best Regards,
J.

[U-Boot] U-Boot Timer Qualification

[Wolfgang Denk]

Dear Jean-Christophe PLAGNIOL-VILLARD,

In message <20090422204936.GB29252@game.jcrosoft.org> you wrote:
> 
> 	For all Timer modification a minimun of qualification is mandatory
> 	as it will impact a lots of part of u-boot.

Maybe you could be so kind and explain what this is actually about?

Who needs this, and why and when, and why didn't we need it the past?

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
Anyone who doesn't believe in miracles is not a realist.
                                                   - David Ben Gurion

[U-Boot] U-Boot Timer Qualification

[Jean-Christophe PLAGNIOL-VILLARD]

On 23:08 Wed 22 Apr     , Wolfgang Denk wrote:
> Dear Jean-Christophe PLAGNIOL-VILLARD,
> 
> In message <20090422204936.GB29252@game.jcrosoft.org> you wrote:
> > 
> > 	For all Timer modification a minimun of qualification is mandatory
> > 	as it will impact a lots of part of u-boot.
> 
> Maybe you could be so kind and explain what this is actually about?
> 
> Who needs this, and why and when, and why didn't we need it the past?
a lot of actual timer are not correct and we have problem on network timeout
as example.

So we need to known the precision of the timer to known the impact on all
timer depends part of u-boot as timeout or bitbanging stack

so when you have to respect some delay to init some chip or other you will to
known the delay you will have in reality. This will avoid you a lots of pain
during the dev

Best Regards,
J.

[U-Boot] U-Boot Timer Qualification

[Wolfgang Denk]

Dear Jean-Christophe PLAGNIOL-VILLARD,

In message <20090422212816.GA18705@game.jcrosoft.org> you wrote:
>
> > Who needs this, and why and when, and why didn't we need it the past?
> a lot of actual timer are not correct and we have problem on network timeout
> as example.

Hm... how muich of precision do we actuually need?

> So we need to known the precision of the timer to known the impact on all
> timer depends part of u-boot as timeout or bitbanging stack
> 
> so when you have to respect some delay to init some chip or other you will to
> known the delay you will have in reality. This will avoid you a lots of pain
> during the dev

In my experience, no parts of the code actually care about precision
of the timers, especially not when implementing delay loops or
timeouts using udelay() which always includes static overhead. For
example, the following two snippets of code are only in theory
equivalent:

	for (i=0; i < 100; ++i)
		udelay (10000);

versus

	for (i=0; i < 1000; ++i) {
		for (j=0; j < 1000; ++j)
			udelay (1);
	}

But - is this really a problem? I am not aware of any place in the
code where a tolerance of +/- 10% or maybe even more would matter.


Note: when you are implementing a bit-banging protcol that requires
precise timings and run into problems, then this is not a problem with
U-Boot timer accuracy, but with incorrect system design on your
system.

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
I'm what passes for a Unix guru in my office. This is  a  frightening
concept. - Lee Ann Goldstein, in <3k55ba$c43@butch.lmsc.lockheed.com>

[U-Boot] U-Boot Timer Qualification

[Ladislav Michl]

On Thu, Apr 23, 2009 at 12:18:00AM +0200, Wolfgang Denk wrote:
> Dear Jean-Christophe PLAGNIOL-VILLARD,
> 
> In message <20090422212816.GA18705@game.jcrosoft.org> you wrote:
> >
> > > Who needs this, and why and when, and why didn't we need it the past?
> > a lot of actual timer are not correct and we have problem on network timeout
> > as example.
> 
> Hm... how muich of precision do we actuually need?

Well, I already complained about all such a testing on the IRC yesterday,
so I'm not going to repeat...

And if I got Jean-Christophe correctly he cares about "real world"
verification that timer code is written the right way.

> > So we need to known the precision of the timer to known the impact on all
> > timer depends part of u-boot as timeout or bitbanging stack
> > 
> > so when you have to respect some delay to init some chip or other you will to
> > known the delay you will have in reality. This will avoid you a lots of pain
> > during the dev
> 
> In my experience, no parts of the code actually care about precision
> of the timers, especially not when implementing delay loops or
> timeouts using udelay() which always includes static overhead. For
> example, the following two snippets of code are only in theory
> equivalent:
> 
> 	for (i=0; i < 100; ++i)
> 		udelay (10000);
> 
> versus
> 
> 	for (i=0; i < 1000; ++i) {
> 		for (j=0; j < 1000; ++j)
> 			udelay (1);
> 	}
> 
> But - is this really a problem? I am not aware of any place in the
> code where a tolerance of +/- 10% or maybe even more would matter.

Well, more interesting case to test is:

	reset_timer();
	while (get_timer() < 100000)
		udelay(10000);

to prove get_timer has no bad interference with udelay. Proposed method also
doesn't verify another corner case - timer {under,over}flow.

> Note: when you are implementing a bit-banging protcol that requires
> precise timings and run into problems, then this is not a problem with
> U-Boot timer accuracy, but with incorrect system design on your
> system.

Seconded, same point made on IRC.

Best regards,
	ladis

[U-Boot] IRC log?, was: Re: U-Boot Timer Qualification

[Dirk Behme]

Ladislav Michl wrote:
...
> Well, I already complained about all such a testing on the IRC yesterday,
...
> Seconded, same point made on IRC.

Btw, is there any chance to get an IRC log? Was this already discussed 
(and rejected)? Or are there any other issues? Opinions?

#beagle has a nice log [1] which I use heavily not being online the 
whole day.

Best regards

Dirk

[1] http://www.beagleboard.org/irclogs/index.php

[U-Boot] U-Boot Timer Qualification

[Mike Frysinger]

On Thursday 23 April 2009 04:01:14 Ladislav Michl wrote:
> On Thu, Apr 23, 2009 at 12:18:00AM +0200, Wolfgang Denk wrote:
> > In message Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > Who needs this, and why and when, and why didn't we need it the past?
> > >
> > > a lot of actual timer are not correct and we have problem on network
> > > timeout as example.
> >
> > Hm... how muich of precision do we actuually need?
>
> Well, I already complained about all such a testing on the IRC yesterday,
> so I'm not going to repeat...

if you want your points to have any meaning/usage, then they have to be on the 
mailing list.  irc is useless for people trying to search for background 
information to a problem.

as it stands, your e-mail simply reads as "i agree with what Jean-Christophe 
said".
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090427/2714d0eb/attachment.pgp 

[U-Boot] U-Boot Timer Qualification

[Ladislav Michl]

On Mon, Apr 27, 2009 at 03:28:28PM -0400, Mike Frysinger wrote:
> if you want your points to have any meaning/usage, then they have to be on the 
> mailing list.  irc is useless for people trying to search for background 
> information to a problem.

I agree here, but I already gave up. And if "the real world timer verification" is
now mandatory, I'll do it, as it will lead to the effect faster. The only thing
I have to do is wait for a scope. I already run out of time I was supposed to spend
with U-Boot, so everything I'm doing eats my spare time (sure, not an excuse ;-))

To repeat it briefly. When dealing with 32bit underflow free running counter
mathematical proof precission is sufficient as everyone can verify its
correctness. Measurement in contrast needs either believe to device operator
or independent verification and after that, custodian is supposed to decide whom
to believe. In that case the most reliable way is to repeat measurement
himself. So this method really doesn't improve situation a lot and does not
take into account corner cases I described earlier.

> as it stands, your e-mail simply reads as "i agree with what Jean-Christophe 
> said".

Or more likely "I agree with what Wolfgang said" ;-)

Best regards,
	ladis

[U-Boot] U-Boot Timer Qualification

[Mike Frysinger]

On Tuesday 28 April 2009 06:08:06 Ladislav Michl wrote:
> On Mon, Apr 27, 2009 at 03:28:28PM -0400, Mike Frysinger wrote:
> > if you want your points to have any meaning/usage, then they have to be
> > on the mailing list.  irc is useless for people trying to search for
> > background information to a problem.
>
> I agree here, but I already gave up. And if "the real world timer
> verification" is now mandatory, I'll do it, as it will lead to the effect
> faster. The only thing I have to do is wait for a scope. I already run out
> of time I was supposed to spend with U-Boot, so everything I'm doing eats
> my spare time (sure, not an excuse ;-))

nothing has been mandated.  we're simply a bunch of devs throwing around 
random ideas to try and make u-boot more resilient to free flowing changes 
that git development enables.  a method to quickly validate user contributions 
is great as we can then say "you have to verify your change against the XXX 
test".

> To repeat it briefly. When dealing with 32bit underflow free running
> counter mathematical proof precission is sufficient as everyone can verify
> its correctness. Measurement in contrast needs either believe to device
> operator or independent verification and after that, custodian is supposed
> to decide whom to believe. In that case the most reliable way is to repeat
> measurement himself. So this method really doesn't improve situation a lot
> and does not take into account corner cases I described earlier.

i too would prefer a POST case that can be classified as a mathematically 
sound proof.  did i miss something, or was such a case proposed ?

> > as it stands, your e-mail simply reads as "i agree with what
> > Jean-Christophe said".
>
> Or more likely "I agree with what Wolfgang said" ;-)

well i'm glad you clarified because i missed the point of your e-mail
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090428/f14851ad/attachment.pgp 

[U-Boot] U-Boot Timer Qualification

[Wolfgang Denk]

Dear Mike Frysinger,

In message <200904280848.14109.vapier@gentoo.org> you wrote:
>
> i too would prefer a POST case that can be classified as a mathematically 
> sound proof.  did i miss something, or was such a case proposed ?

No.

And I think it's actually difficult  to  implement,  as  it's  highly
system-dependent.  Testing against the RTC was mentioned - there is a
plethora of different RTC being usedon different  boards,  some  more
and  some less suitable for such a test. Some board don't even have a
RTC (quite alot of them actually), and other systems have an internal
RTC that runs from the same clock as the main CPU so you can  measure
anything  but  you  cannot  measure wallclock times because you don't
have an independent reference clock.

Yes, being able to test sucha thing is nice, but I want to make clear
that this is not a mandatory prerequisite to get any code accepted.

> > > as it stands, your e-mail simply reads as "i agree with what
> > > Jean-Christophe said".
> >
> > Or more likely "I agree with what Wolfgang said" ;-)
>
> well i'm glad you clarified because i missed the point of your e-mail

I missed it, too. What exactly did I say? :-)

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
"I'm not a god, I was misquoted."                 - Lister, Red Dwarf

[U-Boot] U-Boot Timer Qualification

[Mike Frysinger]

On Tuesday 28 April 2009 09:41:07 Wolfgang Denk wrote:
> In message Mike Frysinger wrote:
> > i too would prefer a POST case that can be classified as a mathematically
> > sound proof.  did i miss something, or was such a case proposed ?
>
> No.
>
> And I think it's actually difficult  to  implement,  as  it's  highly
> system-dependent.  Testing against the RTC was mentioned - there is a
> plethora of different RTC being usedon different  boards,  some  more
> and  some less suitable for such a test. Some board don't even have a
> RTC (quite alot of them actually), and other systems have an internal
> RTC that runs from the same clock as the main CPU so you can  measure
> anything  but  you  cannot  measure wallclock times because you don't
> have an independent reference clock.
>
> Yes, being able to test sucha thing is nice, but I want to make clear
> that this is not a mandatory prerequisite to get any code accepted.

i proposed any RTC POST as a method of being able to somewhat validate things 
sanely, not as a complete or required solution.  i know that RTCs are not a 
given in the embedded world, but they are common enough that you should 
hopefully have a board with one to validate *arch* changes and give you an 
idea that things should be working.  pretty much all Blackfin boards from ADI 
have an RTC on it with a dedicated crystal, so it makes things easy for me.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090428/d4adaa26/attachment.pgp 

[U-Boot] U-Boot Timer Qualification

[Ladislav Michl]

Dear Mike,

a lot of changes are entering arm tree, many without any commit message.
And now we have some special cases which needs some special care for yet
unclear reason. OMAP3 timer precission was discussed to death and patch
still didn't went in, because it needs to be verified against some
document you are claiming is not mandatory.

I'll omit more comments to this topic until my objections get answered.
Just one side note: Both methods can be easily set in code, freeing
every and each developer from reimplementing test case. Such code could
be one for all and selfexplaining. Is it worth doing using current timer
API?

	ladis

[U-Boot] U-Boot Timer Qualification

[Wolfgang Denk]

Dear Ladislav Michl,

In message <20090428151147.GA19683@linux-mips.org> you wrote:
> 
> a lot of changes are entering arm tree, many without any commit message.
> And now we have some special cases which needs some special care for yet
> unclear reason. OMAP3 timer precission was discussed to death and patch
> still didn't went in, because it needs to be verified against some
> document you are claiming is not mandatory.

Just in case there is any doubt here:

There is no, and I say *no*, mandatory verification of any timing
precision in U-Boot.

We all agree that precision is a good thing to have, it it must come
at a reasonable effort, and there is no reason to drive it into
extreme precision.

Clock signals may need an accuracy of 1 or 2% or better - as we may
see character corruption if the baudrate generators are off too far -
but this is usually a hardware issue in the first place.

System timers (like udelay() etc.) in U-Boot do not need such a level
of accuracy. That does not mean we should intentionally be inaccurate.

And of course actual testing is good, and documentation of the test
results is even better.

But: it is not mandatory. Not in U-Boot (and also not in Linux, to the
best of my knowledge).

> I'll omit more comments to this topic until my objections get answered.
> Just one side note: Both methods can be easily set in code, freeing
> every and each developer from reimplementing test case. Such code could
> be one for all and selfexplaining. Is it worth doing using current timer
> API?

See my previuous posting. I don;t think that a generic test method
that works on all boards would be possible.

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
Whom the gods would destroy, they first teach BASIC.

[U-Boot] U-Boot Timer Qualification

[Dirk Behme]

Wolfgang Denk wrote:
> Dear Ladislav Michl,
> 
> In message <20090428151147.GA19683@linux-mips.org> you wrote:
>> a lot of changes are entering arm tree, many without any commit message.
>> And now we have some special cases which needs some special care for yet
>> unclear reason. OMAP3 timer precission was discussed to death and patch
>> still didn't went in, because it needs to be verified against some
>> document you are claiming is not mandatory.
> 
> Just in case there is any doubt here:
> 
> There is no, and I say *no*, mandatory verification of any timing
> precision in U-Boot.
> 
> We all agree that precision is a good thing to have, it it must come
> at a reasonable effort, and there is no reason to drive it into
> extreme precision.

To come back to the more practical part of this discussion ;) , my 
understanding of this is that we agree that

http://lists.denx.de/pipermail/u-boot/2009-April/051204.html

( http://lists.denx.de/pipermail/u-boot/2009-April/051237.html )

should be applied?

Best regards

Dirk

> Clock signals may need an accuracy of 1 or 2% or better - as we may
> see character corruption if the baudrate generators are off too far -
> but this is usually a hardware issue in the first place.
> 
> System timers (like udelay() etc.) in U-Boot do not need such a level
> of accuracy. That does not mean we should intentionally be inaccurate.
> 
> And of course actual testing is good, and documentation of the test
> results is even better.
> 
> But: it is not mandatory. Not in U-Boot (and also not in Linux, to the
> best of my knowledge).
> 
>> I'll omit more comments to this topic until my objections get answered.
>> Just one side note: Both methods can be easily set in code, freeing
>> every and each developer from reimplementing test case. Such code could
>> be one for all and selfexplaining. Is it worth doing using current timer
>> API?
> 
> See my previuous posting. I don;t think that a generic test method
> that works on all boards would be possible.
> 
> Best regards,
> 
> Wolfgang Denk
> 

[U-Boot] U-Boot Timer Qualification

[Wolfgang Denk]

Dear Dirk,

in message <49F884E4.3050709@googlemail.com> you wrote:
>
> > Just in case there is any doubt here:
> > 
> > There is no, and I say *no*, mandatory verification of any timing
> > precision in U-Boot.
> > 
> > We all agree that precision is a good thing to have, it it must come
> > at a reasonable effort, and there is no reason to drive it into
> > extreme precision.
> 
> To come back to the more practical part of this discussion ;) , my 
> understanding of this is that we agree that
> 
> http://lists.denx.de/pipermail/u-boot/2009-April/051204.html
> 
> ( http://lists.denx.de/pipermail/u-boot/2009-April/051237.html )
> 
> should be applied?

Yes.

Actually I'm waiting for Jean-Christophe's pull request for the ARM
repo, and I expect to see this patch included there.

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 glory of creation is in its infinite diversity." "And in the way
our differences combine to create meaning and beauty."
	-- Dr. Miranda Jones and Spock, "Is There in Truth No Beauty?",
	   stardate 5630.8

[U-Boot] U-Boot Timer Qualification

[Jean-Christophe PLAGNIOL-VILLARD]

On 19:47 Tue 28 Apr     , Wolfgang Denk wrote:
> Dear Ladislav Michl,
> 
> In message <20090428151147.GA19683@linux-mips.org> you wrote:
> > 
> > a lot of changes are entering arm tree, many without any commit message.
> > And now we have some special cases which needs some special care for yet
> > unclear reason. OMAP3 timer precission was discussed to death and patch
> > still didn't went in, because it needs to be verified against some
> > document you are claiming is not mandatory.
> 
> Just in case there is any doubt here:
> 
> There is no, and I say *no*, mandatory verification of any timing
> precision in U-Boot.
> 
> We all agree that precision is a good thing to have, it it must come
> at a reasonable effort, and there is no reason to drive it into
> extreme precision.
Personnaly I never ask extreme precision
I ask to known the precision

as the timer is incorrect to known where we go is important

> 
> Clock signals may need an accuracy of 1 or 2% or better - as we may
> see character corruption if the baudrate generators are off too far -
> but this is usually a hardware issue in the first place.
> 
> System timers (like udelay() etc.) in U-Boot do not need such a level
> of accuracy. That does not mean we should intentionally be inaccurate.
> 
> And of course actual testing is good, and documentation of the test
> results is even better.
> 
> But: it is not mandatory. Not in U-Boot (and also not in Linux, to the
> best of my knowledge).
As example when the timer was send by a dev at first and he will send a fix
I think it's start to be mandatory to ask him to test it an a the real hard
It will avoid to have a new fix again and again
which will mean that the timer is never been check in a real use case

> 
> See my previuous posting. I don;t think that a generic test method
> that works on all boards would be possible.
but a docmument and code to do is good and will hepl the dev evenif we can
known and support all boards. This will be improve with patch.

Best Regards,
J.

[U-Boot] U-Boot Timer Qualification

[Wolfgang Denk]

Dear Jean-Christophe PLAGNIOL-VILLARD,

In message <20090429192636.GD13941@game.jcrosoft.org> you wrote:
>
> > We all agree that precision is a good thing to have, it it must come
> > at a reasonable effort, and there is no reason to drive it into
> > extreme precision.
> Personnaly I never ask extreme precision
> I ask to known the precision

What for? It is  not  important.  If  a  timeout  while  waiting  for
peripheral XXX to become ready takes 200 milliseconds or 210 - what's
the difference?

> as the timer is incorrect to known where we go is important

It is not really important.

> > But: it is not mandatory. Not in U-Boot (and also not in Linux, to the
> > best of my knowledge).
> As example when the timer was send by a dev at first and he will send a fix
> I think it's start to be mandatory to ask him to test it an a the real hard

No, I think this is overkill.

> It will avoid to have a new fix again and again
> which will mean that the timer is never been check in a real use case

I agree that it makes sense to run a simple test like "sleep 10" and
check that it's not 5 seconds and not 20.  But that's enough.

> > See my previuous posting. I don;t think that a generic test method
> > that works on all boards would be possible.
> but a docmument and code to do is good and will hepl the dev evenif we can
> known and support all boards. This will be improve with patch.

It's overkill. We can of course make patch submission to U-Boot an
overregulated bureaucratic procedure. The EU gives plenty exaples of
such regulations which keep lots of people busy producing nothing but
hot air. We're engineers howver. Let's be thourough, but efficient.

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
Cogito cogito ergo cogito sum - "I think that I  think,  therefore  I
think that I am."          - Ambrose Bierce, "The Devil's Dictionary"

[U-Boot] U-Boot Timer Qualification

[Mike Frysinger]

On Wednesday 22 April 2009 16:49:36 Jean-Christophe PLAGNIOL-VILLARD wrote:
> 	For all Timer modification a minimun of qualification is mandatory
> 	as it will impact a lots of part of u-boot.
>
> 	So for this purpose I'll propose you to use one of this two approche
> 	to report the precition of your timer or update

describing a method for testing on the list is destined to be ignored/rot.  if 
there was a POST case people could enable and directions under doc/, that has 
a much higher likely hood of being used.

a POST case that utilizes the RTC can be used to verify timer integrity to a 
pretty good degree.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090427/1f75b5fc/attachment.pgp