Hi Graeme,
On Mon, Sep 12, 2011 at 10:24 PM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Simon,
On Tue, Sep 13, 2011 at 2:34 PM, Simon Glass sjg@chromium.org wrote:
Hi Andrew,
On Sat, Sep 10, 2011 at 5:40 AM, Andrew Murray amurray@theiet.org wrote:
On 1 September 2011 00:53, Andrew Murray amurray@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