Hi Tom,
On 19 March 2017 at 18:47, Tom Rini <tr...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
