Commit Graph

8 Commits

Author SHA1 Message Date
Patrick Georgi b145b8301f build: break compiler flags out of $(CC)
Having more than the executable in $(CC) only leads to
trouble in a number of situations.

Change-Id: I7642ca4068b3a3bd5798219d74de9e0eb85bb4e5
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/5769
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-05-17 21:14:52 +02:00
Patrick Georgi 6bc44554b9 build: don't call $(CC) -print-libgcc-file-name twice
Change-Id: Iaeeb8fc58e06c98273520e79999737da9ff3f872
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/5768
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-05-17 21:14:46 +02:00
Patrick Georgi 4ebd3d9195 build: kill one indirection
No need to first define X86_32 and then replace every
single use of it with its lower cased equivalent.
Just start out with the lower case versions in the first
place.

Change-Id: I1e771ef443db1b8d34018d19a64a9ee489cd8133
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/5767
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-05-17 21:14:41 +02:00
Patrick Georgi b83f7deb78 build: get rid of a special case
Don't call things in xcompile i386 and in the
buildsystem x86_32 and then bridge things so
they match. just call it the same everywhere.

Change-Id: Ieef5f03f7aafb0b0a606fbe5a2386e310d2b0e94
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/5766
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-05-17 21:14:35 +02:00
Patrick Georgi 58f73a69cd build: separate CPPFLAGS from CFLAGS
There are a couple of places where CPPFLAGS are
pasted into CFLAGS, eliminate them.

Change-Id: Ic7f568cf87a7d9c5c52e2942032a867161036bd7
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/5765
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-05-17 21:14:29 +02:00
Patrick Georgi 98f49d2823 build: CPPFLAGS is more common than INCLUDES
Rename INCLUDES to CPPFLAGS since the latter is more
commonly used for preprocessor options.

Change-Id: I522bb01c44856d0eccf221fa43d2d644bdf01d69
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/5764
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-05-17 21:14:24 +02:00
Aaron Durbin c087a9e469 toolchain: get rid of some bashisms
On Ubuntu /bin/sh is symlinked to /bin/dash. The
current toolchain.inc was doing some things that
dash doesn't support. Make the shell callouts more
conforming to the POSIX sh standard.

Change-Id: I26b6b82b8d6158c9029e8be9e7c088ca9e207f21
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5701
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2014-05-09 05:38:51 +02:00
Furquan Shaikh 99ac98f7e1 Introduce stage-specific architecture for coreboot
Make all three coreboot stages (bootblock, romstage and ramstage) aware of the
architecture specific to that stage i.e. we will have CONFIG_ARCH variables for
each of the three stages. This allows us to have an SOC with any combination of
architectures and thus every stage can be made to run on a completely different
architecture independent of others. Thus, bootblock can have an x86 arch whereas
romstage and ramstage can have arm32 and arm64 arch respectively. These stage
specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain
and compiler flags for every stage.

These options can be considered as either arch or modes eg: x86 running in
different modes or ARM having different arch types (v4, v7, v8). We have got rid
of the original CONFIG_ARCH option completely as every stage can have any
architecture of its own. Thus, almost all the components of coreboot are
identified as being part of one of the three stages (bootblock, romstage or
ramstage). The components which cannot be classified as such e.g. smm, rmodules
can have their own compiler toolset which is for now set to *_i386. Hence, all
special classes are treated in a similar way and the compiler toolset is defined
using create_class_compiler defined in Makefile.

In order to meet these requirements, changes have been made to CC, LD, OBJCOPY
and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others.
Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the
toolsets are defined using create_class_compiler.

Few additional macros have been introduced to identify the class to be used at
various points, e.g.: CC_$(class) derives the $(class) part from the name of
the stage being compiled.

We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER
as they do not make any sense for coreboot as a whole. All these attributes are
associated with each of the stages.

Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/5577
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@gmail.com>
2014-05-06 20:23:31 +02:00