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

Tom Rini trini at konsulko.com
Mon Mar 20 00:47:04 UTC 2017


On Sun, Mar 19, 2017 at 12:59:19PM -0600, 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. 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.
> 
> [1] https://lists.denx.de/pipermail/u-boot/2011-August/098718.html

How does this look, size wise?  With all of these conversions and
clean-ups, we really need to be size concious as well as it all keeps
adding up.  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170319/1248b8f9/attachment.sig>


More information about the U-Boot mailing list