Commit graph

192 commits

Author SHA1 Message Date
Andrew Davis
b661c1bc92 arm: mach-k3: security: Remove certificate if detected on GP device
If the device is a GP and we detect a signing certificate then remove it.
It would fail to authenticate otherwise as the device is GP and has no
secure authentication services in SYSFW.

This shouldn't happen often as trying to boot signed images on GP devices
doesn't make much sense, but if we run into a signed image we should at
least try to ignore the certificate and boot the image anyway. This could
help with users of GP devices who only have HS images available.

If this does happen, print a nice big warning.

Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
2022-08-04 15:32:20 -04:00
Andrew Davis
a0379c6fe3 arm: mach-k3: security: Bypass image signing at runtime for GP devices
We can skip the image authentication check at runtime if the device is GP.
This reduces the delta between GP and HS U-Boot builds. End goal is
to re-unify the two build types into one build that can run on all
device types.

Signed-off-by: Andrew Davis <afd@ti.com>
2022-08-04 15:32:20 -04:00
Andrew Davis
e1ef04fb3e arm: mach-k3: security: Allow signing bypass if type is HS-FS
On HS-FS devices signing boot images is optional. To ease use
we check if we are HS-FS and if no certificate is attached
to the image we skip the authentication step with a warning
that this will fail when the device is set to security enforcing.

Signed-off-by: Andrew Davis <afd@ti.com>
2022-08-04 15:32:20 -04:00
Andrew Davis
d1c079557f arm: mach-k3: Add support for device type detection
K3 SoCs are available in a number of device types such as
GP, HS-FS, EMU, etc. Like OMAP SoCs we can detect this at runtime
and should print this out as part of the SoC information line.
We add this as part of the common.c file as it will be used
to also modify our security state early in the device boot.

Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
2022-08-04 15:32:20 -04:00
Andrew Davis
121596a98f arm: k3: config.mk: Read software revision information from file on HS
Read the swrv.txt file from the TI Security Development Tools when
TI_SECURE_DEVICE is enabled. This allows us to set our software
revision in one place and have it used by all the tools that create
TI x509 boot certificates.

Signed-off-by: Andrew Davis <afd@ti.com>
2022-07-25 14:57:27 -04:00
Yogesh Siraswar
0019427251 k3_gen_x509_cert: Make SWRV configurable for anti-rollback protection
The x509 certificate SWRV is currently hard-coded to 0. This need to be
updated to 1 for j721e 1.1, j7200 and am64x. It is don't care for other
k3 devices.

Added new config K3_X509_SWRV to k3. Default is set to 1.

Signed-off-by: Yogesh Siraswar <yogeshs@ti.com>
Reviewed-by: Dave Gerlach <d-gerlach@ti.com>
2022-07-25 14:57:27 -04:00
Andrew Davis
080fe39b8c arm: mach-k3: Remove ROM firewalls on GP devices
This isn't strictly needed as these firewalls should all be disabled on
GP, but it also doesn't hurt, so do this unconditionally to remove this
use of CONFIG_TI_SECURE_DEVICE.

Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
2022-07-25 14:57:27 -04:00
Andrew Davis
80b93bb71c arm: mach-k3: Rename SOC_K3_AM6 to SOC_K3_AM654
The first AM6x device was the AM654x, but being the first we named it
just AM6, since more devices have come out with this same prefix we
should switch it to the normal convention of using the full name of the
first compatibility device the series. This makes what device we are
talking about more clear and matches all the K3 devices added since.

Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
2022-07-25 13:02:04 -04:00
Andrew Davis
46da163b72 arm: mach-k3: Only build init files for SPL
The content of these files are only used in SPL builds. The contents are
already ifdef for the same, remove that and only include the whole file
in the build when building for SPL.

Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
2022-07-25 13:02:04 -04:00
Matt Ranostay
cab8510821 armv8: mach-k3: correct define checking for AM625/AM642 memory maps
Using CONFIG_IS_ENABLED breaks accessing memory map structure when
doing a A53 SPL build for AM625 and AM642 platforms. This is due to
'abc if CONFIG_SPL_BUILD is defined and CONFIG_SPL_FOO is set to 'y''
in which there is no CONFIG_SPL_SOC_K3_AM625/CONFIG_SPL_SOC_K3_AM642
defined in the configuration.

For the A53 SPL builds on these platform to access the memory mapping
which it will need for enabling the mmu/cache it must use #if defined(X)
checks and not CONFIG_IS_ENABLED.

