Skip to content

RFC Version 0 of Kconfig for U-Boot

Masahiro Yamada u-boot 1 version New

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 RFC Latest0 of 17 patches 0 repliesNew

Patches in v1 No applies recorded yet

None of the 17 patches the cover letter announces are in this archive.

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

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

Hi Wolfgang,

Quoted 20 lines · On Mon, 24 Mar 2014 08:30:56 +0100 Wolfgang Denk <[email protected]> wrote:

Dear Masahiro,

Quoted 8 lines · In message <[email protected]> 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?

Quoted 6 lines

#ifdef CONFIG_SPL_BUILD
# define CONFIG_SYS_TEXT_BASE 0x00000000
#else
# define CONFIG_SYS_TEXT_BASE 0x10000000
#endif

Quoted 8 lines
Quoted 3 lines

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

Read the cover letter in its thread