boards.cfg: fix a configuration error of ep8248 board again

"make ep8248_config" fails with an error like this:

    $ make ep8248_config
    make: *** [ep8248_config] Error 1

Its cause is that there are two entries for "ep8248".

The first is around line 661 of boards.cfg. (as Active)
The second appears around line 1242. (as Orphan)

This bug was originally introduced by commit e7e90901
and I fixed it by commit 8ad5d45e.
(Refer to git-log of commit 8ad5d45e)

But this bug was re-introduced by commit 05d134b0 because
the custodian made a mistake when he resolved a merge conflict.

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
Cc: Heiko Schocher <hs@denx.de>
Cc: Kim Phillips <kim.phillips@linaro.org>
Series-cc: Tom Rini <trini@ti.com>
Commit-notes:

How many times do I have to post the same patch to fix this trivial bug?

I know even experienced developers make a mistake.
But I think the root problem is in boards.cfg (and reformatting it).
It causes conflicts very often. Really painful.

Breaking with boards.cfg would be another big motivation of Kconfig.
END
kconfig: import Kconfig files from Linux v3.15-rc5

Import
  - scripts/kconfig/*
  - include/linux/kconfig.h
from Linux Kernel v3.15-rc5.

I know they include lots of trailing spaces
but I keep intentionally them untouched.

Series-to: u-boot@lists.denx.de
Series-cc: Simon Glass <sjg@chromium.org>
Series-cc: Tom Rini <trini@ti.com>
Series-cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Series-cc: Wolfgang Denk <wd@denx.de>
Cover-letter:
Kconfig for U-Boot

This series introduces Kconfig.

Besides Linux Kernel, Kconfig is used in some projects,
such as, BusyBox, Buildroot.

But our situation is a little more complicated.
For one board, we need to generate 3 images at most:
Full image, SPL and TPL.

In the previous version, each image has its own defconfig.

Foe example, C29XPCIE_NAND board has:

 - configs/C29XPCIE_NAND_defconfig     (For full U-boot)
 - configs/spl/C29XPCIE_NAND_defconfig (For SPL)
 - configs/tpl/C29XPCIE_NAND_defconfig (For TPL)

Pros for this approach are:
 (1) Maximum flexibility
   Each defconfig can be configured independently.

 (2) More generic approach to each image
   ifdef CONFIG_SPL_BUILD is sprinkled everywhere in C sources
   and makefiles.  If we treated full image, SPL and TPL as
   generic images, we could clean-up the code.

Cons are:
 (1) Multiple configuration
   "make config/menuconfig" must be invoked multiple times.
   This is painful.

 (2) Duplicated CONFIG macros
   Some macros such as CONFIG_ARM=y are defined in
   all of the three defconfigs. This seems stupid.

In this version, contrast to v1, I selected a totally different approach:
Full image, SPL and TPL share a single defconfig.
Only one ".config" file is created by "make defconfig" based on
configs/<board_name>_defconfig.

But the next step is different.
Multiple auto.conf is generated by "make silentoldconfig" from a
single .config.

 - include/config/auto.config     (for Full image)
 - spl/include/config/auto.config (for SPL)
 - tpl/include/config/auto.config (for TPL)

This approach loses flexibility to some extent. But in return,
we get one-time configuration and a single defconfig.

 How does it work?
 -----------------

Case 1. Boolean macros only for Full U-Boot image

Some macros make sense only in the full U-boot image.
For example, CONFIG_SYS_HUSH_PARSER.

In such a case, We can describe it as follows:

    config CONFIG_SYS_HUSH_PARSER
            bool "Hush perser"
            depends on !SPL_BUILD

CONFIG_SYS_HUSH_PARSER will appear in
include/config/auto.conf but be concealed in
{spl,tpl}/include/config/auto.conf
because CONFIG_SPL_BUILD is defined in SPL and TPL build.

Case 2. Boolean macros which might be used in SPL too

Most boards enable serial only in the full image.
But some boards use serial in SPL image too.
In such a case, CONFIG_SPL_SERIAL_SUPPORT should be defined.
We have already done this approach. See spl/Makefile

If we want to support, for ex. CONFIG_OF_CONTROL in SPL,
CONFIG_SPL_OF_CONTROL should be prepared, I suppose.

Case 3. Hex or integer values

In this case, we must define different macros.

For example,

   CONFIG_SYS_TEXT_BASE  (text base for full image)
   CONFIG_SPL_TEXT_BASE  (text base for SPL)
   CONFIG_TPL_TEXT_BASE  (text base for TPL)

 How does Kconfig in U-Boot work?
 --------------------------------

For boards without SPL support, it works as in Linux Kernel.
That is, a list of CONFIGs is saved into ".config" file.
When we run "make", if necessary, "make silentoldconfig" is automatically
invoked, which creates/updates include/config/auto.conf and
include/generated/autoconf.h.

For boards supporting SPL, a list of CONFIG macros defined for
SPL_BUILD is saved into "spl/.config".
include/config/auto.conf and include/generated/autoconf.h are generated
under spl/ directory.

CONFIG macros for TPL are also handled in the same way.

To sum up,

  [1] Main U-boot
    - .config                         (saved CONFIG list)
    - include/config/auto.conf        (for use in makefiles)
    - include/generated/autoconf.h    (for use in C sources)
    - include/config/*                (for if_changed_dep)

  [2] SPL
    - spl/.config                      (saved CONFIG list)
    - spl/include/config/auto.conf     (for use in makefiles)
    - spl/include/generated/autoconf.h (for use in C sources)
    - spl/include/config/*             (for if_changed_dep)

  [3] TPL
    - tpl/.config                      (saved CONFIG list)
    - tpl/include/config/auto.conf     (for use in makefiles)
    - tpl/include/generated/autoconf.h (for use in C sources)
    - tpl/include/config/*             (for if_changed_dep)

 How to configure and build?
 ---------------------------

Prior to this series, we did board configuration like this:

  $ make vexpress_aemv8a_config

Going forward, we should configure like this:

  $ make vexpress_aemv8a_defconfig

Please note we should use suffix "_defconfig" instead of "_config".

And then build the same as before.

  $ make CROSS_COMPILE=<your_gcc_prefix>

Or you can configure and build in one time:

  $ make CROSS_COMPILE=<your_gcc_prefix> vexpress_aemv8a_defconfig all

 How to change the setting?
 --------------------------

We can modify configuration as we do in Linux Kernel.
I think most of you prefer GUI interface of "make menuconfig".
(Although we do not have user-editable settings in Kconfig yet.
But in future many CONFIG will be moved to Kconfig.)

The difference from Linux Kernel is that the configuration is done
on three levels at most.

Just try

  $ make menuconfig

A menu with a blue background will be displayed for the configuration of
the main U-boot image.

Please descend into "General setup" and notice SPL/TPL build setting.

   [*] Build SPL image
   [ ]   Build TPL image

After going around the menu, choose <Exit>.
Your configuration will be saved into ".config".

If you have enabled "Build SPL image", the second menu will come up.
This is for the SPL configuration.
Please note the background color is black for identifiability.
SPL configuration will be written into "spl/.config".

If you have checked "Build TPL image" also, the third menu will be shown.
This is for the configuration of TPL image,
although there are only a few boards supporting TPL.

 Coexistence of Kconfig and board header
 ---------------------------------------

For a long time, we have used C header files to define the set of CONFIGs.

It would take really long term (one year? two year? I don't know)
to move existing CONFIG macros to Kconfig.

So, two different infractructure must coexist in the interim.

The conventional include/autoconf.mk, include/spl-autoconf.mk,
include/tpl-autoconf.mk are merged into include/config/auto.conf,
spl/include/config/auto.conf, tpl/include/config/auto.conf, respectively.

 Build Test
 ----------

I built all boards excepts some already broken ones.
I also checked MD5SUM of output binaries for all of them.

I believe this series should not break any boards.
But if you notice something got broken, please let me know.

Besides, I confirmed out-of-tree build, parallel build (-j make option)
works correctly.

 How to apply this series
 ------------------------

I confirmed this series can be applied on commit adcdeacc.

 What's the difference from the RFC version and why?
 ---------------------------------------------------

I posted RFC version at May, 17.
"Version 0 of Kconfig for U-Boot" (consists of 17 patches)

In that series, I put all macros necessary for board configuration
into defconfig files.
(Please note boards.cfg will be removed when switching to Kconfig.
That's why arch, cpu, soc, vendor, board, etc. must be handled in Kconfig.)

I also put board maintainers information into defconfig.

So, defconfig files in the RFC version were something like this:

  $ cat configs/beaver_defconfig
  CONFIG_SPL=y
  CONFIG_ARM=y
  CONFIG_SYS_CPU="armv7"
  CONFIG_SOC_DIR=y
  CONFIG_SYS_SOC="tegra30"
  CONFIG_SYS_BOARD="beaver"
  CONFIG_VENDOR_DIR=y
  CONFIG_SYS_VENDOR="nvidia"
  CONFIG_SYS_CONFIG_NAME="beaver"
  CONFIG_BOARD_MAINTAINER="Tom Warren <twarren@nvidia.com>:Stephen Warren <swarren@nvidia.com>"

Stephen Warren and Wolfgang Denk were opposed to this approach.
They said only user-editable settings should be included in defconfig files.
Which means CONFIG_SYS_CPU, CONFIG_SYS_BOARD, CONFIG_BOARD_MAINTAINER etc.
should not be included defconfig.

To check our discussion, see this thread:
http://patchwork.ozlabs.org/patch/330915/

As for board maintainer info, Daniel Schwierzeck suggested to
re-add MAINTAINERS file and Tom Rini agreed with him.

I thought it was our consensus and Daniel posted the patch series.
http://patchwork.ozlabs.org/patch/340546/

But Wolfgang disagreed with this too.

As for the board choice, Daniel suggested to use boolean macros
in Kconfig context.
For exampile, something like this:
  CONFIG_CPU_ARMV7=y
  CONFIG_SOC_TEGRA30=y
  CONFIG_VENDOR_NVIDIA=y
  CONFIG_BOARD_BEAVER=y

It is true that boolean macros are more useful in Kconfig context
because we can deasily describe the dependency by using "depends on"
and "select" statement.

But for now it is impossible to switch completely to bealean macro approach.

String macros such as $(BOARD), $(SOC), $(VENDOR) are already referenced from
many places.

Daniel tried to convert boards.cfg to board/Makefile.
(See  git://git.denx.de/u-boot-mips.git kconfig-support)
But it broke some boards. This work is still being stucked.

I posted RFC series suggesting to discontinue CONFIG_SYS_ARCH, CONFIG_SYS_SOC,
CONFIG_SYS_BOARD, etc.
http://patchwork.ozlabs.org/patch/341254/
But it was also NAKed.

So, it looks like we have to live with string macros
such as CONFIG_SYS_ARCH, CONFIG_SYS_VENDOR, CONFIG_SYS_BOARD.
But at the the same time, there is a requirement to select a board by
"choice" context. It is the only way to allow users to select only
supported CONFIG.

Approach in this version:

 - Add menus to select a target board into arch/*/Kconfig

 - Add board-specific Kconfig files under each board directory.
   CONFIG_SYS_CPU, CONFIG_SYS_SOC, CONFIG_SYS_VENDOR, CONFIG_SYS_BOARD,
   CONFIG_BOARD_MAINTAINER, CONFIG_BOARD_STATUS, etc.
   are added to there.
   They are not editable thru "make menuconfig".

 - Add only simple boolean macros into defconfig files

 Known Problems
 --------------

