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

[Masahiro Yamada <yamada.m@jp.panasonic.com>]

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