Cc: Suman Anna <s-anna@ti.com>
Cc: Neha Francis <n-francis@ti.com>
Signed-off-by: Matt Ranostay <mranostay@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
2022-07-25 13:02:04 -04:00
Julien Panis
169582025a arm64: mach-k3: am625_init: Probe ESM nodes
On AM62x devices, main ESM error event outputs can be routed to
MCU ESM as inputs. So, two ESM device nodes are expected in the
device tree : one for main ESM and another one for MCU ESM.
MCU ESM error output can trigger the reset logic to reset
the device when CTRLMMR_MCU_RST_CTRL:MCU_ESM_ERROR_RESET_EN_Z is
set to '0'.

Signed-off-by: Julien Panis <jpanis@baylibre.com>
2022-07-25 09:38:47 -04:00
Georgi Vlaev
a04bbb83b4 arm: mach-k3: common: Use ddr_init in spl_enable_dcache
The spl_enable_dcache() function calls dram_init_banksize()
to get the total memory size. Normally the dram_init_banksize()
setups the memory banks, while the total size is reported
by ddr_init(). This worked so far for K3 since we set the
gd->ram_size in dram_init_banksize() as well.

Signed-off-by: Georgi Vlaev <g-vlaev@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
2022-07-06 14:30:08 -04:00
Vaishnav Achath
c16b4f14a3 arm: k3: j721e: add dynamic sf bus override support for j721e
implement overrides for spl_spi_boot_bus() and spl_spi_boot_cs()
lookup functions according to bootmode selection, so as to support
both QSPI and OSPI boot using the same build.

Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
2022-07-06 14:30:08 -04:00
Tom Rini
52af0101be Merge branch 'master' into next
Merge in v2022.07-rc5.
2022-06-20 14:40:59 -04:00
Christian Gmeiner
761157d310 arch: arm: mach-k3: am642_init: bring back MCU_PADCFG_MMR1 unlock
Without this register unlock it is not possible to configure the
pinmux used for mcu spi0.

Fixes: 92e46092f2 ("arch: arm: mach-k3: am642_init: Probe ESM nodes")
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Nishanth Menon <nm@ti.com>
2022-06-16 15:22:54 -04:00
Suman Anna
900349b7dd board: ti: Introduce the basic files to support AM62 SK board
Add basic support for AM62 SK. This has 2GB DDR.
Note that stack for R5 SPL is in OCRAM @ 0x7000ffff so that is away from
BSS and does not step on BSS section

Add only the bare minimum required to support UART and SD.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
2022-06-10 13:37:33 -04:00
Suman Anna
4b8903a999 arm: mach-k3: am62: Introduce autogenerated SoC data
Introduce autogenerated SoC data support clk and device data for the
AM62. Hook it upto to power-domain and clk frameworks of U-Boot.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2022-06-10 13:37:32 -04:00
Suman Anna
d98e860051 arm: mach-k3: Introduce the basic files to support AM62
The AM62 SoC family is the follow on AM335x built on K3 Multicore SoC
architecture platform, providing ultra-low-power modes, dual display,
multi-sensor edge compute, security and other BOM-saving integration.
The AM62 SoC targets broad market to enable applications such as
Industrial HMI, PLC/CNC/Robot control, Medical Equipment, Building
Automation, Appliances and more.

Some highlights of this SoC are:

* Quad-Cortex-A53s (running up to 1.4GHz) in a single cluster.
  Pin-to-pin compatible options for single and quad core are available.
* Cortex-M4F for general-purpose or safety usage.
* Dual display support, providing 24-bit RBG parallel interface and
  OLDI/LVDS-4 Lane x2, up to 200MHz pixel clock support for 2K display
  resolution.
* Selectable GPUsupport, up to 8GFLOPS, providing better user experience
  in 3D graphic display case and Android.
* PRU(Programmable Realtime Unit) support for customized programmable
  interfaces/IOs.
* Integrated Giga-bit Ethernet switch supporting up to a total of two
  external ports (TSN capable).
* 9xUARTs, 5xSPI, 6xI2C, 2xUSB2, 3xCAN-FD, 3x eMMC and SD, GPMC for
  NAND/FPGA connection, OSPI memory controller, 3xMcASP for audio,
  1x CSI-RX-4L for Camera, eCAP/eQEP, ePWM, among other peripherals.
* Dedicated Centralized System Controller for Security, Power, and
  Resource Management.
