[U-Boot] [PATCH 0/7] Bootgraph.pl instrumentation support for UBoot

Simon Glass sjg at chromium.org
Thu Sep 1 01:39:40 CEST 2011


Hi Andrew,

On Wed, Aug 31, 2011 at 4:32 PM, Graeme Russ <graeme.russ at gmail.com> wrote:
> Hi Andrew,
>
> On Thu, Sep 1, 2011 at 9:25 AM, Andrew Murray <amurray at mpc-data.co.uk> wrote:
>> On 1 September 2011 00:12, Simon Glass <sjg at chromium.org> wrote:
>>> Hi Mike,
>>>
>>> On Wed, Aug 31, 2011 at 3:47 PM, Mike Frysinger <vapier at gentoo.org> wrote:
>>>> On Wednesday, August 31, 2011 18:20:54 Andrew Murray wrote:
>>>>> This patchset introduces the CONFIG_BOOT_TRACE option which provides
>>>>> support for boot time instrumentation.
>>>>>
>
> [snip]
>
>>>>>
>>>>> The patch currently provides support for instrumentation of UBoot commands
>>>>> (e.g. U_BOOT_CMD) for all platforms but only when the HUSH shell is not in
>>>>> use. Initialisation instrumentation is only limited to the
>>>>> arch/arm/lib/board.c file at present but can very easily be extended to
>>>>> other relevant files.
>>>>
>>>> i feel like we've had similar ideas tossed around semi-recently.  am i just
>>>> misremembering ?
>
> No, your memory is fine :)
>
>>>> -mike
>>>>
>>>
>>> Yes, for example:
>>>
>>> http://patchwork.ozlabs.org/patch/95513/
>>>
>>> It got caught up with a big discussion about whether we want a
>>> microsecond timer. There is now one in Tegra, but not in the generic
>>> timer API. There was also a request to unify this with the
>>> boot_progress stuff (i.e. it turned into a big cleanup).
>>>
>>> I haven't got back to it yet, but could probably do something next week.
>>>
>>> I also have patches to pass the timings to the kernel and have it
>>> report them to user space through a device. Planning to send an RFC to
>>> the LKML about that probably next week as well. Could be fun.
>>>
>>> Regards,
>>> Simon
>>>
>>
>> Ah - my bad. I only subscribed to the mailing list today (my first
>> UBoot patch) and didn't notice this previous work.
>>
>> Is there any cross over between my approach and what is
>> planned/already been done?
>>

Don't worry - your contribution is very welcome!

Yes I think there is cross-over, and perhaps the right approach is to
try to merge them somehow. It is great to get graphs out of the code
and it really helps with analysis. My interest was mainly in
monitoring boot time in the field rather than in the lab. But we
should have one framework for both.

>
> Have a look through the mailing list archive - I find this one the easiest
> for scanning headings: http://lists.denx.de/pipermail/u-boot/
>
> Take a look over the last few months for anything timer related - Trust
> me, the rabit warren is very deep ;)
>

Please don't look at the mailing list for timer-related things as you
will go mad.

> When I get a chance to breath again, I'll be taking another look at the
> timer API and with the (hopefully) pending inclusion of the pre-console
> buffer, I think boot tracing will come together very nicely
>
> Regards,
>
> Graeme
>

I will assume that we have a microsecond timer, update my patch and
resubmit so you can take a look and see what you think. Hopefully we
can unify this, your patch and the boot_progress stuff.

Regards,
Simon


More information about the U-Boot mailing list