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

[Wolfgang Denk]

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

> I've seen many instances where everything works well 'in the lab' and as
> soon as you put it in the field, things go pear shaped. Often you need to

We all have seen this, and we all appreciate any tool that is
available then.

> > 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.
> 
> Maybe a limited amount can be stored in global data by testing the
> relocated flag

I don't think so.

> > OK, not needing a console port during boot is indeed an advantage.  It
> > comes at the cost of needing log space, which is not available before
> > relocation, so we miss some interesting parts of the boot procedure.
> 
> Can use global data for a limited number of pre-relocation records. And I
> don't think pre-location is where a lot of problems will occur anyway
> unless you have flaky/misconfigured  hardware

I smell a bloated implementation which works on one specific system or
two.  This doesn't sound attractive to me.

> >> 5. It allows timing of things which don't result in serial output.
> >
> > But to do so, you need to insert trace points.  With the same effort
> > we can insert a printf().
> 
> Which increase code/data size - If you don't care about having pretty
> messages in you boot profile (you can always look up source or
> documentation) the size impact per 'mark' is less

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.


> I think my refined suggestion has a far smaller impact than first thought
> and you can get pre-relocation information if you are willing to use
> some global data storage

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.

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

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
A little suffering is good for the soul.
	-- Kirk, "The Corbomite Maneuver", stardate 1514.0