K3 platforms have reserved memory regions for TFA and OPTEE which should
be unmapped for U-Boot. While other "no-map" memory regions like the
memory pools for remote cores should not be unmapped to allow U-Boot to
load firmware during remoteproc.
Therefore this patch adds the necessary fdt fixups to properly set the
load address for TFA/OPTEE and unmaps both by mmu_unmap_reserved_mem.
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de>
The boot flow in K3 platforms requires the subsequent boot stages to be
aware of the memory reserved for previous boot binaries. In the regular
boot sequence of:
R5 SPL -> ATF -> OP-TEE -> A-core SPL -> U-Boot -> Kernel,
Both A-core SPL and U-Boot should be made aware of the memory reserved
for ATF and OP-TEE from their device-tree. Currently this information is
absent.
Therefore this patch adds the reserved-memory regions as part of
spl_perform_arch_fixups for the next stage's DT. This is called during
both R5 and A-core SPL which fixes up the DT for their respective next
stages: A-core SPL and U-Boot proper.
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de>
The static memory map for K3 (k3_mem_map) only maps the first DRAM bank
and therefore doesn't scale for platforms with multiple memory banks.
This patch modifies enable_caches to add mem_map_from_dram_banks which
appends all the memory banks to k3_mem_map before calling mmu_setup.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de>
The mmu_setup function configures the page tables based on the board
supplied mem_map struct array. It is called implicitly as part of
dcache_enable but this limits us to only be able to use APIs such as
mmu_change_region_attr only after caches are enabled.
This might lead to speculative accesses before we can unmap a region
that is marked as cacheable in the static memory map.
Therefore this patch exports the mmu_setup function in mmu.h allowing
users to have more control over when the mmu is configured.
For K3 specifically this allows for the following configuration sequence
as part of enable_caches:
static mem_map fixups (TODO) -> mmu_setup -> carveouts using
mmu_change_region_attr (TODO) -> icache/dcache enable
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de>
U-Boot's provided enable_caches enforces the following sequence:
icache_enable -> mmu_setup (as part of dcache_enable) -> dcache_enable
Whereas for K3 devices, we would like to add entries to the provided
static array (k3_mem_map) as per gd->bd->bi_dram and then call mmu_setup
to configure the MMU but also create carveouts for TFA/TEE before we
enable caches to prevent speculative accesses to the region. Thus the
following desired sequence:
add dram banks -> mmu_setup -> carveout TFA/TEE -> icache/dcache enable
Therefore this patch adds K3's own implementation of enable_cache for
ARM64, allowing for greater control over the cache enablement sequence.
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Tested-by: Wadim Egorov <w.egorov@phytec.de>
This reverts commit e58d9284850fa78d364d264087fe744717963675.
Bind method of am65_cpsw_nuss driver will ensure binding of it's child
driver am65_cpsw_nuss_ports, and there is no need to call CPSW driver
explicitly. Remove explicit probing of CPSW driver for AM62x.
Signed-off-by: Chintan Vankar <c-vankar@ti.com>
This reverts both commit 4628730ee6c4 ("mach-k3: add runtime memory
carveouts for MMU table") as well as commit b77066d73261 ("mach-k3: add
dynamic mmu fixups for SPL stage") as some feedback from previous
iterations was missed.
This reverts commit b77066d73261855af406422fbbe28a5d527f4dbf and commit
4628730ee6c40864dbe475e4ca91e47a92f371fe.
Signed-off-by: Tom Rini <trini@konsulko.com>
On platforms with spl splash support i.e CONFIG_VIDEO=y, the top of DDR
is reserved for the framebuffer.
The size for the framebuffer is computed at runtime by video_reserve.
During the MMU configuration an entry corresponding to the framebuffer
should be dynamically created to properly map the required space for the
framebuffer.
Therefore this patch adds k3_spl_mem_map_init which adds the required
MMU entry by querying the gd after the framebuffer size has been
computed in spl_reserve_video_from_ram_top.
For non VIDEO=y platforms, the added k3_spl_mem_map_init function gets
optimized out of the final binary so overall, the spl size is not
impacted[1].
[1]: Tested on clang 19.1.7 and gcc 15.1.1
Signed-off-by: Anshul Dalal <anshuld@ti.com>
Beleswar Padhi <b-padhi@ti.com> says:
This series adds remoteproc support on MCU R5F in Split mode.
During boot, ROM can bring up the boot R5F cores in either lockstep or
split mode based on X509 certificate flags. If booted in lockstep mode,
the MCU R5F cores will run first the R5 SPL, and then once A72 comes up,
will run the Device Manager (DM) firmware. But if booted in split mode, core
0 will run DM firmware and second core sits in WFI. Shut it down so that
other firmwares can later be loaded on them.
The shutdown of MCU R5 Core 1 is invoked at A72 SPL init, as by that
time Device Manager (DM) is up and running on R5 Core 0. The shutdown
of MCU R5 Core 1 is handled by Device Manager itself.
Test logs:
https://gist.github.com/3V3RYONE/ee8e3cb9aa5f4c5c00b059b9c14bfa98
Link: https://lore.kernel.org/r/20250609081429.1724643-1-b-padhi@ti.com
Add a function to print version of the DM firmware in use.
The function queries the firmware capabilities first and if
DM split mode bit is set, sends a request to TISCI for
retrieving the version information.
The DM split mode bit indicates that DM is a separate binary
altogether and hence it will have its own versioning.
Signed-off-by: Moteen Shah <m-shah@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
During boot, ROM can bring up the MCU R5F cores in either lockstep or
split mode based on X509 certificate flags. If booted in split mode,
core 0 will run DM firmware and second core sits in WFI. Add support to
shut down core 1 so that other firmwares can later be loaded on them.
The shutdown of MCU R5 Core 1 is invoked at A72 SPL init, as by that
time Device Manager (DM) is up and running on R5 Core 0. The shutdown
request of Core 1 is handled by Device Manager itself.
Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
Call get_reset_reason() during CPU info output and display the result
if the SoC provides the implementation. This helps in debugging by
providing context on the last system reset reason.
Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
Rather than hard coding the maximum memory size, lets just define the
CFG_MAX_MEM_SIZE so get_effective_memsize() will return the correct
value without modification.
Signed-off-by: Bryan Brattlof <bb@ti.com>
Prasanth Babu Mantena <p-mantena@ti.com> says:
The channel allocation and deallocation for dma copy was happening on every
dma transfer. This is a overhead for transactions like NAND, which does
page reads recursively for complete data.
So, moving the dma allocation to probe and implement corresponding
remove function and cleanup dma device while exiting from spl.
Enable SPL_DM_DEVICE_REMOVE, for device removal capability in SPL.
Link: https://lore.kernel.org/r/20241009145703.1970034-1-p-mantena@ti.com
While exiting from spl, remove any dma device active through
spl_board_prepare_for_boot(). This is required for cleaning up
any dma channels being used in spl and avoid issues with overlapping
channel allocation in the next stage bootloaders.
Signed-off-by: Prasanth Babu Mantena <p-mantena@ti.com>
The efi_add_known_memory() function for the TI K3 platforms is adding
the EFI_CONVENTIONAL_MEMORY type. This memory is now being handled
through the LMB module -- the lmb_add_memory() adds this memory to the
memory map. Remove the definition of the now superfluous
efi_add_known_memory() function.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
We don't need a full word for this boolean value. Convert it into a flag
to save space in global_data.
Reviewed-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
The flag will be used for booting authenticated remote procs from hs-se
devices which can optionally be used in hs-fs devices also.
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
Signed-off-by: Udit Kumar <u-kumar1@ti.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> # Intel Edison
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
MD Danish Anwar <danishanwar@ti.com> says:
Introduce ICSSG PRUETH support in uboot. The ICSSG driver is used in TI
AM654 SR2.0.
The ICSSG PRU Sub-system runs on EMAC firmware. This series Introduces
support for ICSSG driver in uboot.
This series has been tested on AM65x SR2.0, and the ICSSG interface is
able to ping / dhcp and boot kernel using tftp in uboot.
To use ICSSG2 ethernet, the ICSSG firmware needs to be loaded to PRU RPROC
cores and RPROC cores need to be booted with the firmware. This step is
done inside driver similar to kernel.
The remoteproc driver uses request_fw_into_buf() API from fs-loader driver
to load and start rproc with the required firmwares.
This series only introduces driver files. The device tree and config
changes to enable ICSSG driver will be introduced later.
This is the PRUSS Ethernet driver for TI AM654 SR2.0 and later SoCs with
the ICSSG PRU Sub-system running EMAC firmware. ICSSG Subsystem supports
two slices per instance. This driver caters to both slices / ports of
the icssg subsystem.
Since it is not possible for Ethernet driver to register more than one
port for a given instance, this patch introduces top level PRUETH as
UCLASS_MISC and binds UCLASS_ETH to individual ports in order to support
bringing up more than one Ethernet interface in U-Boot.
Since top level driver is UCLASS_MISC, board files would need to
instantiate the driver explicitly.
Signed-off-by: MD Danish Anwar <danishanwar@ti.com>
Reviewed-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
During the boot, the EFI loader maps the memory from ram_top to ram_end
as EFI_BOOT_SERVICES_DATA. When LMB does boot_fdt_add_mem_rsv_regions()
to OPTEE, TFA, R5, and M4F DMA/memory "no-map" for the kernel it produces
the following error message:
ERROR: reserving fdt memory region failed (addr=9cb00000 size=100000 flags=4)
ERROR: reserving fdt memory region failed (addr=9cc00000 size=e00000 flags=4)
ERROR: reserving fdt memory region failed (addr=9da00000 size=100000 flags=4)
ERROR: reserving fdt memory region failed (addr=9db00000 size=c00000 flags=4)
ERROR: reserving fdt memory region failed (addr=9e780000 size=80000 flags=4)
ERROR: reserving fdt memory region failed (addr=9e800000 size=1800000 flags=4)
To avoid this, don't flag with EFI_BOOT_SERVICES_DATA the memory from
ram_top to ram_end by the EFI loader.
Signed-off-by: Vitor Soares <vitor.soares@toradex.com>
The disable_linefill_optimization() function is only ever loaded by the
R5 core, move the code into the R5 directory.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Igor Opaniuk <igor.opaniuk@foundries.io>
Refactor common QoS code into a new common header file, and the soc
specific setup_qos functions into a common API.
Rename $(soc)_qos_count and $(soc)_qos_data variables to qos_count and
qos_data. When QoS settings of more SoCs are added, only one pair will
be defined at a time, based on the config SOC_K3_$(soc).
This refactoring has been done for 2 major purposes.
- The auto-generated $(soc)_qos_data.c and $(soc)_qos.h files cannot
have any code that is specific to any bootloader. Those files have to
remain agnostic of different bootloader implementations and their
header files.
- The existing implementation was less than ideal and would have enabled
multiple $(soc)_qos_count and $(soc)_qos_data variables for all SoC
variants.
Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>
Devarsh Thakkar <devarsht@ti.com> says:
Move video memory reservation for SPL at end of RAM so that it does
not interefere with reservations for next stage so that the next stage
need not have holes in between for passed regions and instead it can
maintain continuity in reservations.
Also catch the bloblist before starting reservations to avoid the same
problem.
While at it, also fill missing fields in video handoff struct before
passing it to next stage.
This is as per discussions at :
For moving SPL framebuffer reservation at end of RAM:
https://lore.kernel.org/all/CAPnjgZ3xSoe_G3yrqwuAvoiVjUfZ+YQgkOR0ZTVXGT9VK8TwJg@mail.gmail.com/
For filling missing video handoff fields :
https://lore.kernel.org/all/CAPnjgZ1Hs0rNf0JDirp6YPsOQ5=QqQSP9g9qRwLoOASUV8a4cw@mail.gmail.com/
Setup video memory before page table reservation using
"spl_reserve_video_from_ram_top" which ensures framebuffer memory gets
reserved from the end of RAM.
This is done to enable the next stage to directly skip the
pre-reserved area from previous stage right from the end of RAM without
having to make any gaps/holes to accommodate those regions which was the
case before as previous stage reserved region not from the end of RAM.
Use gd->ram_top instead of local ram_top and update gd->reloc_addr after
each reservation to ensure further regions are reserved properly.
Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
Reviewed-by: Nikhil M Jain <n-jain1@ti.com>
We need to include <config.h> directly when a file needs to have
something such as CFG_SYS_SDRAM_SIZE referenced as this file is not
automatically globally included and is most commonly indirectly included
via common.h. Remove most cases of arm including config.h directly, but
add it where needed. This includes a few board-specific fixes.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Change spl_enable_dcache so it also enable icache on SPL
initialization for the main domain part of the boot flow. This
improves bootloader booting time.
Link: https://lore.kernel.org/all/20231109140958.1093235-1-joao.goncalves@toradex.com/
Signed-off-by: Joao Paulo Goncalves <joao.goncalves@toradex.com>
Tested-by: Nishanth Menon <nm@ti.com>
Use uintptr_t instead of phys_addr_t where appropriate, so passing the
addresses to writel() doesn't result in compile warnings when PHYS_64BIT
is set for 32bit builds (which is actually a useful configuration, as
the K3 SoC family boots from an R5 SPL, which may pass bank information
based on gd->bd->bi_dram to fdt_fixup_memory_banks() etc., so PHYS_64BIT
is needed for fixing up the upper bank).
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
This old patch was marked as deferred. Bring it back to life, to continue
towards the removal of common.h
Move this out of the common header and include it only where needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
The background firewall calculations were wrong, fix that to determine
both the background and foreground correctly.
Fixes: 8bfce2f9989f ("arm: mach-k3: common: reorder removal of firewalls")
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
In spl_dcache_enable after setting up page table, set gd->relocaddr
pointer to tlb_addr, to get next location to reserve memory. Align
tlb_addr with 64KB address.
Signed-off-by: Nikhil M Jain <n-jain1@ti.com>
Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
ft_system_setup cannot be enabled on SoC without msmc sram otherwise
fdt_fixup_msmc_ram function fails causing system reset.
Fix by moving fdt_fixup_msmc_ram to common_fdt.c file and creating
SoC (AM654, J721E and J721S2) specific files for fdt fixups.
This change was verified to not change anything on any existing board
(all the J721S2, AM654 and J721E boards requires it,
none of the remaining k3 boards require it).
Fixes: 30e96a240156 ("arm: mach-k3: Move MSMC fixup to SoC level")
Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.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 b8ebf24e7f4afb5093a31bdf122e1ed0781e5c3c.
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: 1e00e9be62e5 ("arm: mach-k3: common: re-locate authentication for atf/optee")
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>
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 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 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>
