Hi York,
On 22 March 2017 at 10:00, york sun york.sun@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