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>
I2C EEPROM data contains the board name and its revision.
Add support for:
- Reading EEPROM data and store a copy at end of SRAM
- Updating env variable with relevant board info
- Printing board info during boot.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
In SPL, DDR should be made available by the end of board_init_f()
so that apis in board_init_r() can use ddr. Adding support for
triggering DDR initialization from board_init_f().
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Change the memory attributes for the DDR regions used by the remote
processors on AM65x so that the cores can see and execute the proper code.
A separate table based on the previous K3 SoCs is introduced since the
number of remote processors and their DDR usage is different between the
SoC families.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
The AM642 SoCs use the Main R5FSS0 as a boot processor, and runs
the R5 SPL that performs the initialization of the System Controller
processor and starting the Arm Trusted Firmware (ATF) on the Arm
Cortex A53 cluster. The Core0 serves as this boot processor and is
parked in WFE after all the initialization. Core1 does not directly
participate in the boot flow, and is simply parked in a WFI.
Power down these R5 cores (and the associated RTI timer resources
that were indirectly powered up) after starting up ATF on A53 by
using the appropriate SYSFW API in release_resources_for_core_shutdown().
This allows these Main R5F cores to be further controlled from the
A53 to run regular applications.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Use the System Firmware (SYSFW) loader framework to load and start
the SYSFW as part of the AM642 early initialization sequence. Also
make use of existing logic to detect if ROM has already loaded sysfw
and avoided attempting to reload and instead just prepare to use already
running firmware.
While at it also initialize the MAIN_UART1 pinmux as it is used by SYSFW
to print diagnostic messages.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
For AM642, ROM supports loading system firmware directly
from boot image. ROM passes information about the number of
images that are loaded to bootloader at a specific address
that is temporary. Add support for storing this information
somewhere permanent before it gets corrupted.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
To access various control MMR functionality the registers need to
be unlocked. Do that for all control MMR regions in the MAIN domain.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
AM642 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: Keerthy <j-keerthy@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@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>
Historically, the reset_cpu() function had an `addr` parameter which was
meant to pass in an address of the reset vector location, where the CPU
should reset to. This feature is no longer used anywhere in U-Boot as
all reset_cpu() implementations now ignore the passed value. Generic
code has been added which always calls reset_cpu() with `0` which means
this feature can no longer be used easily anyway.
Over time, many implementations seem to have "misunderstood" the
existence of this parameter as a way to customize/parameterize the reset
(e.g. COLD vs WARM resets). As this is not properly supported, the
code will almost always not do what it is intended to (because all
call-sites just call reset_cpu() with 0).
To avoid confusion and to clean up the codebase from unused left-overs
of the past, remove the `addr` parameter entirely. Code which intends
to support different kinds of resets should be rewritten as a sysreset
driver instead.
This transformation was done with the following coccinelle patch:
@@
expression argvalue;
@@
- reset_cpu(argvalue)
+ reset_cpu()
@@
identifier argname;
type argtype;
@@
- reset_cpu(argtype argname)
+ reset_cpu(void)
{ ... }
Signed-off-by: Harald Seiler <hws@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
In the spirit of using the same base name for all of these related macros,
rename this to have the operation at the end. This is not widely used so
the impact is fairly small.
Signed-off-by: Simon Glass <sjg@chromium.org>
Now that there is only one sequence number (rather than both requested and
assigned ones) we can simplify this function. Also update its caller to
simplify the logic.
Signed-off-by: Simon Glass <sjg@chromium.org>
The A72 U-Boot code can load and boot a number of the available
R5FSS Cores on the J7200 SoC. Change the memory attributes for the
DDR regions used by the remote processors so that the cores can see
and execute the proper code.
The J7200 SoC has less number of remote processors compared to J721E,
so use less memory for the remote processors. So, a separate table
based on the current J721E table is added for J7200 SoCs, and selected
using the appropriate Kconfig CONFIG_TARGET_J7200_A72_EVM symbol.
Signed-off-by: Suman Anna <s-anna@ti.com>
HBMC controller on TI K3 SoC provides MMIO access to HyperFlash similar
to legacy Parallel CFI NOR flashes. Therefore alias HyperFlash bootmode
to NOR boot to enable SPL to load next stage using NOR boot flow.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Detect if sysfw is already loaded by ROM and pass this information to
sysfw loader. Based on this information sysfw loader either loads the
sysfw image from boot media or just receives the boot notification
message form sysfw.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Suman Anna <s-anna@ti.com>
Starting J7200 SoC, ROM supports for loading sysfw directly from boot
image. ROM passes this information on number of images that are loaded
to bootloader at certain location. Add support for storing this
information before it gets corrupted.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Suman Anna <s-anna@ti.com>
The J7200 SoC is a part of the K3 Multicore SoC architecture platform.
It is targeted for automotive gateway, vehicle compute systems,
Vehicle-to-Vehicle (V2V) and Vehicle-to-Everything (V2X) applications.
The SoC aims to meet the complex processing needs of modern embedded
products.
Some highlights of this SoC are:
* Dual Cortex-A72s in a single cluster, two clusters of lockstep
capable dual Cortex-R5F MCUs and a Centralized Device Management and
Security Controller (DMSC).
* Configurable L3 Cache and IO-coherent architecture with high data
throughput capable distributed DMA architecture under NAVSS.
* Integrated Ethernet switch supporting up to a total of 4 external ports
in addition to legacy Ethernet switch of up to 2 ports.
* Upto 1 PCIe-GEN3 controller, 1 USB3.0 Dual-role device subsystems,
20 MCANs, 3 McASP, eMMC and SD, OSPI/HyperBus memory controller, I3C and
I2C, eCAP/eQEP, eHRPWM among other peripherals.
* One hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
management.
See J7200 Technical Reference Manual (SPRUIU1, June 2020)
for further details: https://www.ti.com/lit/pdf/spruiu1
Add support for detection J7200 SoC
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
In main control mmr there is no partition 4 and partition 6 is available
only on J721e. Fix the same in ctrl_mmr_unlock function
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Suman Anna <s-anna@ti.com>
Add an api soc_is_j721e(), and use it to enable certain functionality
that is available only on j721e. This detection is needed when DT is not
available.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Starting J7200 SoC, ROM supports for loading sysfw directly from boot
image. In such cases, SPL need not load sysfw from boot media, but need
to receive boot notification message from sysfw. So separate out
remoteproc calls for system controller from sysfw loader and just
receive the boot notification if sysfw is already loaded.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Suman Anna <s-anna@ti.com>
mmr_unlock api is common for all k3 devices. Move it to a common
location.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Suman Anna <s-anna@ti.com>
If SPL_MULTI_DTB_FIT is not enabled, then CONFIG_SPL_OF_LIST is not defined
And in turn tispl.bin ends up not embedding any DTB.
Fixing it by using CONFIG_DEFAULT_DEVICE_TREE if SPL_OF_LIST is empty.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Guard all eeprom probe with TI_I2C_BOARD_DETECT to avoid reading eeprom
when eeprom is not available
Reviewed-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
U-boot only supports either USB host or device mode for a node at a
time in dts. To support both host and dfu bootmodes, set "peripheral"
as the default dr_mode but fixup property to "host" if host bootmode
is detected.
This needs to happen before the dwc3 generic layer binds the usb device
to a host or device driver. Therefore, add an fdtdec_setup_board()
implementation to fixup the dt based on the boot mode.
Also use the same fixup function to set the USB-PCIe Serdes mux to PCIe
in both the host and device cases. This is required for accessing the
interface at USB 2.0 speeds.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
In order to be able to use things like file system drivers early on in
SPL (before relocation) in a memory-constrained environment when DDR is
not yet available we cannot use the simple malloc scheme which does not
implement the freeing of previously allocated memory blocks. To address
this issue go ahead and enable the use of the full malloc by manually
initializing the required functionality inside board_init_f by creating
a full malloc pool inside the pre-relocation malloc pool.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
When switching on or off the ARM caches some care must be taken to ensure
existing cache line allocations are not left in an inconsistent state.
An example of this is when cache lines are considered non-shared by
and L3 controller even though the lines are shared. To prevent these
and other issues all cache lines should be cleared before enabling
or disabling a coherent master's cache. ARM cores and many L3 controllers
provide a way to efficiently clean out all cache lines to allow for
this, unfortunately there is no such easy way to do this on current K3
MSMC based systems.
We could explicitly clean out every valid external address tracked by
MSMC (all of DRAM), or we could attempt to identify only the set of
addresses accessed by a given boot stage and flush only those
specifically. This patch attempts the latter. We start with cleaning the
SPL load address. More addresses can be added here later as they are
identified.
Note that we perform a flush operation for both the flush and invalidate
operations, this is not a typo. We do this to avoid the situation that
some ARM cores will promote an invalidate to a clean+invalidate, but only
emit the invalidation operation externally, leading to a loss of data.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Tested-by: Faiz Abbas <faiz_abbas@ti.com>
This header file should not be included in other header files. Remove it
and use a forward declaration instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
When binman is in use, most of the targets built by the Makefile are
inputs to binman. We then need a final rule to run binman to produce the
final outputs.
Rename the variable to indicate this, and add a new 'inputs' target.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Replace the function spl_board_prepare_for_boot_linux by the correct
name of the weak function spl_board_prepare_for_linux defined in spl.h.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Buiding u-boot-spl-k3[_HS].its is currently unconditionally verbose
about what it does. Change that by wrapping the call to k3_fit_atf.sh
into a cmd, also using that chance to reduce duplicate lines of makefile
code - only IS_HS=1 is different when CONFIG_TI_SECURE_DEVICE is on.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Acked-by: Lokesh Vutla <lokeshvutla@ti.com>
- Enable DM_ETH on omap3_logic board
- Enable Caches in SPL for K3 platforms
- Enable backup boot mode support for J721E
- Update the DDR timings for AM654 EVM
- Add automated tests for RX-51
Add support for enabling dcache already in SPL. It accelerates the boot
and resolves the risk to run into unaligned 64-bit accesses.
Based on original patch by Lokesh Vulta.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Acked-by: Lokesh Vutla <lokeshvutla@ti.com>
When the boot of J721E devices using the primary bootmode (configured
via device pins) fails a boot using the configured backup bootmode is
attempted. To take advantage of the backup boot mode feature go ahead
and add support to the J721E init code to determine whether the ROM code
performed the boot using the primary or backup boot mode, and if booted
from the backup boot mode, decode the bootmode settings into the
appropriate U-Boot mode accordingly so that the boot can proceed.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.
Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.
Signed-off-by: Simon Glass <sjg@chromium.org>
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>
The function's name is misleading as one might think it is used
generally to select the boot-mode when in reality it is only used by the
MMC driver to find out in what way it should try reading U-Boot Proper
from a device (either using a filesystem, a raw sector/partition, or an
eMMC boot partition).
Rename it to spl_mmc_boot_mode() to make it more obvious what this
function is about.
Link: https://lists.denx.de/pipermail/u-boot/2020-April/405979.html
Signed-off-by: Harald Seiler <hws@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
JTAG ID register is defined by IEEE 1149.1 for device identification.
Use this JTAG ID register for identifying AM65x[0] and J721E[1] devices
instead of using SoC specific registers.
[0] http://www.ti.com/lit/ug/spruid7e/spruid7e.pdf
[1] http://www.ti.com/lit/ug/spruil1a/spruil1a.pdf
Reported-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
K3 J721E:
* OSPI boot support
* Support for loading remote cores in R5 SPL
* PMIC ESM Support
* Minor fixes for R5F and C7x remoteproc drivers
K3 AM654:
* Update AVS class 0 voltages.
* Add I2C nodes
DRA7xx/AM57xx:
* Fixed Android boot on AM57xx
AM33/AM43/Davinci:
* switch to driver model for the net and mdio driver for baltos
* Add DM/DTS support for omap video driver
* Enable fastboot on am335x-evm
The A72 U-Boot code supports early load and boot of a number of
remote processors including the C66_0 and C66_1 DSPs. The current
code supports only loading into the DDR regions which were already
given the appropriate memory attributes. The C66 DSPs also have L1
and L2 internal memory regions that can behave as normal-memories.
Add a new entry to the J721E MMU table covering these regions with
the appropriate memory attributes to allow the A72 U-Boot code to
support loading directly into these memory regions.
Signed-off-by: Suman Anna <s-anna@ti.com>
Add a separate function for printing sysfw version so that it can be
called independently of k3_sysfw_loader.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
System firmware does not guarantee that clocks going out of the device
will be stable during power management configuration. There are some
DCRC errors when SPL tries to get the next stage during eMMC boot after
sysfw pm configuration.
Therefore add a config_pm_pre_callback() to switch off the eMMC clock
before power management and restart it after it is done.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
MCU Domain rf50 is currently shutting down after loading the ATF.
Load elf firmware and jump to firmware post loading ATF.
ROM doesn't enable ATCM memory, so make sure that firmware that
is being loaded doesn't use ATCM memory or override SPL.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Add MAIN domain R5FSS0 remoteproc support from spl. This enables
loading the elf firmware in SPL and starting the remotecore.
In order to start the core, there should be a file with path
"/lib/firmware/j7-main-r5f0_0-fw" under filesystem
of respective boot mode.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
[Guard start_non_linux_remote_cores under CONFIG_FS_LOADER]
Signed-off-by: Andreas Dannenberg <dannenberg@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>
Populate address mapping entries in A53 MMU for 4 GB of MMIO space
reserved for providing MMIO access to multiple flash devices through
OSPI/HBMC IPs within FSS.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Activate early console functionality on AM65x devices to allow for
early diagnostic messages until the main console is ready
to get activated.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@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>
Data manual mentions the new silicon revisions as SR instead of PG. Use
the same nomenclature inside U-Boot as well.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Add support to download SYSFW into internal RAM via DFU in DFU boot
mode. Prepare a DFU config entity entry dynamically using buffer address
allocated for SYSFW and start DFU gadget to get SYSFW.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
J721e does not support USB Host MSC boot, but only supports DFU boot.
Since BOOT_DEVICE_USB is often used for host boot mode and
BOOT_DEVICE_DFU is used for DFU boot, rename BOOT_DEVICE_USB macro to
BOOT_DEVICE_DFU
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
K3 J721E:
* DMA support.
* MMC and ADMA support.
* EEPROM support.
* J721e High Security EVM support.
* USB DT nodes
K3 AM654:
* Fixed boot due to pmic probe error.
* USB support and DT nodes.
* ADMA support
DRA7xx/AM57xx:
* BBAI board support
* Clean up of net platform code under board/ti
AM33/AM43/Davinci:
* Reduce SPL size for omap3 boards.
* SPL DT support for da850-lcdk
* PLL divider fix for AM335x
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>
ROM configures certain firewalls based on its usage, which includes
the one in front of boot peripherals. In specific case of boot
peripherals, ROM does not open up the full address space corresponding
to the peripherals. Like in OSPI, ROM only configures the firewall region
for 32 bit address space and mark 64bit address space flash regions
as in-accessible.
When security-cfg is initialized by sysfw, all the non-configured
firewalls are kept in bypass state using a global setting. Since ROM
configured firewalls for certain peripherals, these will not be touched.
So when bootloader touches any of the address space that ROM marked as
in-accessible, system raises a firewall exception causing boot hang.
It would have been ideal if sysfw cleans up the ROM configured boot
peripheral firewalls. Given the memory overhead to store this
information provided by ROM and the boot time increase in re configuring
the firewalls, it is concluded to clean this up in bootloaders.
So disable all the firewalls that ROM doesn't open up the full address
space.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Venkateswara Rao Mandela <venkat.mandela@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
This file used to be the common location for K3 init when AM6 was the
only device, but common code was moved to common.c and this file became
AM6 specific, correct this header text.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
On K3 systems U-Boot runs on both an R5 and a large ARM cores (usually
A53 or A72). The large ARMs are coherent with the DMA controllers and
the SYSFW that perform authentication. And previously the R5 core did
not enable caches. Now that R5 does enable caching we need to be sure
to clean out any of the image that may still only be in cache before we
read it using external DMA for authentication.
Although not expected to happen, it may be possible that the data was
read back into cache after the flush but before the external operation,
in this case we must invalidate our stale local cached version.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Not finding a node that we try to disable does not always need to be
fatal to boot but should at least print out a warning. Return error
from fdt_disable_node as it did fail to disable the node, but only
warn in the case of disabling the TRNG as this will not prevent boot.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
The TI J721E EVM system on module (SOM), the common processor board, and
the associated daughtercards have on-board I2C-based EEPROMs containing
board config data. Use the board detection infrastructure to do the
following:
1) Parse the J721E SOM EEPROM and populate items like board name, board
HW and SW revision as well as board serial number into the TI common
EEPROM data structure residing in SRAM scratch space
2) Check for presence of daughter card(s) by probing associated I2C
addresses used for on-board EEPROMs containing daughter card-specific
data. If such a card is found, parse the EEPROM data such as for
additional Ethernet MAC addresses and populate those into U-Boot
accordingly
3) Dynamically apply daughter card DTB overlays to the U-Boot (proper)
DTB during SPL execution
4) Dynamically create an U-Boot ENV variable called name_overlays
during U-Boot execution containing a list of daugherboard-specific
DTB overlays based on daughercards found to be used during Kernel
boot.
This patch adds support for the J721E system on module boards containing
the actual SoC ("J721EX-PM2-SOM", accessed via CONFIG_EEPROM_CHIP_ADDRESS),
the common processor board ("J7X-BASE-CPB"), the Quad-Port Ethernet
Expansion Board ("J7X-VSC8514-ETH"), the infotainment board
("J7X-INFOTAN-EXP") as well as for the gateway/Ethernet switch/industrial
expansion board ("J7X-GESI-EXP").
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
At present panic() is in the vsprintf.h header file. That does not seem
like an obvious choice for hang(), even though it relates to panic(). So
let's put hang() in its own header.
Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: Migrate a few more files]
Signed-off-by: Tom Rini <trini@konsulko.com>
On K3 devices there are 2 conditions where R5F can deadlock:
1.When software is performing series of store operations to
cacheable write back/write allocate memory region and later
on software execute barrier operation (DSB or DMB). R5F may
hang at the barrier instruction.
2.When software is performing a mix of load and store operations
within a tight loop and store operations are all writing to
cacheable write back/write allocates memory regions, R5F may
hang at one of the load instruction.
To avoid the above two conditions disable linefill optimization
inside Cortex R5F which will make R5F to only issue up to 2 cache
line fills at any point of time.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
In SPL, DDR should be made available by the end of board_init_f()
so that apis in board_init_r() can use ddr. Adding support for
triggering DDR initialization from board_init_f().
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
U-Boot cleans and invalidate L1 and L2 caches before jumping to Linux
by set/way in cleanup_before_linux(). Additionally there is a custom
hook provided to clean and invalidate L3 cache.
Unfortunately on K3 devices(having a coherent architecture), there is no
easy way to quickly clean all the cache lines for L3. The entire address
range needs to be cleaned and invalidated by Virtual Address. This can
be implemented using the L3 custom hook but it take lot of time to clean
the entire address range. In the interest of boot time this might not be
a viable solution.
The best hit is to make sure the loaded Linux image is flushed so that
the entire image is written to DDR from L3. When Linux starts running with
caches disabled the full image is available from DDR.
Reported-by: Andrew F. Davis <afd@ti.com>
Reported-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
The A72 U-Boot code loads and boots a number of remote processors
including the C71x DSP, both the C66_0 and C66_1 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 by 256MB.
Signed-off-by: Kedar Chitnis <kedarc@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
The A53 U-Boot code can load and boot the MCU domain R5F cores (either a
single core in LockStep mode or 2 cores in Split mode) to achieve various
early system functionalities. Change the memory attributes for the DDR
regions used by the remote processors so that the cores can see and
execute the proper code loaded by U-Boot.
These regions are currently limited to 0xa0000000 to 0xa2100000 as per
the DDR carveouts assigned for these R5F cores in the overall DDR memory
map.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
In order to allow booting TI K3 family SoCs via Y-Modem add support for
loading System Firmware by tapping into the associated SPL core loader
function.
In this context also make sure a console is available and if not go
ahead and activate the early console feature which allows bringing up
an alternate full console before the main console is activated. Such
an alternate console is typically setup in a way that the associated
UART can be fully initialized prior to SYSFW services being available.
Signed-off-by: Andreas Dannenberg <dannenberg@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>
On HS devices the access to TRNG is restricted on the non-secure
ARM side, disable the node in DT to prevent firewall violations.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-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 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>
API get_ti_sci_handle() is relying on the device-tree node name
to be "dmsc" for probing the ti_sci device. But with the introduction
of debug messages for dmsc, the node name changed to dmsc@44083000.
Because of this ti_sci is never probed cause a boot failure. Instead
of relying on device-tree node name, use the first available firmware
node for probing ti_sci.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
A previous commit...
commit 2a51e16bd5 ("configs: Make USE_TINY_PRINTF depend on SPL||TPL and be default")
...causes the System Firmware version string during SPL boot to no longer
getting printed to the console as expected. To fix this issue rework the
handling of that string to only use basic printf() syntax rather than
for example disabling CONFIG_USE_TINY_PRINTF on affected devices, this
way maintaining most of the memory size benefit the initial patch brings
when it comes to SPL.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
The A72 U-Boot code loads and boots a number of remote processors
including the C71x DSP, both the C66_0 and C66_1 DSPs, and the various
Main R5FSS Cores. Change the memory attributes for the DDR regions used
by the remote processors so that the cores can see and execute the
proper code.
A separate table based on the current AM65x table is added for J721E SoCs,
since the number of remote processors and their DDR usage will be different
between the two SoC families.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Use the System Firmware (SYSFW) loader framework to load and start
the SYSFW as part of the J721E early initialization sequence. While
at it also initialize the MCU_UART0 pinmux as it is used by SYSFW
to print diagnostic messages.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Populate the release_resources_for_core_shutdown() api with
shutting down r5 cores so that it will by called just after
jumping to ATF.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Obtain the boot index as left behind by the device boot ROM and store
it in scratch pad SRAM for later use before it may get overwritten.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
To access various control MMR functionality the registers need to
be unlocked. Do that for all control MMR regions in the MCU and MAIN
domains. We may want to go back later and limit the unlocking that's
being done.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
J721E 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: Faiz Abbas <faiz_abbas@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>
Rather than simply parking the R5 core in WFE after starting up ATF
on A53 instead use SYSFW API to properly shut down the R5 CPU cores
as well as associated timer resources that were pre-allocated. This
allows software further downstream to properly and gracefully bring
the R5 cores back online if desired.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
