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>
This is not needed and we should avoid typedefs. Use the struct instead
and rename it to indicate that it really is a legacy struct.
Signed-off-by: Simon Glass <sjg@chromium.org>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