* Multiple low power modes support, ex: Deep sleep,Standby, MCU-only,
  enabling battery powered system design.

AM625 is the first device of the family. Add DT bindings for the same.

More details can be found in the Technical Reference Manual:
https://www.ti.com/lit/pdf/spruiv7

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Gowtham Tammana <g-tammana@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
2022-06-10 13:37:32 -04:00
Aswath Govindraju
36dafd8045 arm: mach-k3: am6_init: Fix the path and value's length in the fixup performed for usb boot
The node name of the bus in the device tree has changed. Also, the length
argument to be passed should be the length of new value. Therefore, fix the
path to usb device tree node as well as the length argument passed.

Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
2022-06-10 13:37:32 -04:00
Vaishnav Achath
09d14d7f10 arm: k3: sysfw-loader: add hyperflash support
add support for loading system firmware from hyperflash.

Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
2022-06-10 09:03:22 -04:00
Tom Rini
59bffec43a Merge branch '2022-04-04-platform-updates'
- Updates for exynos78x0 and TI K3 platforms
2022-04-05 13:45:22 -04:00
Hari Nagalla
92e46092f2 arch: arm: mach-k3: am642_init: Probe ESM nodes
On AM64x devices, it is possible to route Main ESM0 error events to MCU
ESM. MCU ESM high error output can trigger the reset logic to reset the
device. So, for these devices we expect two ESM device nodes in the
device tree, one for Main ESM and the another MCU ESM in the device tree.
 When these ESM device nodes are properly configired it is possible to
route the Main RTI0 WWDT output to the MCU ESM high output through Main
ESM and trigger a device reset when
CTRLMMR_MCU_RST_CTRL:MCU_ESM_ERROR_RESET_EN_Z is set to '0'.

On K3 AM64x devices, the R5 SPL u-boot handles the ESM device node
configurations.

Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
2022-04-04 19:02:04 -04:00
Andre Przywara
5907357322 spl: mmc: extend spl_mmc_boot_mode() to take mmc argument
Platforms can overwrite the weak definition of spl_mmc_boot_mode() to
determine where to load U-Boot proper from.
For most of them this is a trivial decision based on Kconfig variables,
but it might be desirable the probe the actual device to answer this
question.

Pass the pointer to the mmc struct to that function, so implementations
can make use of that.

Compile-tested for all users changed.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Stefano Babic <sbabic@denx.de>
Reviewed-by: Ley Foon Tan <ley.foon.tan@inte.com> (for SoCFPGA)
Acked-by: Lokesh Vutla <lokeshvutla@ti.com> (for OMAP and K3)
Reviewed-by: Simon Glass <sjg@chromium.org>
2022-04-04 23:24:17 +01:00
Christian Gmeiner
f7fbe547d9 arm: mach-k3: am6_init: Use CONFIG_TI_I2C_BOARD_DETECT
We only want to call do_board_detect() if CONFIG_TI_I2C_BOARD_DETECT
is set. Same as done for am64.

This makes it possible to add a custom am65 based board design to
U-Boot that does not use this board detection mechanism.

Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
2022-03-04 15:20:06 -05:00
Sinthu Raja
1e82a80d17 arm: j721e: Add support for selecting DT based on board name
Enable support for selecting DTB from FIT within SPL based on the
board name read from EEPROM. This will help to use single defconfig
for both EVM and SK.

Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
2022-02-16 14:19:30 -05:00
Keerthy
b071a07743 drivers: misc: Makefile: Enable fs_loader compilation at SPL Level
Enable fs_loader compilation at SPL Level.

Signed-off-by: Keerthy <j-keerthy@ti.com>
[Amjad: fix compilation failures for J721e platform]
Signed-off-by: Amjad Ouled-Ameur <aouledameur@baylibre.com>
2022-02-08 11:00:02 -05:00
David Huang
681023aba4 arm: K3: Add basic support for J721S2 SoC definition
Add basic support for J721S2 SoC definition

