Hi Graeme, On Mon, Sep 12, 2011 at 10:24 PM, Graeme Russ <graeme.r...@gmail.com> wrote: > Hi Simon, > > On Tue, Sep 13, 2011 at 2:34 PM, Simon Glass <s...@chromium.org> wrote: >> Hi Andrew, >> >> On Sat, Sep 10, 2011 at 5:40 AM, Andrew Murray <amur...@theiet.org> wrote: >>> On 1 September 2011 00:53, Andrew Murray <amur...@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 > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot