Commit graph

11 commits

Author SHA1 Message Date
Vasili Galka
dbb7234b2a x86: Enable 32-bit build using x86_64 multilib toolchain
Until now building the x86 arch boards required 32-bit toolchain. As
many x86_64 toolchains come with 32-bit support (multilib) that's a
good idea to enable build with such toolchains.

The change required was to specify the usage of 32-bit explicitly to
the compiler and the linker (-m32 and -m elf_i386 flags) and locate
the right libgcc path.

Signed-off-by: Vasili Galka <vvv444@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
2014-06-23 15:37:23 -06:00
Masahiro Yamada
c2e5b6a090 x86: specify CONFIG_USE_PRIVATE_LIBGCC more simply
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Simon Glass <sjg@chromium.org>
2014-03-12 17:04:45 -04:00
Masahiro Yamada
cd2e46cb38 kbuild: add CONFIG_ prefix to USE_PRIVATE_LIBGCC
Before this commit, USE_PRIVATE_LIBGCC was defined in
arch-specific config.mk and referenced in
arch/$(ARCH)/lib/Makefile.

We are not happy about parsing config.mk again and again.
We have to keep the same behavior with a different way.

By adding "CONFIG_" prefix, this macro appears
in include/autoconf.mk, include/spl-autoconf.mk.
(And treating USE_PRIVATE_LIBGCC as CONFIG macro
is reasonable enough.)

Tegra SoC family defined USE_PRIVATE_LIBGCC as "yes"
in arch/arm/cpu/arm720t/tegra*/config.mk,
whereas did not define it in arch/arm/cpu/armv7/tegra*/config.mk.

It means Tegra enables PRIVATE_LIBGCC only for SPL.
We can describe the same behavior by adding

  #ifdef CONFIG_SPL_BUILD
  # define CONFIG_USE_PRIVATE_LIBGCC
  #endif

to include/configs/tegra-common.h.

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Tom Warren <twarren@nvidia.com>
Cc: Simon Glass <sjg@chromium.org>
Acked-by: Stephen Warren <swarren@nvidia.com>
2014-03-07 10:59:06 -05:00
Masahiro Yamada
f694183ba1 x86: Delete redundant compiler flags
-Wstrict-prototypes, -ffreestanding, -fno-stack-protector
are defined at the top Makefile for all architectures.

Do not define them twice for x86.

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>
2014-03-04 09:27:40 -05:00
Masahiro Yamada
3954b739b3 x86: convert makefiles to Kbuild style
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Simon Glass <sjg@chromium.org>
2013-11-01 11:42:12 -04:00
Wolfgang Denk
1a4596601f Add GPL-2.0+ SPDX-License-Identifier to source files
Signed-off-by: Wolfgang Denk <wd@denx.de>
[trini: Fixup common/cmd_io.c]
Signed-off-by: Tom Rini <trini@ti.com>
2013-07-24 09:44:38 -04:00
Simon Glass
e424c15c1f x86: Enable generic board support
This enables generic board support so that x86 boards can define
CONFIG_SYS_GENERIC_BOARD.

Signed-off-by: Simon Glass <sjg@chromium.org>
2013-03-15 16:14:00 -04:00
Gabe Black
36b2409a3d x86: Wrap small helper functions from libgcc to avoid an ABI mismatch
When gcc compiles some 64 bit operations on a 32 bit machine, it generates
calls to small functions instead of instructions which do the job directly.
Those functions are defined in libgcc and transparently provide whatever
functionality was necessary. Unfortunately, u-boot can be built with a
non-standard ABI when libgcc isn't. More specifically, u-boot uses
-mregparm. When the u-boot and libgcc are linked together, very confusing
bugs can crop up, for instance seemingly normal integer division or modulus
getting the wrong answer or even raising a spurious divide by zero
exception.

This change borrows (steals) a technique and some code from coreboot which
solves this problem by creating wrappers which translate the calling
convention when calling the functions in libgcc. Unfortunately that means
that these instructions which had already been turned into functions have
even more overhead, but more importantly it makes them work properly.

To find all of the functions that needed wrapping, u-boot was compiled
without linking in libgcc. All the symbols the linker complained were
undefined were presumed to be the symbols that are needed from libgcc.
These were a subset of the symbols covered by the coreboot code, so it was
used unmodified.

