Add a new file include/environment/ti/k3_rproc.h that defines
common environment variables useful for booting various remote
processors from U-Boot. This file is expected to be included in
the board config files with the EXTRA_ENV_RPROC_SETTINGS added
to CONFIG_EXTRA_ENV_SETTINGS and DEFAULT_RPROCS macro overwritten
to include the actual list of processors to be booted.

The 'boot_rprocs' variable just needs to be added to the board's
bootcmd to automatically boot the processors, and runtime control
can be achieved through the 'dorprocboot' variable.

The variables are currently defined to use MMC as the boot media,
and can be expanded in the future to include other boot media.
The immediate usage is intended for K3 J721E SoCs.
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
Signed-off-by: NSuman Anna <s-anna@ti.com>

The AM65x SoCs has a single dual-core Arm Cortex-R5F processor
subsystem/cluster (MCU_R5FSS0) within the MCU domain. This cluster
can be configured at boot time to be either run in a LockStep mode
or in an Asymmetric Multi Processing (AMP) fashion in Split-mode.
This subsystem has 64 KB each Tightly-Coupled Memory (TCM) internal
memories for each core split between two banks - ATCM and BTCM
(further interleaved into two banks). There are some IP integration
differences from standard Arm R5 clusters such as the absence of
an ACP port, presence of an additional TI-specific Region Address
Translater (RAT) module for translating 32-bit CPU addresses into
larger system bus addresses etc.

Add the DT node for the MCU domain R5F cluster/subsystem, the two
R5 cores are added as child nodes to the main cluster/subsystem node.
The cluster is configured to run in Split-mode by default, with the
ATCMs enabled to allow the R5 cores to execute code from DDR with
boot-strapping code from ATCM. The inter-processor communication
between the main A72 cores and these processors is achieved through
shared memory and Mailboxes.
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

The J721E SoCs have a single TMS320C71x DSP Subsystem in the MAIN
voltage domain containing the next-generation C711 CPU core. The
subsystem has 32 KB of L1D configurable SRAM/Cache and 512 KB of
L2 configurable SRAM/Cache. This subsystem has a CMMU but is not
used currently. The inter-processor communication between the main
A72 cores and the C711 processor is achieved through shared memory
and a Mailbox. Add the DT node for this DSP processor sub-system
in the common k3-j721e-main.dtsi file.
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

The J721E SoCs have two TMS320C66x DSP Core Subsystems (C66x CorePacs)
in the MAIN voltage domain, each with a C66x Fixed/Floating-Point DSP
Core, and 32 KB of L1P & L1D configurable SRAMs/Cache and an additional
288 KB of L2 configurable SRAM/Cache. These subsystems do not have
an MMU but contain a Region Address Translator (RAT) sub-module for
translating 32-bit processor addresses into larger bus addresses.
The inter-processor communication between the main A72 cores and
these processors is achieved through shared memory and Mailboxes.
Add the DT nodes for these DSP processor sub-systems in the common
k3-j721e-main.dtsi file.
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

The J721E SoCs have 3 dual-core Arm Cortex-R5F processor (R5FSS)
subsystems/clusters. One R5F cluster (MCU_R5FSS0) is present within
the MCU domain, and the remaining two clusters are present in the
MAIN domain (MAIN_R5FSS0 & MAIN_R5FSS1). Each of these can be
configured at boot time to be either run in a LockStep mode or in
an Asymmetric Multi Processing (AMP) fashion in Split-mode. These
subsystems have 64 KB each Tightly-Coupled Memory (TCM) internal
memories for each core split between two banks - ATCM and BTCM
(further interleaved into two banks). There are some IP integration
differences from standard Arm R5 clusters such as the absence of
an ACP port, presence of an additional TI-specific Region Address
Translater (RAT) module for translating 32-bit CPU addresses into
larger system bus addresses etc.

Add the DT nodes for these two MAIN domain R5F cluster/subsystems,
the two R5 cores are each added as child nodes to the corresponding
main cluster node. Configure SS0 in split mode an SS1 in lockstep mode,
with the ATCMs enabled to allow the R5 cores to execute code from DDR
with boot-strapping code from ATCM.
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

