Fix the regression that occurred during the alignment of binman series
merges along with these HS fixes that caused silent regression in this.
Fixes: 30a7ee87fd ("Kconfig: j721s2: Change K3_MCU_SCRATCHPAD_BASE to non firewalled region")
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
When booting with HS silicon, the system firmware image is 278270, which
is slightly larger than currently allocated amount.
This can cause unexpected behavior if this overlap interferes with other
things in memory, so increase this with a slightly margin added as well
to avoid any boot issues that can appear after system firmware gets
loaded.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Tero Kristo <kristo@kernel.org>
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
In non-combined boot flow for K3, all the firewalls are locked by default
until sysfw comes up. Rom configures some of the firewall for its usage
along with the SRAM for R5 but the PSRAM region is still locked.
The K3 MCU Scratchpad for j721e was set to a PSRAM region triggering the
firewall exception before sysfw came up. The exception started happening
after adding multi dtb support that accesses the scratchpad for reading
EEPROM contents.
The commit changes R5 MCU scratchpad for j721e to an SRAM region.
Old Map:
┌─────────────────────────────────────┐ 0x41c00000
│ SPL │
├─────────────────────────────────────┤ 0x41c40000 (approx)
│ STACK │
├─────────────────────────────────────┤ 0x41c85b20
│ Global data │
│ sizeof(struct global_data) = 0xd8 │
├─────────────────────────────────────┤ gd->malloc_base = 0x41c85bfc
│ HEAP │
│ CONFIG_SYS_MALLOC_F_LEN = 0x70000 │
├─────────────────────────────────────┤ CONFIG_SPL_BSS_START_ADDR
│ SPL BSS │ (0x41cf5bfc)
│ CONFIG_SPL_BSS_MAX_SIZE = 0xA000 │
└─────────────────────────────────────┘ CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX
(0x41cffbfc)
New Map:
┌─────────────────────────────────────┐ 0x41c00000
│ SPL │
├─────────────────────────────────────┤ 0x41c40000 (approx)
│ EMPTY │
├─────────────────────────────────────┤ 0x41c81920
│ STACK │
│ SPL_SIZE_LIMIT_PROVIDE_STACK=0x4000 │
├─────────────────────────────────────┤ 0x41c85920
│ Global data │
│ sizeof(struct global_data) = 0xd8 │
├─────────────────────────────────────┤ gd->malloc_base = 0x41c859f0
│ HEAP │
│ CONFIG_SYS_MALLOC_F_LEN = 0x70000 │
├─────────────────────────────────────┤ CONFIG_SPL_BSS_START_ADDR
│ SPL BSS │ (0x41cf59f0)
│ CONFIG_SPL_BSS_MAX_SIZE = 0xA000 │
├─────────────────────────────────────┤ 0x41cff9fc
│ NEW MCU SCRATCHPAD │
│ SYS_K3_MCU_SCRATCHPAD_SIZE = 0x200 │
└─────────────────────────────────────┘ CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX
(0x41cffbfc)
Fixes: ab977c8b91 ("configs: j721s2_evm_r5: Enable support for building multiple dtbs into FIT")
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
[n-francis@ti.com: SRAM allocation addressing diagram]
Signed-off-by: Neha Francis <n-francis@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Kamlesh Gurudasani <kamlesh@ti.com>
On K3 HS-SE devices all the firewalls are locked by default
until sysfw comes up. Rom configures some of the firewall for its usage
along with the SRAM for R5 but the PSRAM region is still locked.
The K3 MCU Scratchpad for j721s2 was set to a PSRAM region triggering the
firewall exception before sysfw came up. The exception started happening
after adding multi dtb support that accesses the scratchpad for reading
EEPROM contents.
Old map:
┌─────────────────────────────────────┐ 0x41c00000
│ SPL │
├─────────────────────────────────────┤ 0x41c61f20 (approx)
│ STACK │
├─────────────────────────────────────┤ 0x41c65f20
│ Global data │
│ sizeof(struct global_data) = 0xd8 │
├─────────────────────────────────────┤ gd->malloc_base = 0x41c66000
│ HEAP │
│ CONFIG_SYS_MALLOC_F_LEN = 0x10000 │
├─────────────────────────────────────┤ CONFIG_SPL_BSS_START_ADDR
│ SPL BSS │ (0x41c76000)
│ CONFIG_SPL_BSS_MAX_SIZE = 0xA000 │
├─────────────────────────────────────┤ (0x41c80000)
│ DM DATA │
├─────────────────────────────────────┤ (0x41c84130) (approx)
│ EMPTY │
└─────────────────────────────────────┘ CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX
(0x41cffbfc)
New map:
┌─────────────────────────────────────┐ 0x41c00000
│ SPL │
├─────────────────────────────────────┤ 0x41c61f20 (approx)
│ STACK │
├─────────────────────────────────────┤ 0x41c65f20
│ Global data │
│ sizeof(struct global_data) = 0xd8 │
├─────────────────────────────────────┤ gd->malloc_base = 0x41c66000
│ HEAP │
│ CONFIG_SYS_MALLOC_F_LEN = 0x10000 │
├─────────────────────────────────────┤ CONFIG_SPL_BSS_START_ADDR
│ SPL BSS │ (0x41c76000)
│ CONFIG_SPL_BSS_MAX_SIZE = 0xA000 │
├─────────────────────────────────────┤ (0x41c80000)
│ DM DATA │
├─────────────────────────────────────┤ (0x41c84130) (approx)
│ EMPTY │
├─────────────────────────────────────┤ SYS_K3_MCU_SCRATCHPAD_BASE
│ SCRATCHPAD │ (0x41cff9fc)
│ SYS_K3_MCU_SCRATCHPAD_SIZE = 0x200 │
└─────────────────────────────────────┘ CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX
(0x41cffbfc)
Reviewed-by: Kamlesh Gurudasani <kamlesh@ti.com>
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
This matches how it was done for pre-K3 TI platforms and it allows
us to move the forward declaration out of sys_proto.h.
It also removes the need for K3_BOARD_DETECT as one is free to simply
override the weak function in their board files as needed.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
For non TI boards it is not possible to enable the do_board_detect()
call as TI_I2C_BOARD_DETECT is defined in board/ti/common/Kconfig.
I want to use do_board_detect() to dectect boards and properties based
on some SPI communication with a FPGA.
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Texas Instruments has begun enabling security settings on the SoCs it
produces to instruct ROM and TIFS to begin protecting the Security
Management Subsystem (SMS) from other binaries we load into the chip by
default.
One way ROM and TIFS do this is by enabling firewalls to protect the
OCSRAM and HSM RAM regions they're using during bootup.
The HSM RAM the wakeup SPL is in is firewalled by TIFS to protect
itself from the main domain applications. This means the 'bootindex'
value in HSM RAM, left by ROM to indicate if we're using the primary
or secondary boot-method, must be moved to OCSRAM (that TIFS has open
for us) before we make the jump to the main domain so the main domain's
bootloaders can keep access to this information.
Signed-off-by: Bryan Brattlof <bb@ti.com>
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>
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>
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>
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>
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>
On J7 family of SoCs (J721E and J7200), sysfw is being split to be run
under two cores, TIFS portion on DMSC core, and DM firmware under MCU
R5. As MCU R5 is also used to run one phase of the bootloader, we must
prevent access from here towards sysfw services. To support this, add
new config option which can be used to detect presence of RM/PM sysfw
services.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tero Kristo <kristo@kernel.org>
Add support for providing ATF load address with a Kconfig symbol.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Suman Anna <s-anna@ti.com>
Link: https://lore.kernel.org/r/20210604163043.12811-2-a-govindraju@ti.com
The AM642 SoC belongs to the K3 Multicore SoC architecture platform,
providing advanced system integration to enable applications such as
Motor Drives, PLC, Remote IO and IoT Gateways.
Some highlights of this SoC are:
* Dual Cortex-A53s in a single cluster, two clusters of dual Cortex-R5F
MCUs, and a single Cortex-M4F.
* Two Gigabit Industrial Communication Subsystems (ICSSG).
* Integrated Ethernet switch supporting up to a total of two external
ports.
* PCIe-GEN2x1L, USB3/USB2, 2xCAN-FD, eMMC and SD, UFS, OSPI memory
controller, QSPI, I2C, eCAP/eQEP, ePWM, ADC, among other
peripherals.
* Centralized System Controller for Security, Power, and Resource
Management (DMSC).
See AM64X Technical Reference Manual (SPRUIM2, Nov 2020)
for further details: https://www.ti.com/lit/pdf/spruim2
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
The memory allocated to store the FIT image containing SYSFW and board
configuration data is statically defined to the largest size expected.
Some additions to the board configuration data has pushed us slightly
over the current defined size on some HS devices, expand to 278000.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Since ROM configures OSPI controller to be in memory mapped mode in OSPI
boot, R5 SPL can directly pass the memory mapped pointer to ROM. With
this ROM can directly pull the SYSFW image from OSPI.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The boot parameter table index memory address for J721E was configured
to an incorrect value which prevented the use of this definition to
determine which boot parameter table is active which is needed to be
able to distinguish between primary and backup boot modes. Fix this
issue by updating the value to the correct one also in alignment with
the J721E Technical Reference Manual (TRM).
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
The memory allocated to store the FIT image containing SYSFW and board
configuration data is statically defined to the largest size expected.
This was 276000 bytes but now needs to be grown to 277000 to make room
for the slightly larger SYSFW image used on J721e High-Security devices.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
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>
The memory allocated to store the FIT image containing SYSFW and board
configuration data is statically defined to the largest size expected.
This was 269000 bytes but now needs to be grown to 276000 to make room
for the signatures attached to the board configuration data on High
Security devices.
Signed-off-by: Andrew F. Davis <afd@ti.com>
The J721E SoC belongs to the K3 Multicore SoC architecture platform,
providing advanced system integration to enable lower system costs
of automotive applications such as infotainment, cluster, premium
Audio, Gateway, industrial and a range of broad market applications.
This SoC is designed around reducing the system cost by eliminating
the need of an external system MCU and is targeted towards ASIL-B/C
certification/requirements in addition to allowing complex software
and system use-cases.
Some highlights of this SoC are:
* Dual Cortex-A72s in a single cluster, three clusters of lockstep
capable dual Cortex-R5F MCUs, Deep-learning Matrix Multiply Accelerator(MMA),
C7x floating point Vector DSP, Two C66x floating point DSPs.
* 3D GPU PowerVR Rogue 8XE GE8430
* Vision Processing Accelerator (VPAC) with image signal processor and Depth
and Motion Processing Accelerator (DMPAC)
* Two Gigabit Industrial Communication Subsystems (ICSSG), each with dual
PRUs and dual RTUs
* Two CSI2.0 4L RX plus one CSI2.0 4L TX, one eDP/DP, One DSI Tx, and
up to two DPI interfaces.
* Integrated Ethernet switch supporting up to a total of 8 external ports in
addition to legacy Ethernet switch of up to 2 ports.
* System MMU (SMMU) Version 3.0 and advanced virtualisation
capabilities.
* Upto 4 PCIe-GEN3 controllers, 2 USB3.0 Dual-role device subsystems,
16 MCANs, 12 McASP, eMMC and SD, UFS, OSPI/HyperBus memory controller, QSPI,
I3C and I2C, eCAP/eQEP, eHRPWM, MLB among other peripherals.
* Two hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
management.
* Configurable L3 Cache and IO-coherent architecture with high data throughput
capable distributed DMA architecture under NAVSS
* Centralized System Controller for Security, Power, and Resource
Management (DMSC)
See J721E Technical Reference Manual (SPRUIL1, May 2019)
for further details: http://www.ti.com/lit/pdf/spruil1
Add base support for J721E SoC
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Introduce a framework that allows loading the System Firmware (SYSFW)
binary as well as the associated configuration data from an image tree
blob named "sysfw.itb" from an FS-based MMC boot media or from an MMC
RAW mode partition or sector.
To simplify the handling of and loading from the different boot media
we tap into the existing U-Boot SPL framework usually used for loading
U-Boot by building on an earlier commit that exposes some of that
functionality.
Note that this initial implementation only supports FS and RAW-based
eMMC/SD card boot.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Considering the boot time requirements, Cortex-A core
should be able to start immediately after SPL on R5.
Add support for the same.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Update Makefiles to generate:
- tiboot3.bin: Image format that can be processed by ROM.
Below is the tiboot3.bin image format that is required by ROM:
_______________________
| X509 |
| Certificate |
| ____________________ |
| | | |
| | u-boot-spl.bin | |
| | | |
| |___________________| |
|_______________________|
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Add initial support for AM654 based EVM running on A53. Enable
4GB of DDR available on the EVM so that kernel DTB file
can be updated accordingly.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
[Andreas: Added 4GB ddr support]
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
AM654 allows for booting from primary or backup boot media.
Both media can be chosen individually based on switch settings.
ROM looks for a valid image in primary boot media, if not found
then looks in backup boot media. In order to pass this boot media
information to boot loader, ROM stores a value at a particular
address. Add support for reading this information and determining
the boot media correctly.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
The AM654 device is designed for industrial automation and PLC
controller class platforms among other applications. Introduce
base support for AM654 SoC.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
