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

[Graeme Russ]

On Mon, May 16, 2011 at 7:34 AM, Simon Glass <sjg at chromium.org> wrote:
> On Sun, May 15, 2011 at 3:03 AM, Graeme Russ <graeme.russ at gmail.com> wrote:
>>
>> Couple of thoughts:
>>  - Macro the definition of show_boot_progress() so it accepts a (const
>>    char *) argument if CONFIG_BOOTSTAGE is defined
>>  - Change BOOTSTAGE_COUNT to CONFIG_MAX_BOOTSTAGE_RECORDS
>>  - Any call to show_boot_progress() with a non-null second argument
>>    causes it to be logged in the next available bootstage record
>>  - After the last bootstage record is filled, no further calls to
>>    show_boot_progress() cause logging to the bootstage records
>>  - Instead of CONFIG_BOOTSTAGE_REPORT, create a command which dumps the
>>    contents of the bootstage records
>>
>> No this is going to result in a big patch (every instance of
>> show_boot_progress() will need to be touched to at least add NULL as the
>> second parameter - Maintainers can add better text later ;)

I've thought of a 'better' approach:
  - Do no modify the parameters of show_boot_progress()
  - Create a new struct:
    struct boot_progress_msg {
      int boot_progress_id;
      const char *message;
    {
  - Initialise the 'boot profile messages'
    struct boot_progress_msg boot_messages[] = {init with any boot progress
    id's you want to assign a text message too}
  - The 'bootstage record' array is simply an array of int's
  - show_boot_progress() logs the argument into the 'bootstage record'
    array as described before
  - The 'dump boot profile' command dumps the contents in the array,
    looking up matches in the 'boot profile messages' array to print out
    meaningful messages (or just the raw integer if no message defined)
  - Can show_boot_progress() be modified to add a 'flag' to select logging
    to the boot profile (do any platforms already use the highest bit for
    flagging for example) - Maybe #define CONFIG_BOOTSTAGE_LOG_FLAG in the
    config file to select an available bit
  - Create another command to compile the boot profile into a memory (for
    passing to Linux for example) - This command would need to perform
    strcpy() but is not in the time critical path anymore

So the 'time' overhead of profiling is
  - A call to show_boot_progress() (already there for a majority of cases)
  - A timer read
  - An integer test (current record < MAX_RECORDS)
  - A integer write to boot_messages[]
  - An integer increment (current_record++)

The code impact is now negligible - no modification to show_boot_progress()
calls unless the 'profile' flag is added and only minor modifications
to the show_boot_progress() function which can all be contained in an
#ifdef

The memory overhead can be as little as almost zero (have nothing in
boot_progress_msg boot_messages[]) at the expense of you profile log
requiring code or documentation to decode (can even add a #define
CONFIG_BOOTSTAGE_MESSAGES)


> Thanks for your thoughts. It can be done, but my bigger question is this:
>> If there is a strong appetite for that sort of patch I'm happy to do it.
>
> If I get some +ve responses then I will do it, otherwise I think I should
> assume people want this left as is.

I hope some more people are interested ;)

Regards,

Graeme