From mboxrd@z Thu Jan 1 00:00:00 1970 From: Graeme Russ Date: Sun, 15 May 2011 20:03:47 +1000 Subject: [U-Boot] [PATCH 0/4] Accurate boot time measurement In-Reply-To: References: <1305319923-9477-1-git-send-email-sjg@chromium.org> <201105140734.13610.vapier@gentoo.org> Message-ID: <4DCFA503.2070805@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 15/05/11 03:32, Simon Glass wrote: > On Sat, May 14, 2011 at 4:34 AM, Mike Frysinger wrote: > >> On Friday, May 13, 2011 16:51:59 Simon Glass wrote: >>> This defines the basics of a new boot time measurement feature. This >> allows >>> logging of very accurate time measurements as the boot proceeds, by using >>> an available microsecond counter. >>> >>> To enable the feature, define CONFIG_BOOTSTAGE in your board config file. >>> Also available is CONFIG_BOOTSTAGE_REPORT which will cause a report to be >>> printed just before handing off to the OS. >> >> this seems to overlap the existing show_boot_progress() code. any chance >> we >> can look at these being merged ? >> -mike >> > > Hi Mike, > > Yes I did look at this a few weeks ago. It would be a pretty invasive > change. That code just uses a whole lot of numbers which presumably are > approximately how far through the boot process we are. Bootstage is intended > as a debugging tool for performance tune-up rather than a user display tool. > I could imagine adding a table to bootstage with the progess number for each > bootstage id, but then people are going to complain that the bootstage > report is far to long and includes uninteresting things. I suppose I could > fix that by including a flag as to whether to report each item or not...but > it any case as you can see it is not a clear win. > > If there is a strong appetite for that sort of patch I'm happy to do it. > > Regards, > Simon > 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 ;) Regards, Graeme