Currently CPU_V7 kconfig symbol supports only ARMv7A architectures under
armv7 folder. This led to a misconception of creating separate folders
for armv7m and armv7r. There is no reason to create separate folder for
other armv7 based architectures when it can co-exist with few Kconfig
symbols.

As a first step towards a common folder, rename CPU_V7 as CPUV7A. Later
separate Kconfig symbols can be added for CPU_V7R and CPU_V7M and
can co exist in the same folder.
Reviewed-by: NTom Rini <trini@konsulko.com>
Tested-by: NMichal Simek <michal.simek@xilinx.com>
Suggested-by: NAlexander Graf <agraf@suse.de>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

Not all ARM V7 based cpus has VBAR for remapping
vector base address. So, update VBAR only if it available.
Reviewed-by: NTom Rini <trini@konsulko.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

Test ofnode_device_is_compatible(), and also ofnode_path().
Requested-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Like Linux, syscon_node_to_regmap() allows a node to work as a syscon
provider without binding it to a syscon driver.  Test this.
Requested-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

The syscon implementation in U-Boot is different from that in Linux.
Thus, DT files imported from Linux do not work for U-Boot.

In U-Boot driver model, each node is bound to a dedicated driver
that is the most compatible to it.  This design gets along with the
concept of DT, and the syscon in Linux originally worked like that.