Signed-off-by: David Huang <d-huang@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
2022-02-08 09:41:26 -05:00
Vignesh Raghavendra
07252f5c71 mach-k3: am64_spl: Alias Ethernet RGMII boot to CPGMAC
This is required to enables spl_net boot on AM64x

Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2022-01-15 10:38:26 -05:00
Vignesh Raghavendra
93c43a8365 mach-k3: am642_init: Probe AM65 CPSW NUSS for R5/A53 SPL
In order to support Ethernet boot on AM64x, probe AM65 CPSW NUSS.

Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2022-01-15 10:38:26 -05:00
Vignesh Raghavendra
e58d928485 mach-k3: common: Instantiate AM65 CPSW NUSS wrapper
Probe toplevel AM65 CPSW NUSS driver from misc_init_r() when driver
is enabled. Since driver is modeled as UCLASS_MISC, we need to
explicitly probe the driver. Use common misc_init_r() that entire
K3 family of SoCs.

Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2022-01-15 10:38:26 -05:00
Vignesh Raghavendra
584216315d ARM: mach-k3: sysfw-loader: Copy sysfw.itb to OCRAM in OSPI/SPI bootmode
In case of xSPI bootmode OSPI flash is in DDR mode and needs to be accessed
in multiple of 16bit accesses Hence we cannot parse sysfw.itb FIT image
directly on OSPI flash via MMIO window. So, copy the image to internal
on-chip RAM before parsing the image.

Moreover, board cfg data maybe modified by ROM/TIFS in case of HS platform
and thus cannot reside in OSPI/xSPI and needs to be copied over to
internal OCRAM.

This unblocks OSPI/xSPI boot on HS platforms

Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Dave Gerlach <d-gerlach@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Acked-by: Pratyush Yadav <p.yadav@ti.com>
2022-01-15 10:38:26 -05:00
Michael Liebert
67c8678346 arm: mach-k3: am642_init: Unlock MCU PADCFG regs
Currently only the PADCFG registers of the main domain are unlocked.
Also unlock PADCFG registers of MCU domain, so MCU pin muxing can be configured by u-boot or Linux.

Signed-off-by: Michael Liebert <liebert@ibv-augsburg.de>
Tested-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Acked-by: Nishanth Menon <nm@ti.com>
2022-01-15 10:38:26 -05:00
Jan Kiszka
a2db09e269 board: siemens: Add support for SIMATIC IOT2050 devices
This adds support for the IOT2050 Basic and Advanced devices. The Basic
used the dual-core AM6528 GP processor, the Advanced one the AM6548 HS
quad-core version.

Both variants are booted via a Siemens-provided FSBL that runs on the R5
cores. Consequently, U-Boot support is targeting the A53 cores. U-Boot
SPL, ATF and TEE have to reside in SPI flash.

Full integration into a bootable image can be found on
https://github.com/siemens/meta-iot2050

Based on original board support by Le Jin, Gao Nian and Chao Zeng.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
2021-10-03 14:40:56 -04:00
Tom Rini
e908d20fcb Prepare v2021.10-rc5
-----BEGIN PGP SIGNATURE-----
 
 iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmFRyIMACgkQFHw5/5Y0
 tyz1jgv/aTtHWVcGiw+nvvnnlgdrY4h9yVP5AfBLhOR7ogYOw2B9xHmdh+9oCas9
 Rt45AC4nFvUszxCPJqg36kjljTKRVapemHqhCbgGGeb9GYMkNb1zjk79WnuqgeJy
 ydBUCh1NQI5pOvrpDv7kWRx1IyDi/gUgQO3RBdufbunNmn4Zj4jlw5RmMTgDACRC
 cvTr39gVQq1LOzL2W7+XkSfiEejtGERNs32Nt+jzyAm5a2PkngULUnPW6WsHu+qy
 5YJTR50TK55QgPIdoiqY14BUDpqEbHlNKsE7p6hHkDf6XSS7gLHYW2tVVt2Z8ocg
 9cW35Qotov7MeiSClc3SIEPiIefwh2oTVf0uYoP+uvlRAComvcIzphq68NIQe6Av
 es+ZJI1Qx5ERvDQMMW3xOHTlcBGgpqA0Y/QVr62rE8bEzK/1gvTiP+hVVqzUrnHJ
 f3ZAVt16clIfXKAxGsW4Am05iMmT+rtcS5IrUMuEzmkb0KK58YXsOVmsKHLX9aI1
 T74ewXfu
 =y67Q
 -----END PGP SIGNATURE-----

Merge tag 'v2021.10-rc5' into next

Prepare v2021.10-rc5
2021-09-27 09:45:36 -04:00
Nishanth Menon
ee91d46557 arm: mach-k3: common: Make sure firmware sections are loaded prior to armv8 startup
With Device Manager firmware in an elf file form, we cannot load the FIT
image to the exact same address as any of the executable sections of the
elf file itself is located.

