On Tue, Jan 24, 2017 at 11:36:11AM +0900, Masahiro Yamada wrote:
Hi Simon, Tom.
2017-01-24 5:31 GMT+09:00 Simon Glass sjg@chromium.org:
This converts the following to Kconfig: CONFIG_ARCH_EARLY_INIT_R
Signed-off-by: Simon Glass sjg@chromium.org
arch/Kconfig | 1 + arch/arc/include/asm/config.h | 1 - arch/arm/Kconfig | 1 + arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 4 ++++ common/Kconfig | 13 +++++++++++++ configs/bayleybay_defconfig | 1 + configs/cougarcanyon2_defconfig | 1 + configs/dfi-bt700-q7x-151_defconfig | 1 + configs/efi-x86_defconfig | 1 + configs/minnowmax_defconfig | 1 + configs/mvebu_db-88f3720_defconfig | 1 + configs/mvebu_db-88f7040_defconfig | 1 + configs/mvebu_db-88f8040_defconfig | 1 + configs/qemu-x86_efi_payload32_defconfig | 1 + configs/qemu-x86_efi_payload64_defconfig | 1 + configs/rut_defconfig | 1 + configs/theadorable-x86-dfi-bt700_defconfig | 1 +
I have some questions
[1] Is this a user-configurable symbol?
You use "select" in some places, but add it in defconfig in others.
This is controlling whether arch_early_init_r() is called from common/board_r.c or not, right?
Does it make sense to skip the init function if users want to?
Maybe, Tom will end up with converting all of them to "select" like this? http://patchwork.ozlabs.org/patch/718315/
I will probably end up moving this to all select iff it ends up with no size change.
[2] How painful is it to use __weak function instead of CONFIG_ARCH_EARLY_INIT_R
For something that's only in U-Boot proper? Probably not bad, but a follow-up.
[3] We have board_early_init_r() for board-specific init procedure. From its function name, I thought arch_early_init_r() is called for arch-specific (ARC, ARM, x86) init. In fact, it is not. ARC is good. For ARM, x86, it is abused for board specific init.
For example,
board/siemens/rut/board.c
int arch_early_init_r(void) { enable_lcd(); return 0; }
This is apparently board_init, not arch_init.
This is indeed problematic and partly why moving this to 'select' isn't trivial as some of the locations of the functions make it unclear enough if the right answer isn't instead to move this elsewhere. My first guess is that on 'rut' the LCD needs to be visible asap for the "it's alive!" factor.