In the first silicon revision of the am62x family of SoCs, the hardware
wakeup event cannot be used if software is unable to unlock the RTC
device within one second after boot. To work around this limitation
unlock RTC as soon as possible in the boot flow to maximize our chance
of linux being able to use this device.
Add the erratum i2327 workaround to initialize the RTC.
Signed-off-by: Nishanth Menon <nm@ti.com>
[bb@ti.com: rebased from 2021.01 and expanded commit and code messages]
Signed-off-by: Bryan Brattlof <bb@ti.com>
ATF and OPTEE regions may be firewalled from non-secure entities.
If we still map them for non-secure A53, speculative access may happen,
which will not cause any faults and related error response will be ignored,
but it's better to not to map those regions for non-secure A53 as there
will be no actual access at all.
Create separate table as ATF region is at different locations for am64
and am62/am62a.
Signed-off-by: Kamlesh Gurudasani <kamlesh@ti.com>
Add main_uart1 clocks in clk-data.c for J7200. Now,
main_uart1 clocks will be set up while booting the J7200 SoC.
Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>
Add device data for main_uart1 in dev-data.c for J7200. Now,
main_uart1 will be powered on while booting the J7200 SoC.
Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>
When selecting UDA partition for booting. MMC read
mode was selected as RAW.
Due to growing/changing size of u-boot and tispl
images.
It will be better change to FS in case of UDA FS instead of
adjusting offsets with new change.
Signed-off-by: Udit Kumar <u-kumar1@ti.com>
Add main_uart5 clocks in clk-data.c for J721S2. Now,
main_uart5 clocks will be set up while booting the J721S2 SoC.
Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Add device data for main_uart5 in dev-data.c for J721S2. Now,
main_uart5 will be powered on while booting the J721S2 SoC.
Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Add main_uart2 clocks in clk-data.c for J721E. Now,
main_uart2 clocks will be set up while booting the J721E SoC.
Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>
Add device data for main_uart2 in dev-data.c for J721E. Now,
main_uart2 will be powered on while booting the J721E SoC.
Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>
K3 devices have some firewalls set up by ROM that we usually remove so
that the development is easy in HS devices.
While removing the firewalls disabling a background region before
disabling the foreground regions keeps the firewall in a state where all
the transactions will be blacklisted until all the regions are disabled.
This causes a race for some other entity trying to access that memory
region before all the firewalls are disabled and causes an exception.
Since there is no guarantee on where the background regions lie based on
ROM configurations or no guarantee if the background regions will allow
all transactions across the memory spaces, iterate the loop twice removing
the foregrounds first and then backgrounds.
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
This reverts commit b8ebf24e7f.
This patch seems to be fundamentally wrong and requires a different way
on how the background firewalls should be configured so revert the patch
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
K3 GP devices allows booting the secure binaries on them by bypassing
the x509 header on them.
ATF and OPTEE firewalling required the rproc_load to be called before
authentication. This change caused the failure for GP devices that
strips off the headers. The boot vector had been set before the headers
were stripped off causing the runtime stripping to fail and stripping
becoming in-effective.
Separate out the secure binary check on GP/HS devices so that the
boot_vector could be stripped before calling rproc_load. This allows
keeping the authentication later when the cluster is on along with
allowing the stripping of the binaries in case of gp devices.
Fixes: 1e00e9be62 ("arm: mach-k3: common: re-locate authentication for atf/optee")
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>
When building for secure devices using non-buildman based image generation
the signed tispl.bin file is called tispl.bin_HS. Also build the unsigned
tispl.bin file as expected.
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Manorit Chawdhry <m-chawdhry@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>
Errata doc: https://www.ti.com/lit/pdf/sprz457
Errata ID i2331 CPSW: Device lockup when reading CPSW registers
Details: A device lockup can occur during the second read of any CPSW
subsystem register after any MAIN domain power on reset (POR). A MAIN
domain POR occurs using the hardware MCU_PORz signal, or via software
using CTRLMMR_RST_CTRL.SW_MAIN_POR or CTRLMMR_MCU_RST_CTRL.SW_MAIN_POR.
After these resets, the processor and internal bus structures may get
into a state which is only recoverable with full device reset using
MCU_PORz.
Due to this errata, Ethernet boot should not be used on this device.
Workaround(s): To avoid the lockup, a warm reset should be issued after
a MAIN domain POR and before any access to the CPSW registers. The warm
reset realigns internal clocks and prevents the lockup from happening.
Workaround above errata by calling do_reset() in case of cold boot in
order to trigger warm reset. This needs enabling SYSRESET driver in R5
SPL to enable TI SCI reset driver.
Signed-off-by: Nitin Yadav <n-yadav@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Enable Quality of Service (QoS) blocks for Display SubSystem (DSS), by
servicing the DSS - DDR traffic from the Real-Time (RT) queue. This is
done by setting the DSS DMA orderID to 8.
The C7x and VPAC have been overwhelming the DSS's access to the DDR
(when it was accessing via the Non Real-Time (NRT) Queue), primarily
because their functional frequencies, and hence DDR accesses, were
significantly higher than that of DSS. This led the display to flicker
when certain edgeAI models were being run.
With the DSS traffic serviced from the RT queue, the flickering issue
has been found to be mitigated.
The am62a qos files are auto generated from the k3 resource partitioning
tool.
Section-3.1.12, "QoS Programming Guide", in the AM62A TRM[1], provides
more information about the QoS, and section-14.1, "System Interconnect
Registers", provides the register descriptions.
[1] AM62A Tech Ref Manual: https://www.ti.com/lit/pdf/spruj16
Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>
J721E and J7200 have same file j721e_init.c which had the firewall
configs for J721E being applied on J7200 causing the warnings. Split the
firewalls for both the boards to remove those warnings.
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
K3 devices have some firewalls set up by ROM that we usually remove so
that the development is easy in HS devices.
While removing the firewalls disabling a background region before
disabling the foreground regions keeps the firewall in a state where all
the transactions will be blacklisted until all the regions are disabled.
This causes a race for some other entity trying to access that memory
region before all the firewalls are disabled and causes an exception.
Since the background regions configured by ROM are in such a manner
that they allow all transactions, don't touch the background regions at
all.
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
Reviewed-by: Kamlesh Gurudasani <kamlesh@ti.com>
Allow non fitImage bootflow on Field Securable (HS-FS) devices in
addition to GP, force fitImage boot only on Security enforced (HS-SE)
devices where signed images are necessary to maintain chain of trust.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Kamlesh Gurudasani <kamlesh@ti.com>
Some firewalls enabled by ROM are still left on. So some
address space is inaccessible to the bootloader. For example,
in OSPI boot mode we get an exception and the system hangs.
Therefore, disable all the firewalls left on by the ROM.
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Reviewed-by: Andrew Davis <afd@ti.com>
Reviewed-by: Manorit Chawdhry <m-chawdhry@ti.com>
Makes it possible to use e.g mcu_spi0 for custom board detection.
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
For setting up the master firewalls present in the K3 SoCs, the arm64
clusters need to be powered on.
Re-locates the code for atf/optee authentication.
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
This matches AM64 and J721e and removes the need to forward
declare k3_spl_init(), k3_mem_init(), and check_rom_loaded_sysfw()
in sys_proto.h.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
These probably should be in some system wide header given their use.
Until then move them out of K3 sys_proto.h so we can finish cleaning
that header out.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.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>
This header is only used locally by K3 init files, no need to have it
up with the global mach includes. Move into local includes.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
This function is the same for each device when it needs to shutdown
the R5 core. Move this to the common section and move the remaining
device specific ID list to the device hardware include.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
This belongs in the J721e specific file as it is the only place
this is used. Any board level users should use the SOC driver.
While here, move the J721e and J7200 SoC IDs out of sys_proto.h
and into hardware.h. Use a macro borrowed from Rockchip and add
the rest of the SoC IDs for completeness and later use.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
The MSMC fixup is something we do based on SoC, not based on the board.
So this fixup does not belong in the board files. Move this to the
mach-k3 common file so that it does not have to be done in each board
that uses these SoCs.
We use ft_system_setup() here instead of ft_board_setup() since it is no
longer board level. Enable OF_SYSTEM_SETUP in the configurations that use
this to keep functionality the same.
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>
On high security devices, ROM enables firewalls to protect the OCSRAM
region access during bootup. Only after TIFS has started (and had
time to disable the OCSRAM firewall region) will we have write access to
the region.
So, move scratch board area to HSM RAM.
Signed-off-by: Kamlesh Gurudasani <kamlesh@ti.com>
Although the board_init_f API initialises the SoC, the API name is
incorrectly specified and misleads the functionality. This file should
only include k3-specific functionality. Change the API's name to something
more K3-specific and separate the function to make it more modular.
Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
The fs_loader device is used to pull in settings via the chosen node.
However, there was no library function for this, so arria10 was doing it
explicitly. This function subsumes that, and uses ofnode_get_chosen_node
instead of navigating the device tree directly. Because fs_loader pulls
its config from the environment by default, it's fine to create a device
with nothing backing it at all. Doing this allows enabling
CONFIG_FS_LOADER without needing to modify the device tree.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ramon Fried <rfried.dev@gmail.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 boot mode detection assumes that BOOT_DEVICE_MMC2 should always
result in MMCSD_MODE_FS, but MMCSD_MODE_RAW is also a valid option for
this port.
The current logic also avoids looking at the bootmode pin strapping,
which should be the primary means of determining whether a device is
being booted in MMCSD_MODE_EMMCBOOT mode.
Switch around the logic to check the boot mode to determine whether the
eMMC boot mode is expected or MMC/SD boot mode. From there we can look
at the boot mode config if in MMC/SD boot mode to determine whether to
attempt RAW or FS based booting.
This change allows U-Boot to also be successfully booted from RAW
offsets in addition to from a filesystem.
Signed-off-by: Martyn Welch <martyn.welch@collabora.com>
Introduce the auto-generated clock tree and power domain data needed to
attach the am62a into the power-domain and clock frameworks of uboot
Signed-off-by: Bryan Brattlof <bb@ti.com>
The rest of the unmigrated CONFIG symbols in the CONFIG_SYS namespace do
not easily transition to Kconfig. In many cases they likely should come
from the device tree instead. Move these out of CONFIG namespace and in
to CFG namespace.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The rest of the unmigrated CONFIG symbols in the CONFIG_SYS_SDRAM
namespace do not easily transition to Kconfig. In many cases they likely
should come from the device tree instead. Move these out of CONFIG
namespace and in to CFG namespace.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The current name is inconsistent with SPL which uses CONFIG_SPL_TEXT_BASE
and this makes it imposible to use CONFIG_VAL().
Rename it to resolve this problem.
Signed-off-by: Simon Glass <sjg@chromium.org>
These hardware register definitions are common for all K3, remove
duplicate data them by moving them to hardware.h.
While here do some minor whitespace cleanup + grouping.
Signed-off-by: Andrew Davis <afd@ti.com>
This matches how this would be done in Linux and these functions
do the alignment for us which makes the code look cleaner.
Signed-off-by: Andrew Davis <afd@ti.com>
This matches what we did for pre-K3 devices. This allows us to build
boot commands that can check for our device type at runtime.
Signed-off-by: Andrew Davis <afd@ti.com>
There are a couple users of uclass_next_device return value that get the
first device by other means and use uclass_next_device assuming the
following device in the uclass is related to the first one.
Use uclass_next_device_err because the return value from
uclass_next_device will be removed in a later patch.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
