Hi Bin, On 26 February 2015 at 00:15, Bin Meng <bmeng...@gmail.com> wrote: > Hi Simon, > > On Thu, Feb 26, 2015 at 8:55 AM, Simon Glass <s...@chromium.org> wrote: >> Hi Bin, >> >> On 25 February 2015 at 01:45, Bin Meng <bmeng...@gmail.com> wrote: >>> Hi Simon, >>> >>> On Thu, Feb 19, 2015 at 5:10 AM, Simon Glass <s...@chromium.org> wrote: >>>> At present we do more in this function than we should. Create a new >>>> x86_post_cpu_init() which can be called from the board file when needed >>>> (e.g. in board_early_init_f(). This allows us to use driver model for >>>> our x86_post_cpu_init() function. >>>> >>>> It is likely that some future refactoring will improve this and reduce >>>> the number of steps, using driver model's probing features. >>>> >>>> Note: this needs more discussion - e.g. I believe it breaks other x86 >>>> boards. We may want to plumb this in differently (e.g. promote >>>> x86_post_cpu_init() to the board_init_f() boot sequence). >>> >>> Or maybe change the order in board_f.c so that arch_cpu_init() comes >>> after init_dm()? >> >> I feel that arch_cpu_init() should be for very early things, the >> absolute minimum to allow the machine to function and driver model to >> be set up. Clearly x86 does not conform to that now! >> >> But I think there are a few things that fit in this category so having >> the separated seems better. > > OK, I would prefer we explicitly put the post_cpu_init() into > board_f.c initialization sequence. This isn't x86-specific. Any > architecture which uses DM and generic board (starting from v2015.04 > release) will benefit from this.
Yes I'll do this, sounds like a good idea. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot