R5 image building is not yet implemented using Binman. Don't select
CONFIG_BINMAN for R5 build. This should fix boot on AM64 HS.
Fixes: 7650825383 ("k3-am642-evm-u-boot: Use binman to generate u-boot.img and tispl.bin")
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Add cdns,phy-mode tag in the OSPI NOR flash device tree node to disable
initial read delay calibration and use the read delay value from the device
tree node, during initialization.
Fixes: f8c841752104 ("arm64: dts: k3-j721s2: Add support for OSPI Flashes")
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
As the size of tiboot3.bin has increased, the memory layout of the
bootloaders in eMMC and OSPI have been changed to accommodate this.
Therefore, use the dfu environment variables of combined images instead.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
The current size of tiboot3.bin with GP configs is 548KB and the memory
reserved for it in the OSPI flash is 512KB. This leads to overlap of
tiboot3.bin on tispl.bin region and break in OSPI boot mode.
Therefore, fix this by increasing the memory allocated for tiboot3.bin to
1MB.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
The current size of tiboot3.bin with GP configs is 548KB and the memory
reserved for it in eMMC boot partition is 512KB. This leads to overlap of
tiboot3.bin over tispl.bin region and break in eMMC boot mode.
Therefore, fix this by increasing the memory allocated for tiboot3.bin
to 1MB.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
commit 19f7a34a46 upstream.
Add support for enumerating MMC card in a given mode using mmc rescan and
mmc dev commands. The speed mode is provided as the last argument in these
commands and is indicated using the index from enum bus_mode in
include/mmc.h. A speed mode can be set only if it has already been enabled
in the device tree.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Re-enable the ESM driver and this goes along with the patch to enabling
the MCU ESM error reset in MCU control MMR register, after clearing the
main and mcu ESM events on bootup.
This reverts commit ebc8dca63d.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Enable MCUESM error output in MCU reset control register
CTRLMMR_MCU_RST_CTRL, after the Main and MCU ESM events
are cleared on bootup and configured to route the Main ESM
error output to the MCUESM error output.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
The ESM for AM64x HS is currently broken. Revert this patch till the ESM
support is fixed for HS.
This reverts commit ba2e5bd756.
Signed-off-by: Yogesh Siraswar <yogeshs@ti.com>
Configure CTRLMMR_MCU_RST_CTRL register only, when the R5 SPL is built
with CONFIG_ESM_K3 flag is set in the board configuration.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Add support to detect daughtercards (GESI Ethernet card) in-order
to set the MAC address of the main CPSW2G interface.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Correct the min/max voltages of VDD_CPU. As per data sheet the VDD_CPU
minimum voltage is .6V & maximum voltage is .9V.
Correct the same. While at it fix the comment to reflect VDD_CPU
instead of VDD_MPU.
Data Sheet Link: https://www.ti.com/lit/gpn/dra829v
Signed-off-by: Keerthy <j-keerthy@ti.com>
The A72 U-Boot code loads and boots a number of remote processors
including the C71x 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.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Add aliases for remote procs and support for early boot of remote
processors from A72 u-boot. The remote proc device nodes and shared
memory allocations for IPC and external memory also match with the
kernel device node definitions.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
The J721S2 SoCs have 3 dual-core Arm Cortex-R5F processor (R5FSS)
subsystems/clusters. One R5F cluster is present within the MCU
domain (MCU_R5FSS0), and the other one is present within the MAIN
domain (MAIN_R5FSS0/1). 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). The TCMs of both Cores are combined in LockStep-mode
to provide a larger 128 KB of memory.
Add the DT node for the MAIN domain R5F cluster/subsystems, the two
R5F cores are added as child nodes to a main cluster/subsystem node.
The clusters are 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: Hari Nagalla <hnagalla@ti.com>
The J721S2 SoCs have 3 dual-core Arm Cortex-R5F processor (R5FSS)
subsystems/clusters. One R5F cluster is present within the MCU
domain (MCU_R5FSS0), and the other one is present within the MAIN
domain (MAIN_R5FSS0/1). 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). The TCMs of both Cores are combined in LockStep-mode
to provide a larger 128 KB of memory.
Add the DT node for the MAIN domain R5F cluster/subsystems, the two
R5F cores are added as child nodes to a main cluster/subsystem node.
The clusters are 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.
The J721S2 SoCs have two TMS320C71x DSP Subsystems in the MAIN
voltage domain containing the next-generation C711 CPU core.
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 these DSP processor sub-systems in the common
k3-j721s2-main.dtsi file.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
The K3 J721S2 SoCs have two C71x DSP subsystems in MAIN voltage domain,
and there are no C66x DSP subsystems on these SoCs. The C71x DSP subsystem
is a slighly updated version of the C71x DSP subsystem on J721e. The
C71x DSPs are 64 bit machine with fixed and floating point DSP
operations.
Extend support to the C71x DSPs with J721S2 compatible strings.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
The K3 J721S2 SoCs have three dual-core R5F subsystems, one in MCU
voltage domain and the other two in MAIN voltage domain. These R5F
clusters are similar to the R5F clusters in J7200 SoCs.
Compatible Info is updated to support J721S2 SoCs.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
The TI K3 J721S2 SoCs have two TM320C71x DSP susbsystems, and does not
have any TMS320C66x DSP subsystems. The C71x DSP subsystems in J721S2
SoCs are similar to the C71x DSP on J721E with some minor core IP
updates.
Compatible info is updated for intuitively matching to the new J721S2
SoCs.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
The TI K3 J721S2 SoCs have three dual-core Arm R5F clusters/subsystems.
One in MCU voltage domain and the other two in MAIN voltage domain.
These clusters are similar to J7200 R5F clusters. Compatible info is
updated for intuitively matching to the new J721S2 SoCs.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Fix the Product ID used by the USB driver.
Fixes: 33008be54b8d ("configs: j721s2_evm_a72_defconfig: Add A72 specific defconfig")
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
am64-sk EVM doesn't support daughtercards so let's restrict
daughtercard probing to am64-gp EVM only.
Gets rid of below message at boot on am64-sk EVM
"Failed to lookup gpio gpio@38_0: -22"
Reported-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Roger Quadros <rogerq@kernel.org>
After moving to binman image builds we need to include
the appropriate binman file in the k3-am642-sk-u-boot.dtsi
Fixes: 7650825383 ("k3-am642-evm-u-boot: Use binman to generate u-boot.img and tispl.bin")
Suggested-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Upstream uses $BL31 for ATF blob and will use $BL32 for OP-TEE OS blob.
Since our Yocto build scripts and most of the developer build scripts
pass $ATF and $TEE, we continue to support those if provided.
Their usage should be deprecated. We can then drop this patch once
migration to $BL31 and $BL32 is done.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Introduce k3-am642-evm-binman.dtsi to provide binman configuration.
Provide a third configuration for AM64 EVM with NAND card.
R5 build is still not converted to use binman so restrict binman.dtsi
to A53 build.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Add an entry for OP-TEE Trusted OS 'BL32' payload.
This is required by platforms using Cortex-A cores with TrustZone
technology.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Enable configuration required for NAND support on R5 SPL.
We need CONFIG_SOC_DEVICE_TI_K3 to detect the SoC
and apply SoC specific quirks.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Provide NAND device and NAND driver configuration for AM64x EVM.
We are currently using raw NAND partitions for tispl.bin (A53 SPL)
and u-boot.img (A53 u-boot).
Signed-off-by: Roger Quadros <rogerq@kernel.org>
The current way it is implemented chipid node is overridden
in the k3-am642-sk-u-boot.dtsi, losing compatible and other
properties of the chipid node defined in k3-am64-main.dtsi
We simply need to use a label and add "u-boot,dm-spl" property
in k3-am642-sk-u-boot.dtsi.
Fixes: cf26b081da9d ("arm: dts: am642-sk: Add initial sk dts")
Signed-off-by: Roger Quadros <rogerq@kernel.org>
The current way it is implemented chipid node is overridden
in the k3-am642-evm-u-boot.dtsi, losing compatible and other
properties of the chpid node defined in k3-am64-main.dtsi
We simply need to use a label and add "u-boot,dm-spl" property
in k3-am642-evm-u-boot.dtsi.
Fixes: 2c91701ba0 ("arm: dts: k3-am64-evm: Make chip id available before pre-reloc")
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Add NAND support for A53 SPL, u-boot and R5 SPL.
For A53 SPL & u-boot we use NAND overlay to add NAND support.
For R5 SPL, we include the NAND support in the board DTS file
(k3-am642-r5-evm.dts) as there is no way to use overlay in
BootROM at the moment.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Since we are using overlay for A53 SPL and A53 u-boot the
SPL must select the NAND overlay from the FIT image if
HSE card is present.
For simplicity sake, we only check if a card is present or not in
the HSE (High Speed Expansion) slot to determine if we need to
use NAND overlay.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Adds driver model support.
We need to be able to self initialize the NAND controller/chip
at probe and so enable CONFIG_SYS_NAND_SELF_INIT.
Doing so requires nand_register() API which is provided by nand.c
and needs to be enabled during SPL build via CONFIG_SPL_NAND_INIT.
But nand.c also provides nand_init() so we need to get rid of nand_init()
in omap_gpmc driver if CONFIG_SPL_NAND_INIT is set.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Allocate omap_ecclayout on the heap as we have
limited .bss space on AM64 R5 SPL configuration.
Reduces .bss usage by 2984 bytes.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Support NAND SPL loader. We rely on nand_base driver for
detecting the NAND chip, bad block detection and read page.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Fixes the below build warning on 64-bit platforms.
drivers/mtd/nand/raw/nand_spl_loaders.c:26:21: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
dst = (void *)((int)dst - page_offset);
Signed-off-by: Roger Quadros <rogerq@kernel.org>
nand_bbt.c is not being built with the nand_base driver during SPL
build. This results in build failures if we try to access any nand_bbt
related functions.
Don't use any nand_bbt functions for SPL build.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
The BCH detection hardware can generate ECC bytes for multiple
sectors in one go. Use that feature.
correct() only corrects one sector at a time so we need to call it
repeatedly for each sector.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
GPMC is the parent of NAND controller. It needs to be probed
before NAND can work. Use uclass_get_device_by_driver() to
get and activate the GPMC driver.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Some SoCs have a limitation where GPMC reads cannot be less than
32-bits. Add workaround for such SoCs.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Rename omap_nand_read() to omap_nand_read_buf() to reflect
actual behaviour.
Use FIFO read address instead of raw read address for reads.
The GPMC automatically converts 32-bit/16-bit reads to NAND
device specific reads (8/16 bit). Use the largest possible
read granularity size for more efficient reads.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
In certain cases e.g. readid, only lower 8 I/O bits are used.
So for 16-bit devices we need to ensure that the read_buf function
skips the upper 8 I/O bits when returning data.
Provide a 'force_8bit' flag to the read_buf() hook to allow
for that.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Some platforms (e.g. TI AM64) have a limitation that 8-bit
and 16-bit reads do not behave correctly. We need to force 32-bit
reads on such platforms.
Try to use read_buf() ops as much as possible as platform driver
can take care of the quirk. For other places where we cannot use
read_buf() use the quirk flag to limit to 32-bit read.
There are still 2 places where read_byte/read_word is still in use
- nand_block_bad()
- nand_status_op()
A more proper fix will be to move to exec_op() like interface in
the kernel. But for now that might be an overkill.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
The omap_elm driver still uses ELM_BASE macro to know the ELM module's
base address. Define it for am642 platform.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Roger Quadros
Aswath Govindraju
Hari Nagalla
Yogesh Siraswar
Kishon Vijay Abraham I
Keerthy