path: root/toolchain.inc
Commit message (Collapse)AuthorAgeFilesLines
* coreboot classes: Add dynamic classes to corebootFurquan Shaikh2014-08-111-0/+12
| | | | | | | | | | | | | | | | | | | | Provide functionality to create dynamic classes based on program name and architecture for which the program needs to be compiled/linked. define_class takes program_name and arch as its arguments and adds the program_name to classes-y to create dynamic class. Also, compiler toolset is created for the specified arch. All the files for this program can then be added to program_name-y += .. Ensure that define_class is called before any files are added to the class. Check subdirs-y for order of directory inclusion. One such example of dynamic class is rmodules. Multiple rmodules can be used which need to be compiled for different architectures. With dynamic classes, this is possible. Change-Id: Ie143ed6f79ced5f58c200394cff89b006bc9b342 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/6426 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
* build system: remove duplicate architecture listPatrick Georgi2014-07-301-2/+0
| | | | | | | | | | | | Let xcompile pass the list of architectures, given that it already has it. Change-Id: I565512d3bef987c9a4e48a39bfd88bacf0b65de9 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/6254 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Marc Jones <marc.jones@se-eng.com>
* build: remove -ccopts mechanismPatrick Georgi2014-06-291-2/+2
| | | | | | | | | | | | We now use the slightly more familiar CFLAGS_* and CPPFLAGS_* for the same purpose. Change-Id: Ifd2bd13f67f71fa0a15611a6d11a6a4c7994271b Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/5875 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
* build: use CFLAGS_* in more places where they're neededPatrick Georgi2014-05-191-1/+1
| | | | | | | | | | | | After moving out -m32 from CC_*, 64bit compilers need CFLAGS_* in more places to handle everything in 32bit as appropriate. Change-Id: I692a46836fc0ba29a3a9eb47b123e3712691b45d Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/5789 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
* build: re-enable ccache supportPatrick Georgi2014-05-171-1/+19
| | | | | | | | | | | | | | | The ccache support was mostly disabled because it didn't hook onto most compilers anymore. Caveat: ccache and scan-build don't work together since scan-build doesn't like arguments in its compiler command line (eg. "ccache gcc"). Change-Id: I7c1c6e22cb662f2b08e774ea484ac1c412fdd2db Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/5775 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
* build: make scan-build work againPatrick Georgi2014-05-171-0/+16
| | | | | | | | | | | | | | | | | | | | This drops the scan-build related Kconfig options since it's now possible to simply run scan-build [-o outdir] make and get coreboot built with its report. There's also no inner make process anymore, and the way things work should be clearer now. Also adapt abuild to this new reality. Change-Id: I03e03334761ec83f718b3235ebf811834cd2e3e3 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/5774 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
* build: remove call to missing functionPatrick Georgi2014-05-171-2/+1
| | | | | | | | | | set_stage_libgcc never existed in our tree. Change-Id: I864fc683dd7b89a030daf05eafb9624ce828cb72 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/5770 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
* build: break compiler flags out of $(CC)Patrick Georgi2014-05-171-2/+2
| | | | | | | | | | | 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>
* build: don't call $(CC) -print-libgcc-file-name twicePatrick Georgi2014-05-171-2/+1
| | | | | | | | 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>
* build: kill one indirectionPatrick Georgi2014-05-171-10/+6
| | | | | | | | | | | | | 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>
* build: get rid of a special casePatrick Georgi2014-05-171-3/+0
| | | | | | | | | | | | 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>
* build: separate CPPFLAGS from CFLAGSPatrick Georgi2014-05-171-2/+2
| | | | | | | | | | | 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>
* build: CPPFLAGS is more common than INCLUDESPatrick Georgi2014-05-171-3/+3
| | | | | | | | | | | 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>
* toolchain: get rid of some bashismsAaron Durbin2014-05-091-2/+2
| | | | | | | | | | | | | 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>
* Introduce stage-specific architecture for corebootFurquan Shaikh2014-05-061-0/+89
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>