Add the DT nodes for the ICSSG0, ICSSG1 and ICSSG2 processor subsystems
that are present on the K3 AM65x SoCs. The three ICSSGs are identical
to each other for the most part, with the ICSSG2 supporting slightly
enhanced features for supporting SGMII PRU Ethernet. Each ICSSG instance
is represented by a PRUSS subsystem node. These nodes are enabled by
default.
DT nodes are fetch from Linux 5.10 Kernel.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
So far all the u-boot specific properties for both r5 and a53 are
placed in k3-am654-base-board-u-boot.dtsi. But there are few a53
nodes that should be updated but doesn't belong to r5. So create a
separate r5 specific u-boot dtsi.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
This is the extension to PRUSS Ethernet driver for TI AM654 SR1.0 SoC
with the ICSSG PRU Sub-system running EMAC firmware.
Following are the firmwares needed to run cores:
am65x-pru0-prueth-fw.elf for pru0 of slice0
am65x-rtu0-prueth-fw.elf for rtu0 of slice0
am65x-pru1-prueth-fw.elf for pru1 of slice1
am65x-rtu1-prueth-fw.elf for rtu1 of slice1
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
This is the PURSS Ethernet driver for TI AM654 Sr2.0 and laterSoCs
with the ICSSG PRU Sub-system running EMAC firmware.
This driver caters to either of the slices(pru/rtu pair)
of the icssg subsystem.
One and exactly one of the slices is supported
as the u-boot ethernet supports probing one interface
at a time.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
The K3 AM65x family of SoCs have the next generation of the PRU-ICSS
processor subsystem, commonly referred to as ICSSG. Each ICSSG processor
subsystem on AM65x SR1.0 contains two primary PRU cores and two new
auxiliary PRU cores called RTUs. The AM65x SR2.0 SoCs have a revised
ICSSG IP that is based off the subsequent IP revision used on J721E
SoCs. This IP instance has two new custom auxiliary PRU cores called
Transmit PRUs (Tx_PRUs) in addition to the existing PRUs and RTUs.
Each RTU and Tx_PRU cores have their own dedicated IRAM (smaller than
a PRU), Control and debug feature sets, but is different in terms of
sub-modules integrated around it and does not have the full capabilities
associated with a PRU core. The RTU core is typically used to aid a
PRU core in accelerating data transfers, while the Tx_PRU cores is
normally used to control the TX L2 FIFO if enabled in Ethernet
applications. Both can also be used to run independent applications.
The RTU and Tx_PRU cores though share the same Data RAMs as the PRU
cores, so the memories have to be partitioned carefully between different
applications. The new cores also support a new sub-module called Task
Manager to support two different context thread executions.
The driver currently supports the AM65xx SoC
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
The Programmable Real-Time Unit - Industrial Communication
Subsystem (PRU-ICSS) is present of various TI SoCs such as
AM335x or AM437x or the AM654x family. Each SoC can have
one or more PRUSS instances that may or may not be identical.
The PRUSS consists of dual 32-bit RISC cores called the
Programmable Real-Time Units (PRUs), some shared, data and
instruction memories, some internal peripheral modules, and
an interrupt controller. The programmable nature of the PRUs
provide flexibility to implement custom peripheral interfaces,
fast real-time responses, or specialized data handling.
Add support for pruss driver. Currently am654x family
is supported.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Currently stop is being called unconditionally without even
checking if start is called which will result in crash where
multiple instances are present and stop gets called even
without calling start.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
In case of multiple eth interfaces currently eth_get_dev
fetches the device based on the probe order which can be
random hence try with the alias.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
In case of SPL_LOAD_FIT_APPLY_OVERLAY, overlay files are applied in the
order as specified in overlay structure in board/ti/am65x/evm.c:
- k3-am654-gp.dtbo
- k3-am654-idk.dtbo
- k3-am654-pcie-usb2.dtbo
- k3-am654-pcie-usb3.dtbo
- k3-am654-evm-oldi-lcd1evm.dtbo
Since it is peripheral boot and overlays are applied on the fly, if the
above order is not maintained, specific overlays cannot be applied as
images would have already loaded and got discarded. So create u-boot.img
with the above order.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Enable the OPP_HIGH configuration for GPU voltage domain
by default for various TI DRA7xx and AM57xx boards. This
is being done to meet the performance needs of 1080p
GFX/MultiMedia usecases. This domain does not support DVFS
and the kernel will continue to run at the boot OPP chosen
here.
Based on logic similar to that of DSPEVE and IVA voltage
domains in commit 58a8921fe34fd5 ("ARM: DRA7: Enable OPP_HIGH
for DSPEVE and IVA voltage domains")
Signed-off-by: Subhajit Paul <subhajit_paul@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Enable the OPP_HIGH configuration for DSPEVE and IVA voltage
domains by default for various TI DRA7xx and AM57xx boards. This
is being done to meet the performance needs of 1080p MultiMedia
usecases and other DSP usecases. These domains do not support
DVFS and the kernel will continue to run at the boot OPPs chosen
here.
Signed-off-by: Suman Anna <s-anna@ti.com>
The PADCONFIG_202 register (0x02621328) is affected by the locking
of the RSTMUX8 register (0x02620328), and so cannot be configured
in kernel. This has been confirmed as a hardware bug and affects
all K2G SoCs.
Setup the pinmux for this pin before locking the RSTMUX8 register
to allow the ICSS1 PRU1 Ethernet PHY port to work properly. The
workaround was added only for the K2G-ICE board to configure the
pins needed for the PRUSS Ethernet usecase.
Signed-off-by: Suman Anna <s-anna@ti.com>
NB0 is bridge to SRAM and NB1 is bridge to DDR.
To ensure that SRAM transfers are not stalled due to
delays during DDR refreshes, SRAM traffic should be higher
priority (threadmap=2) than DDR traffic (threadmap=0).
This patch does just that.
This is required to fix ICSSG TX lock-ups due to delays in
MSMC transfers due to incorrect Northbridge configuration.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Acked-by: Andrew F. Davis <afd@ti.com>
Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Update the ddr settings to use the DDR reg config tool rev 0.6.0.
This enables 2666MTs DDR configuration.
Signed-off-by: Kevin Scholz <k-scholz@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Update the ddr settings to use the DDR reg config tool rev 0.6.0.
Signed-off-by: Kevin Scholz <k-scholz@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Add ti,ddr-freq0 entry for the DDR controller used by j721e and j7200
and provide a value in the corresponding SoC specific configuration
files.
Signed-off-by: Kevin Scholz <k-scholz@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Allow device tree to provide ti,ddr-freq0 to be used as the initial DDR
frequency that is set for lpddr4 before initialization of the
controller. Make this optional and continue to use bypass frequency if
ti,ddr-freq0 is not provided.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
[praneeth@ti.com: fix minor build error]
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
The J721E PM1 SoM board uses a TPS65917 PMIC with the MMC card IO
supply provided by LDO1 regulator. This regulator comes up in bypass
mode by default with the input supply at 3.3V. As such, the board
fails to boot with UHS mode enabled.
This can probably work if the regulator is switched into regular
operating mode, but there is no support for this PMIC in U-Boot.
So disable the UHS mode to have the boot functional on this board.
Signed-off-by: Suman Anna <s-anna@ti.com>
Customize the findfdt command to find the appropriate dtb for
J721E PM1 SOM boards leveraging the board_name variable.
Signed-off-by: Suman Anna <s-anna@ti.com>
The J721E PM1 SoM board uses a TPS65917 PMIC. The MMC SDCard
IO supply is provided by the LDO1 regulator from this PMIC.
Add a separate PM1 SoM specific dts file with this PMIC, and
make the necessary adjustments for the regulator consumer usage
changes.
Signed-off-by: Keerthy <j-keerthy@ti.com>
[s-anna@ti.com: port to 2021 LTS and split up the A72 dts]
Signed-off-by: Suman Anna <s-anna@ti.com>
The J721E PM1 SoM uses TPS65917 PMIC, and uses a different regulator
(SMPS12) as the supply for A72 AVS Class 0. Add support for this by
fixing up the DT supply dynamically based on the board version to
get the right phandle for avs supply regulator.
The same k3-j721e-r5-common-proc-board.dts file is used to avoid
dynamic detection for R5 SPL DTB, with the TPS65917 PMIC nodes
added. Both PMIC nodes are present (not at all ideal), but their
sole usage is to provide for AVS Class 0 functionality.
There is no plan to upstream this support, and hence the simpler
HACK approach is taken.
Signed-off-by: Keerthy <j-keerthy@ti.com>
[s-anna@ti.com: port to 2021 LTS and split up the R5 portion]
Signed-off-by: Suman Anna <s-anna@ti.com>
Resync the j721e_evm_a72_defconfig and j721e_evm_r5_defconfig using
savedefconfig.
CONFIG_K3_DM_FW gets auto-selected due to default option in its
Kconfig, otherwise all the others are just relocated. The commented
out CONFIG_TI_SCI_POWER_DOMAIN and CONFIG_CLK_TI_SCI are cleaned
up.
Signed-off-by: Suman Anna <s-anna@ti.com>
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>
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>
Add support for providing ATF load address with a Kconfig symbol.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Reviewed-by: Suman Anna <s-anna@ti.com>
EMIF tool for J7200 is now updated to 0.5.0
* Includes LPDDR with 2666MTs configuration
Signed-off-by: Kevin Scholz <k-scholz@ti.com>
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
Tested-by: Suman Anna <s-anna@ti.com>
AM64x SK lp4ddr 800MHz frequency configuration was initial data which
is still under investigation for random failures and is expected to be
tweaked. Lets delete this initial configuration for now till the final
values are stabilized.
Suggested-by: Lokesh Vutla <lokeshvutla@ti.com>
Suggested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
AM64x SK lp4ddr with 800MHz frequency config which was initial data
facing random failures. Alternatively, lp4ddr configuration with
667MHz frequency is functioning stable. Lets Add AM64x SK lp4ddr
configuration data for 667MHz frequency. Also, Update
k3-am642-r5-sk.dts file to use the 667MHz dtsi file.
Validated memtester test on 900MB of lp4 ddr memory with multiple
iterations.
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
Reviewed-by: James Doublesin <doublesin@ti.com>
The default U-Boot environment variables and design are all set up for
both the MAIN R5FSS clusters to be in Split-mode. This is the setting
in v2021.01 U-Boot and the dt nodes are synched with the newer kernel
binding property names in commit c118d25546 ("remoteproc: k3_r5:
Sync to upstreamed kernel DT property names").
The modes for both the clusters got switched back to LockStep mode by
mistake in commit 16c0c84460 ("arm: dts: k3-j721e: Sync Linux v5.11-rc6
dts into U-Boot"). This throws the following warning messages when
early-booting the cores using default env variables,
k3_r5f_rproc r5f@5d00000: Invalid op: Trying to start secondary core 7 in lockstep mode
Load Remote Processor 3 with data@addr=0x82000000 98484 bytes: Failed!
k3_r5f_rproc r5f@5f00000: Invalid op: Trying to start secondary core 9 in lockstep mode
Load Remote Processor 5 with data@addr=0x82000000 98484 bytes: Failed!
Fix this by switching back both the clusters to the expected Split-mode.
Make this mode change in the u-boot specific dtsi file to avoid such
sync overrides in the future until the kernel dts is also switched to
Split-mode by default.
Fixes: 16c0c84460 ("arm: dts: k3-j721e: Sync Linux v5.11-rc6 dts into U-Boot")
Reported-by: Minas Hambardzumyan <minas@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
While Kernel expects ethernetX alias to point to individual ethernet
ports in case of multi MAC ethernet controller, U-Boot DM core expects
ethernetX alias to point to the node that ethernet (am65-cpsw-nuss)
driver binds to. Hence aliases copied from kernel DT will
leads to 3 issues:
- ethernet interfaces on K3 SoCs get a different seq number than that of
intended alias (eg.: CPSW port0 on AM65x get eth1 instead of eth0).
- "ethaddr" env variable is no longer set to eFuse MAC address.
- U-Boot FDT fixup code won't update MAC address in Kernel's DT
due to missing "ethaddr" variable.
Fix this by updating alias to point to CPSW node in -u-boot.dtsi file
for all K3 SoCs to match U-Boot's expectation.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Enable all relevant configs for building multiple dtbs into a single fit
image and load the right dtb for next stage.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Enable relevant configs that checks for the size of image and stack:
BSS: 4KB
Initial MALLOC: 512KB
Initial Stack: 8K
SPL Image size can be: ~960KB
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Now that single defconfig can be used for booting AM64 EVM and SK,
default device tree will not work for selecting dtb for kernel.
Update the env to select right dtb based on eeprom.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Current BSS allocation of SPL is as below:
size spl/u-boot-spl
text data bss dec hex filename
144572 5484 1752 151808 25100 spl/u-boot-spl
But 20KB is allocated currently for BSS. Reduce it to 4KB and
save some space for stack.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Enable support for selecting DTB within SPL based on EEPROM.
This will help to use single defconfig for both EVM and SK
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
AM64 EVM has EEPROM populated at 0x50. Am64 SK has EEPROM populated at
next address 0x51 in order to be compatible with RBPi.
So start looking for TI specific EEPROM at 0x50, if not found look for
EEPROM at 0x51.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Lokesh Vutla
Roger Quadros
Keerthy
Subhajit Paul
Suman Anna
Kevin Scholz
Dave Gerlach
Aswath Govindraju
Sinthu Raja
Vignesh Raghavendra