The J721E SoCs have 3 dual-core Arm Cortex-R5F processor (R5FSS)
subsystems/clusters. One R5F cluster (MCU_R5FSS0) is present within
the MCU domain, and the remaining two clusters are present in the
MAIN domain (MAIN_R5FSS0 & MAIN_R5FSS1). Each of these can be
configured at boot time to be either run in a LockStep mode or in
an Asymmetric Multi Processing (AMP) fashion in Split-mode. These
subsystems have 64 KB each Tightly-Coupled Memory (TCM) internal
memories for each core split between two banks - ATCM and BTCM
(further interleaved into two banks). There are some IP integration
differences from standard Arm R5 clusters such as the absence of
an ACP port, presence of an additional TI-specific Region Address
Translater (RAT) module for translating 32-bit CPU addresses into
larger system bus addresses etc.

Add the DT node for the MCU domain R5F cluster/subsystem, the two
R5 cores are added as child nodes to the main cluster/subsystem node.
The cluster is configured to run in LockStep mode by default, with the
ATCMs enabled to allow the R5 cores to execute code from DDR with
boot-strapping code from ATCM. The inter-processor communication
between the main A72 cores and these processors is achieved through
shared memory and Mailboxes.
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

Certain SoCs with K3 architecture have integrated a C66 Corepac DSP
subsystem and an advanced C71 DSPs. Introduce a remoteproc driver
that that does take care of loading an elf to any of the specified
DSPs and start it.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NSuman Anna <s-anna@ti.com>

Some Texas Instruments K3 family of SoCs have one of more Digital Signal
Processor (DSP) subsystems that are comprised of either a TMS320C66x
CorePac and/or a next-generation TMS320C71x CorePac processor subsystem.
Add the device tree bindings document for the C66x DSP devices on these
SoCs. The added example illustrates the DT nodes for the first C66x DSP
device present on the K3 J721E family of SoCs.
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

SoCs with K3 architecture have an integrated Arm Cortex-R5F subsystem
that is comprised of dual-core Arm Cortex-R5F processor cores. This R5
subsytem can be configured at boot time to be either run in a LockStep
mode or in an Asymmetric Multi Processing (AMP) fashion in Split-mode.
This subsystem has each Tightly-Coupled Memory (TCM) internal memories
for each core split between two banks - TCMA and TCMB.

Add a remoteproc driver to support this subsystem to be able to load
and boot the R5 cores primarily in LockStep mode or split mode.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NSuman Anna <s-anna@ti.com>

The Texas Instruments K3 family of SoCs have one of more dual-core
Arm Cortex R5F processor subsystems/clusters (R5FSS). Add the device
tree bindings document for these R5F subsystem devices. These R5F
processors do not have an MMU, and so require fixed memory carveout
regions matching the firmware image addresses. The nodes require more
than one memory region, with the first memory region used for DMA
allocations at runtime. The remaining memory regions are reserved
and are used for the loading and running of the R5F remote processors.

The added example illustrates the DT nodes for the single R5FSS device
present on K3 AM65x family of SoCs.
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

Power domain for the remote cores needs to be handled in a right
sequence as mandated by the spec. Introduce tisci helper apis
that can control power-domains of remote cores. TISCI clients
can use this api and control the remote cores power domain instead
of hooking it to power-domain layer.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

Introduce rproc_elf_get_boot_addr() that returns the entry point of
the elf file. This api auto detects the 64/32 bit elf file and returns
the boot addr accordingly.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

Introduce a common remoteproc elf loader and checker functions that
automatically detects the 64 bit elf file or 32 bit elf file and
loads/checks the sections accordingly.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: NFabien Dessenne <fabien.dessenne@st.com>

The current rproc-elf-loader supports loading of only 32 bit elf files.
Introduce support for loading of 64 bit elf files in rproc-elf-loader.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: NFabien Dessenne <fabien.dessenne@st.com>

rproc_elf32_load_image() rely on user to send a valid address for elf loading.
Instead do a sanity check on the address passed by user. This will help
all rproc elf users to not call sanity_check explicitly before calling
elf_loading.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: NFabien Dessenne <fabien.dessenne@st.com>

