Commit graph

60801 commits

Author SHA1 Message Date
Kursad Oney
9a3eddd263 spi: hsspi: allow to be used on bcm6858 and bcm63158
This IP exists in both MIPS and ARM cores, so we also
allow to use this driver on bcm6858 and bcm63158.

Signed-off-by: Kursad Oney <kursad.oney@broadcom.com>
Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
2019-10-11 10:09:16 -04:00
Lokesh Vutla
3d95fc523e board: j721e: Add README
Add README file explaining the build and boot procedure for J721E evm.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-10-11 10:07:59 -04:00
Kedar Chitnis
8bdd83ee50 armv8: K3: j721e: Updated ddr address regions in MMU table
The A72 U-Boot code loads and boots a number of remote processors
including the C71x DSP, both the C66_0 and C66_1 DSPs, and the various
Main R5FSS Cores. In order to view the code loaded by the U-Boot by
remote cores, U-Boot should configure the memory region with right
memory attributes. Right now U-Boot carves out a memory region which
is not sufficient for all the images to be loaded. So, increase this
carve out region by 256MB.

Signed-off-by: Kedar Chitnis <kedarc@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-10-11 10:07:59 -04:00
Suman Anna
60bdc6b9f3 armv8: K3: am65x: Update DDR address regions in MMU table
The A53 U-Boot code can load and boot the MCU domain R5F cores (either a
single core in LockStep mode or 2 cores in Split mode) to achieve various
early system functionalities. Change the memory attributes for the DDR
regions used by the remote processors so that the cores can see and
execute the proper code loaded by U-Boot.

These regions are currently limited to 0xa0000000 to 0xa2100000 as per
the DDR carveouts assigned for these R5F cores in the overall DDR memory
map.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-10-11 10:07:59 -04:00
Suman Anna
65b91b2f8c configs: am65x_evm_a53: Enhance bootcmd to start remoteprocs
The A53 U-boot can support early booting of the MCU R5F remote processor(s)
from U-boot prompt to achieve various system usecases before booting the
Linux kernel. Update the default BOOTCOMMAND to provide an automatic and
easier way to start the MCU R5F cores through added environment variables.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-10-11 10:07:59 -04:00
Suman Anna
9af139c17b configs: am65x_evm_a53: Enable R5F remoteproc driver
Enable the R5F remoteproc driver for the AM65x GP EVM so that the
MCU domain R5F cores can be booted from A53 U-boot.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-10-11 10:07:50 -04:00
Suman Anna
750dc1ed51 configs: j721e_evm_a72: Enhance bootcmd to start remoteprocs
The A72 U-boot can support early booting of any of the R5F or C66x
or C71x remote processors from U-boot prompt to achieve various system
usecases before booting the Linux kernel. Update the default BOOTCOMMAND
to provide an automatic and easier way to start various remote processors
through added environment variables.

Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
2019-10-11 10:07:50 -04:00
Lokesh Vutla
5b1185c15b configs: j721e_evm_a72: Enable R5F and DSP remoteproc driver
Enable R5F and DSP remoteproc drivers for j721e running on a72.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-10-11 10:07:35 -04:00
Suman Anna
b9bb1952c9 env: ti: am65x_evm: Add env support to boot the MCU R5F rprocs
Add support to boot the MCU domain R5F Core0 remoteproc at U-boot prompt
on the AM65x EVM boards by using the 'boot_rprocs' and other env variables
defined in the common environment file k3_rproc.h, and updating the
'DEFAULT_RPROCS' macro.

The default configuration is to use the MCU R5F in Split mode, so both
the R5F Core0 and Core1 are started before loading and booting the Linux
kernel using the following firmware:
   MCU R5FSS0 Core0 (Split) : 0 /lib/firmware/am65x-mcu-r5f0_0-fw
   MCU R5FSS0 Core1 (Split) : 1 /lib/firmware/am65x-mcu-r5f0_1-fw

The MCU R5FSS was initially running the R5 SPL in LockStep mode with ATCM
disabled, and is actually shutdown to enable it to be reconfigured and
booted by either A53 U-Boot or Linux kernel in remoteproc mode and using
ATCM.

