[U-Boot] [PATCH v3 13/15] bootstage: Implement core microsecond boot time measurement

[Simon Glass]

Hi Wolfgang,

On Mon, Mar 19, 2012 at 12:13 AM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Simon Glass,
>
> In message <1326590698-7767-14-git-send-email-sjg at chromium.org> you 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.
>>
>> Most IDs are not named at this stage. For that I would first like to
>> renumber them all.
>
> Hm.... I'm not sure what happened.
>
> I am positively sure (and I just checked again in the bash history)
> that I did apply the correct version of "[PATCH v3 11/15] timer: add
> microsecond boot func".
>
> However, the repository appears to have an old version instead:
>
>        f933e84   2012-03-18 21:43:17 +0100   bootstage: arm: Add bootstage calls in board and bootm
>        573f14f   2012-03-18 21:42:56 +0100   bootstage: Plumb in bootstage calls for basic operations
>        3a608ca   2012-03-18 21:42:14 +0100   bootstage: Implement core microsecond boot time measurement
>        770605e   2012-03-18 21:41:39 +0100   bootstage: Replace show_boot_progress/error() with bootstage_...()
> ==>     5ff5539   2012-03-18 21:33:53 +0100   bootstage: Define an optional microsecond timer
>        aacc8c1   2012-03-18 21:33:32 +0100   bootstage: Convert FIT progress numbers to enums
>        c8e66db   2012-03-18 21:33:05 +0100   bootstage: Convert net progress numbers to enums
>        cd24a6b   2012-03-18 21:27:20 +0100   bootstage: Convert NAND progress numbers to enums
>        90e153d   2012-03-18 21:24:21 +0100   bootstage: Convert IDE progress numbers to enums
>        8ade950   2012-03-18 21:16:22 +0100   bootstage: Convert progress numbers 20-41 to enums
>        5e41088   2012-03-18 20:59:53 +0100   bootstage: Convert progress numbers 10-19 to enums
>        5dc8871   2012-03-18 20:57:37 +0100   bootstage: Convert progress numbers 1-9 into enums
>        5ddb118   2012-03-18 20:56:00 +0100   bootstage: Use show_boot_error() for -ve progress numbers
>        578ac1e   2012-03-18 20:45:57 +0100   bootstage: Make use of BOOTSTAGE_ID_RUN_OS in show_boot_progress()
>        097e178   2012-03-18 20:43:38 +0100   bootstage: Create an initial header for boot progress integers
>
>
> I cannot reproduce it, but it seems patchworked palyed some trick on
> me (it has also beenx extremely slow last night - eventually some
> works was going on there?).
>
>
> Anyway. Fact is, the current mainline code contains a broken patch,
> which breaks for example the PMC440 board:
>
> Configuring for PMC440 board...
> /work/wd/tmp-ppc/examples/api/time.o: In function `__timer_get_boot_us':
> /home/wd/git/u-boot/work/lib/time.c:60: undefined reference to `get_timer'
> /home/wd/git/u-boot/work/lib/time.c:61: undefined reference to `get_timer'
> make[1]: *** [/work/wd/tmp-ppc/examples/api/demo] Error 1
>
>
> Can you please have a look and provide an incremental patch to bring mainline back in sync with your current code base?

Yes I will send one though. But this is my mistake, not yours. I did
not get around to sending an updated patch - I was in fact going to
ask about the best solution for it, as I was thinking of moving the
timer function into bootstage.c.

Anyway I will send a patch as is, but if you would rather the function
move so we can remove the #ifdef let me know.

Regards,
Simon

>
> Thanks.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> Each team building another component has been using the  most  recent
> tested  version  of the integrated system as a test bed for debugging
> its piece. Their work will be set back by having that test bed change
> under them. Of course it must. But the changes need to be  quantized.
> Then  each  user  has periods of productive stability, interrupted by
> bursts of test-bed change. This seems to be much less disruptive than
> a constant rippling and trembling.
>                     - Frederick Brooks Jr., "The Mythical Man Month"