Introduce a new parameter "size" that accepts size of the region to
remoteproc ops callback device_to_virt(). This can enforce more checks
on the region that device_to_virt() is dealing with.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Tested-by: NFabien Dessenne <fabien.dessenne@st.com>
Reviewed-by: NFabien Dessenne <fabien.dessenne@st.com>

Add a function to count the available children of a device.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>

am65x ROM support booting over UART. And U-Boot built for am65x EVM
supports UART boot as well. Add the UART boot procedure into the README
also providing a corresponding example command sequence for execution
on a host PC.
Signed-off-by: NAndreas Dannenberg <dannenberg@ti.com>

Activate early console functionality on AM654x devices to allow for an
alternate serial port to be used to support UART-based boot. This is so
that System Firmware (SYSFW) can get loaded over the serial port prior
to the main console being brought up and made available.
Signed-off-by: NAndreas Dannenberg <dannenberg@ti.com>

Although we currently use the MAIN_UART0 for R5 SPL console output there
are cases where we require access to the MCU_UART0 as well for example in
case of UART-based Y-Modem boot. To support these scenarios add related
DTS definitions to be able to use that UART early on.
Signed-off-by: NAndreas Dannenberg <dannenberg@ti.com>

In order to allow booting TI K3 family SoCs via Y-Modem add support for
loading System Firmware by tapping into the associated SPL core loader
function.

In this context also make sure a console is available and if not go
ahead and activate the early console feature which allows bringing up
an alternate full console before the main console is activated. Such
an alternate console is typically setup in a way that the associated
UART can be fully initialized prior to SYSFW services being available.
Signed-off-by: NAndreas Dannenberg <dannenberg@ti.com>

Implement an early console functionality in SPL that can be used before
the main console is being brought up. This helps in situations where the
main console is dependent on System Firmware (SYSFW) being up and running,
which is usually not the case during the very early stages of boot. Using
this early console functionality will allow for an alternate serial port
to be used to support things like UART-based boot and early diagnostic
messages until the main console is ready to get activated.
Signed-off-by: NAndreas Dannenberg <dannenberg@ti.com>

Expose SPL's Y-Modem core loader function via the common SPL header
file so it can be re-used for purposes other than loading U-Boot itself.
Signed-off-by: NAndreas Dannenberg <dannenberg@ti.com>

During FIT reading through ymodem_read_fit() the function
xyzModem_stream_read() is being used which returns zero once the end
of a stream has been reached. This could lead to an premature exit from
ymodem_read_fit() with certain-sized FIT images reporting that zero
bytes overall were read. Such a premature exit would then result in an
-EIO failure being triggered within the spl_load_simple_fit() caller
function and ultimately lead to a boot failure.

Fix this logic by simply aborting the stream read loops and continuing
with the regular code flow which ultimately would lead to returning
the number of bytes to be read ('size') as expected by the callers of
ymodem_read_fit().

Fixes: fa715193 ("spl: Add an option to load a FIT containing U-Boot from UART")
Signed-off-by: NAndreas Dannenberg <dannenberg@ti.com>

Xilinx/FPGA changes for v2020.01

FPGA:
- Enable fpga loading on Versal
- Minor fix

Microblaze:
- Fix LMB configurations to support initrds
- Some other cleanups

Zynq:
- Minor config/dt changes
- Add distro boot support for usb1 and mmc1
- Remove Xilinx private boot commands and use only distro boot

ZynqMP:
- Kconfig cleanups, defconfig updates
- Update some dt files
- Add firmware driver for talking to PMUFW
- Extend distro boot support for jtag
- Add new IDs
- Add system controller configurations
- Convert code to talk firmware via mailbox or SMCs

Versal:
- Add board_late_init()
- Add run time DT memory setup
- Add DFU support
- Extend distro boot support for jtag and dfu
- Add clock driver
- Tune mini configurations

Xilinx:
- Improve documentation (boot scripts, dt binding)
- Enable run time initrd_high calculation
- Define default SYS_PROMPT
- Add zynq/zynqmp virtual defconfig