To prevent symbols which are provided by libgcc but not currently wrapped
(or even known about) from being silently linked against by code generated
by libgcc, a new copy of libgcc is created where all the symbols are
prefixed with __normal_. Without being purposefully wrapped, these symbols
will cause linker errors instead of silently introducing very subtle,
confusing bugs.

Another approach would be to whitelist symbols from libgcc and strip out
all the others. The problem with this approach is that it requires the
white listed symbols to be specified three times, once for objcopy, once so
the linker inserts the wrapped, and once to generate the wrapper itself,
while this implementation needs it to be listed only twice. There isn't
much tangible difference in what each approach produces, so this one was
preferred.

Signed-off-by: Gabe Black <gabeblack@chromium.org>
2011-11-29 21:31:24 +11:00
Wolfgang Denk
cca4e4aec1 Reduce build times
U-Boot Makefiles contain a number of tests for compiler features etc.
which so far are executed again and again.  On some architectures
(especially ARM) this results in a large number of calls to gcc.

This patch makes sure to run such tests only once, thus largely
reducing the number of "execve" system calls.

Example: number of "execve" system calls for building the "P2020DS"
(Power Architecture) and "qong" (ARM) boards, measured as:
	-> strace -f -e trace=execve -o /tmp/foo ./MAKEALL <board>
	-> grep execve /tmp/foo | wc -l

	Before: After:	Reduction:
==================================
P2020DS 20555	15205	-26%
qong	31692	14490	-54%

As a result, built times are significantly reduced, typically by
30...50%.

Signed-off-by: Wolfgang Denk <wd@denx.de>
Cc: Andy Fleming <afleming@gmail.com>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: Albert Aribaud <albert.aribaud@free.fr>
cc: Graeme Russ <graeme.russ@gmail.com>
cc: Mike Frysinger <vapier@gentoo.org>
Tested-by: Graeme Russ <graeme.russ@gmail.com>
Tested-by: Matthias Weisser <weisserm@arcor.de>
Tested-by: Sanjeev Premi <premi@ti.com>
Tested-by: Simon Glass <sjg@chromium.org>
Tested-by: Macpaul Lin <macpaul@gmail.com>
Acked-by: Mike Frysinger <vapier@gentoo.org>
2011-11-03 20:44:58 +01:00
Scott Wood
83b7e2a7f2 Handle most LDSCRIPT setting centrally
Currently, some linker scripts are found by common code in config.mk.
Some are found using CONFIG_SYS_LDSCRIPT, but the code for that is
sometimes in arch config.mk and sometimes in board config.mk.  Some
are found using an arch-specific rule for looking in CPUDIR, etc.

Further, the powerpc config.mk rule relied on CONFIG_NAND_SPL
when it really wanted CONFIG_NAND_U_BOOT -- which covered up the fact
that not all NAND_U_BOOT builds actually wanted CPUDIR/u-boot-nand.lds.

Replace all of this -- except for a handful of boards that are actually
selecting a linker script in a unique way -- with centralized ldscript
finding.

If board code specifies LDSCRIPT, that will be used.
Otherwise, if CONFIG_SYS_LDSCRIPT is specified, that will be used.

If neither of these are specified, then the central config.mk will
check for the existence of the following, in order:

$(TOPDIR)/board/$(BOARDDIR)/u-boot-nand.lds (only if CONFIG_NAND_U_BOOT)
$(TOPDIR)/$(CPUDIR)/u-boot-nand.lds (only if CONFIG_NAND_U_BOOT)
$(TOPDIR)/board/$(BOARDDIR)/u-boot.lds
$(TOPDIR)/$(CPUDIR)/u-boot.lds

Some boards (sc3, cm5200, munices) provided their own u-boot.lds that
were dead code, because they were overridden by a CPUDIR u-boot.lds under
the old powerpc rules.  These boards' own u-boot.lds have bitrotted and
no longer work -- these lds files have been removed.

Signed-off-by: Scott Wood <scottwood@freescale.com>
Tested-by: Graeme Russ <graeme.russ@gmail.com>
2011-04-30 00:59:47 +02:00
Graeme Russ
fea2572001 x86: Rename i386 to x86
Signed-off-by: Graeme Russ <graeme.russ@gmail.com>
2011-04-13 19:43:28 +10:00
Renamed from arch/i386/config.mk (Browse further)