On Mon, May 16, 2011 at 7:34 AM, Simon Glass <s...@chromium.org> wrote:
> On Sun, May 15, 2011 at 3:03 AM, Graeme Russ <graeme.r...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
