This was missed when the real mode support was dropped. Remove it.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

The motivation of this commit is to change CONFIG_USE_PRIVATE_LIBGCC
to a boolean macro so we can move it to Kconfig.

In the current implementation, there are two forms of syntax
for this macro:

  - CONFIG_USE_PRIVATE_LIBGCC=y
  - CONFIG_USE_PRIVATE_LIBGCC=path/to/private/libgcc

The latter is only used by x86 architecture.
With a little bit refactoring, it can be converted to the former.
Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>
Tested-by: NSimon Glass <sjg@chromium.org>
Acked-by: NSimon Glass <sjg@chromium.org>

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: NVasili Galka <vvv444@gmail.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Simon Glass <sjg@chromium.org>

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: NMasahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Tom Warren <twarren@nvidia.com>
Cc: Simon Glass <sjg@chromium.org>
Acked-by: NStephen Warren <swarren@nvidia.com>

-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: NMasahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Simon Glass <sjg@chromium.org>
Acked-by: NSimon Glass <sjg@chromium.org>

Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Simon Glass <sjg@chromium.org>

Signed-off-by: NWolfgang Denk <wd@denx.de>
[trini: Fixup common/cmd_io.c]
Signed-off-by: NTom Rini <trini@ti.com>

This enables generic board support so that x86 boards can define
CONFIG_SYS_GENERIC_BOARD.
Signed-off-by: NSimon Glass <sjg@chromium.org>

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: NGabe Black <gabeblack@chromium.org>

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: NWolfgang 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: NGraeme Russ <graeme.russ@gmail.com>
Tested-by: NMatthias Weisser <weisserm@arcor.de>
Tested-by: NSanjeev Premi <premi@ti.com>
Tested-by: NSimon Glass <sjg@chromium.org>
Tested-by: NMacpaul Lin <macpaul@gmail.com>
Acked-by: NMike Frysinger <vapier@gentoo.org>

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: NScott Wood <scottwood@freescale.com>
Tested-by: NGraeme Russ <graeme.russ@gmail.com>

Signed-off-by: NGraeme Russ <graeme.russ@gmail.com>

Rename STANDALONE_LOAD_ADDR into CONFIG_STANDALONE_LOAD_ADDR
and allow that the architecture-specific default value gets
overwritten by defining the value in the board header file.
Signed-off-by: NWolfgang Denk <wd@denx.de>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Shinya Kuribayashi <skuribay@ruby.dti.ne.jp>
Cc: Daniel Hellstrom <daniel@gaisler.com>
Cc: Tsi Chung Liew <tsi-chung.liew@freescale.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>

Signed-off-by: NWolfgang Denk <wd@denx.de>

commit 8aba9dce
Divides variable of linker flags to LDFLAGS-u-boot and LDFLAGS

breaks the usage of --gc-section to build nand_spl. We still need linker option
--gc-section for every uboot image, not only the main one. LDFLAGS_FINAL passes
the --gc-sections to each uboot image.

To get the proper linker flags, we use LDFLAGS and LDFLAGS_FINAL to replace
PLATFORM_LDFLAGS in the Makefile of each nand_spl board.
Signed-off-by: NScott Wood <scottwood@freescale.com>
Signed-off-by: NHaiying Wang <Haiying.Wang@freescale.com>

Linker needs to use the proper endian/bfd flags even when doing partial linking.
LDFLAGS_u-boot sets linker option which is called it when U-boot is built
(u-boot final).
LDFLAGS sets necessary option by partial linking (use in cmd_link_o_target).

CC: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: NNobuhiro Iwamatsu <iwamatsu@nigauri.org>

Change to:
 - reparam=3
 - no-from-pointer
 - no-stack-protector
 - preferred-stack-boundary=2
 - no-top-level-reorder

These options make the code a little smaller and faster

Follow the discussion of Charles Manning and Mike Frysinger.
Using gc_sections helps reduce image size.

Also move lib_$ARCH/config.mk to arch/$ARCH/config.mk

This change is intended to clean up the top-level directory structure
and more closely mimic Linux's directory organization.
Signed-off-by: NPeter Tyser <ptyser@xes-inc.com>

Rather than maintain/extend the current ifeq($(ARCH)) mess that exists in
the standalone Makefile, push the setting up of LOAD_ADDR out to the arch
config.mk (and rename to STANDALONE_LOAD_ADDR in the process).  This keeps
the common code clean and lets the arch do whatever crazy crap it wants in
its own area.
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Rather than maintain/extend the current ifeq($(ARCH)) mess that exists in
the standalone Makefile, push the setting up of LOAD_ADDR out to the arch
config.mk (and rename to STANDALONE_LOAD_ADDR in the process).  This keeps
the common code clean and lets the arch do whatever crazy crap it wants in
its own area.
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

This cleans up U-Boot's toplevel directory a bit and makes the
architecture 'config.mk' file naming and location similar to board
and cpu 'config.mk' files
Signed-off-by: NPeter Tyser <ptyser@xes-inc.com>

Each arch should handle setting a proper default CROSS_COMPILE value in
their own config.mk file rather than having to maintain a large ugly list
in the Makefile.  By using conditional assignment, we don't have to worry
about the variable already being set (env/cmdline/etc...).

The common config.mk file takes care of exporting CROSS_COMPILE already,
and while a few variables (toolchain ones) utilize CROSS_COMPILE before
including the arch config.mk, they do so with deferred assignment.
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

  Add support for i386 architecture and AMD SC520 board

* Patch by Pierre Aubert, 12 Nov 2002:
  Add support for DOS filesystem and booting from DOS floppy disk