[U-Boot] [PATCH 03/11] Convert CONFIG_ARCH_EARLY_INIT_R to Kconfig

[Tom Rini]

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 at chromium.org>:
> > This converts the following to Kconfig:
> >    CONFIG_ARCH_EARLY_INIT_R
> >
> > Signed-off-by: Simon Glass <sjg at 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.

-- 
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/20170123/aec2720a/attachment.sig>