However, the device tree descriptions for the ARMV8 bootloader/OS
includes DDR regions only the final sections in DDR where the Device
Manager firmware is actually executing out of.

As the R5 uC is usually operating at a slower rate than an ARMv8 MPU,
by starting the Armv8 ahead of parsing the elf and copying the correct
sections to the required memories creates a race condition where the
ARMv8 could overwrite the elf image loaded from the FIT image prior to
the R5 completing parsing and putting the correct sections of elf in
the required memory locations. OR create rather obscure debug conditions
where data in the section is being modified by ARMV8 OS while the elf
copy is in progress.

To prevent all these conditions, lets make sure that the elf parse and
copy operations are completed ahead of ARMv8 being released to execute.

We will pay a penalty of elf copy time, but that is a valid tradeoff in
comparison to debug of alternate scenarios.

Signed-off-by: Nishanth Menon <nm@ti.com>
2021-09-17 14:48:53 -04:00
Roger Quadros
6887f8e00b arm: mach-k3: am6_init: Prioritize MSMC traffic over DDR in NAVSS Northbridge
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 fixup is critical to provide deterministic access latency to
MSMC from ICSSG, it applies to all AM65 silicon revisions and is due
to incorrect reset values (has no erratum id) and statically setting
things up should be done independent of usecases and board.

This specific style of Northbridge configuration is specific only to
AM65x devices, follow-on K3 devices have different data prioritization
schemes (ASEL and the like) and hence the fixup applies purely to
AM65x.

Without this fix, ICSSG TX lock-ups due to delays in MSMC transfers in
case of SR1 devices, on SR2 devices, lockups were not observed so far
but high retry rates of ICSSG Ethernet (icssg-eth) and, thus, lower
throughput.

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>
[Jan: rebased, dropped used define, extended commit log]
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
[Nishanth: Provide relevant context in the commit message]
Signed-off-by: Nishanth Menon<nm@ti.com>
2021-09-17 14:47:03 -04:00
Suman Anna
cfd50dfb72 clk: ti: k3: Update driver to account for divider flags
The K3 SoCs have some PLL output clocks (POSTDIV clocks) which in
turn serve as inputs to other HSDIV output clocks. These clocks use
the actual value to compute the divider clock rate, and need to be
registered with the CLK_DIVIDER_ONE_BASED flags. The current k3-clk
driver and data lacks the infrastructure to pass in divider flags.
Update the driver and data to account for these divider flags.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
2021-09-17 14:47:03 -04:00
Dave Gerlach
ae8d3d236a arm: mach-k3: Add note to auto-generated files
Add a note to the automatically generated clk-data and dev-data files
for j721e and j7200 to indicate that they are in fact auto-generated and
should not be hand edited.

Also adjust TI URL to use https instead of http and also add an empty
line before first header inclusion.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
2021-09-17 14:47:03 -04:00
Suman Anna
326c03b548 arm: mach-k3: j7200: Fix clk-data parenting for postdiv PLL clocks
The TI K3 Fractional PLLs use two programmable POSTDIV1 and POSTDIV2
divisors to generate the final FOUTPOSTDIV clock. These are in sequence
with POSTDIV2 following the POSTDIV1 clock. The current J7200 clock data
has the POSTDIV2 clock as the parent for the POSTDIV1 clock, which is
opposite of the actual implementation. Fix the data by simply adjusting
the register bit-shifts.

The Main PLL1 POSTDIV clocks were also defined incorrectly using Main PLL0
register values, fix these as well.

Fixes: 277729eaf3 ("arm: mach-k3: Add platform data for j721e and j7200")
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
2021-09-17 14:47:03 -04:00
Suman Anna
f1a815d068 arm: mach-k3: j721e: Fix clk-data parenting for postdiv PLL clocks
The TI K3 Fractional PLLs use two programmable POSTDIV1 and POSTDIV2
divisors to generate the final FOUTPOSTDIV clock. These are in sequence
with POSTDIV2 following the POSTDIV1 clock. The current J721E clock data
has the POSTDIV2 clock as the parent for the POSTDIV1 clock, which is
opposite of the actual implementation. Fix the data by simply adjusting
the register bit-shifts.

The Main PLL1 POSTDIV clocks were also defined incorrectly using Main PLL0
register values, fix these as well.

Fixes: 277729eaf3 ("arm: mach-k3: Add platform data for j721e and j7200")
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
2021-09-17 14:47:03 -04:00
Suman Anna
d86a089d29 arm: mach-k3: common: Add a release_resources_for_core_shutdown() stub
Add a weak release_resources_for_core_shutdown() stub implementation
that can be overridden by actual implementation if a SoC supports that
function.

