Merge branch 'next' of https://source.denx.de/u-boot/custodians/u-boot-riscv into next

- K210 updates

test: Add K210 PLL tests to sandbox defconfigs

This adds the unit test for the K210 PLL to the sandbox defconfigs.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

k210: Don't imply CCF

Now that the k210 clock driver does not depend on CCF, we should no longer
imply it (and probably should not have in the first place). We can also
reduce the pre-relocation malloc arena back to something sensible.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

k210: dts: Set PLL1 to the same rate as PLL0

Linux has had some stability issues when using AISRAM with a different
frequency from SRAM. Mirror their change here now that we relocate into
AISRAM.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

clk: k210: Move k210 clock out of its own subdirectory

Now that we have only one clock driver, we don't need to have our own
subdirectory. Move the driver back with the rest of the clock drivers.

The MAINTAINERS for kendryte pinctrl is also fixed since it has always been
wrong.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

clk: k210: Remove bypass driver

This driver no longer serves a purpose now that we have moved away from
CCF. Drop it.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

clk: k210: Don't set PLL rates if we are already at the correct rate

This speeds up boot by preventing multiple reconfigurations of the PLLs.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

clk: k210: Re-add support for setting rate

This adds support for setting clock rates, which was left out of the
initial CCF expunging. There are several tricky bits here, mostly related
to the PLLS:

* The PLL's bypass is broken. If the PLL is reconfigured, any child clocks
  will be stopped.
* PLL0 is the parent of ACLK which is the CPU and SRAM's clock. To prevent
  stopping the CPU while we configure PLL0's rate, ACLK is reparented
  to IN0 while PLL0 is disabled.
* PLL1 is the parent of the AISRAM clock. This clock cannot be reparented,
  so we instead just disallow changing PLL1's rate after relocation (when
  we are using the AISRAM).

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

clk: k210: Implement soc_clk_dump

Since we are no longer using CCF we cannot use the default soc_clk_dump.
Instead, implement our own.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

clk: k210: Move pll into the rest of the driver

Now that there no separate PLL driver, we can no longer make the PLL
functions static. By moving the PLL driver in with the rest of the clock
code, we can make these functions static again. We still keep the pll
header for unit testing, but it is pretty reduced.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

clk: k210: Rewrite to remove CCF

This is effectively a complete rewrite to remove all dependency on CCF.
The code is now smaller, and so is the binary. It also takes up less memory
at runtime (since we don't have to create 40 udevices). In general, I am
much happier with this driver as much of the complexity and late binding
has been removed.

The k210_*_params structs which were previously used to initialize CCF
clocks are now used as the complete configuration. Since we can write our
own division logic, we can now do away with several "half" clocks which
only existed to provide constant factors of two.

The clock IDs have been renumbered to remove unused clocks. This may not be
the last time they are renumbered, since we have diverged with Linux. There
are also still a few clocks left out which may need to be added back in.

In general, I have tried to leave out behavioral changes. However, there is
a small bugfix regarding ACLK. According to the technical reference manual,
its mux comes *after* its divider (which is present only for PLL0). This
would have required yet another intermediate clock to fix with CCF, but
with the new driver it is just 2 lines of code :)

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

clk: Allow force setting clock defaults before relocation

