When OF_CONTROL is enabled, u-boot-dtb.* files are the same as u-boot.*
files. So we can use the latter for simplicity.
Tested-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NSimon Glass <sjg@chromium.org>

Create u-boot.img even when OF_CONTROL is enabled, so that this file can be
used in both cases.
Tested-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NSimon Glass <sjg@chromium.org>

We don't need the -dtb suffix anymore, so drop it.
Tested-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NSimon Glass <sjg@chromium.org>

Adjust the Makefile to build u-boot-tegra.bin which contains a device tree
if OF_SEPARATE is enabled, and does not if not. This mirrors U-Boot's new
approach of using u-boot.bin to handle both cases.
Tested-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NSimon Glass <sjg@chromium.org>

At present u-boot.bin holds the plain U-Boot binary without the device tree.
This is somewhat annoying since you need either u-boot.bin or u-boot-dtb.bin
depending on whether device tree is used.

Adjust the build such that u-boot.bin includes a device tree (if enabled),
and the plain binary is in u-boot-nodtb.bin. For now u-boot-dtb.bin remains
the same.

This should be acceptable since:

- without OF_CONTROL, u-boot.bin still does not include a device tree
- with OF_CONTROL, u-boot-dtb.bin does not change

The main impact is build systems which are set up to use u-boot.bin as
the output file and then add a device tree. These will have to change to use
u-boot-nodtb.bin instead.

Adjust tegra rules so it continues to produce the correct files.
Tested-by: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NSimon Glass <sjg@chromium.org>

Fix the ALL-y logic in the Makefile so that is clear that we always want
the -nodtb file.
Tested-by: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NSimon Glass <sjg@chromium.org>

There are a lot of unrelated files in common, including all of the commands.
Moving them into their own directory makes them easier to find and is more
logical.

Some commands include non-command code, such as cmd_scsi.c. This should be
sorted out at some point so that the function can be enabled with or without
the associated command.

Unfortunately, with m68k I get this error:

m68k:  +   M5329AFEE
+arch/m68k/cpu/mcf532x/start.o: In function `_start':
+arch/m68k/cpu/mcf532x/start.S:159:(.text+0x452): relocation truncated to fit: R_68K_PC16 against symbol `board_init_f' defined in .text.board_init_f section in common/built-in.o

I hope someone can shed some light on what this means. I hope it isn't
depending on the position of code in the image.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NHeiko Schocher <hs@denx.de>
Acked-by: NStefan Roese <sr@denx.de>
Acked-by: NPrzemyslaw Marczak <p.marczak@samsung.com>

Now, there is no board defining CONFIG_SYS_TEXT_BASE by its config.mk,
so this workaround is no longer needed.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: NStefan Roese <sr@denx.de>

This patch adds runtime detection of the Marvell UART boot-mode (xmodem
protocol). If this boot-mode is detected, SPL will return to the
BootROM to continue the UART booting.

With this patch its now possible, to generate a U-Boot image that
can be booted either from the strapped boot-device (e.g. SPI NOR, MMC,
etc) or via the xmodem protocol from the UART. In the UART case,
the kwboot tool will dynamically insert the UART boot-device type
into the image. And also patch the load address in the header, so
that the mkimage header will be skipped (as its not expected by the
Marvell BootROM).

This simplifies the development for Armada XP / 38x based boards.
As no special images need to be generated by selecting the
MVEBU_BOOTROM_UARTBOOT Kconfig option.

Since the Kconfig option MVEBU_BOOTROM_UARTBOOT is not needed any
more, its now completely removed.
Signed-off-by: NStefan Roese <sr@denx.de>
Cc: Luka Perkov <luka.perkov@sartura.hr>
Cc: Dirk Eibach <dirk.eibach@gdsys.cc>
Cc: Phil Sutter <phil@nwl.cc>
Cc: Kevin Smith <kevin.smith@elecsyscorp.com>

Signed-off-by: NTom Rini <trini@konsulko.com>

The compilation of u-boot-dtb.img should be controlled by
CONFIG_OF_CONTROL and not CONFIG_DM.
CONFIG_DM may be defined even without Device Tree requirement.

This was added in commit 947cee11.
Signed-off-by: NRuchika Gupta <ruchika.gupta@freescale.com>
Signed-off-by: NAneesh Bansal <aneesh.bansal@freescale.com>
CC: Alison Wang <alison.wang@freescale.com>

Signed-off-by: NTom Rini <trini@konsulko.com>

Signed-off-by: NTom Rini <trini@konsulko.com>

Signed-off-by: NTom Rini <trini@konsulko.com>

Add a build target to generate 'boot.bin' which includes SPL. This is
used by the platforms BootROM to load SPL directly.

