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

[Simon Glass]

On Mon, May 16, 2011 at 11:32 AM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Simon Glass,
>...
>> Yes we do, and in fact they do improve boot performance slightly when the
>> console is muted.
>
> Do you have an explanation how that works?  When there is no output on
> the console, the use of a FIFO in tx direction should not matter at
> all?

Hi Wolfgang,

That's right, but when output is not muted, the FIFO allows for some
characters to be output before stalling the CPU.

>
>> I agree it is unfortunate to have features which require platform-specific
>> features. Perhaps we should define a microsecond timer as a requirement of a
>> U-Boot port? Or perhaps an option which opens up new features?
>
> We already have that, or better.  The problem is that it depends on
> the architecture.

The implementation, maybe (not the interface which can be common), but
by expressing things in microseconds it is normally possible to
convert, and when this isn't available people will understand that
some rounding is going on.

>
> On PPC systems for example you always have the time base, a 64 bit
> counter which is clocked with something like 1/4 or 1/16 of the CPU
> clock.
>
> And whe have the timer that gettime() is based on - which is in
> milliseocnd resolution (hence the demand that CONFIG_SYS_HZ must
> always be defined as 1000).
>
> The problem comes with the multitude of different architectures and
> SoCs we support - there is no concept of timebase registers on ARM, on
> some systems we need interrupts to implement timer services so these
> are available only after relocation, etc.

On several ARM SOCs there is a monotonic timer - it's not always a
microsecond timer but is typically good enough for this sort of
purpose. In some cases this doesn't require interrupts (e.g. Tegra).

>
>> > But you need storage for the timing events, and you don't have this
>> > before relocation. So you miss some really interesting parts of the
>> > boot procedure.
>>
>> It is easy enough to get storage if we want it - you can maintain a
>> pre-reloc table which is copied over afterwards. I notice that some
>
> Where will you store this "pre-reloc" table?  Yes, there are some
> systems with plenty of on-chip-memory or huge caches that can beused
> for this.  But there are also systems where we barely can find the
> room for the most vital global data before relocation.

I would rather discuss this once we get agreement on the first part of
this, which is the concept of using a timer at all! But it is not hard
to store data pre-reloc and move it later. This is what happens with
the global data at the moment.

>
> Even worse - if you take this seriously, you will probably also get
> timing information from early boot stages, like how long it's taking
> to load the U-Boot image from NAND - but on some systems this loader
> code has to fit in as little as 2 KiB.

SOC boot ROMs are changing this, but even so I don't see this as a
serious limitation. If you don't have room for boot timing in your
pre-boot loader, don't add it.

>
>> I believe it compares favourably. It has a more friendly display, doesn't
>> require a serial port, is more accurate, can run self-hosted, etc. With the
>> TCL script you need to add a new line before you will get a new time.
>
> Well, the display format is trivial to adapt, as well as the trigger
> criteria. Keep in mind that this is just an example script that
> covers the most common use case we've seen so far.

OK

>
>> > But to do so, you need to insert trace points.  With the same effort
>> > we can insert a printf().
>>
>> Fair enough. If you have your heart set on the TCL script I'm really not
>> going to get very far!
>
> I haven't my heart set on it.  It is just one example of solutions
> which cover a large percentage of the potential use cases.  I am
> trying to understand the ration of advanatges versus effort, that's
> all.

In that case will you consider the inclusion of this as a different
way of doing things?

>
>> In terms of all this discussion I can see your point :-) I did have
>> expressions of interest from two people including one I thought was at your
>> company, which I why I went to the effort to clean up and submit this. At
>> that time I didn't realise it would be such a touchy subject.
>
> Where is the problem?  If you are convinced of you idea you should be
> ready to defend it.  If you are not, it's not wort it at all.  And if
> you see a voting result of 2:1 pro this is pretty good, isn't it?

I think I have mounted a robust defense. In fact I haven't written so
much on one topic for a week :-)

>
>> But if you really don't want this in U-Boot then please accept my apologies
>> for wasting so much time on the list.
>
> I don't consider this discussion a waste of time. I hope you don't do,
> either.

Regards,
Simon

>
> 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
> Life would be so much easier if we could  just  look  at  the  source
> code.                                                   -- Dave Olson
>