[U-Boot] [RFC PATCH 0/17] Version 0 of Kconfig for U-Boot

Masahiro Yamada
2014-03-24T07:52:38Z

Hi Wolfgang,

On Mon, 24 Mar 2014 08:30:56 +0100
Wolfgang Denk <wd@denx.de> wrote:

> Dear Masahiro,
>
> In message <20140324145814.B35F.AA925319@jp.panasonic.com> you wrote:
> >
> > You are suggesting a better idea below.
> > We should not treat SPL as a special case.
> >
> > In my opinion, CONFIG_SPL_* should be discontinued.
> >
> > For example, we can merge CONFIG_SPL_TEXT_BASE
> > to CONFIG_SYS_TEXT_BASE.
>
> Are you sure this is always possible?
>
> > #ifdef CONFIG_SPL_BUILD
> > # define CONFIG_SYS_TEXT_BASE 0x00000000
> > #else
> > # define CONFIG_SYS_TEXT_BASE 0x10000000
> > #endif
> >
> > rather than
> > #define CONFIG_SPL_TEXT_BASE 0x00000000
> > #define CONFIG_SYS_TEXT_BASE 0x10000000
>
> Are there really no cases where for example the SPL needs to know
> CONFIG_SYS_TEXT_BASE, for example when loading U-Boot to RAM?
> I think that the "normal" U-Boot does not need to know about the SPL,
> but is this also always true the other way round?

SPL should refer to "load addr" in the uImage header when loading U-Boot
to RAM.
So __if the code is written correctly__, CONFIG_SYS_TEXT_BASE should
not be refered from another image.

But I am not sure. There may be some exception.

By the way, the rule of CONFIG_SYS_ is broken here too.
We're using CONFIG_SPL_TEXT_BASE instead of CONFIG_SYS_SPL_TEXT_BASE
inconsistently.
I'm afraid inconsistent rules sometimes make the situation worse than
nothing.

Best Regards
Masahiro Yamada