Drivers:
- Add Xilinx mailbox driver for talking to firmware
- Clean zynq_gem for Versal
- Move ZYNQ_HISPD_BROKEN to Kconfig
- Wire genphy_init() in phy.c
- Add Xilinx gii2rgmii bridge
- Cleanup zynq_sdhci
- dwc3 fix
- zynq_gpio fix
- axi_emac fix

Others:
- apalis-tk1 - clean config file

Build the keystone 3 platforms with the keystone 2 platforms, in order
to get back more room in the "catch-all" build jobs.
Signed-off-by: NTom Rini <trini@konsulko.com>

As both "catch-all" ARM jobs are nearing their time limit, move all of
the bcm SoC boards into a single job.
Signed-off-by: NTom Rini <trini@konsulko.com>

u-boot-imx-20191009
-------------------

Travis : https://travis-ci.org/sbabic/u-boot-imx/builds/595148532

- MX6UL / ULZ
- Toradex board
- Allow to set OCRAM for MX6Q/D
- MX7ULP
- MX8: (container image, imx8mq_mek), SCU API
- fix several board booting from SD/EMMC (cubox-i for example)
- pico boards

[trini: display5 merged manually]
Signed-off-by: NTom Rini <trini@konsulko.com>

- Move WATCHDOG_TIMEOUT_MSECS to Kconfig (Heiko)

- Rename existing FSP code to fsp1
- Add fsp2 directory in preparation to support FSP 2.0
- Various x86 platform codes update
- Various bug fixes and updates in dm core, sandbox and spl

First set of u-boot-atmel features and fixes for 2020.01 cycle

The feature set includes support for two new boards from Microchip AT91:
The sama5d27_wlsom1_ek , an evaluation kit which includes the SAMA5D2
SOC packaged in a 256 MB LPDDR2 SIP, on a SOM including wireless, which
is placed on evaluation kit with sd-card, ethernet, LCD, Camera sensor,
QSPI, etc
The sam9x60ek, an evaluation kit for the new SoC based on ARM926j , the
SAM9X60 . The evaluation kit includes NAND flash, QSPI, Ethernet, Audio,
Camera sensor connector, etc.
The full support for sam9x60ek will come at a later time. There are
still missing bits regarding the clock support and power management
controller.

Pull request for UEFI sub-system for efi-2020-01-rc1

The major corrections in this pull request are:

Fixes for the SetVariable() boot service.
Device path node for NVMe drives.
Disable CONFIG_CMD_NVEDIT by default.

- Python3 conversion of genboardscfg.py
- Resync Kconfiglib.py
- Switch to running CI on Ubuntu "bionic" to facilitate Python 3.6 being
  the minimum we use and test.

To match what we're doing in GitLab, move to 'bionic' for these builds
as well.
Signed-off-by: NTom Rini <trini@konsulko.com>

In order to run all filesystem tests we need to have newer ext4 tools,
move up to Ubuntu 18.04 'bionic' for our base.  We need to change
slightly how we invoke the provided grub-mkimage.  This will also make
future python3 work easier.
Signed-off-by: NTom Rini <trini@konsulko.com>

When running as another user we might not be able to use '..' for
certain directories and this is the default for buildman.  Specify an
output directory instead.
Signed-off-by: NTom Rini <trini@konsulko.com>

We may not always be able to write to the default output directory so
have a temporary directory for our output be created.

Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: NStephen Warren <swarren@wwwdotorg.org>
Suggested-by: NStephen Warren <swarren@wwwdotorg.org>
Signed-off-by: NTom Rini <trini@konsulko.com>

With the reverting of a previous change to spl_boot_device,
this board needs a new solution to determining if we're booting
from MMC1 or MMC2.

This patch creates board_boot_order function which overrides the
standard, and returns not only MMC1, or MMC2, but also can fall
back to NAND or the serial downloader should other boot options
fail.
Signed-off-by: NAdam Ford <aford173@gmail.com>

Apologies to everyone whose board I broke by attempting to return
MMC1 or MMC2. I misunderstood how the MMC indexing worked.

This reverts commit 14d319b1.
Signed-off-by: NAdam Ford <aford173@gmail.com>

This reverts commit 34f2feb92db6146831bafa696b7b46785c9f6b10.
Signed-off-by: NStefano Babic <sbabic@denx.de>