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

[Scott Wood]

On Mon, 16 May 2011 13:40:20 +0200
Wolfgang Denk <wd at denx.de> wrote:

> Dear Graeme Russ,
> 
> In message <BANLkTi=u4gJ+Ci8hPfv95m8nYNyEdHgn-g at mail.gmail.com> you wrote:
> >
> > > As we can trivially use regular expressions, the effort to implement a
> > > "timing parser" can be ignored. And it is independet of what sort of
> > > boot device we are using.
> > 
> > Fine if your running Linux - What if the only tool tyou have is
> > Hyperterminal?
> 
> AFAICT tcl is also available under Windoze...

What about a board farm with a networked serial port server, adding
unpredictable latency?  Even if you have direct access to the host serial
port, there's not just the host FIFO distorting things, but the scheduling
latency of the application.  I suspect the useful precision of this
approach is significantly higher than 100 us.

> What makes you think a call to printf()/puts()/putc() would increase
> the code size worse than a call to the trace function? If I don't
> care about pretty messages (and use silent console otherwise) my
> serial console based messages consist of a plain "putc('a')" or
> similar - certainly not more overhead than the call to the trace
> function.

The size impact minor in either case, but in terms of time overhead (i.e.
the thing being measured), waiting for previous output to go
over the wire and the THR to empty is less overhead than putting a
timestamp in a log? Even if THR is already empty, those I/O accesses tend
to be much more expensive than reading from an CPU-internal time source and
writing to a cached data structure.

> It's not about willing or not.  If willing or wanting would help, we
> had an ideal world.  But in reality, we have a world full of
> restrictions.

And requiring that debugging infrastructure for such a low-level piece of
software be universally applicable is a pretty big
self-imposed restriction...

How many targets are so short on pre-relocation memory that they can't
spare a couple hundred bytes for debugging, lacking a suitable time
source, etc.?  It seems like the concept would be usable on more than just
a handful of boards, even if not necessarily all of them.

> GD is definitely not buffer space for arbitrary amounts of log data.

When did "limited" become "arbitrary"?

-Scott