[1] MAKEALL and buildman have not been not adjusted yet

As I mentioned above, boards.cfg is not necessary for Kconfig.
I want to delete it.

But before that, we must rework MAKEALL and buildman to search defconfig
files instead of boards.cfg.

[2] Many targets in one choice

Especially in ARM and PowerPC, there are too many target boards
in one choice.

This should be refactored in follow-up patches.
Increase the hierarchy by grouping the similar boards family.
END
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Do not apply: tools: add genkconfig

 ========================================
 Do not apply this patch to the main line
 ========================================

 What is this tool?
 ------------------

This tool converts boards.cfg to defconfig and Kconfig files.

It automatically generates
 - arch/${ARCH}/Kconfig
 - board/${VENDOR}/${BOARD}/Kconfig
 - board/${BOARD}/Kconfig
 - configs/*_defconfig

 How to use?
 -----------

Open tools/print_allconfigs with an editor.

Adjust cross compilers part for your environment.

  # Specify your favoriate cross tools
  CROSS_COMPILE_ARC=arc-linux-
  CROSS_COMPILE_AARCH64=aarch64-linux-gnu-
  CROSS_COMPILE_ARM=arm-unknown-linux-gnueabi-
   [snip]
  CROSS_COMPILE_X86=i386-linux-

And then, run "tools/genkconfig".

 Why is this patch here?
 -----------------------

The file boards.cfg is touched very frequently.
All the time, new/old boards are being added/removed.

The next commit was generated based on the u-boot/master at the time
I posted it.
It will become out-dated soon.

You can update it with this tool.

Series-changes: 2
 - Do not generate defconfig files for SPL and TPL
 - Do not output CONFIG_BOARD_MAINTAINERS and CONFIG_BOARD_STATUS
 - Delete board/Kconfig and instead, move "source board/*/*/Kconfig"
   statements to arch/*/Kconfig.
kconfig: add board Kconfig and defconfig files

This commit adds
 - arch/*/Kconfig: provide a menu to select target boards
 - board/*/Kconfig: set CONFIG macros to the appropriate values
        for each board
 - configs/*_defconfig: default setting of each board

(This commit was automatically generated by a conversion script
based on boards.cfg)

In Linux Kernel, defconfig files are located under
arch/${ARCH}/configs/ directory.
It works in Linux Kernel because ARCH is always given from the
command line for cross compile.

But in U-Boot, ARCH is not given from the command line.
Which means we cannot know ARCH before the board configuration.
That is why "*_defconfig" files over all architectures should be
gathered into one directory ./configs/.
(The problem is configs/ directory contains about 1200 files!)

Besides, we must configure boards for SPL and TPL too
if they are supported.
For those boards, defconfig files with the same name are placed
in configs/spl/, configs/tpl/ directories.
kconfig: add basic Kconfig files

This commit adds more Kconfig files, which were written by hand.

Changes-version: 2
  - Do not include "board/Kconfig"
include: define CONFIG_SPL and CONFIG_TPL as 1

We are about to switch to Kconfig in the next commit.
But there are something to get done beforehand.

In Kconfig, include/generated/autoconf.h defines boolean
CONFIG macros as 1.

CONFIG_SPL and CONFIG_TPL, if defined, must be defined as 1.
Otherwise, when switching to Kconfig, the build log
would be sprinkled with warning messages like this:
  warning: "CONFIG_SPL" redefined [enabled by default]

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
kconfig: switch to Kconfig

This commit enables Kconfig.
Going forward, we use Kconfig for board configuration.
mkconfig will never be used. Nor will include/config.mk be generated.

Kconfig must be adjusted for U-Boot because our situation is
a little more complicated than Linux Kernel.
We have to generate multiple binary images (Full U-Boot, SPL, TPL)
from one source tree.
Each image needs each configuration input.

Our approach is like this:

Every board has a signle defconfig file under "configs" directory.
SPL/TPL image, if it is supported, shares the same defconfig file
with the full U-boot image.

First, you need to configure for the target baord like this.

     make <board_name>_defconfig

A file ".config" will be created, storing configs setting
for all the images of the  target board.
You can use "make config", "make menuconfig" etc. to create
a new .config or modify the existing one.

And then run "make".

Kbuild will automatically invoke "make silentoldconfig" if auto.conf
is missing or need to be updated.
The full, SPL, TPL image has its own auto.conf:
  - include/config/auto.conf      (for full image)
  - spl/include/config/auto.conf  (for SPL)
  - tpl/include/config/auto.conf  (for TPL)

How to generate three different auto.conf file from the same .config ?

The key is CONFIG_SPL_BUILD and CONFIG_TPL_BUILD.
CONFIG_SPL_BUILD is defined for both SPL and TPL, while CONFIG_TPL
is only for TPL image.

Some config macros only make sense for the full U-Boot.

For instance,

If you describe Kconfig entry like this:

    config SYS_HUSH_PARSER
            bool "Hush Parser"
            depends on !SPL_BUILD

CONFIG_SYS_HUSH_PARSER will be conceiled from SPL/TPL auto.conf.

If you want to set a config macro for each image separately,
you need to define another CONFIG.
Maybe CONFIG_SPL_ or CPNFIG_TPL_ prefix would be better for clarification.
For example,  CONFIG_SYS_TEXT_BASE, CONFIG_SPL_TEXT_BASE,
CONFIG_TPL_TEXT_BASE, respectively.

I have to admit duplicating config macros is painful but we get
a single defconfig file in return.

By the way, there is another item worth remarking here:
coexistence of Kconfig and board herder files.

Prior to Kconfig, we used C headers to define define a set of configs.

We expect a very long term to move existing config macros to Kconfig.
Two different infractructure must coexist in the interim.

In our former configuration scheme, include/autoconf.mk was generated
for the use in makefiles.
It is still generated in include/, spl/include/, tpl/include/ directory
for the full, SPL, TPL image, respectively.
Don't send: do not clean scripts/kconfig/* by make mrproper
MAKEALL: adjust for Kconfig

Use "make <board>_defconfig" instead of "make <board>_config".

FIXME!
This fixup is bad because it spends still depends on boards.cfg
to support options such as -a <ARCH>, -c <CPU> etc.
We want to delete it when switching to Kconfig.

We have to invent another method without using boards.cfg.
buildman: adjust for Kconfig

Use "make <board>_defconfig" instead of "make <board>_config".

FIXME!
This fixup is bad because it spends still depends on boards.cfg
to support options such as -a <ARCH>, -c <CPU> etc.
We want to delete it when switching to Kconfig.

We have to invent another method without using boards.cfg.
MAKEALL: Show configuration
kconfig: delete redundant CONFIG_${ARCH} definition

CONFIG_${ARCH} is defined by Kconfig.

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
kbuild: remove CONFIG_SPL/CONFIG_TPL definition in config headers

CONFIG_SPL and CONFIG_TPL are defined in Kconfig.

Remove the redundant definition in config headers.

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
kconfig: remove old script

mkconfig is no longer used in Kconfig.
kconfig: add CONFIG_CROSS_COMPILE

Copy from Linux Kernel (with a few adjustments in comments).
kconfig: Add CONFIG_CC_OPTIMIZE_FOR_SIZE
Do not apply: tools: add updatedefconfig
Do not apply: tools: move_config
build: split CONFIG_SPL_TEXT_BASE into two different macros

We are about to move CONFIG_SPL_TEXT_BASE from header files to defconfig.
But we cannot move them as they are.

The problem is that #ifdef statements are used in board headers with
TPL support. Like this:

  #ifdef CONFIG_TPL_BUILD
  #define CONFIG_SPL_TEXT_BASE    0xD0001000
  #elif defined(CONFIG_SPL_BUILD)
  #define CONFIG_SPL_TEXT_BASE    0xff800000
  #endif

We cannot describe conditinal statments in defconfig.
One possible solution is to add CONFIG_TPL_TEXT_BASE.

This commit modifies the code as follow:

  #ifdef CONFIG_TPL_BUILD
  #define CONFIG_TPL_TEXT_BASE    0xD0001000
  #elif defined(CONFIG_SPL_BUILD)
  #define CONFIG_SPL_TEXT_BASE    0xff800000
  #endif

(include/config_fallbakcs.h should also be tweaked because some other
parts still reference to CONFIG_SPL_TEXT_BASE)

In the next commit, it will be converted into defconfig like this:

  CONFIG_SPL_TEXT_BASE=0xff800000
  CONFIG_TPL_TEXT_BASE=0xd0001000
kconfig: move CONFIG_{SPL,TPL}_TEXT_BASE to Kconfig

This commit was automatically generated by a conversion tool.