[U-Boot] [PATCH 0/4] Accurate boot time measurement

[Graeme Russ]

On Fri, May 20, 2011 at 11:48 AM, Simon Glass <sjg at chromium.org> wrote:
> On Thu, May 19, 2011 at 1:36 AM, Detlev Zundel <dzu at denx.de> wrote:
>> Hi Simon,
>>
>> [...]
>>
>>> I believe I have covered this ground very thoroughly and would like
>>> advice please on what to do next. The options I can see are:
>>
>> As Graeme points out, you got enough positive feedback that I encourage
>> you to continue and address the comments.
>
> OK, it would be nice to have a note from Wolfgang since without his OK
> it won't make it in, right?
>
>>
>>> - change the code to use a fallback when a microsecond timer is not
>>> available
>>
>> Excuse me for not diving into that too deep, but from my top-level
>> overview, it would seem like a good idea that if an architecture _has_ a
>> microsecond timer, it could use generic code to massage that into the
>> HZ=1000 API that we currently use with the addition of offering the
>> extended precision.  Your code then would need such a fallback and could
>> work with the best precision offered by the architecture.  New
>> architectures with microsecond timers would need to only implement the
>> new microsecond timer infrastructure and be done with it.
>
> Yes I suggested that a few emails ago but didn't get a response.

Is it just me or are get_timer(), set_timer() and reset_timer() in U-Boot
a little bit braindead? get_timer() returns microseconds since last
reset_timer() plus an optional offset, set_timer() allows the current
microseconds to an arbitrary value and reset_timer() is essentially
set_timer(0)

A random look at at91 is interesting though:

void set_timer(ulong t)
{
	gd->tbl = t;
}

void reset_timer(void)
{
	reset_timer_masked();
}

void reset_timer_masked(void)
{
	/* reset time */	
	at91_tc_t *tc = (at91_tc_t *) AT91_TC_BASE;
	gd->lastinc = readl(&tc->tc[0].cv) & 0x0000ffff;
	gd->tbl = 0;
}

So set_timer(0) != reset_timer() in a rather big way!

Now some arches (imx for example) do not implement set_timer() which makes
using it a 'Bad Idea'(tm)

And why do we need reset_timer() - Anything that uses it can just do:

ulong start_time = get_timer(0);
while (get_timer(start_time) < SOME_TIMEOUT) {
	...do stuff..
}

NOTE: May not be the 'safest' way to do that - I recall there being a LOT
of discussion about this with regards to wrap-around and safe ways of
doing the above

Anyway, my point is, if the timer API wasa fixed, all the boot logging API
needs to do is call get_timer() and your done - instant millisecond
timestamp - No fallbacks - Each arch just needs to implement get_timer()
correctly

>>> - integrate with boot progress
>>
>> The current boot progress to me seems pretty ugly and could do with a
>> make-over.  So if it is possible to merge those two logical functions,
>> we would have a win-win situation.

Sounds like a two-patch approach - Fix up boot progress and then slap
logging on top

>
> OK fair enough. I will do this if there is agreement that this type of
> boot timing is worth having.

I could have a look at this if you like Simon

Regards,

Graeme