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

[Wolfgang Denk <wd@denx.de>]

Dear Simon Glass,

In message <BANLkTi=wdddeKLjoBFRoNcqzXJN9uGnBSw@mail.gmail.com> you wrote:
>
> Such a lot of text about such a small patch. It is clear to me that you are
> used to doing things one way, and this is a different approach. As I said

You can tell many things about me, but this one certainly is not the
case.

> > I don't see that we use any FIFOs in the output direction.
> 
> 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?

> 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.

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.

> > 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.

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.

> 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.

> > 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 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?

> 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.

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