This change also conditionally changes what the 'boot.bin' target
generates depending on the SoC. Leaving the behaviour unchanged for the
AT91 targets.
Signed-off-by: NNathan Rossi <nathan@nathanrossi.com>
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Andreas Bießmann <andreas.devel@googlemail.com>
Cc: Heiko Schocher <hs@denx.de>
Reviewed-by: NTom Rini <trini@konsulko.com>

Signed-off-by: NTom Rini <trini@konsulko.com>

After consulting with some of the SPDX team, the conclusion is that
Makefiles are worth adding SPDX-License-Identifier tags too, and most of
ours have one.  This adds tags to ones that lack them and converts a few
that had full (or in one case, very partial) license blobs into the
equivalent tag.

Cc: Kate Stewart <kstewart@linuxfoundation.org>
Signed-off-by: NTom Rini <trini@konsulko.com>

When building a Thumb-1-only target with CONFIG_SYS_THUMB_BUILD,
some files fail to build, most of the time because they include
mcr instructions, which only exist for Thumb-2.

This patch introduces a Kconfig option CONFIG_THUMB2 and uses
it to select between Thumb-2 and ARM mode for the aforementioned
files.
Signed-off-by: NAlbert ARIBAUD <albert.u.boot@aribaud.net>

As QSPI and IFC are pin-multiplexed on LS1021A, only IFC is supported in
SD boot now. For the customer's demand, QSPI needs to be supported in SD
boot too.

This patch adds QSPI or IFC support in SD boot according to the
corresponding defconfig. For detail, ls1021atwr_sdcard_ifc_defconfig is
used to support IFC in SD boot and ls1021atwr_sdcard_qspi_defconfig is
used to support QSPI in SD boot.
Signed-off-by: NAlison Wang <alison.wang@freescale.com>
Reviewed-by: NYork Sun <yorksun@freescale.com>

Add U_BOOT_DMI_DATE (format mm/dd/yyyy) generation to be used by
SMBIOS tables, as required by SMBIOS spec 3.0 [1]. See chapter 7.1,
BIOS information structure offset 08h for details.

[1] http://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.0.0.pdfSigned-off-by: NBin Meng <bmeng.cn@gmail.com>
Acked-by: NSimon Glass <sjg@chromium.org>

This patch adds driver model support for some Marvell MVEBU SoC's. Including
Armada XP and 38x. All 3 currently mainlined boards are converted. DM is now
selected automatically for MVEBU platforms.

With this DM support now available for MVEBU, hardcoding the base addresses
and other information is not necessary any more. Probing should be done
by using the values provided via the device tree now instead. For this
the driver also need to be converted to DM. Patches for some of the drivers
will follow.
Signed-off-by: NStefan Roese <sr@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Luka Perkov <luka.perkov@sartura.hr>

This patch enables the use of the kwboot tool, to boot mainline U-Boot
on the Marvell Armada XP/38x SoC's. This is done by returning to the
SoC's BootROM after SPL has initialized the SDRAM. We need to make sure
to not reconfigure the internal register space and MBARs. Otherwise
the BootROM will not be able to continue after SPL jumps back to it.

To use this feature, please don't forget to change the BOOT_FROM line
in your board specfic kwbimage.cfg file this way:

    BOOT_FROM uart

Tested on these Marvell eval boards:
DB-MV784MP-GP - Armada XP
DB-88F6820-GP - Armada 38x
Signed-off-by: NStefan Roese <sr@denx.de>
Cc: Dirk Eibach <eibach@gdsys.de>
Cc: Kevin Smith <kevin.smith@elecsyscorp.com>
Cc: Luka Perkov <luka.perkov@sartura.hr>

Signed-off-by: NTom Rini <trini@konsulko.com>

Signed-off-by: NTom Rini <trini@konsulko.com>

Signed-off-by: NTom Rini <trini@konsulko.com>

Signed-off-by: NTom Rini <trini@konsulko.com>

The SOURCE_DATE_EPOCH mechanism for reproducible builds require some date(1)
with -d switch to print the relevant date and time strings of another point of
time.

In other words it requires some date(1) that behaves like the GNU date(1) [1].
The BSD date(1) [2] on the other hand has the same switch but with a different
meaning.

Respect this and check the date(1) abilities before usage, error on non
working version.  Use the well known pre- and suffixes for the GNU variant of
a tool on *BSD hosts to search for a working date(1) version.

[1] http://man7.org/linux/man-pages/man1/date.1.html [2]
http://www.freebsd.org/cgi/man.cgi?query=dateSigned-off-by: NAndreas Bießmann <andreas.devel@googlemail.com>

