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

[Graeme Russ]

On Mon, May 16, 2011 at 9:40 PM, 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...
>
>> 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.

As I said before, the timing aberation per-boot in pre-relocation code is
going to be pretty minimal. 'In The Lab' you can easily use putc() and
your favourite terminal/script to do the timing analysis when you are
trying to trim micro-seconds (optimising SDRAM init/sizing etc, NAND
loading, NOR wait states)

My particular interest in the boot timing analysis is where it is being
affected by factors such as:
 - Device initialisation (peripherals via I2C, FPGAs etc)
 - Network (DHCP/TFTP requests)
 - Storage device access (HDDs, NAND etc)
 - Physical Environment (temperature etc)

These factors are not as reproducible 'In The Lab' and in the field may
be very transient.

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

Another 'In The Field' scenario is where you do not have a free console
port available because thay are all used for communicating to other
devices. We have devices with five serial ports and at times we still run
out of ports

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

Yes, and some of those restrictions limit your ability to use a serial
port to debug boot times

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

Agreed, but:
 a) Pre-relocation logging may not strictly be needed because boot-times
    up to relocation can be fine tuned in the lab using putc()
 b) A few dozen bytes in GD in a debug build to isolate some stupid random
    issue onyl seen in the field can save hundreds (if not thousands) of
    <insert you local currency here> of engineering time

Regards,

Graeme