setup_board_eeprom_env() and setup_serial() is called only under
CONFIG_BOARD_LATE_INIT, so guard these functions with the same.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
The AM64x SoC uses a central Device Management and Security Controller
(DMSC) processor that manages all the low-level device controls
including the system-wide SoC reset. The system-wide reset is managed
through the system reset driver.
Add a sysreset controller node as a child of the dmsc node to enable
the "reset" command from U-Boot prompt for the K3 AM642 SK.
Signed-off-by: Suman Anna <s-anna@ti.com>
The AM64x SoC uses a central Device Management and Security Controller
(DMSC) processor that manages all the low-level device controls
including the system-wide SoC reset. The system-wide reset is managed
through the system reset driver.
Add a sysreset controller node as a child of the dmsc node to enable
the "reset" command from U-Boot prompt for the K3 AM642 EVM.
Signed-off-by: Suman Anna <s-anna@ti.com>
Move all initial DDR PLL configuration to a common function so that it
happens in one place for DDR4 and LPDDR4 as needed.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
commit 9636bf8b2e upstream.
Since commit 0f036bf4b8 ("env: Warn on force access if ENV_ACCESS_IGNORE_FORCE set")
a warning message is displayed when setenv -f is used WITHOUT
CONFIG_ENV_ACCESS_IGNORE_FORCE, but the variable is set anyway, resulting
in lots of log pollution.
env_flags_validate() returns 0 if the access is accepted, or non zero
if it is refused.
So the original code
#ifndef CONFIG_ENV_ACCESS_IGNORE_FORCE
if (flag & H_FORCE)
return 0;
#endif
was correct, it returns 0 (accepts the modification) if forced UNLESS
IGNORE_FORCE is set (in which case access checks in the following code
are applied). The broken patch just added a printf to the force accepted
case.
To obtain the intent of the patch we need this:
if (flag & H_FORCE) {
#ifdef CONFIG_ENV_ACCESS_IGNORE_FORCE
printf("## Error: Can't force access to \"%s\"\n", name);
#else
return 0;
#endif
}
Fixes: 0f036bf4b8 ("env: Warn on force access if ENV_ACCESS_IGNORE_FORCE set")
Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group>
[s-anna@ti.com: cherry-pick commit '9636bf8b2e31' from v2021.07-rc1]
Signed-off-by: Suman Anna <s-anna@ti.com>
The AM654 IDK daughter card supports few additional peripherals
like MCAN and 4 ICSSG Ethernet ports. The ICSSG IP is different
between the two AM65x Silicon Revisions SR1.0 and SR2.0, and so
warrants a separate overlay file when using on top of a AM654
base board populated with a SR1.0 silicon.
Add a new k3-am654-idk-sr1.dts overlay file, which includes the
k3-am654-idk.dts overlay file. The built overlays are identical
for now, but will diverge after ICSSG Ethernet support is added.
This fixes the following warning currently seen in A53 SPL on
AM65x EVMs with SR1.0 after the board logic is fixed up to pick
the separate overlay for kernel in commit ba961d78ac16 ("board:
ti: am65x: Use different overlay for IDK with SR1.0 EVM")
"cannot find image node 'k3-am654-idk-sr1': -1"
Signed-off-by: Suman Anna <s-anna@ti.com>
The ICSSG IP is different between the two AM65x Silicon Revisions SR1.0
and SR2.0, and the ICSSG Ethernet nodes will look different between the
two versions. The Linux kernel uses a separate overlay file for the IDK
board between the two variants. Introduce a runtime check to use a
different overlay for IDK daughter card specifically for SR1.0 silicon.
Code is based on logic from an older patch from Roger Quadros.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
The AM65x EVM board can use either the newer SR2.0 or an older SR1.0
SoC. The default board dts file is used for SR2.0 silicons, and the
differences between the two silicon revision variants are handled
through a board-specific overlay file, k3-am654-base-board-sr1.dtbo.
Add logic to detect the silicon revision and apply this overlay while
booting Linux.
NOTE:
The ICSSG nodes are not yet added to U-Boot, and so there are no separate
overlay files to apply for U-Boot from A53 SPL.
Signed-off-by: Suman Anna <s-anna@ti.com>
The AM654 IDK daughter card supports few additional peripherals
like MCAN and 4 ICSSG Ethernet ports. Add a new initial overlay
file, k3-am654-idk.dts, for this daughter card. This overlay file
will be be used with the standard AM654 EVM board. The overlay file
is currently empty and differs from the equivalent Linux kernel dts
overlay file as there is no required MCAN support in U-Boot, and
the ICSSG Ethernet support is not yet available.
This fixes the following warning currently seen in A53 SPL,
"cannot find image node 'k3-am654-idk': -1"
Signed-off-by: Suman Anna <s-anna@ti.com>
Add DT nodes to enable S28HS512T OSPI flash on the SK board.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Setup mtdids and mtdparts to be used at U-Boot prompt and also to be
passed as cmdline arguments to kernel. This enables kernel to create MTD
partition for each of the component required for boot.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Enable config options required to support OSPI along with OSPI boot.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
AM64 EVM has a S28HS512T flash. Add DT nodes for the same.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
AM64 SoC has a Flash SubSystem with an OSPI controller within. Add DT
entries for the same.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Both AM64x GP and SK EVMs have DP83867 PHYs connected to CPSW ports.
Enable the driver for the same.
PHY_TI is selected by PHY_TI_DP83867, so no need to select explicitly
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Tested-by: Pratyush Yadav <p.yadav@ti.com>
commit 1d4e8a15d2fa21548250ad9acc3d13706e140e4b upstream.
Since commit 6239cc8c4e ("arm: dts: k3-j7200: Sync Linux v5.11-rc6 dts
into U-Boot") ranges have been added to CPSW node which results in
U-Boot CPSW driver failing to acquire phy_gmii_sel register range and
thus failing to configure GMII mode correctly.
Fix this by deleting ranges in -u-boot-dtsi just like its done for other
K3 platforms.
Fixes: 6239cc8c4e ("arm: dts: k3-j7200: Sync Linux v5.11-rc6 dts into U-Boot")
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Enable configs for USB SuperSpeed Host Port.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Fix the clock names in USB device tree node.
Fixes: 3092efc090 ("arm: dts: k3-am64-main: Add USB DT nodes")
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Modeled the internal clocks without subnodes being populated in device
tree. This is based on recent discussions in the mailing list [1] suggested
to just add #clock cells in the parent DT node and model the clocks within
the driver.
Model the mux clocks without device tree input for AM64x SoC. Don't
remove the earlier design since DT nodes for J7200 and J721e are already
upstreamed.
[1] -> http://lore.kernel.org/r/20210108025943.GA1790601@robh.at.kernel.org
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
The frequency of the txmclk between PCIe and SERDES has
changed to 250MHz from 500MHz. Configure full rate divider
for AM64 accordingly.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
AM64 has a single lane SERDES which can be configured to be used
with either PCIe or USB. Define the possilbe values for the SERDES
function in AM64 SoC here.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Add binding for refclk driver used to route the refclk out of torrent
SERDES.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
MLO has increased to a size greater than the allocated
128 kB in dfu_alt_info_emmc and _mmc.
Therefore, double the allocated size for MLO.raw in
the default environment.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Enable config to support gpt command on AM642 evm/sk and enable config for
FDT library overlay support
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
This fixes the following warning at boot.
"cannot find image node 'k3-am654-pcie-usb3': -1"
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Add support for PCIe 2 lane with USB 2.0 daughter card.
Only PCIe support is added at this time. Patch is based on
work by Kishon Vijay Abraham I <kishon@ti.com> in Linux kernel.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
J7200 ROM supports booting from xSPI compliant flash. Detect if ROM
booted from xSPI bootmode and map that to BOOT_DEVICE_SPI
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Enable Octal DTR mode and PHY mode. Use the frequency of 25MHz because
that is what Octal DTR mode has been tested with.
The PHY partition is added in U-Boot specific dtsi because it is not
currently required by Kernel so it will make it easier to sync with
Kernel.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Enable Octal DTR mode and PHY mode. Use the frequency of 25MHz because
that is what Octal DTR mode has been tested with.
The PHY partition is added in U-Boot specific dtsi because it is not
currently required by Kernel so it will make it easier to sync with
Kernel.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
TI J7200 has the Cadence OSPI controller for interfacing with OSPI
flashes. Add its nodes to allow using SPI flashes.
The PHY partition is added in U-Boot specific dtsi because it is not
currently required by Kernel so it will make it easier to sync with
Kernel.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
The MTD partitions listed are not what should be. Changes made are:
- Move ospi.env.backup to 0x6C0000 so it does not lie in the middle of
an erase block.
- Make ospi.env and ospi.env.backup 256k so they span a full erase
block.
- Drop the sysfw partition. It is bundled with R5 SPL now.
- Add the PHY calibration pattern partition.
NOTE: The code in the OSPI driver is very naive so it won't actually
read this variable to find the PHY pattern location as of now, and needs
the partition to also be present in device tree. But this change will
make sure Linux does not over-write the pattern thinking it is part of
the rootfs.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
With PHY calibration now added in the Cadence QSPI controller driver, it
needs the PHY pattern partition to find out where the PHY calibration
pattern is stored. This partition is usually stored at the start of the
last erase sector on the flash. This means the rootfs can't span till
the end of the flash anymore.
Update CONFIG_MTDPARTS_DEFAULT to include the PHY pattern partition so
Linux won't unknowingly over-write the pattern.
NOTE: The code in the driver is very naive so it won't actually read
this variable as of now, and needs the partition to also be present in
device tree. But this change will make sure Linux does not over-write
the pattern thinking it is part of the rootfs.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
With PHY calibration now added in the Cadence QSPI controller driver, it
needs the PHY pattern partition to find out where the PHY calibration
pattern is stored. This partition is usually stored at the start of the
last erase sector on the flash. This means the rootfs can't span till
the end of the flash anymore.
Update CONFIG_MTDPARTS_DEFAULT to include the PHY pattern partition so
Linux won't unknowingly over-write the pattern.
NOTE: The code in the driver is very naive so it won't actually read
this variable as of now, and needs the partition to also be present in
device tree. But this change will make sure Linux does not over-write
the pattern thinking it is part of the rootfs.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
xSPI support comes with a set of configs that can be used to customize
what code gets built like soft reset, PHY tuning, etc. Enable these
configs because these features are needed to get the MT35XU flash
working.
Also enable thermal support because PHY needs it to adjust the tuning
point.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
xSPI support comes with a set of configs that can be used to customize
what code gets built like soft reset, PHY tuning, etc. Enable these
configs because these features are needed to get the MT35XU flash
working.
Also enable thermal support because PHY needs it to adjust the tuning
point.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
xSPI support comes with a set of configs that can be used to customize
what code gets built like soft reset, PHY tuning, etc. Enable these
configs because these features are needed to get the MT35XU flash
working.
Also enable thermal support because PHY needs it to adjust the tuning
point.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
xSPI support comes with a set of configs that can be used to customize
what code gets built like soft reset, PHY tuning, etc. Enable these
configs because these features are needed to get the MT35XU flash
working.
Also enable thermal support because PHY needs it to adjust the tuning
point.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
xSPI support comes with a set of configs that can be used to customize
what code gets built like soft reset, PHY tuning, etc. Enable these
configs because these features are needed to get the S28HS and MT35XU
flashes working.
Also enable thermal support because PHY needs it to adjust the tuning
point.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
xSPI support comes with a set of configs that can be used to customize
what code gets built like soft reset, PHY tuning, etc. Enable these
configs because these features are needed to get the MT35XU flash
working.
Also enable thermal support because PHY needs it to adjust the tuning
point.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
xSPI support comes with a set of configs that can be used to customize
what code gets built like soft reset, PHY tuning, etc. Enable these
configs because these features are needed to get the S28HS and MT35XU
flashes working.
Also enable thermal support because PHY needs it to adjust the tuning
point.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
xSPI support comes with a set of configs that can be used to customize
what code gets built like soft reset, PHY tuning, etc. Enable these
configs because these features are needed to get the S28HS and MT35XU
flashes working.
Also enable thermal support because PHY needs it to adjust the tuning
point.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
xSPI support comes with a set of configs that can be used to customize
what code gets built like soft reset, PHY tuning, etc. Enable these
configs because these features are needed to get the MT35XU flash
working.
Also enable thermal support because PHY needs it to adjust the tuning
point.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
xSPI support comes with a set of configs that can be used to customize
what code gets built like soft reset, PHY tuning, etc. Enable these
configs because these features are needed to get the S28HS and MT35XU
flashes working.
Also enable thermal support because PHY needs it to adjust the tuning
point.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
A very frequent operation is the Read Status Register command that is
executed repeatedly after doing an erase or page program. On the Cypress
S28HS512T flash this command expects 4 address bytes and so it does not
go via the STIG route. The command reads 2 bytes from the flash. Setting
up DMA for it is more hassle than it is worth. For small reads like
this, the speed gain, if any, will not be worth the extra overhead.
So do not use DMA for reads smaller than 16 bytes. This should cover
polling operations like SR polling.
It also fixes an issue on J721E and J7200 with the Cypress S28HS512T
flash where DMA would eventually freeze when writing or erasing because
of the constant bombardment of small, frequent reads.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>