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

[Simon Glass <sjg@chromium.org>]

Hi Tom,

On 19 March 2017 at 18:47, Tom Rini <trini@konsulko.com> wrote:
> 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!

It include size a bit - e.g. x86 808 bytes of text, although that does
include a few extra features.

11: dm: board: Add documentation
16: dm: x86: board: ivybridge: Remove old board init code
       x86: (for 1/1 boards) all +4331.0 bss +2944.0 data +252.0
rodata +327.0 text +808.0
            chromebook_link: all +4331 bss +2944 data +252 rodata +327 text +808
               u-boot: add: 22/0, grow: 1/-4 bytes: 3012/-2183 (829)
                 function                                   old     new   delta
                 ivybridge_dram_init                          -    1956   +1956
                 cpu_x86_ivybridge_phase                      -     151    +151
                 board_walk_phase_count                       -     145    +145
                 ivybridge_checkcpu                           -      96     +96
                 board_phase                                  -      95     +95
                 do_board                                     -      77     +77
                 cpu_print_info                               -      76     +76
                 _u_boot_list_2_uclass_2_board                -      72     +72
                 _u_boot_list_2_driver_2_cpu_x86_ivybridge_board_drv
    -      68     +68
                 _u_boot_list_2_driver_2__cpu_x86_board_drv       -
  68     +68
                 board_walk_phase                             -      28     +28
                 board_walk_opt_phase                         -      28     +28
                 _u_boot_list_2_cmd_2_board                   -      28     +28
                 board_support_phase                          -      27     +27
                 board_support_phase_mask                     -      20     +20
                 cpu_x86_phase                                -      14     +14
                 misc_init_f                                  -      10     +10
                 cpu_x86_ivybridge_board_probe                -      10     +10
                 cpu_x86_board_probe                          -      10     +10
                 checkcpu                                     -      10     +10
                 _u_boot_list_2_driver_info_2_cpu_x86_ivybridge_board
     -       8      +8
                 _u_boot_list_2_driver_info_2_cpu_x86_board       -
   8      +8
                 board_early_init_f                           3      10      +7
                 reserve_arch                                14      10      -4
                 arch_cpu_init_dm                           120       7    -113
                 print_cpuinfo                              125       5    -120
                 dram_init                                 1956      10   -1946
(no errors to report)

I think I can use a linker-list approach to reduce the overhead. But I
still think the driver has value as it provides a means of adding
hooks to do board-specific things from drivers, something that we keep
running into. Also the idea of a board 'driver' seems conceptually
useful.

So one approach would be to have:

1. A linker-list-based board hook setup, where you can declare, for example:

static int ivybridge_dram_init(void)
{
 ...
}
U_BOOT_BOARD_HOOK(ivybridge_dram_init, BOARD_F_DRAM_INIT);

This should be pretty cheap, perhaps <200 bytes with some care.


2. An optional BOARD uclass which can be used for more involved
situations, but with a higher code size penalty.

Regards,
Simon