Since 291da96b8e ("clk: Allow clock defaults to be set during re-reloc
state for SPL only") it has been impossible to set clock defaults before
relocation. This is annoying on boards without SPL, since there is no way
to set clock defaults before U-Boot proper. In particular, the aisram rate
must be changed before relocation on the K210, since U-Boot will hang if we
try and change the rate while we are using aisram.

To get around this, extend the stage parameter to allow force setting
defaults, even if they would be otherwise postponed for later. A device
tree property was decided against because of the concerns in the original
commit thread about the overhead of repeatedly parsing the device tree.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Merge tag 'ti-v2021.10-next-v2' of https://source.denx.de/u-boot/custodians/u-boot-ti into next

- HSM re-architecture support for all K3 platforms
- AM64 USB support
- Driver model support for Davinci RTC

dma: ti: k3-udma: Add support for native configuration of chan/flow

In absence of Device Manager (DM) services such as at R5 SPL stage,
driver will have to natively setup TCHAN/RCHAN/RFLOW cfg registers.
Add support for the same.

Note that we still need to send chan/flow cfg message to TIFS via TISCI
client driver in order to open up firewalls around chan/flow but setting
up of cfg registers is handled locally.

U-Boot specific code is in a separate file included in main driver so
as to maintain similarity with kernel driver in order to ease porting of
code in future.

Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210607141753.28796-8-vigneshr@ti.com

soc: ti: k3-navss-ringacc: Add support for native configuration of rings

In absence of Device Manager (DM) services such as at R5 SPL stage,
driver will have to natively setup Ring Cfg registers. Add support for
the same.

Note that we still need to send RING_CFG message to TIFS via TISCI
client driver in order to open up firewalls around Rings.

U-Boot specific code is in a separate file included in main driver so
as to maintain similarity with kernel driver in order to ease porting of
code in future.

Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210607141753.28796-7-vigneshr@ti.com

ARM: dts: k3: Add cfg register space for ringacc and udmap

R5 SPL needs access to cfg space of Rings and UDMAP, therefore add RING
CFG, TCHAN CFG and RCHAN CFG address ranges.
Note that these registers are present within respective IPs but are
not populated in Linux DT nodes (as they are configured via TISCI APIs)
and hence are added to -u-boot.dtsi for now.

Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210607141753.28796-6-vigneshr@ti.com

ARM: dts: j72xx-r5-common-proc-board: Add DM firmware node

Add DM firmware node which will provide DM services during R5 SPL stage.

Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210607141753.28796-5-vigneshr@ti.com

firmware: ti_sci: Add support for Resoure Management at R5 SPL stage.

On J721e and J7200, MCU R5 core (boot master) itself would run Device
Manager (DM) Firmware and interact with TI Foundational Security (TIFS)
firmware to enable DMA and such other Resource Management (RM) services.
So, during R5 SPL stage there is no such RM service available and ti_sci
driver will have to directly interact with TIFS using DM to DMSC
channels to request RM resources.

Therefore add DT binding and driver for the same. This driver will
handle Resource Management services at R5 SPL stage.

Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210607141753.28796-4-vigneshr@ti.com

firmware: ti_sci: Implement GET_RANGE with static data

In case of R5 SPL, GET_RANGE API service is not available (as DM
services are not yet up), therefore service such calls locally using
per SoC static data.

Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210607141753.28796-3-vigneshr@ti.com

mailbox: k3-sec-proxy: Add DM to DMSC communication thread

R5 SPL would need to talk to DMSC using DM to DMSC sec-proxy threads.
Mark these as valid threads in the driver.

Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210607141753.28796-2-vigneshr@ti.com

arm: dts: k3-j72xx: correct MCU timer1 frequency

MCU timer1 is used as the tick timer for MCU R5 SPL, and the
clock-frequency defined in DT appears to be incorrect at the moment.
Actual clock source for the timer is MCU_SYSCLK0 / 4 which is 250MHz.

Earlier setup of 25MHz went unnoticed, as there was a separate issue
with omap-timer, which caused an error to the clock by a factor of 8
with j7 devices. This problem surfaced once the omap-timer was fixed.

Signed-off-by: Tero Kristo <kristo@kernel.org>

board: ti: j72xx: README: update build instructions and image formats

Update build instructions and image formats based on HSM rearch. A new
DM image is added into the build, which gets executed right after R5
SPL finishes its job.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tero Kristo <kristo@kernel.org>

configs: j7200_evm_r5: Enable raw access power management features

Sysfw is not going to provide access to power management features in the
new architecture, so SPL must implement these itself. Enable all the raw
register access based clock + power domain drivers.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Tero Kristo <kristo@kernel.org>

configs: j721e_evm_r5: Enable raw access power management features

Sysfw is not going to provide access to power management features in the
new architecture, so SPL must implement these itself. Enable all the raw
register access based clock + power domain drivers.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tero Kristo <kristo@kernel.org>

arm: mach-k3: j721e_init: Force early probe of clk-k3 driver

Force the clk-k3 driver to probe early during R5 SPL boot to ensure the
default system clock configuration is completed. Many other drivers
assume a default state of the clock tree and it is currently possible
for them to probe before clk-k3 depending on the exact system
configuration.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Reported-by: Keerthy <j-keerthy@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tero Kristo <kristo@kernel.org>

arm: mach-k3: sysfw-loader: pass boardcfg to sciserver

Copy the contents of the board config loaded from sysfw.itb into an
EXTBOOT shared memory buffer that gets passed to sciserver. This only
needs to be done if EXTBOOT area has not been populated by ROM code yet.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tero Kristo <kristo@kernel.org>

arm: mach-k3: common: Drop main r5 start

Only start-up the non-linux remote cores if we are running in legacy
boot mode. HSM rearch is not yet supporting this.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tero Kristo <kristo@kernel.org>

arm: mach-k3: do board config for PM only if supported

If the raw PM support is built in, we are operating in the split
firmware approach mode where PM support is not available. In this
case, skip the board config for this.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tero Kristo <kristo@kernel.org>

arm: mach-k3: add support for detecting firmware images from FIT

Add callback routines for parsing the firmware info from FIT image, and
use the data to boot up ATF and the MCU R5 firmware.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tero Kristo <kristo@kernel.org>

arm: mach-k3: Add platform data for j721e and j7200

Add platform clock and powerdomain data for J721e and J7200. This data
is used by the corresponding drivers to register all the required device
clocks and powerdomains.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Tero Kristo <kristo@kernel.org>

tools: k3_fit_atf: add DM binary to the FIT image

Add DM (device manager) firmware image to the fit image that is loaded by
R5 SPL. This is needed with the HSM rearch where the firmware allocation
has been changed slightly.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tero Kristo <kristo@kernel.org>

cmd: ti: pd: Add debug command for K3 power domains

Add support command for debugging K3 power domains. This is useful with
the HSM rearch setup, where power domains are directly controlled by SPL
instead of going through the TI SCI layer. The debugging support is only
available in the u-boot codebase though, so the raw register access
power domain layer must be enabled on u-boot side for this to work. By
default, u-boot side uses the TI SCI layer, and R5 SPL only uses the
direct access methods.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tero Kristo <kristo@kernel.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>

power: domain: Introduce driver for raw TI K3 PDs

Normally, power domains are handled via TI-SCI in K3 SoCs. However,
SPL is not going to have access to sysfw resources, so it must control
them directly. Add driver for supporting this.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tero Kristo <kristo@kernel.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>

clk: add support for TI K3 SoC clocks

Add driver to support TI K3 generation SoC clocks. This driver registers
the clocks provided via platform data, and adds support for controlling
the clocks via DT handles.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tero Kristo <kristo@kernel.org>

clk: add support for TI K3 SoC PLL

Add support for TI K3 SoC PLLs. This clock type supports
enabling/disabling/setting and querying the clock rate for the PLL. The
euclidean library routine is used to calculate divider/multiplier rates
for the PLLs.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tero Kristo <kristo@kernel.org>

clk: fix set_rate to clean up cached rates for the hierarchy

Clock rates are cached within the individual clock nodes, and right now
if one changes a clock rate somewhere in the middle of the tree, none
of its child clocks notice the change. To fix this, clear up all the
cached rates for us and our child clocks.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tero Kristo <kristo@kernel.org>

clk: fix assigned-clocks to pass with deferring provider

If a clock provider is not ready for assigning default rates/parents
during its probe, it may return -EPROBE_DEFER directly from xlate.
Handle this special case properly by skipping the entry and adjusting the
return value to pass. The defaults will be handled properly in post probe
phase then.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tero Kristo <kristo@kernel.org>

clk: sci-clk: fix return value of set_rate

Set rate should return the new clock rate on success, and negative error
value on failure. Fix this, as currently set_rate returns 0 on success.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tero Kristo <kristo@kernel.org>

clk: add support for setting clk rate from cmdline

Add new clk subcommand "clk setfreq", for setting up a clock rate
directly from u-boot cmdline. This is handy for any debugging purposes
towards clocks.

Acked-by: Lukasz Majewski <lukma@denx.de>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tero Kristo <kristo@kernel.org>

clk: do not attempt to fetch clock pointer with null device

Bail out early if device returned for the parent clock is null.
This avoids warning prints like this when doing clk dump:

  dev_get_uclass_priv: null device

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tero Kristo <kristo@kernel.org>

clk: fix clock tree dump to properly dump out every registered clock

Some clocks are not associated to a DM node, so just parsing the DM is not
enough. This is especially true for root clocks, which typically don't have
any parents. Instead, fetch every registered UCLASS_CLK instance, and dump
these out.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tero Kristo <kristo@kernel.org>

clk: fixed_rate: add API for directly registering fixed rate clocks

Current driver only supports registering fixed rate clocks from DT. Add
new API which makes it possible to register fixed rate clocks directly
from e.g. platform specific clock drivers.

Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tero Kristo <kristo@kernel.org>

common: fit: Update board_fit_image_post_process() to pass fit and node_offset

board_fit_image_post_process() passes only start and size of the image,
but type of the image is not passed. So pass fit and node_offset, to
derive information about image to be processed.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Tero Kristo <kristo@kernel.org>

remoteproc: k3-r5: remove sysfw PM calls if not supported

With the sysfw rearch, sysfw PM calls are no longer available from SPL
level. To properly support this, remove the is_on checks and the reset
assertion from the R5 remoteproc driver as these are not supported.
Attempting to access unavailable services will cause the device to hang.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tero Kristo <kristo@kernel.org>

arm: mach-k3: introduce new config option for sysfw split

On J7 family of SoCs (J721E and J7200), sysfw is being split to be run
under two cores, TIFS portion on DMSC core, and DM firmware under MCU
R5. As MCU R5 is also used to run one phase of the bootloader, we must
prevent access from here towards sysfw services. To support this, add
new config option which can be used to detect presence of RM/PM sysfw
services.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tero Kristo <kristo@kernel.org>

lib: rational: copy the rational fraction lib routines from Linux

Copy the best rational approximation calculation routines from Linux.
Typical usecase for these routines is to calculate the M/N divider
values for PLLs to reach a specific clock rate.

This is based on linux kernel commit:
"lib/math/rational.c: fix possible incorrect result from rational
fractions helper"
(sha1: 323dd2c3ed0641f49e89b4e420f9eef5d3d5a881)

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Tero Kristo <kristo@kernel.org>

rtc: davinci: fix date loaded on reset

On reset, the RTC loads the 2000-01-01 date with a wrong day of the
week (Sunday instead of Saturday).

Signed-off-by: Dario Binacchi <dariobin@libero.it>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210602203805.11494-9-dariobin@libero.it

rtc: davinci: add driver model support

Update the driver to support the device tree and the driver model.
The read / write helpers in rtc_ops allow access to scratch registers
only. The offset parameter is added to the address of the scratch0
register.

Support for non-DM has been removed as there were no users.

Signed-off-by: Dario Binacchi <dariobin@libero.it>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210602203805.11494-8-dariobin@libero.it

arm: dts: sync rtc node of am335x boards with Linux 5.9-rc7

There have been some changes to the am335x-<board> DTs related to the
rtc node, so let's re-syncs them with Linux.

Signed-off-by: Dario Binacchi <dariobin@libero.it>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210602203805.11494-7-dariobin@libero.it

rtc: davinci: use unlock/lock mechanism

The RTC module contains a kicker mechanism to prevent any spurious
writes from changing the register values. To set the time, you must
first unlock the TC registers, update them and then lock.

Signed-off-by: Dario Binacchi <dariobin@libero.it>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210602203805.11494-6-dariobin@libero.it

rtc: davinci: check BUSY bit before set TC registers

To write correct data to the TC registers, the STATUS register must be
read until the BUSY bit is equal to zero. Once the BUSY flag is zero,
there is a 15 μs access period in which the TC registers can be
programmed.
The rtc_wait_not_busy() has been inspired by the Kernel.

Signed-off-by: Dario Binacchi <dariobin@libero.it>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210602203805.11494-5-dariobin@libero.it

rtc: davinci: replace 32bit access with 8bit access

Use 32-bit access only where it is needed. Most of the RTC registers
contain useful information in the 8 least significant bits, the others
are reserved.

Signed-off-by: Dario Binacchi <dariobin@libero.it>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210602203805.11494-4-dariobin@libero.it

rtc: davinci: fix compiler errors

Fix errors raised by module compilation.

Signed-off-by: Dario Binacchi <dariobin@libero.it>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210602203805.11494-3-dariobin@libero.it

rtc: davinci: enable compilation for omap architectures

The Davinci's onchip RTC is also present on TI OMAP1, AM33XX, AM43XX and
DRA7XX SOCs. So, let's enable compilation for these architectures too.

Signed-off-by: Dario Binacchi <dariobin@libero.it>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210602203805.11494-2-dariobin@libero.it

Nokia RX-51: Enable CONFIG_WDT to remove deprecation warning

Also convert CONFIG_HW_WATCHDOG to CONFIG_WATCHDOG.

Signed-off-by: Pali Roh?r <pali@kernel.org>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210309201915.16586-1-pali@kernel.org

configs: am64: Enable configs to support USB host and device modes

Enable config options required to add support for USB Mass storage boot,
USB DFU boot, host and device modes in U-Boot.

Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210604163043.12811-11-a-govindraju@ti.com

arm: dts: k3-am64-main: Update the location of ATF in SRAM and increase its max size

Due to a limitation for USB DFU boot mode, SPL load address has to be less
than  or equal to 0x70001000. So, load address of SPL and ATF have been
moved to 0x70000000 and 0x701a0000 respectively.

Also, the maximum size of ATF has been increased to 0x1c000 [1].

Therefore, update ATF's location and maximum size accordingly in the device
tree file.

[1] - https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=2fb5312f61a7de8b7a70e1639199c4f14a10b6f9

Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210604163043.12811-10-a-govindraju@ti.com

configs: am64x_evm_*_defconfig: Rearrange the components in SRAM to satisfy the limitations for USB DFU boot mode

For USB DFU boot mode there is a limitation on the load address of boot
images that they have to be less than 0x70001000. Therefore, move the
SPL_TEXT_BASE address to 0x70000000.

Currently ATF is being loaded at 0x70000000, if the SPL is being loaded at
0x70000000 then ATF would overwrite SPL image when loaded. Therefore, move
the location of ATF to a latter location in SRAM, past the SPL image. Also
rearrange the EEPROM and BSS data on top of ATF.

Given below is the placement of various data sections in SRAM

     ┌──────────────────────────────────────┐0x70000000
     │                                      │
     │                                      │
     │                                      │
     │    SPL IMAGE (Max size 1.5 MB)       │
     │                                      │
     │                                      │
     │                                      │
     ├──────────────────────────────────────┤0x7017FFFF
     │                                      │
     │           SPL STACK                  │
     │                                      │
     ├──────────────────────────────────────┤0x70192727
     │          GLOBAL DATA(216 B)          │
     ├──────────────────────────────────────┤0x701927FF
     │                                      │
     │       INITIAL HEAP (32 KB)           │
     │                                      │
     ├──────────────────────────────────────┤0x7019A7FF
     │                                      │
     │          BSS  (20 KB)                │
     ├──────────────────────────────────────┤0x7019F7FF
     │         EEPROM DATA (2 KB)           │
     ├──────────────────────────────────────┤0x7019FFFF
     │                                      │
     │                                      │
     │            ATF (123 KB)              │
     │                                      │
     │                                      │
     ├──────────────────────────────────────┤0x701BEBFB
     │   BOOT PARAMETER INDEX TABLE (5124 B)│
     ├──────────────────────────────────────┤0x701BFFFF
     │                                      │
     │SYSFW FIREWALLED DUE TO A BUG (128 KB)│
     │                                      │
     ├──────────────────────────────────────┤0x701DFFFF
     │                                      │
     │      DMSC CODE AREA (128 KB)         │
     │                                      │
     └──────────────────────────────────────┘0x701FFFFF

Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210604163043.12811-9-a-govindraju@ti.com

arm: dts: k3-am642-evm-u-boot: Add U-Boot tags and fix the dr_mode to peripheral for USB subsystem

Add U-Boot tags and fix the dr_mode as peripheral in U-Boot to support DFU
by default.

Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210604163043.12811-8-a-govindraju@ti.com

arm: dts: k3-am642-*-evm: Add USB support

AM64 EVM board has a micro USB 2.0 AB connector and the USB0_VBUS is
connected with a resistor divider in between. USB0_DRVVBUS pin is muxed
between USB0_DRVVBUS and GPIO1_79 signals.

Add the corresponding properties and set the pinmux mode for USB subsystem
in the evm dts file.

Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210604163043.12811-7-a-govindraju@ti.com

arm: dts: k3-am64-main: Add USB DT nodes

Add DT node for the single USB subsystem in main dtsi file.

Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210604163043.12811-6-a-govindraju@ti.com

board: ti: am64x: Set the core voltage of USB PHY to 0.85V

Set the core voltage of USB PHY in AM64x to 0.85V in spl_board_init().

Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210604163043.12811-5-a-govindraju@ti.com

arm: mach-k3: am642_init: Do USB fixups to facilitate host and device boot modes

U-Boot either supports USB host or device mode for a node at a time in the
device tree nodes. To support both host and dfu bootmodes, dr_mode is set
to "peripheral" by default and then fixed based on the mode selected by
the boot mode config dip switches on the board.

This needs to happen before the cdns3 generic layer binds the usb device
to a host or a device driver. Therefore, use fdtdec_setup_board()
implementation to fixup the device tree property.

Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210604163043.12811-4-a-govindraju@ti.com

arm: mach-k3: am642_init: Add support for USB boot mode

Add support for identifying USB host and device boot modes

Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210604163043.12811-3-a-govindraju@ti.com

tools: k3_fit_atf: Add support for providing ATF load address using a Kconfig symbol

Add support for providing ATF load address with a Kconfig symbol.

Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Suman Anna <s-anna@ti.com>
Link: https://lore.kernel.org/r/20210604163043.12811-2-a-govindraju@ti.com

arm: dts: k3-j7200: ddr: Update to 0.5.0 version of DDR for LPDDR 2666MTs

Update the ddr settings to use the DDR reg config tool rev 0.5.0.
This enables 2666MTs LPDDR configuration on J7200.

Signed-off-by: Kevin Scholz <k-scholz@ti.com>
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Tested-by: Suman Anna <s-anna@ti.com>
Link: https://lore.kernel.org/r/20210603131453.11414-1-praneeth@ti.com

Merge branch '2021-06-08-kconfig-migrations' into next

- Migrate TFTP_SIZE and SYS_DFU_DATA_BUF_SIZE to Kconfig

usb: dfu: Migrate CONFIG_SYS_DFU_DATA_BUF_SIZE and CONFIG_SYS_DFU_MAX_FILE_SIZE to Kconfig

Currently the config options CONFIG_SYS_DFU_DATA_BUF_SIZE and
CONFIG_SYS_DFU_MAX_FILE_SIZE are being set in include/configs/<board>.h
files and also in <board_name>_defconfig files without a Kconfig option. It
is easier for users to set these configs in defconfig files than in config
header files as they are a part of the source code.

Add Kconfig symbols, and update the defconfigs by using tools/moveconfig.py
script.

Suggested-by: Pratyush Yadav <p.yadav@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Acked-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
Acked-by: Matthias Brugger <mbrugger@suse.com>
Acked-by: Lukasz Majewski <lukma@denx.de>

net: convert TFTP_TSIZE to proper Kconfig option

TFTP transfer size can be used to re-size the TFTP progress bar on
single line based on the server reported file size. The support for
this has been around from 2019, but it was never converted to proper
Kconfig.

While adding this new Kconfig, enable it by default for OMAP2+ and K3
devices also.

Signed-off-by: Tero Kristo <kristo@kernel.org>

Merge branch '2021-06-08-display-and-logging-updates' into next

To quote Simon, first for the display changes:
At present we have two ways of showing a hex dump. Once has been in
U-Boot since the dawn of time and the other was recently added from
Linux.

They both have their own unique features.

This series makes a few changes to bring them closer together. It also
adds support for logging a buffer, which is useful since it can put it
through the same log drivers as other logging output.

Also it adds tests, so we can check the behaviour.

And then the logging changes:
At present when logging is not enabled, all log() calls become nops.
This does not seem right, since if the log level is high enough then
there should be some sort of message. So in that case, this series
updates it to print the message if the log level is above LOGL_INFO.

This mimics the behaviour for the log_...() macros like log_debug() and
log_info(), so we can drop the special case for these.

Also the current implementation does not support multiple log calls on
the same line nicely. The tags are repeated so the line is very hard to
read.  This series adds that as a new feature.

log: Convert log values to printf() if not enabled

At present if logging not enabled, log_info() becomes a nop. But we want
log output at the 'info' level to be akin to printf(). Update the macro to
pass the output straight to printf() in this case.

This mimics the behaviour for the log_...() macros like log_debug() and
log_info(), so we can drop the special case for these.

Add new tests to cover this case.
Signed-off-by: Simon Glass <sjg@chromium.org>

sandbox: log: Avoid build error with !CONFIG_LOG

The pr_cont_test.c test requires CONFIG_LOG since it directly accesses
fields in global_data that require it. Move the test into the CONFIG_LOG
condition to avoid build errors.

Enable CONFIG_LOG on sandbox (not sandbox_spl, etc.) so that we still run
this test. This requires resyncing of the configs.

Signed-off-by: Simon Glass <sjg@chromium.org>

log: Add support for logging a buffer

The print_buffer() function is very useful for debugging. Add a version
of this in the log system also.

Signed-off-by: Simon Glass <sjg@chromium.org>

display_options: Split print_buffer() into two functions

At present print_buffer() outputs a hex dump but it is not possible to
place this dump in a string. Refactor it into a top-level function which
does the printing and a utility function that dumps a line into a string.
This makes the code more generally useful.

Signed-off-by: Simon Glass <sjg@chromium.org>

hexdump: Allow ctrl-c to interrupt output

If a long hexdump is initated the user may wish to interrupt it. Add
support for this.

Signed-off-by: Simon Glass <sjg@chromium.org>

hexdump: Support any rowsize

At present print_hex_dump() only supports either 16- or 32-byte lines.
With U-Boot we want to support any line length up to a maximum of 64.
Update the function to support this, with 0 defaulting to 16, as with
print_buffer().

Signed-off-by: Simon Glass <sjg@chromium.org>

hexdump: Add support for sandbox

The current implementation outputs an address as a pointer. Update the
code to use an address instead, respecting the 32/64 nature of the CPU.

Add some initial tests copied from print_test_display_buffer(), just the
ones that can pass with the current implementation.

Note that for this case print_hex_dump() and print_bufffer() produce the
same result. For now the tests are duplicated sine we have separate
functions.

Signed-off-by: Simon Glass <sjg@chromium.org>

hexdump: Move API to header file

Move the comments to the header file so people can find the function info
without digging in the implementation. Fix up the code style and add an
enum for the first arg.

Signed-off-by: Simon Glass <sjg@chromium.org>

display_options: Drop two spaces before the ASCII column

At present with print_buffer() U-Boot shows four spaces between the hex
and ASCII data. Two seems enough and matches print_hex_dump(). Change it.

Signed-off-by: Simon Glass <sjg@chromium.org>

test: Add a test for print_buffer()

Add a test for this function, to cover the various features. Expand the
expect_str length to take acount of the ~300-bytes lines generated in one
case.

Signed-off-by: Simon Glass <sjg@chromium.org>

test: Convert print tests to use ut framework

This test predates the test framework in U-Boot. It uses #define DEBUG and
assert() to check the result. Update it to use the framework so it can
report failure constitent with other tests.

Signed-off-by: Simon Glass <sjg@chromium.org>

test: Detect when expect_str is too small

If a line of more than 256 bytes is generated, the test will fail but the
reason is not clear. Add a check for this condition and print a helpful
message.

Signed-off-by: Simon Glass <sjg@chromium.org>

console: Report an error when output buffer is exhausted

If the console output buffer is exhausted, characters are silently dropped
from the end. Detect this condition and report an error when reading back
the characters.

Signed-off-by: Simon Glass <sjg@chromium.org>

Merge branch '2021-06-07-arm-cache-cp15-improvements' into next

To quote the series author, Patrick Delaunay:

On STM32MP15x platform we can use OP-TEE, loaded in DDR in a region
protected by a firewall. This region is reserved in the device with
the "no-map" property as defined in the binding file
doc/device-tree-bindings/reserved-memory/reserved-memory.txt.

Sometime the platform boot failed in U-Boot on a Cortex A7 access to
this region (depending of the binary and the issue can change with compiler
version or with code alignment), then the firewall raise an error,
for example:

E/TC:0   tzc_it_handler:19 TZC permission failure
E/TC:0   dump_fail_filter:420 Permission violation on filter 0
E/TC:0   dump_fail_filter:425 Violation @0xde5c6bf0, non-secure privileged read,
         AXI ID 5c0
E/TC:0   Panic

After investigation, the forbidden access is a speculative request performed
by the Cortex A7 because all the DDR is mapped as MEMORY with CACHEABLE
property.

The issue is solved only when the region reserved by OP-TEE is no more
mapped in U-Boot as it is already done in Linux kernel.

Tested on DK2 board with OP-TEE 3.12 / TF-A 2.4:

With hard-coded address for OP-TEE reserved memory,
the error doesn't occur.

 void dram_bank_mmu_setup(int bank)
 {
 ....

     for (i = start >> MMU_SECTION_SHIFT;
       i < (start >> MMU_SECTION_SHIFT) + (size >> MMU_SECTION_SHIFT);
       i++) {
  option = DCACHE_DEFAULT_OPTION;
  if (i >= 0xde0)
  option = INVALID_ENTRY;
  set_section_dcache(i, option);
  }
 }

Just by modifying the test on 0xde0 to 0xdf0, the OP-TEE memory protected
by firewall is mapped cacheable and the error occurs.

I think that it can be a general issue for ARM architecture: the "no-map" tag
of reserved memory in device should be respected by U-Boot if firewall
is configured before U-Boot execution.

But I don't propose a generic solution in
arm/lib/cache-cp15.c:dram_bank_mmu_setup()
because the device tree parsing done in lmb_init_and_reserve() takes a
long time when it is executed without data cache.

stm32mp: don't map the reserved region with no-map property

No more map the reserved region with "no-map" property by marking
the corresponding TLB entries with invalid entry (=0) to avoid
speculative access.

The device tree parsing done in lmb_init_and_reserve() takes a
long time when it is executed without data cache, so it is called in
enable_caches() before to disable it.

This patch fixes an issue where predictive read access on secure DDR
OP-TEE reserved area are caught by firewall.

  Series-cc: marex
  Series-cc: pch
  Series-cc: marek.bykowski@gmail.com
  Series-cc: Ard Biesheuvel <ardb@kernel.org>
  Series-cc: Etienne Carriere <etienne.carriere@linaro.org>

Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

stm32mp: Increase the reserved memory in board_get_usable_ram_top

Add 8M for the U-Boot reserved memory (display, fdt, gd, ...)
mapped cacheable before relocation.

Without this patch the device tree, located before the MALLOC area
is not tagged cacheable just after relocation, before mmu reconfiguration.

This patch reduces the duration for device tree parsing in
lmb_init_and_reserve.

Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

image-fdt: save no-map parameter of reserve-memory

Save the 'no-map' information present in 'reserved-memory' node to allow
correct handling when the MMU is configured in board to avoid
speculative access.

This binding is defined in
doc/device-tree-bindings/reserved-memory/reserved-memory.txt

Additional properties:
...
no-map (optional) - empty property
    - Indicates the operating system must not create a virtual mapping
      of the region as part of its standard mapping of system memory,
      nor permit speculative access to it under any circumstances other
      than under the control of the device driver using the region.

Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

test: lmb: add test for lmb_reserve_flags

Add a test to check the management of reserved region with flags.

Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

lmb: add lmb_dump_region() function

Add lmb_dump_region() function, to simplify lmb_dump_all_force().
This patch is based on Linux memblock dump function.

An example of bdinfo output is:

.....
fdt_size    = 0x000146a0
FB base     = 0xfdd00000
lmb_dump_all:
 memory.cnt  = 0x1
 memory[0] [0xc0000000-0xffffffff], 0x40000000 bytes flags: 0
 reserved.cnt  = 0x6
 reserved[0] [0x10000000-0x10045fff], 0x00046000 bytes flags: 4
 reserved[1] [0x30000000-0x3003ffff], 0x00040000 bytes flags: 4
 reserved[2] [0x38000000-0x3800ffff], 0x00010000 bytes flags: 4
 reserved[3] [0xe8000000-0xefffffff], 0x08000000 bytes flags: 4
 reserved[4] [0xfbaea344-0xfdffffff], 0x02515cbc bytes flags: 0
 reserved[5] [0xfe000000-0xffffffff], 0x02000000 bytes flags: 4
arch_number = 0x00000000
TLB addr    = 0xfdff0000
....

Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

lmb: add lmb_is_reserved_flags

Add a new function lmb_is_reserved_flags to check if
an address is reserved with a specific flags.

This function can be used to check if an address was
reserved with no-map flags with:

lmb_is_reserved_flags(lmb, addr, LMB_NOMAP);

Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

lmb: Add support of flags for no-map properties

Add "flags" in lmb_property to save the "no-map" property of
reserved region and a new function lmb_reserve_flags() to check
this flag.

The default allocation use flags = LMB_NONE.

The adjacent reserved memory region are merged only when they have
the same flags value.

This patch is partially based on flags support done in Linux kernel
mm/memblock .c (previously lmb.c); it is why LMB_NOMAP = 0x4, it is
aligned with MEMBLOCK_NOMAP value.

Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Prepare v2021.07-rc4

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

configs: Resync with savedefconfig

Rsync all defconfig files using moveconfig.py

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

Merge tag 'u-boot-rockchip-20210606' of https://source.denx.de/u-boot/custodians/u-boot-rockchip

Merge tag 'dm-pull-6jun21' of https://source.denx.de/u-boot/custodians/u-boot-dm

Minor fixes for sandbox and handling of dm-ranges

Merge tag 'video-for-2021-07-rc3' of https://source.denx.de/u-boot/custodians/u-boot-video

 - disable legacy video for brxre1, mx28evk, pico-imx6ul,
   pxm2 and rut boards after DM_VIDEO conversion deadline

test: add dm_test_read_resource

Add a test of dev_read_resource with translation or without translation

Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

net: luton: remove address translation after ofnode_read_resource

Removed call of ofnode_translate_address() after ofnode_read_resource
in luton_switch.c:luton_probe(); it is unnecessary since
the commit feb7ac457c20 ("dm: core: Add address translation in
fdt_get_resource").

Fixes: feb7ac457c20 ("dm: core: Add address translation in fdt_get_resource")
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Reported-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

pwm: cros_ec: Rename "priv_auto_alloc_size" to "priv_auto"

With commit 41575d8e4c33 ("dm: treewide: Rename auto_alloc_size members
to be shorter") "priv_auto_alloc_size" was renamed to "priv_auto". This
driver was sent to the mailing list before that change, merged after it,
and still has the old form. Apply the rename here as well.

Fixes: 1b9ee2882e6b ("pwm: Add a driver for Chrome OS EC PWM")
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

sandbox: correct determination of the text base

os_find_text_base() assumes that first line of /proc/self/maps holds
information about the text. Hence we must call the function before calling
os_malloc() which calls mmap(0x10000000,).

Failure to do so has led to incorrect values for pc_reloc when an
exception was reported

    => exception undefined

    Illegal instruction
    pc = 0x5628d82e9d3c, pc_reloc = 0x5628c82e9d3c

as well as incorrect output of the bdinfo command

    => bdinfo
    relocaddr   = 0x0000000007858000
    reloc off   = 0x0000000010000000

Fixes: b308d9fd18fa ("sandbox: Avoid using malloc() for system state")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>