Current LDS files /DISCARD/ a lot of sections when linking ELF
files, causing diagnostic tools such as readelf or objdump to
produce partial output. Keep all section at link stage, filter
only at objcopy time so that .bin remains minimal.
Signed-off-by: NAlbert ARIBAUD <albert.u.boot@aribaud.net>
Reviewed-by: NBenoît Thébaudeau <benoit.thebaudeau@advansee.com>

Signed-off-by: NWolfgang Denk <wd@denx.de>
[trini: Drop changes for PEP 4 following python tools]
Signed-off-by: NTom Rini <trini@ti.com>

To be more EABI compliant and as a preparation for building
with clang, use the platform-specific r9 register for gd
instead of r8.

note: The FIQ is not updated since it is not used in u-boot,
and under discussion for the time being.

The following checkpatch warning is ignored:
WARNING: Use of volatile is usually wrong: see
Documentation/volatile-considered-harmful.txt
Signed-off-by: NJeroen Hofstee <jeroen@myspectrum.nl>
cc: Albert ARIBAUD <albert.u.boot@aribaud.net>

Every ARM cpu config.mk (arch/arm/cpu/{CPUDIR}/config.mk) defines:

PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float

So, this patch moves the common compiler options to arch/arm/config.mk.
Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>

The movt/movw instruction can be used to hardcode an
memory location in the instruction itself. The linker
starts complaining about this if the compiler decides
to do so: "relocation R_ARM_MOVW_ABS_NC against `a local
symbol' can not be used" and it is not support by U-boot
as well. Prevent their use by requiring word relocations.
This allows u-boot to be build at other optimalization
levels then -Os.
Signed-off-by: NJeroen Hofstee <jeroen@myspectrum.nl>
Cc: TigerLiu@viatech.com.cn
Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
Acked-by: NSimon Glass <sjg@chromium.org>

Adding a new CONFIG_OMAP_COMMON which is included by all boards
that needs to build cpu/armv7/omap-common folder.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

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

Add a Makefile target ('checkarmreloc') which
fails if the ELF binary contains relocation records
of types other than R_ARM_RELATIVE.
Signed-off-by: NAlbert ARIBAUD <albert.u.boot@aribaud.net>
Tested-by: NLubomir Popov <lpopov@mm-sol.com>
Tested-by: NJeroen Hofstee <jeroen@myspectrum.nl>
Reviewed-by: NBenoît Thébaudeau <benoit.thebaudeau@advansee.com>

While other architectures have enabled these gcc / ld options for some
time on U-Boot itself, ARM has only been doing this on SPL.  Enable this
on full U-Boot as well now.

Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
Signed-off-by: NTom Rini <trini@ti.com>

Signed-off-by: NBenoît Thébaudeau <benoit.thebaudeau@advansee.com>

All of these platforms have memory starting at 0x80000000, so this is
the correct CONFIG_STANDALONE_LOAD_ADDR for all of them.
Acked-by: NPeter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: NTom Rini <trini@ti.com>

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

Disable sibling call optimization based on binutils version.  This is
to work around a bug in the assember in binutils versions < 2.22.
Branches to weak symbols can be incorrectly optimized in thumb mode to
a short branch (b.n instruction) that won't reach when the symbol gets
preempted.

http://sourceware.org/bugzilla/show_bug.cgi?id=12532Signed-off-by: NAllen Martin <amartin@nvidia.com>
Acked-by: NTom Rini <trini@ti.com>

This rule confirms that if we're on ARM and we have enabled THUMB builds
that we have a new enough toolchain to produce a working binary.

Changes in v2:
- Switch to ALL-$(CONFIG_SYS_THUMB_BUILD) in arch/arm/config.mk (Mike F)
- Simplfy checkthumb test after doing the above
Signed-off-by: NTom Rini <trini@ti.com>
Acked-by: NMike Frysinger <vapier@gentoo.org>

Enable Thumb build and ARM-Thumb interworking based on the new
config flag CONFIG_SYS_THUMB_BUILD
Signed-off-by: NAneesh V <aneesh@ti.com>
Acked-by: NMike Frysinger <vapier@gentoo.org>

This is set by the top level Makefile anyway, so drop it. This does
have the effect of changing the order - now the board link script will
have preference over the CPU one. But this seems more correct anyway.
Signed-off-by: NSimon Glass <sjg@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>

Signed-off-by: NAneesh V <aneesh@ti.com>
Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>

Signed-off-by: NMichael Schwingen <michael@schwingen.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>

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>

Commit 8aba9dce breaks
ARM boards because for ARM the -pie option is used
for partial linking together with -r option.

The patch adds the -pie option to link u-boot.bin only.
Signed-off-by: NStefano Babic <sbabic@denx.de>
CC: Jason Liu <liu.h.jason@gmail.com>
CC: lool@dooz.org
CC: Wolfgang Denk <wd@denx.de>
CC: Albert Aribaud <albert.aribaud@free.fr>
Tested-by: NAlexander Holler <holler@ahsoftware.de>