However, Linux commit bdb0066df96e ("mfd: syscon: Decouple syscon
interface from platform devices") changed the behavior because it is
useful to let a device bind to another driver, but still work as a
syscon provider.

That change had happened before U-Boot initially supported the syscon
driver by commit 6f98b750 ("dm: Add support for generic system
controllers (syscon)").  So, the U-Boot's syscon works differently
from the beginning.  I'd say this is mis-implementation given that
DT is not oriented to a particular project, but Linux is the canon
of DT in practice.

The problem typically arises in the combination of "syscon" and
"simple-mfd" compatibles.

In Linux, they are orthogonal, i.e., the order between "syscon" and
"simple-mfd" does not matter at all.

Assume the following compatible.

   compatible = "foo,bar-syscon", "syscon", "simple-mfd";

In U-Boot, this device node is bound to the syscon driver
(driver/core/syscon-uclass.c) since the "syscon" is found to be the
most compatible.  Then, syscon_get_regmap() succeeds.

However,

   compatible = "foo,bar-syscon", "simple-mfd", "syscon";

does not work because this node is bound to the simple-bus driver
(drivers/core/simple-bus.c) in favor of "simple-mfd" compatible.
The compatible string "syscon" is just dismissed.

Moreover,

   compatible = "foo,bar-syscon", "syscon";

works like the first case because the syscon driver populates the
child devices.  This is wrong because populating children is the job
of "simple-mfd" (or "simple-bus").

This commit ports syscon_node_to_regmap() from Linux.  This API
does not require the given node to be bound to a driver in any way.
Reported-by: NKunihiko Hayashi <hayashi.kunihiko@socionext.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Currently, regmap_init_mem() takes a udevice. This requires the node
has already been associated with a device. It prevents syscon/regmap
from behaving like those in Linux.

Change the first argumenet to take a device node.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: NNeil Armstrong <narmstrong@baylibre.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

device_is_compatible() takes udevice, but there is no such a helper
that takes ofnode.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Putting zero length array at the end of struct is a common technique
to embed arbitrary length of members.  There is no good reason to let
regmap_alloc_count() branch by "if (count <= 1)".

As far as I understood the code, regmap->base is an alias of
regmap->ranges[0].start, but it is not helpful but make the code
just ugly.

Rename regmap_alloc_count() to regmap_alloc() because the _count
suffix seems pointless.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
[trini: fixup cpu_info-rcar.c]
Signed-off-by: NTom Rini <trini@konsulko.com>

This function is no more used, and replaced by psci_save
which save also context id as requested by PSCI requirements.

Even if the context id is not used by Linux, it should be saved
and restored in r0 when the CPU_ON is performed.
Signed-off-by: NPatrick Delaunay <patrick.delaunay@st.com>

Replace the psci_save_target_pc call by the new function
psci_save(cpu, pc,context_id)
Signed-off-by: NPatrick Delaunay <patrick.delaunay@st.com>

Replace the psci_save_target_pc call by the new function
psci_save(cpu, pc,context_id)
Signed-off-by: NPatrick Delaunay <patrick.delaunay@st.com>
Acked-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Replace the psci_save_target_pc call by the new function
psci_save(cpu, pc,context_id)
Signed-off-by: NPatrick Delaunay <patrick.delaunay@st.com>
Reviewed-by: NStephen Warren <swarren@nvidia.com>

Replace the psci_save_target_pc call by the new function
psci_save(cpu, pc,context_id)
Signed-off-by: NPatrick Delaunay <patrick.delaunay@st.com>

Replace the psci_save_target_pc call by the new function
psci_save(cpu, pc,context_id)
Signed-off-by: NPatrick Delaunay <patrick.delaunay@st.com>

Add PSCI v1.0 support for Linux and manage PSCI state
for each CPU (affinity 0 level) with all mandatory functions:
- PSCI_VERSION
- CPU_SUSPEND
- CPU_OFF
- CPU_ON
- AFFINITY_INFO
- SYSTEM_OFF
- SYSTEM_RESET
- PSCI_FEATURES
and 1 optional to avoid Linux warning
- MIGRATE_INFO_TYPE
Signed-off-by: NPatrick Delaunay <patrick.delaunay@st.com>
Reviewed-by: NCITOOLS <smet-aci-reviews@lists.codex.cro.st.com>

The added function psci_arch_cpu_entry() is called
during psci_cpu_entry() and can be used by arch to handle
PSCI state transition from ON_PENDING to ON.

The default weak function is empty: not behavior change.
Signed-off-by: NPatrick Delaunay <patrick.delaunay@st.com>

Save and use the 3rd parameter of PSCI CPU_ON request: context_id.

The context_id parameter is only meaningful to the caller.
U-Boot PSCI preserves a copy of the value passed in this parameter.
Following wakeup from a  powerdown state, U-BOOT PSCI places
this value in R0 when it first enters the OS.

NB: this context id is not (yet?) used by Linux but it is mandatory
    to be PSCI compliant.

update armv7 psci functions:
- psci_save_target_pc(): keep for backward compatibility with
  current platform (only save PC and force context id to 0)
  => should be removed when all platform migrate to the new API

- psci_save(): new API to use by ARMv7 platform with PSCI,
  save pc (= entry_point_address) and context_id
Signed-off-by: NPatrick Delaunay <patrick.delaunay@st.com>
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

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

- Based on commit 08ae21af ("MAINTAINERS: Switch nxp.com domain")
  update or drop some formerly Freescale addresses.
- Update a few aliases to reflect current custodians
Signed-off-by: NTom Rini <trini@konsulko.com>

When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from.  So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry.  Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.

In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.

This commit changes all instances where we have multiple licenses (in
these cases, dual license) declared in the SPDX-License-Identifier tag.
In this case we change from listing "LICENSE-A LICENSE-B" or "LICENSE-A
or LICENSE-B" or "(LICENSE-A OR LICENSE-B)" to "LICENSE-A OR LICENSE-B"
as per the Linux Kernel style document.  Note that parenthesis are
allowed so when they were used before we continue to use them.
Reviewed-by: NFabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: NTom Rini <trini@konsulko.com>

When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from.  So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry.  Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.

In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.

This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents.  There's also a few places where I found we did not have a tag
and have introduced one.
Signed-off-by: NTom Rini <trini@konsulko.com>

omap-common cache enabling sequence relies on cpu_init_cp15()
(inside start.S) for enabling I-caches. But cpu_init_cp15()
can be skipped if CONFIG_SKIP_LOWLEVEL_INIT is defined. So
enable I-caches if not enabled already.
Debugged-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
Tested-by: NSteve Kipisz <s-kipisz2@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Tested-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>

Building with verified boot support requires hash, add that
dependency here. Otherwise the following build error will come out
without crc command.

      LD      u-boot
lib/built-in.o: In function `hash_calculate':
lib/rsa/rsa-checksum.c:29: undefined reference to
`hash_progressive_lookup_algo'
...
make[1]: *** [u-boot] Error 1
Signed-off-by: NKelvin Cheung <keguang.zhang@gmail.com>
Reviewed-by: NJoe Hershberger <joe.hershberger@ni.com>

A common voltage of 1.35V was being programmed for all am43 board
versions. EPOS-EVM Needs 1.20V for LPDDR2.

Fixes: fc69d472 (“board: ti: AM43XX: Add ddr voltage rail configuration”)
Reported-by: NJames Doublesin <doublesin@ti.com>
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Reviewed-by: NTom Rini <trini@konsulko.com>

Signed-off-by: NTrevor Woerner <twoerner@gmail.com>

With tighter build flags the fact that <stdio_dev.h> doesn't have a
reference back to MAX_NAMES causes an error.  Include <stdio.h> here and
then in common/console.c use MAX_NAMES rather than 3 when working with
stdio_names.
Reported-by: NPeter Robinson <pbrobinson@gmail.com>
Signed-off-by: NTom Rini <trini@konsulko.com>
Tested-by: NPeter Robinson <pbrobinson@gmail.com>

With tighter build flags the fact that this header referenced
uchar/ushort without including what typedefs it causes an error.  Rather
than add another include here, drop the section in question as it is
unused.
Reported-by: NPeter Robinson <pbrobinson@gmail.com>
Tested-by: NPeter Robinson <pbrobinson@gmail.com>
Signed-off-by: NTom Rini <trini@konsulko.com>

The DEBUG macro is never defined unless explicitly enabled.
Drop useless #undef DEBUG in the board configs so it won't
spread any further.
Signed-off-by: NMarek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>

Pull the symbol from the boards and zap struct rmobile_sysinfo as they
are rather useless. The entire purpose of that whole machinery was to
print board name in the CONFIG_ARCH_RMOBILE_BOARD_STRING. Do that in a
far simpler and more contained manner.
Signed-off-by: NMarek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>

Convert the symbol to Kconfig, no functional change.
Signed-off-by: NMarek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>

Rename CONFIG_RMOBILE_BOARD_STRING to CONFIG_ARCH_RMOBILE_BOARD_STRING
to make things consistent, no functional change.
Signed-off-by: NMarek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>

Synchronize the README with the current state of U-Boot, unify
the build instructions to avoid duplication.
Signed-off-by: NMarek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>

The R8A7792 does not have the USB extal, so drop it.
Signed-off-by: NMarek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>

freescale.com domain is no longer reachable, so switch the
maintainers' emails to nxp.com domain instead.
Signed-off-by: NFabio Estevam <fabio.estevam@nxp.com>

As ret is not set when calling max77693_get_vcell() there is no
need to check ret again.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

The 'SDHCI_QUIRK_NO_HISPD_BIT' is used wrong here. The purpose of this
quirk is to tell the sdhci-driver that the IP-core doesn't have a "high-
speed-enable" bit in its registers.

With this commit we change this to the correct quirk:
SDHCI_QUIRK_BROKEN_HISPD_MODE
Signed-off-by: NHannes Schmelzer <hannes.schmelzer@br-automation.com>

Some IP-core implementations of the SDHCI have different troubles on the
silicon where they are placed.

On ZYNQ platform for example Xilinx doesn't accept the hold timing of an
eMMC chip which operates in High-Speed mode and must be forced to
operate in non high-speed mode. To get rid of this
"SDHCI_QUIRK_BROKEN_HISPD_MODE" is introduced.

For more details about this refer to the Xilinx answer-recor #59999
https://www.xilinx.com/support/answers/59999.html

This commit:
- doesn't set HISPD bit on the host-conroller
- reflects this fact within the host-controller capabilities

Upon this the layer above (mmc-driver) can setup the card correctly.

Otherwise the MMC card will be switched into high-speed mode and causes
possible timing violation on the host-controller side.
Signed-off-by: NHannes Schmelzer <oe5hpm@oevsv.at>
Signed-off-by: NHannes Schmelzer <hannes.schmelzer@br-automation.com>