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

Wolfgang Denk
2010-10-16T23:57:37Z

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@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@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@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@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@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@denx.de>

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