Most of architectures have .text section situated in the very beginning
of U-Boot binary and thus it is very logical that CONFIG_SYS_TEXT_BASE
is used on final linkage step to specify where U-Boot gets linked to.

For that we pass the following construction to the LD:
---------------------------->8-----------------------
xxx-ld ...  -Ttext $(CONFIG_SYS_TEXT_BASE) ...
---------------------------->8-----------------------

But there could be exceptions. For example:
 1. In case of ARCv2 we want to put vectors table in its own section
    .ivt in front of .text section which means we need either add an
    offset to CONFIG_SYS_TEXT_BASE to compensate for .ivt or don't
    pass "-Ttext" to the LD at all and specify link base in linker
    script directly.

 2. Some architectures even though have .text section in the very
    beginning of the U-Boot image still use different symbols to
    specify link-base:
       * NIOS2: CONFIG_SYS_MONITOR_BASE (which I really like because
         that exactly what makes sense - where out image starts but not
         beginning of its .text section which just happened to match the
         whole image beginning)
       * EXTENSA: CONFIG_SYS_TEXT_ADDR
       * X86: Which doesn't use CONFIG_SYS_MONITOR_BASE in case of EFI
         otherwise sets explicit link base in u-boot.lds

I think that's good to allow for flexibility and don't require each and
every architecture or even platform to specify CONFIG_SYS_TEXT_BASE as well
as use it to set .text section location.

So let's only pass "-Ttext xxx" for those architectures who don't set
link-base explicitly in their linker scripts.

This patch iaddresses comments for previously sent
https://patchwork.ozlabs.org/patch/867540/.
Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Marek Vasut <marek.vasut@gmail.com>
Cc: Max Filippov <jcmvbkbc@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>

These were dropped in [1], after relocation, for their values offset by
reloc_off.
Unconditionally show the HW values and add a '(reloc)' hint for the
offset values showed after relocation.
Also, the LRs' dumps are now formatted the same way the other regs' are.

[1] Commit 082693f4 ("arm64 :show_regs: show the address before relocation")
Signed-off-by: NKarl Beldan <karl.beldan+oss@gmail.com>

Fix build after addition of RSA_get0_key() to LibreSSL.
Patch from Theo Buehler and Stuart Henderson.
Signed-off-by: NTheo Buehler <tb@openbsd.org>
Signed-off-by: NStuart Henderson <sthen@openbsd.org>

ll_temac driver was used by Xilinx Microblaze big endian and
Xilinx ppc405/ppc440 SoCs.

ppc support was removed by: "powerpc: remove 4xx support"
(sha1: 98f705c9)
and Microblaze BE is not tested for a long time that's why this driver
can be removed because none is going to updated it to DM anyway.
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

Add CONFIG_SPL_NET_VCI_STRING to enable USB-Ethernet boot mode
support.
Signed-off-by: NFaiz Abbas <faiz_abbas@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>

Memory banks with address 0 and size 0 are empty and should not be
passed to the OS via device tree.
Acked-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Do a explicit check for CONFIG_SYS_BIG_ENDIAN and
CONFIG_SYS_LITTLE_ENDIAN to avoid errors on platforms where both
are undefined (x86).
Signed-off-by: NBernhard Messerklinger <bernhard.messerklinger@br-automation.com>
Reviewed-by: NHannes Schmelzer <hannes.schmelzer@br-automation.com>

Since memory banks may not be located behind each other we need to add
them separately.
Signed-off-by: NBernhard Messerklinger <bernhard.messerklinger@br-automation.com>
Reviewed-by: NHannes Schmelzer <hannes.schmelzer@br-automation.com>

These got removed in config re-syncs due to a Kconfig bug. Add these
back here.
Signed-off-by: NAndrew F. Davis <afd@ti.com>
Reviewed-by: NLokesh Vutla <lokeshvutla@ti.com>

This seems to have been missed, possibly due to the inability to
enable TI_SECURE_DEVICE on Keystone2 devices previously.

Fixes: bfebc8c9 ("env: Rename getenv_hex(), getenv_yesno(), getenv_ulong()")
Signed-off-by: NAndrew F. Davis <afd@ti.com>
Reviewed-by: NLokesh Vutla <lokeshvutla@ti.com>

TI_SECURE_DEVICE is used by both OMAP2+ and Keystone2 family devices,
and so when ARCH_OMAP2PLUS was used to gate off the OMAP2+ Kconfig
Keystone2 family devices lost this config option.

Move this option out of mach-omap2 Kconfig to a spot accessible by both
families. We picked arch/arm/Kconfig over the TI specific board/ti/
location as this option is not specific to our boards but rather our
architecture.

Plus at some point this option can be changed to just
SECURE_DEVICE, as having secure parts is not exclusive to TI and
so other vendors can interpret this option as needed by their device
configurations.

Fixes: a93fbf4a ("ARM: omap2+: rename config to ARCH_OMAP2PLUS and consolidate Kconfig")
Signed-off-by: NAndrew F. Davis <afd@ti.com>
Reviewed-by: NLokesh Vutla <lokeshvutla@ti.com>

Drop CONFIG_SYS_MEMORY_TOP. Rename CONFIG_SYS_TEXT_ADDR to
XTENSA_SYS_TEXT_ADDR.
Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>

