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: Tom Rini <trini@konsulko.com>

We have a large number of places where while we historically referenced
gd in the code we no longer do, as well as cases where the code added
that line "just in case" during development and never dropped it.

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

With full SPL enabled, the loaded image overwrites the mxs_spl_data
location.  Moving it a slightly lower address fixes this.

Signed-off-by: Mans Rullgard <mans@mansr.com>

Since commit commit 152038ea1886 ("i.MX6UL: icore: Add SPL_OF_CONTROL
support") the OPOS6UL board doesn't boot anymore. Adding SPL_DM support
makes the board boot again.

Fixes: commit 152038ea1886 ("i.MX6UL: icore: Add SPL_OF_CONTROL support")
Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>

For most i.MX6 processors the PAD_CTL_SPEED_LOW constant is the same.
Only the i.MX6 SoloLite is an exemption. So far the code did not
consider that. Additionally, for a few i.MX6 processors the code used
the wrong value for the constant.

This patch fixes the PAD_CTL_SPEED_LOW constant for:
 - i.MX6 Solo [1]
 - i.MX6 DualLite [1]
 - i.MX6 Dual [2]
 - i.MX6 Quad [2]
 - i.MX6 DualPlus [3]
 - i.MX6 QuadPlus [3]

Before, it was already correct for:
 - i.MX6 SoloLite [4]
 - i.MX6 SoloX [5]
 - i.MX6 UtraLite [6]
 - i.MX6 ULL [7]

[1] https://www.nxp.com/docs/en/reference-manual/IMX6SDLRM.pdf
[2] https://www.nxp.com/docs/en/reference-manual/IMX6DQRM.pdf
[3] https://www.nxp.com/docs/en/reference-manual/iMX6DQPRM.pdf
[4] https://www.nxp.com/docs/en/reference-manual/IMX6SLRM.pdf
[5] https://www.nxp.com/docs/en/reference-manual/IMX6SXRM.pdf
[6] https://www.nxp.com/docs/en/reference-manual/IMX6ULRM.pdf
[7] https://www.nxp.com/docs/en/reference-manual/IMX6ULLRM.pdf

Signed-off-by: Mark Jonas <mark.jonas@de.bosch.com>
Reviewed-by: Heiko Schocher <hs@denx.de>

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

Working with HAB on the i.MX7 we've encountered a case where a board that
successfully authenticates u-boot when booting Linux via OPTEE subsequently
fails to properly bring up the RTC.

The RTC registers live in the low-power block of the Secure Non-Volatile
Storage (SNVS) block.

The root cause of the error has been traced to the HAB handing off the
SNVS-RTC in a state where HPCOMR::NPSWA_EN = 0 in other words where the
Non-Privileged Software Access Enable bit is zero. In ordinary
circumstances this is OK since we typically do not run in TZ mode, however
when we boot via HAB and enablng TrustZone, it is required to set
HPCOMR::NPSWA_EN = 1 in order for the upstream Linux driver to have
sufficient permissions to manipulate the SNVS-LP block.

On our reference board it is the difference between Linux doing this:

root@imx7s-warp-mbl:~# dmesg | grep rtc
snvs_rtc_enable read 0x00000000 from SNVS_LPLR @ 0x00000034
snvs_rtc_enable read 0x00000021 from SNVS_LPCR @ 0x00000038
snvs_rtc_enable read 0x00000000 from SNVS_HPLR @ 0x00000000
snvs_rtc_enable read 0x80002100 from SNVS_HPCOMR @ 0x00000004
snvs_rtc 30370000.snvs:snvs-rtc-lp: rtc core: registered
         30370000.snvs:snvs-rtc-lp as rtc0
snvs_rtc 30370000.snvs:snvs-rtc-lp: setting system clock to2018-04-01 00:51:04 UTC (1522543864)

and doing this:

root@imx7s-warp-mbl:~# dmesg | grep rtc
snvs_rtc_enable read 0x00000000 from SNVS_LPLR @ 0x00000034
snvs_rtc_enable read 0x00000020 from SNVS_LPCR @ 0x00000038
snvs_rtc_enable read 0x00000001 from SNVS_HPLR @ 0x00000000
snvs_rtc_enable read 0x00002020 from SNVS_HPCOMR @ 0x00000004
snvs_rtc 30370000.snvs:snvs-rtc-lp: failed to enable rtc -110
snvs_rtc: probe of 30370000.snvs:snvs-rtc-lp failed with error -110
hctosys: unable to open rtc device (rtc0)

Note bit 1 of LPCR is not set in the second case and is set in the first
case and that bit 31 of HPCOMR is set in the second case but not in the
first.

Setting NPSWA_EN in HPCOMR allows us to boot through enabling TrustZone
and continue onto the kernel. The kernel then has the necessary permissions
to set LPCR::SRTC_ENV (RTC enable in the LP command register) whereas in
contrast - in the failing case the non-privileged kernel cannot do so.

This patch adds a simple init_snvs() call which sets the permission-bit
called from soc.c for the i.MX7. It may be possible, safe and desirable to
perform this on other i.MX processors but for now this is only tested on
i.MX7 as working.

Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>

Latest xilfpga expects to set BIT5 of flags for nonsecure
bitsream and also expects length in bytes instead of words
This patch does the same.

Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Joe Hershberger <joe.hershberger@ni.com>

This inhibits the re-inititialization of DDR during an RTC-only resume. If
this is not done, an L3 NOC error is produced as the DDR gets accessed
before the re-init has time to complete. Tested on AM437x GP EVM.

Signed-off-by: Russ Dill <Russ.Dill@ti.com>
[j-keerthy@ti.com Ported to Latest Master branch]
Signed-off-by: Keerthy <j-keerthy@ti.com>