The MCU R5FSS would need to be reconfigured for Lockstep mode through
DT if a fault-tolerant/safety application were to be run on the cluster
with the DEFAULT_RPROCS macro updated to remove the Core1 firmware.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-10-11 10:07:35 -04:00
Suman Anna
0b4ab9c9a7 env: ti: j721e-evm: Add support to boot rprocs including R5Fs and DSPs
Add support to boot some remoteprocs at U-boot prompt on the J721E EVM
boards by using the 'boot_rprocs' and other env variables defined in the
common environment file k3_rproc.h, and updating the 'DEFAULT_RPROCS'
macro.

The list of R5F cores to be started before loading and booting the Linux
kernel are as follows, and in this order:
   Main R5FSS0 (Split) Core1 : 3 /lib/firmware/j7-main-r5f0_1-fw
   Main R5FSS1 (LockStep)    : 4 /lib/firmware/j7-main-r5f1_0-fw

The MCU R5FSS0 and Main R5FSS1 are currently in LockStep mode, so the
equivalent Core1 rprocs (rproc #1 and #5) are not included. The Main
R5FSS0 Core0 (rproc #2) is already started by R5 SPL, so is not included
in the list either.

The DSP cores are started in the following order before loading and
booting the Linux kernel:
   C66_0: 6 /lib/firmware/j7-c66_0-fw
   C66_1: 7 /lib/firmware/j7-c66_1-fw
   C71_0: 8 /lib/firmware/j7-c71_0-fw

The order of the rprocs to boot can be changed at runtime if desired by
overwriting the 'rproc_fw_binaries' environment variable at U-boot prompt.

Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-10-11 10:07:35 -04:00
Suman Anna
bb17aaf658 env: ti: k3_rproc: Add common rproc environment variables
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: Jean-Jacques Hiblot <jjhiblot@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
2019-10-11 10:07:35 -04:00
Suman Anna
35f21c3ac6 arm: dts: k3-am65-mcu: Add MCU domain R5F DT nodes
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: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-10-11 10:07:35 -04:00
Lokesh Vutla
1b846fc24d arm: dts: k3-j721e-main: Add C71x DSP node
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: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-10-11 10:07:35 -04:00
Lokesh Vutla
293e39780d arm: dts: k3-j721e-main: Add C66x DSP nodes
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: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-10-11 10:07:35 -04:00
Lokesh Vutla
55f8eb3169 arm: dts: k3-j721e-main: Add MAIN domain R5F cluster nodes
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: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-10-11 10:07:35 -04:00
Lokesh Vutla
b9f035e9c8 arm: dts: k3-j721e-mcu: Add MCU domain R5F cluster node
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: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-10-11 10:07:34 -04:00
Lokesh Vutla
ab827b3857 remoteproc: Introduce K3 C66 and C71 remoteproc driver
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: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
2019-10-11 10:07:34 -04:00
Suman Anna
e18fb7dd5c dt-bindings: remoteproc: Add bindings for DSP C66x clusters on TI K3 SoCs
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: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-10-11 10:07:34 -04:00
Lokesh Vutla
4c850356a8 remoteproc: Introduce K3 remoteproc driver for R5F subsystem
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: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
2019-10-11 10:07:34 -04:00
Suman Anna
471c2d5e22 dt-bindings: remoteproc: Add bindings for R5F subsystem on TI K3 SoCs
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: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-10-11 10:07:34 -04:00
Lokesh Vutla
f7954828b8 remoteproc: tisci_proc: Add helper api for controlling core power domain
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: Lokesh Vutla <lokeshvutla@ti.com>
2019-10-11 10:07:34 -04:00
Lokesh Vutla
81e39fbd92 remoteproc: elf_loader: Introduce rproc_elf_get_boot_addr() api
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: Lokesh Vutla <lokeshvutla@ti.com>
2019-10-11 10:07:34 -04:00
Lokesh Vutla
856c0ad413 remoteproc: elf_loader: Introduce a common elf loader and checker functions
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: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Fabien Dessenne <fabien.dessenne@st.com>
2019-10-11 10:07:34 -04:00
Lokesh Vutla
e3c4d6f01f remoteproc: elf-loader: Add 64 bit elf loading support
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: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Fabien Dessenne <fabien.dessenne@st.com>
2019-10-11 10:07:34 -04:00
Lokesh Vutla
14d963d1b5 remoteproc: elf_loader: Always check the validity of the image before loading
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: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Fabien Dessenne <fabien.dessenne@st.com>
2019-10-11 10:07:34 -04:00
Lokesh Vutla
c08eb93626 remoteproc: ops: Add elf section size as input parameter to device_to_virt api
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: Lokesh Vutla <lokeshvutla@ti.com>
Tested-by: Fabien Dessenne <fabien.dessenne@st.com>
Reviewed-by: Fabien Dessenne <fabien.dessenne@st.com>
2019-10-11 10:07:33 -04:00
Lokesh Vutla
240b932010 dm: core: Add a function to count the children of a device
Add a function to count the available children of a device.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-10-11 10:07:33 -04:00
Andreas Dannenberg
bc74163a46 board: ti: am65x: Add UART boot procedure in README
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: Andreas Dannenberg <dannenberg@ti.com>
2019-10-11 10:07:33 -04:00
Andreas Dannenberg
b8cc99a48f configs: am65x_evm_r5: Activate early console functionality
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: Andreas Dannenberg <dannenberg@ti.com>
2019-10-11 10:07:33 -04:00
Andreas Dannenberg
20a229676e armv7R: dts: k3: am654: Add MCU_UART0 related definitions
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: Andreas Dannenberg <dannenberg@ti.com>
2019-10-11 10:07:33 -04:00
Andreas Dannenberg
921b325854 arm: K3: sysfw-loader: Allow loading SYSFW via Y-Modem
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: Andreas Dannenberg <dannenberg@ti.com>
2019-10-11 10:07:33 -04:00
Andreas Dannenberg
e630afe1de arm: K3: common: Allow for early console functionality
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: Andreas Dannenberg <dannenberg@ti.com>
2019-10-11 10:07:33 -04:00
Andreas Dannenberg
e413033d35 spl: ymodem: Make SPL Y-Modem loader framework accessible
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: Andreas Dannenberg <dannenberg@ti.com>
2019-10-11 10:07:33 -04:00
Andreas Dannenberg
9d6ee3e235 spl: ymodem: Fix FIT loading termination handling
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: fa715193c0 ("spl: Add an option to load a FIT containing U-Boot from UART")
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
2019-10-11 10:07:33 -04:00
Bin Meng
c443f56cc6 binman: Use qemu-x86_defconfig in the example
The doc currently uses sandbox_defconfig as examples of enabling
debug/verbose output of binman. However during a sandbox build it
does not call binman at all. Change it to qemu-x86_defconfig.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2019-10-11 17:37:44 +08:00
Simon Glass
d362a08817 x86: Reduce resetvec size
At present this produces a 16-byte file. It is intended to start 16 bytes
before the end of ROM and pads with zeroes to readh the end.

But binman sometimes wants to add an image-header at the very end of ROM.
Furthermore binman automatically pads the data if it is finishes early.

Drop the padding in resetvec and let binman handle it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
2019-10-11 17:37:38 +08:00
Simon Glass
b9e7c3370e x86: Drop RESET_SEG_SIZE
This is not used anywhere now, so drop it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
2019-10-11 17:37:34 +08:00
Simon Glass
fd0ef895b6 x86: Drop RESET_BASE
Since x86 users binman now, we don't need this compile-time define.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
2019-10-11 17:37:29 +08:00
Simon Glass
530bec93d6 x86: Update Kconfig options for FSP1
Many of the Kconfig options do not apply to FSP2. Update them to use the
FSP_VERSION1 condition instead.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
2019-10-11 17:37:19 +08:00
Simon Glass
ca4e40887e x86: Add a function to find the size of an mrccache record
Move the code to determine the size of a cache record into a function so
we can use it elsewhere in this file.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-10-11 17:37:19 +08:00
Simon Glass
9859dc76e7 trace: Remove the const from write functions
The write functions do actually change the contents of memory so it is not
correct to use 'const'. Remove it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-10-11 17:37:19 +08:00
Simon Glass
6498fda140 sandbox: pci: Remember the device being emulated
Add a field to the PCI emulator per-device data which records which device
is being emulated. This is useful when the emulator needs to check the
device for something.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
[bmeng: rebase the patch against u-boot-x86/master to get it applied cleanly]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
2019-10-11 17:37:15 +08:00
Simon Glass
3d95688c85 x86: Panic when SPL or TPL fail
At present when these fail to boot there is no message, just a hang. Add a
panic so it is obvious that something when wrong.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-10-11 16:45:05 +08:00
Yann Gautier
a8ef8b2289 mmc: stm32_sdmmc2: implement host_power_cycle callback
For the correct power cycle sequence with stm32_sdmmc2, the write of the
power cycle value in PWRCTL field of SDMMC_POWER register is now done in
stm32_sdmmc2_host_power_cycle() and no more in stm32_sdmmc2_pwrcycle().

Signed-off-by: Yann Gautier <yann.gautier@st.com>
2019-10-10 10:59:48 +08:00
Yann Gautier
3602a56ac6 mmc: add a driver callback for power-cycle
Some MMC peripherals require specific power cycle sequence, where some
registers need to be written between the regulator is turned off and then
back on. This is the case for the MMC IP embedded in STM32MP1 SoC.

In STM32MP157 reference manual [1], the power cycle sequence is:
1. Reset the SDMMC with the RCC.SDMMCxRST register bit. This will reset
the SDMMC to the reset state and the CPSM and DPSM to the Idle state.
2. Disable the Vcc power to the card.
3. Set the SDMMC in power-cycle state. This will make that the
SDMMC_D[7:0], SDMMC_CMD and SDMMC_CK are driven low, to prevent the card
from being supplied through the signal lines.
4. After minimum 1ms enable the Vcc power to the card.
5. After the power ramp period set the SDMMC to the power-off state for
minimum 1ms. The SDMMC_D[7:0], SDMMC_CMD and SDMMC_CK are set to
drive “1”.
6. After the 1ms delay set the SDMMC to power-on state in which the
SDMMC_CK clock will be enabled.
7. After 74 SDMMC_CK cycles the first command can be sent to the card.

The step 3. cannot be handled by the current framework implementation.
A new callback (host_power_cycle) is created, and called in
mmc_power_cycle(), after mmc_power_off().

The incorrect power cycle sequence has shown some boot failures on
STM32MP1 with some SD-cards, especially on cold boots when the input
frequency is low (<= 25MHz).
Those failures are no more seen with this correct power cycle sequence.

[1] https://www.st.com/resource/en/reference_manual/DM00327659.pdf

Signed-off-by: Yann Gautier <yann.gautier@st.com>
2019-10-10 10:59:48 +08:00
Arun Parameswaran
36645f45a0 drivers: mmc: Add sdhci driver for Broadcom iProc platform
Add SDHCI driver for iProc family of Broadcom devices.

Signed-off-by: Corneliu Doban <corneliu.doban@broadcom.com>
Signed-off-by: Pramod Kumar <pramod.kumar@broadcom.com>
Signed-off-by: Pavithra Ravi <pavithra.ravi@broadcom.com>
Signed-off-by: Bharat Kumar Reddy Gooty <bharat.gooty@broadcom.com>
Signed-off-by: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com>
Signed-off-by: Arun Parameswaran <arun.parameswaran@broadcom.com>
2019-10-10 10:59:48 +08:00
Lokesh Vutla
80f02019ee spl: dm_mmc: Initialize only the required mmc device
In SPL, all the available mmc devices gets initialized during boot.
This might not work in cases where clocks are not available for
certain mmc devices(other than boot device) and the support for
enabling device might not be ready.

Texas Instruments' K3 J721E device having a central system controller
(dmsc) is one such example falling in this category. Below is the
sequence for the failing scenario:
- ROM comes up in SD mode and loads SPL by just initialing SD card.
- SPL loads dmsc firmware from SD Card.
Since ROM has enabled SD, SPL need not enable the SD, just need
to re initialize the card. But SPL is trying to initialize other MMC
instances which are in disabled state. Since dmsc firmware is not yet
available, devices cannot be enabled. So in SPL, initialize only the
mmc device that is needed.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
2019-10-10 10:59:48 +08:00
Marek Vasut
e6281b8ab0 ARM: socfpga: vining_fpga: Extract eth1 MAC from EEPROM
The EEPROM contains eth1 MAC address as well, use it.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Silvio Fricke <silvio.fricke@softing.com>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
2019-10-09 22:57:41 +02:00
Marek Vasut
110861992f ARM: socfpga: vining_fpga: Update environment
Update board environment to match the one used in deployment.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Silvio Fricke <silvio.fricke@softing.com>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
2019-10-09 22:57:40 +02:00
Marek Vasut
76f0f01008 ARM: socfpga: vining_fpga: Update generated headers
Update headers generated by quartus to the latest version.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Silvio Fricke <silvio.fricke@softing.com>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
2019-10-09 22:54:18 +02:00