[U-Boot] U-Boot Timer Qualification
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.
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
participants (5)
-
Dirk Behme -
Jean-Christophe PLAGNIOL-VILLARD -
Ladislav Michl -
Mike Frysinger -
Wolfgang Denk