Hi Simon, On 03/19/17 20:59, 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
I haven't got this one yet from the patchset. May be I need to look closer... > > This series starts the process of replacing the pre-relocation init > sequence with a driver-model solution. It defines a uclass, adds tests > and converts sandbox and a few x86 boards over to use this new setup. > > This series is not ready for use yet as the rest of the init sequence > hooks need to be converted. But there is enough here to show the idea. > > Comments welcome. Overall, it sounds like a great idea! -- Regards, Igor. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