Signed-off-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Nishanth Menon <nm@ti.com>
2021-09-17 14:47:03 -04:00
Simon Glass
103c5f1806 mmc: Rename MMC_SUPPORT to MMC
Rename these options so that CONFIG_IS_ENABLED can be used with them.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
[trini: Fixup some incorrect renames]
Signed-off-by: Tom Rini <trini@konsulko.com>
2021-09-04 11:42:41 -04:00
Suman Anna
ea985f6d92 arm: mach-k3: Cleanup common start_non_linux_remote_cores()
The mach-k3 common code defined a weak start_non_linux_remote_cores()
function so that the proper implementation can be plugged in the
SoC-specific source files. This won't be needed anymore, so remove the
the common code.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210726211311.5977-4-s-anna@ti.com
2021-07-27 11:00:44 +05:30
Suman Anna
536f633d8a arm: mach-k3: j721e: Cleanup MAIN R5 boot code from R5 SPL
The common J7 specific start_non_linux_remote_cores() override function
implements the logic to load and boot the Main R5FSS Core0 from R5 SPL.
This won't be supported any more for either J721E or J7200 after the R5
SPL rearchitecture for the System Firmware split into TI Foundation
Security (TIFS) and Device Management (DM) firmwares. So, cleanup the
corresponding code and the related SPL env variables.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210726211311.5977-3-s-anna@ti.com
2021-07-27 11:00:44 +05:30
Suman Anna
05e858aefe arm: mach-k3: j721e: Move booting of Main R5FSS Core0 to A72 U-Boot
The Main R5FSS Core0 on J721E SoCs is originally booted from R5 SPL
itself to achieve certain product-level early-boot metrics. This is
no longer supported after the R5 SPL re-architecture (support merged
for v2021.10-rc1). Move the booting of this core altogether from R5
SPL to A72 U-Boot.

The env variables are left as is for now, and will be cleaned up
in a subsequent patch.

Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210726211311.5977-2-s-anna@ti.com
2021-07-27 11:00:44 +05:30
Aswath Govindraju
2140d6b0ff arch: arm: mach-k3: am642_init: Correct the function name spl_boot_mode() to spl_mmc_boot_mode()
Function spl_boot_mode() is called in common/spl/spl_mmc.c, to find the
boot mode for a given boot device. This function was renamed to
spl_mmc_boot_mode() by commit e97590654a.

Therefore, rename spl_boot_mode to spl_mmc_boot_mode.

Fixes: 57dba04afb ("arm: mach-k3: am642: Add support for boot device detection")
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210726152807.22991-2-a-govindraju@ti.com
2021-07-27 10:58:49 +05:30
Gowtham Tammana
ba7455a796 arm: mach-k3: am642_init: Add missing ddr guard
The `struct udevice *` reference is needed for either of the
K3_LOAD_SYSFW, K3_AM64_DDRSS config guards. Adding the missing
K3_AM64_DDRSS guard.

Signed-off-by: Gowtham Tammana <g-tammana@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210624171614.14244-1-g-tammana@ti.com
2021-07-15 17:56:04 +05:30
Dave Gerlach
61305e00c7 arm: mach-k3: j721e_init: Force early probe of clk-k3 driver
Force the clk-k3 driver to probe early during R5 SPL boot to ensure the
default system clock configuration is completed. Many other drivers
assume a default state of the clock tree and it is currently possible
for them to probe before clk-k3 depending on the exact system
configuration.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Reported-by: Keerthy <j-keerthy@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tero Kristo <kristo@kernel.org>
2021-06-11 16:34:52 +05:30
Tero Kristo
925698daac arm: mach-k3: sysfw-loader: pass boardcfg to sciserver
Copy the contents of the board config loaded from sysfw.itb into an
EXTBOOT shared memory buffer that gets passed to sciserver. This only
needs to be done if EXTBOOT area has not been populated by ROM code yet.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tero Kristo <kristo@kernel.org>
2021-06-11 16:34:52 +05:30
Dave Gerlach
7acd4d7142 arm: mach-k3: common: Drop main r5 start
Only start-up the non-linux remote cores if we are running in legacy
boot mode. HSM rearch is not yet supporting this.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tero Kristo <kristo@kernel.org>
2021-06-11 16:34:52 +05:30