Keystone has build rules introduced by commit ef509b90 ("k2hk: add
support for k2hk SOC and EVM") and commit 0e7f2dba ("keystone: add
support for NAND gpheader image").

These are not reused by other platforms for the build, hence there is no
clear benefit is maintaining them in the generic makefile as a build
target. move these to the keystone specific make option

Original idea of using config.mk by Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

When building with SOURCE_DATE_EPOCH the timezone is in UTC. When
building normally the timezone is taken from the build machine's locale
setting.
Signed-off-by: NChris Packham <judge.packham@gmail.com>
Tested-by: NBin Meng <bmeng.cn@gmail.com>
Tested-by: NPaul Kocialkowski <contact@paulk.fr>
Tested-by: NAndreas Bießmann <andreas.devel@googlemail.com>

The Intel Firmware Support Package (FSP) requires that microcode be provided
very early before the device tree can be scanned. We already support adding
a pointer to the microcode data in a place where early init code can access.

However this just points into the device tree and can only point to a single
lot of microcode. For boards which may have different CPU types we must
support multiple microcodes and pass all of them to the FSP in one place.

Enhance ifdtool to scan all the microcode, place it together in the ROM and
update the microcode pointer to point there. This allows us to pass multiple
microcode blocks to the FSP using its existing API.

Enable the flag in the Makefile so that this feature is used by default for
all boards.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
Tested-by: NBin Meng <bmeng.cn@gmail.com>

Signed-off-by: NTom Rini <trini@konsulko.com>

Add build target for generating boot partition images recognised by
the SoCFPGA BootROM. The SoCFPGA BootROM expects four copies of the
u-boot-spl-dtb.sfp at the beginning of boot partition. Those are
u-boot-spl-dtb.bin augmented by a header with which the BootROM can
work. The u-boot-dtb.img uImage is appended to this to produce a
full boot partition image, the u-boot-with-spl-dtb.sfp . This is
the name of the final target.
Signed-off-by: NMarek Vasut <marex@denx.de>

This patch enables the SDRAM controller that is used on Altera's SoCFPGA
family. This patch configures the SDRAM controller based on a configuration
file that is generated from the Quartus tool, sdram_config.h.
Signed-off-by: NDinh Nguyen <dinguyen@opensource.altera.com>

Most EFI implementations use 64-bit. Add a way to build U-Boot as a 64-bit
EFI payload. The payload unpacks a (32-bit) U-Boot and starts it. This can
be enabled for x86 boards at present.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Improvements to how the payload is built:
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
Tested-by: NBin Meng <bmeng.cn@gmail.com>

It is useful to be able to load U-Boot onto a board even if is it already
running EFI. This can allow access to the U-Boot command interface, flexible
booting options and easier development.

The easiest way to do this is to build U-Boot as a binary blob and have an
EFI stub copy it into RAM. Add support for this feature, targeting 32-bit
initially.

Also add a way to detect when U-Boot has been loaded via a stub. This goes
in common.h since it needs to be widely available so that we avoid redoing
initialisation that should be skipped.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Improvements to how the payload is built:
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
Tested-by: NBin Meng <bmeng.cn@gmail.com>

Add support for building U-Boot as an EFI application with a .efi suffix.
This can be loaded by EFI provided that EFI has the same bit width (32-
or 64-bit) as U-Boot. This unfortunate limitation is imposed by EFI.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

This is currently done for all targets, since 0xff is the default erased
value for most flash devices. In some cases this is not what we want (e.g.
for EFI images) so provide a command to do a vanilla objcopy.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

Signed-off-by: NTom Rini <trini@konsulko.com>

Secure Boot Target is added for NAND for P3041.
For mpc85xx SoCs, the core begins execution from address 0xFFFFFFFC.
In case of secure boot, this default address maps to Boot ROM.
The Boot ROM code requires that the bootloader(U-boot) must lie
in 0 to 3.5G address space i.e. 0x0 - 0xDFFFFFFF.

In case of NAND Secure Boot, CONFIG_SYS_RAMBOOT is enabled and CPC is
configured as SRAM. U-Boot binary will be located on SRAM configured
at address 0xBFF00000.
In the U-Boot code, TLB entries are created to map the virtual address
0xFFF00000 to physical address 0xBFF00000 of CPC configured as SRAM.
Signed-off-by: NSaksham Jain <saksham@freescale.com>
Signed-off-by: NRuchika Gupta <ruchika.gupta@freescale.com>
Signed-off-by: NAneesh Bansal <aneesh.bansal@freescale.com>
Reviewed-by: NYork Sun <yorksun@freescale.com>

In order to achieve reproducible builds in U-Boot, timestamps that are defined
at build-time have to be somewhat eliminated. The SOURCE_DATE_EPOCH environment
variable allows setting a fixed value for those timestamps.

Simply by setting SOURCE_DATE_EPOCH to a fixed value, a number of targets can be
built reproducibly. This is the case for e.g. sunxi devices.

However, some other devices might need some more tweaks, especially regarding
the image generation tools.
Signed-off-by: NPaul Kocialkowski <contact@paulk.fr>