Hi Simon, Tom. 2017-01-24 5:31 GMT+09:00 Simon Glass <s...@chromium.org>: > This converts the following to Kconfig: > CONFIG_ARCH_EARLY_INIT_R > > Signed-off-by: Simon Glass <s...@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/ [2] How painful is it to use __weak function instead of CONFIG_ARCH_EARLY_INIT_R [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. -- Best Regards Masahiro Yamada _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
