[U-Boot] [PATCH v2 0/5] Makefile cleanup

[Wolfgang Denk]

The following series of patches prepares the ground to move the
remaining board configuration entries out of the Makefile into the
boards.cfg file, replacing multi-line scripts to fiddle with config.h
and config.mk files into simple, single-line entries. This has a
number of advantages:

- The Makefile becomes much smaller and simpler, and a bit faster.
- By moving the definition of (CONFIG_SYS_) TEXT_BASE from the
  board/*/config.mk files into the board config files, we now use a
  homogenous config mechanism, which prepares the ground to using
  something like Kconfig one day.
- Many of the board/*/config.mk files become redundant and can be
  removed.
- Lists of board configurates as needed for MAKEALL can now be
  automatically generated from boards.cfg, so MAKEALL becomes much
  smaller, and there is no danger that board configurations get
  forgotten and never get tested for a long time.
- It becomes trivial to extend MAKEALL to support new features. For
  example, it can now easily be extended for functions like "build all
  boards of vendor XXX" ("MAKEALL -v freescale"); "build all boards
  with CPU YYY" ("MAKEALL -c armv7") or "build all boards that have
  `nand' in their options field ("MAKEALL -o nand"), etc.
- When adding a new board, we have to add a single line entry to
  boards.cfg now.

One problem of these patches is that they touch deep into the innards
of the board configurations, and I can actually test only on a tiny
percentage of the boards.  So I decided to compare the build results
and make sure these don't change.  However, this is a non-trivial
ting.  For example, the U-Boot binary images have the git commit ID
and date built in, which show up in different locations for the misc
boards, and different lenghts of the strings may cause the remainder
of the image to be shifted, so images look very different...

What I did was the following: I built all PowerPC configurations (a
total of 531) both without and with my patches applied.  I used a
modified version of tools/setlocalversion for these builds to make
sure all version strings have the same length.  Then I compared the
following build results:

- LOG/<name>.ERR :	my rationale was that no new build errors or
			warnings must be generated.
- u-boot.map  and
  System.map :		my rationale was that any changes to the
			configuration would most likely cause either
			symbols or addresses to change: any additional
			code that should be selected woul show up as
			new symbos, code getting omitted should show
			up as disappearing symbos, and both would
			cause shifts in the memory maps.  When both
			u-boot.map and System.map show no differences,
			then the binaries should be functionally the
			same, too.

During development of the patches it turned out that this method
appears to work reliably, detecting even minimal changes in the build
results.

Note that there are a number of board configurations where the
automatic testing showed problems or differences:

- some don't build in mainline; no attempt was made to fix such build
  issues in the context of this patch series; in most cases these
  configurations had no entries in MAKEALL, so the build issues went
  by undetected, sometimes for a very long time (one more reason to
  auto-generate the board lists for MAKEALL).

  Configs: CP850, NC650_Rev1, NC650_Rev2, P2020DS_DDR2,
  TQM5200S_HIGHBOOT, TQM5200_B_HIGHBOOT, VoVPN-GW_100MHz,
  rainier_ramboot, sequoia_ramboot

- some show differences, but careful checking indicates that the
  results with this patch series applied are the correct ones, while
  previous builds were wrong, but failures were not detected or
  reported:

  Configs: CPC45_ROMBOOT, CPU86_ROMBOOT, CPU87_ROMBOOT, PM828_ROMBOOT,
  PM828_ROMBOOT_PCI, rainier_nand

- some show differences for u-boot.maps, but inspection shows that
  this is only in "ppcenv_assert" strings, where master has TEXT_BASE
  while we have CONFIG_SYS_TEXT_BASE

  Configs: v5fx30teval, v5fx30teval_flash, xilinx-ppc405-generic,
  xilinx-ppc405-generic_flash, xilinx-ppc440-generic,
  xilinx-ppc440-generic_flash

- some differences were accepted because they could be tracked back to
  other, unrelated changes:

  Configs: mpc5121ads, mpc5121ads_rev2



Overview:
=========

[PATCH 1/5] Build: Add "board options" column to boards.cfg

    Build: Add "board options" column to boards.cfg

    There are some boards where it's currently not possible to detect all
    board information at runtime, therefore a new column was added to
    boards.cfg .

    This column can contain multiple options: a board configuration name,
    optionally followed by a colon (':') and a list of options, which are
    separated by comma (',').

    In case of simple options like '256M_U_BOOT', these expand to
    "#define CONFIG_MK_256M_U_BOOT 1" in config.h . In case of
    assignments like 'RAM=8192', these expand to "#define CONFIG_MK_RAM
    8192" in config.h .

    Example:

    	FOO:HAS_BAR,BAZ=64

    means:
    	- the name of the board config file is include/configs/FOO.h
    	- the generated file include/config.h will contain these
    	  lines:

    		#define CONFIG_HAS_BAR  1
    		#define CONFIG_BAZ  64

    Signed-off-by: Marek Vasut <marek.vasut at gmail.com>

    [wd at denx.de: edited commit message; added code to deal with an
    optional board configuration name]

    Signed-off-by: Wolfgang Denk <wd at denx.de>

 2 files changed, 31 insertions(+), 7 deletions(-)

[PATCH 2/5] mkconfig: change CONFIG_MK_ prefix into plain CONFIG_

    mkconfig: change CONFIG_MK_ prefix into plain CONFIG_

    When planning for more generalization and Makefile cleanup it became
    obvious that the introduction of a separate CONFIG_MK_ name space for
    config options that were set through scripting in the Makefile was
    not a good idea.

    Originally the idea was to provide a script-free approach to supply
    configuration options - there was no real need for a separate name
    space. But when we now convert the existing Makefile entries to make
    use of this approach, it would mean that we have to touch a large
    number of board config files and add #ifdef / #define sequences to
    "convert" from the CONFIG_MK_ to the CONFIG_ name space.

    It seems much cleaner to get rid of this somewhat arbitrary _MK
    string now for the few boards that actually use it.

    Signed-off-by: Wolfgang Denk <wd at denx.de>

 21 files changed, 54 insertions(+), 59 deletions(-)

[PATCH 3/5] Rename TEXT_BASE into CONFIG_SYS_TEXT_BASE

    Rename TEXT_BASE into CONFIG_SYS_TEXT_BASE

    The change is currently needed to be able to remove the board
    configuration scripting from the top level Makefile and replace it by
    a simple, table driven script.

    Moving this configuration setting into the "CONFIG_*" name space is
    also desirable because it is needed if we ever should move forward to
    a Kconfig driven configuration system.

    Signed-off-by: Wolfgang Denk <wd at denx.de>

 799 files changed, 1494 insertions(+), 1436 deletions(-)

[PATCH 4/5] autoconfig.mk: avoid apostophes around hex values

    autoconfig.mk: avoid apostophes around hex values

    When generating include/autoconfig.mk, hex numbers would be quoted.
    This appears to be not a real problem, but caused some false positives
    during automatic testing of the builds. Don't use apostophes for 
    decimal and hex numbers (nor or octal numbers).

    Signed-off-by: Wolfgang Denk <wd at denx.de>

 1 files changed, 6 insertions(+), 2 deletions(-)

[PATCH 5/5] Makefile: move all Power Architecture boards into boards.cfg

    Makefile: move all Power Architecture boards into boards.cfg

    Clean up Makefile, and drop a lot of the config.mk files on the way.

    We now also automatically pick all boards that are listed in 
    boards.cfg (and with all configurations), so we can drop the redundant
    entries from MAKEALL to avoid building these twice.
 
    Signed-off-by: Wolfgang Denk <wd at denx.de>

 580 files changed, 1395 insertions(+), 6768 deletions(-)