A number of platforms include config_distro_defaults.h but do not enable
CONFIG_DISTRO_DEFAULTS.  As they plainly intended to, set that flag and
re-sync config files.
Signed-off-by: NTom Rini <trini@konsulko.com>

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

This commit fixes several issues:

- After moving env related code to ./env directory the env_common.o file
is no longer present in the system (has been replaced with built-in.o).

- Use ${OBJCOPY} if available, fallback to system default's objcopy if not
present.

- Extend the script to accept different build directory than current one.
It is extremely handy with OE usage, where source code is separated from
build.
Signed-off-by: NLukasz Majewski <lukma@denx.de>
Tested-by: NAlex Kiernan <alex.kiernan@gmail.com>

When booting from a non-MMC device, the MMC sub-system may not be
initialized when the environment is first accessed.
We need to make sure that the MMC sub-system is ready in even a non-MMC
boot case.

Therefore, initialize mmc before loading environment from it.
Signed-off-by: NFaiz Abbas <faiz_abbas@ti.com>

These ARM boards are in nice shape and still being used a lot
with e.g. QEMU, so I can maintain them.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

When using omap_hsmmc without the device model then the allocation
of mmc->priv ends up uninitialised.
Signed-off-by: NAlex Kiernan <alex.kiernan@gmail.com>
Tested-by: NRobert Nelson <robertcnelson@gmail.com>
Reviewed-by: NSam Protsenko <semen.protsenko@linaro.org>

The correspondence between mmc versions as used in u-boot and the version
numbers reported in register EXT_CSD_REV is wrong for versions above and
including MMC_VERSION_4_41. All those versions were shifted by one:
real 4.5 hardware appeared to be MMC_VERSION_5_0.

Fix this by adding the missing version in the correspondence table.
Reported-by: Neil Eilmsteiner Heribert <eil@keba.com>
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NSam Protsenko <semen.protsenko@linaro.org>

After settings the speed of the sd with the switch command, a check is
done to make sure that the new speed has been set. The current check has a
masking error: speed are encoded on 4 bits only.
Fix it by masking the upper bits.

This fixes a problem seen with QEmu emulating a vexpress-a15.
Reported-by: NJonathan Gray <jsg@jsg.id.au>
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
Tested-by: NJonathan Gray <jsg@jsg.id.au>

By default UHS and HS200 are not enabled.
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

Since DRA7xx/AM57xx SR1.1 and SR1.0 has errata to limit the frequency of
MMC1 to 96MHz and frequency of MMC2 to 48MHz for AM572x SR1.1, limit the
frequency and disable higher speed modes for those revision.
Also use the recommended IO delays (those tagged with "rev11")
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

HS200 cannot be supported on mmc2, because the IO lines of mmc2 are
connected to 3.3v.
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

The UHS modes are not supported in beagle-x15 because it's not possible to
switch the IO lines supply voltage to 1.8v.
Also HS200 cannot be supported on mmc2, because the IO lines of mmc2 are
connected to 3.3v.
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

On DRA7 family SoCs, MMC1 controller supports SDR104,
SDR50, DDR50, SDR25 and SDR12 UHS modes.

MMC2 controller supports HS200 and DDR modes.

MMC3 controller supports SDR12, SDR25 and SDR50 modes.

MMC4 controller supports SDR12 and SDR25 modes.

Add these supported modes in device-tree file.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

Use the new compatible string "ti,dra7-hsmmc" that was specifically
added for dra7 and dra72. This is required since for dra7 and dra72
processors iodelay values has to be set unlike other processors.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

Now that omap_hsmmc has support for hs200 mode, change the clock
frequency to 192MHz. Also change the REFERENCE CLOCK frequency to
192MHz based on which the internal mmc clock divider is calculated.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

I/O data lines of UHS SD card operates at 1.8V when in UHS speed
mode (same is true for eMMC in DDR and HS200 modes). Add support
to switch signal voltage to 1.8V in order to support
UHS cards and eMMC HS200 and DDR modes.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

mmc core has defined a new parameter *clk_disable* to gate the clock.
Disable the clock here if *clk_disable* is set.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

This callback is used to send the 74 clock cycles after power up.
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

When the clock is applied, compute the actual value of the clock. It may be
slightly different from the requested value (max freq, divisor threshold)
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

The default configuration is usually working fine for the the HS modes.
Don't enforce the presence of a dedicated pinmux for the HS modes.
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

AM572x SR1.1 requires different IODelay values to be used than that used
in AM572x SR2.0. These values are populated in device tree. Add
capability in omap_hsmmc driver to extract IOdelay values for different
silicon revision. The maximum frequency is also reduced when using a ES1.1.
To keep the ability to boot both revsions with the same dtb, those values
can be provided by the platform code.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

The data manual of J6/J6 Eco recommends to set different IODELAY values
depending on the mode in which the MMC/SD is enumerated in order to
ensure IO timings are met.

Add support to parse mux values and iodelay values from device tree
and set these depending on the enumerated MMC mode.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>

Add a new API to perform iodelay recalibration without isolate
io to be used in uboot.

The data manual of J6/J6 Eco recommends to set different IODELAY values
depending on the mode in which the MMC/SD is enumerated in order to
ensure IO timings are met. The MMC driver can use the new API to
set the IO delay values depending on the MMC mode.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>