From mboxrd@z Thu Jan  1 00:00:00 1970
From: Simon Glass <sjg@chromium.org>
Date: Sun, 15 May 2011 14:34:49 -0700
Subject: [U-Boot] [PATCH 0/4] Accurate boot time measurement
In-Reply-To: <4DCFA503.2070805@gmail.com>
References: <1305319923-9477-1-git-send-email-sjg@chromium.org>
	<201105140734.13610.vapier@gentoo.org>
	<BANLkTikbUdVza1iLe_Vdj4RsJUwRtO4kQw@mail.gmail.com>
	<4DCFA503.2070805@gmail.com>
Message-ID: <BANLkTi=i1vmrSBh4KZh8BLFoUzEQr1i4Kw@mail.gmail.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On Sun, May 15, 2011 at 3:03 AM, Graeme Russ <graeme.russ@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 ;)
>

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.

Regards,
Simon


>
> Regards,
>
> Graeme
>