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

[Simon Glass]

Hi Graeme,

On Mon, Sep 12, 2011 at 10:24 PM, Graeme Russ <graeme.russ at gmail.com> wrote:
> Hi Simon,
>
> On Tue, Sep 13, 2011 at 2:34 PM, Simon Glass <sjg at chromium.org> wrote:
>> Hi Andrew,
>>
>> On Sat, Sep 10, 2011 at 5:40 AM, Andrew Murray <amurray at theiet.org> wrote:
>>> On 1 September 2011 00:53, Andrew Murray <amurray at theiet.org> wrote:
>>>>
>
>>
>> This patch touches on Graeme's initcall patch. If board_init_r were
>> just a list of function pointers then your patch would be easier! Not
>> much we can do about that at this stage, and I think your solution is
>> reasonable.
>
> And I would love to get this back on the table - I honestly think that
> the initcall solution, although it had it's own set of 'problems' is a
> more robust approach that the current 'array of function pointers'
> solution.

Yes I prefer it, it's a question of how to make things simple and
obvious, and not obfuscate to much something which is currently very
simple (if a little primitive). With respect to initcalls, it would
perhaps be a shorter step if the board_init_f/r functions were truly
just running through a list of function pointers. At present they
contain other code also.

Also, while we worry about ordering, it is really important that (for
example) NAND init happens before MMC?

>
> I think we now have a number of ideas (some with solid patches) that is
> going to make the future of the boot sequence very bright indead:
>
>  - Bootgraph
>  - Unified timer API (nanosecond would be nice)
>  - initcall
>  - 'pre-console' output buffer
>  - timestamped printf()
>
> Looking forward to opening up these cans of worms again :)

Bravery is to be encouraged. Biting off what seems like the smallest,
what is the status of pre-console output?

Regards,
Simon

>
> Regards,
>
> Graeme
>