When this define was introduced, the idea was to provide a soft
migration path for ARM boards to get adapted to the new relocation
support.  However, other recent changes led to a different
implementation (ELF relocation), where this no longer works.  By now
CONFIG_SYS_ARM_WITHOUT_RELOC does not only not help any more, but it
actually hurts because it obfuscates the actual code by sprinkling it
with lots of dead and non-working debris.

So let's make a clean cut and drop CONFIG_SYS_ARM_WITHOUT_RELOC.
Signed-off-by: NWolfgang Denk <wd@denx.de>
Tested-by: NHeiko Schocher <hs@denx.de>
Tested-by: NReinhard Meyer <u-boot@emk-elektronik.de>

Signed-off-by: NHeiko Schocher <hs@denx.de>

ELF relocation tables generated with linker option -pie can
be used to fixup code and data in a single loop at relocation,
removing the need for manual fixups anywhere else in the code.
Signed-off-by: NAlbert Aribaud <albert.aribaud@free.fr>

!! This breaks support for all arm boards !!

To compile in old style, you must define
CONFIG_SYS_ARM_WITHOUT_RELOC or you can compile
with "CONFIG_SYS_ARM_WITHOUT_RELOC=1 ./MAKEALL board"

!! This define will be removed soon, so convert your
board to use relocation support

Portions of this work were supported by funding from
the CE Linux Forum.
Signed-off-by: NHeiko Schocher <hs@denx.de>

Fix boot from NAND for non-ARM systems
Signed-off-by: NWolfgang Denk <wd@denx.de>

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>

The CPUDIR variable points to the location of a target's CPU directory.
Currently, it is set to cpu/$CPU.  However, using $CPUDIR will allow for
more flexibility in the future.  It lays the groundwork for reorganizing
U-Boot's directory structure to support a layout such as:

  arch/$ARCH/cpu/$CPU/* (architecture with multiple CPU types)
  arch/$ARCH/cpu/*      (architecture with one CPU type)
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>

For some time there have been repeated reports about build problems
with some ARM (cross) tool chains.  Especially issues about
(in)compatibility with the tool chain provided runtime support
library libgcc.a caused to add and support a private implementation
of such runtime support code in U-Boot.  A closer look at the code
indicated that some of these issues are actually home-made.  This
patch attempts to clean up some of the most obvious problems and make
building of U-Boot with different tool chains easier:

- Even though all ARM systems basicy used the same compiler options
  to select a specific ABI from the tool chain, the code for this was
  distributed over all cpu/*/config.mk files.  We move this one level
  up into lib_arm/config.mk instead.

- So far, we only checked if "-mapcs-32" was supported by the tool
  chain; if yes, this was used, if not, "-mabi=apcs-gnu" was
  selected, no matter if the tool chain actually understood this
  option.  There was no support for EABI conformant tool chains.
  This patch implements the following logic:

  1) If the tool chain supports
	"-mabi=aapcs-linux -mno-thumb-interwork"
     we use these options (EABI conformant tool chain).
  2) Otherwise, we check first if
	"-mapcs-32"
     is supported, and then check for
	"-mabi=apcs-gnu"
     If one test succeeds, we use the first found option.
  3) In case 2), we also test if "-mno-thumb-interwork", and use
     this if the test succeeds. [For "-mabi=aapcs-linux" we set
     "-mno-thumb-interwork" mandatorily.]

  This way we use a similar logic for the compile options as the
  Linux kernel does.

- Some EABI conformant tool chains cause external references to
  utility functions like raise(); such functions are provided in the
  new file lib_arm/eabi_compat.c

  Note that lib_arm/config.mk gets parsed several times, so we must
  make sure to add eabi_compat.o only once to the linker list.
Signed-off-by: NWolfgang Denk <wd@denx.de>
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Dirk Behme <dirk.behme@googlemail.com>
Cc: Magnus Lilja <lilja.magnus@gmail.com>
Cc: Tom Rix <Tom.Rix@windriver.com>
Cc: Prafulla Wadaskar <prafulla@marvell.com>
Acked-by: NSergey Kubushyn <ksi@koi8.net>
Tested-by: NMagnus Lilja <lilja.magnus@gmail.com>
Tested-by: NAndrzej Wolski <awolski@poczta.fm>
Tested-by: NGaye Abdoulaye Walsimou <walsimou@walsimou.com>
Tested-by: NTom Rix <Tom.Rix@windriver.com>
Tested-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>

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>

all arm boards except a few use the same cpu linker script
so move it to cpu/$(CPU)

that could be overwrite in following order
SOC
BOARD
via the corresponding config.mk
Signed-off-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>