[U-Boot] [PATCH 00/16] RFC: Board init using driver model

[Simon Glass]

Hi York,

On 22 March 2017 at 10:00, york sun <york.sun at nxp.com> wrote:
> On 03/19/2017 11:59 AM, Simon Glass wrote:
>> At present we have a lot of ad-hoc init functions related to boards, for
>> example board_early_init_f(), board_misc_init_f() and dram_init().
>>
>> There are used in different ways by different boards as useful hooks to
>> do the required init and sequence it correctly. Some functions are always
>> enabled but have a __weak default. Some are controlled by the existence
>> of a CONFIG.
>>
>> There are two main init sequences: board_init_f() (f for running from
>> read-only flash) which runs before relocation and board_init_r() (r for
>> relocated) which runs afterwards.
>>
>> One problem with the current sequence is that it has a lot of
>> arch-specific #ifdefs around various functions. There are also #ifdefs
>> for various features. There has been quite a bit of discussion about how
>> to tidy this up and at least one RFC series[1].
>>
>> Now that we have driver model we can use this to deal with the init
>> sequences. This approach has several advantages:
>>
>> - We have a path to remove the #ifdefs
>> - It is easy for multiple parts of the code to implement the same hook
>> - We can track what is called and what is not
>> - We don't need weak functions
>> - We can eventually adjust the sequence to improve naming or to add new
>> init phases
>> - It provides a model for how we might deal with ft_board_setup() and
>> friends
>>
>> This series starts the process of replacing the pre-relocation init
>> sequence with a driver-model solution.
>
> I like the idea to be able to use DM earlier.

Well actually my series does not allow that. Here is the start of the
init sequence with u-boot-dm/rmb-working applied:

static const init_fnc_t init_sequence_f[] = {
        setup_mon_len,
#ifdef CONFIG_OF_CONTROL
        fdtdec_setup,
#endif
#ifdef CONFIG_TRACE
        trace_early_init,
#endif
        initf_malloc,
        initf_console_record,
#if defined(CONFIG_HAVE_FSP)
        arch_fsp_init,
#endif
        arch_cpu_init, /* basic arch cpu dependent setup */
        mach_cpu_init, /* SoC/machine dependent CPU setup */
        initf_dm,

Of these:
- Setting up device tree must happen before DM
- trace could be moved later, but then you lose tracing of DM init
- malloc() is needed
- recording console could move, but as it is it records DM init
console debug output, which could be useful
- arch_fsp_init() and arch_cpu_init() and mach_cpu_init() could
perhaps move later depending on how we define them

Anyway I'm interested in your suggestions.

Regards,
Simon