commit e7588d81cd upstream.
The arm64 version of the exception command was just defining the
undefined exception, but actually copied the AArch32 instruction.
Replace that with an encoding that is guaranteed to be and stay
undefined. Also add instructions to trigger unaligned access faults and
a breakpoint.
This brings ARM64 on par with ARM(32) for the exception command.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
[nm@ti.com: backport from upstream]
Signed-off-by: Nishanth Menon <nm@ti.com>
commit 5ff4857d35 upstream.
The branch_if_master macro jumps to a label if the CPU is the "master"
core, which we define as having all affinity levels set to 0. To check
for this condition, we need to mask off some bits from the MPIDR
register, then compare the remaining register value against zero.
The implementation of this was slighly broken (it preserved the upper
RES0 bits), overly complicated and hard to understand, especially since
it lacked comments. The same was true for the very similar
branch_if_slave macro.
Use a much shorter assembly sequence for those checks, use the same
masking for both macros (just negate the final branch), and put some
comments on them, to make it clear what the code does.
This allows to drop the second temporary register for branch_if_master,
so we adjust all call sites as well.
Also use the opportunity to remove a misleading comment: the macro
works fine on SoCs with multiple clusters. Judging by the commit
message, the original problem with the Juno SoC stems from the fact that
the master CPU *can* be configured to be from cluster 1, so the
assumption that the master CPU has all affinity values set to 0 does not
hold there. But this is already mentioned above in a comment, so remove
the extra comment.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
[nm@ti.com: Modified from upstream to apply to just relevant files]
Signed-off-by: Nishanth Menon <nm@ti.com>
commit f660fe0bd3 upstream.
The switch_el macro is a neat contraption to handle cases where we need
different code depending on the current exception level, but its
implementation was longer than needed.
Simplify it by doing just one comparison, then using the different
condition codes to branch to the desired target. PState.CurrentEL just
holds two bits, and since we don't care about EL0, we can use >, =, < to
select EL3, EL2 and EL1, respectively.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
[nm@ti.com: backport from upstream]
Signed-off-by: Nishanth Menon <nm@ti.com>
commit 7ab2e47d27 upstream.
asm/io.h is the header file containing the central MMIO accessor macros.
Judging by the header and the comments, it was apparently once copied
from the Linux kernel, but has deviated since then *heavily*. There is
absolutely no point in staying close to the original Linux code anymore,
so just remove the old cruft, by:
- removing pointless Linux history
- removing commented code
- removing outdated comments
- removing unused definitions (for mem_isa)
This massively improves the readability of the file.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
[nm@ti.com: backport from upstream]
Signed-off-by: Nishanth Menon <nm@ti.com>
commit 7ed340a828 upstream.
In ARMv8 we have the choice between two stack pointers to use: SP_EL0 or
SP_ELx, which is banked per exception level. This choice is stored in
the SP field of PState, and can be read and set via the SPSel special
register. When the CPU takes an exception, it automatically switches to
the SP_ELx stack pointer.
Trusted Firmware enters U-Boot typically with SPSel set to 1, so we use
SP_ELx all along as our sole stack pointer, both for normal operation and
for exceptions.
But if we now for some reason enter U-Boot with SPSel cleared, we will
setup and use SP_EL0, which is fine, but leaves SP_ELx uninitialised.
When we now take an exception, we try to save the GPRs to some undefined
location, which will usually end badly.
To make sure we always have SP_ELx pointing to some memory, set SPSel
to 1 in the early boot code, to ensure safe operation at all times.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
[nm@ti.com: backport from upstream]
Signed-off-by: Nishanth Menon <nm@ti.com>
commit e7588d81cd upstream.
The ARMv8 architecture describes the "SError interrupt" as the fourth
kind of exception, next to synchronous exceptions, IRQs, and FIQs.
Those SErrors signal exceptional conditions from which the system might
not easily recover, and are normally generated by the interconnect as a
response to some bus error. A typical situation is access to a
non-existing memory address or device, but it might be deliberately
triggered by a device as well.
The SError interrupt replaces the Armv7 asynchronous abort.
Trusted Firmware enters U-Boot (BL33) typically with SErrors masked,
and we never enable them. However any SError condition still triggers
the SError interrupt, and this condition stays pending, it just won't be
handled. If now later on the Linux kernel unmasks the "A" bit in PState,
it will immediately take the exception, leading to a kernel crash.
This leaves many people scratching their head about the reason for
this, and leads to long debug sessions, possibly looking at the wrong
places (the kernel, but not U-Boot).
To avoid the situation, just unmask SErrors early in the ARMv8 boot
process, so that the U-Boot exception handlers reports them in a timely
manner. As SErrors are typically asynchronous, the register dump does
not need to point at the actual culprit, but it should happen very
shortly after the condition.
For those exceptions to be taken, we also need to route them to EL2,
if U-Boot is running in this exception level.
This removes the respective code snippet from the Freescale lowlevel
routine, as this is now handled in generic ARMv8 code.
Reported-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
[nm@ti.com: backport from upstream]
Signed-off-by: Nishanth Menon <nm@ti.com>
commit 68f08966b0 upstream.
There is some code that tries to "reset" the SCTLR_ELx register early in
the boot process. The idea seems to be to guarantee some sane settings
that U-Boot actually relies on, for instance running in little-endian
mode, with the MMU off initially.
However the current code has multiple problems:
- For a start, no platform or config defines the symbol that would
enable that code.
- The code itself really only works if the bits that it tries to clear
are already cleared:
- If we run in big-endian mode initially, any previous loads would have
been wrong already. That applies to the (optional) relocation code,
but more prominently to the mask that it uses to clear those bits:
"ldr x1, =0xfdfffffa" looks innocent, but actually involves a memory
access to the literal pool, using the current endianness.
- If we run with the MMU enabled, we are probably doomed already. We
*could* hope that we are running with an identity mapping, but would
need to do some cache maintenance to avoid losing dirty cache lines.
- The idea of doing a read-modify-write of SCTLR is somewhat
questionable to begin with, because as the owner of the current
exception level we should initialise all bits of this register with a
certain fixed value.
- The code is unnecessarily complicated, and the function name is
misspelled.
While those problems *could* admittedly be fixed, the point that is does
not seem to be used at all at the moment tells me we should just remove
this code, and be it to not give a bad example.
If people care, I could introduce some proper SCTLR initialisation code.
We are about to work this out for the boot-wrapper[1] as we speak, but
apparently we got away without doing this in U-Boot ever since, so it
might not be worth the potential trouble.
[1] https://lore.kernel.org/linux-arm-kernel/20220114105653.3003399-7-mark.rutland@arm.com/
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
[nm@ti.com: backport from upstream]
Signed-off-by: Nishanth Menon <nm@ti.com>
commit c48fec6e7c upstream.
CNTFRQ_EL0 is only writable from the highest supported exception
level on the platform. For Armv8-A, this is typically EL3, but
technically EL2 and EL3 are optional so it may need to be
initialized at EL2 or EL1. For Armv8-R, the highest exception
level is always EL2.
This patch moves the initialization outside of the switch_el
block and uses a new macro branch_if_not_highest_el which
dynamically detects whether it is at the highest supported
exception level.
Linux's docs state that CNTFRQ_EL0 should be initialized by the
bootloader. If not set, the the U-Boot prompt countdown hangs.
Signed-off-by: Peter Hoyes <Peter.Hoyes@arm.com>
[nm@ti.com: backport from upstream]
Signed-off-by: Nishanth Menon <nm@ti.com>
commit bfb798461a upstream.
On implementations that support VHE, the layout of the CPTR_EL2
register depends on whether HCR_EL2.E2H is set. If the bit is
set, CPTR_EL2 uses the same layout as CPACR_EL1 and can in fact
be accessed through that register. In that case, jump to the
EL1 code to enable access to the FP/SIMD registers. This allows
U-Boot to run on systems that pass control to U-Boot in EL2 with
EL2 Host mode enabled such as machines using Apple's M1 SoC.
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Acked-by: Marc Zyngier <maz@kernel.org>
[nm@ti.com: backport from upstream]
Signed-off-by: Nishanth Menon <nm@ti.com>
In AM62, the maximum supported speed mode in the MMCSD0 instance is HS200.
Therefore, fix the configs to reflect the same.
Fixes: 993a48448c ("configs: Add configs for AM62x SK")
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Add u-boot,dm-spl tag in sdhci0 device tree node to include sdhci0 instance
in R5 and A53 SPL dtb.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Add support for booting from the UDA partition of the eMMC flash. Also, fix
function name from spl_boot_mode to spl_mmc_boot_mode.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
On arm64 systems, recommendation is to use per-cpu timer for time
keeping. Currently AM64 ends up using DM timer as tick timer as driver
is enabled in the config. Drop OMAP DM Timer related configs, this will
switch to using armv8 per-cpu timer as tick timer for A53 SPL/U-Boot.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
wkup_uart0 pinmux is wrongly placed under main_pmx0. Fix this by moving
to mcu_pmx0, without this TIFS logs are not visible on wkup_uart0
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Add mtdids/mtdparts for NAND as it is required for u-boot
mtd subsystem and commands to recognize NAND partitions.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Reviewed-by: Aswath Govindraju <a-govindraju@ti.com>
This should make it easy for user to boot from NAND.
We assume that UBIFS will be used for NAND. This is fine as
there is no better alternative.
User can specify/override the NAND partition and UBIFS volume
for booting via ${bootpart} and ${bootvolume} variables
respectively.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Reviewed-by: Aswath Govindraju <a-govindraju@ti.com>
MCU Timer0 runs at 250MHz, and the clock-frequency defined in DT appears
incorrect.
Without this delays in R5 SPL are 10x off.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Tested-by: Aswath Govindraju <a-govindraju@ti.com>
Timer0 runs at 200MHz,and the clock-frequency defined in DT
is incorrect.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Tested-by: Kishon Vijay Abraham I <kishon@ti.com>
commit bb318d8dc8 upstream.
MCU timer1 is used as the tick timer for MCU R5 SPL, and the
clock-frequency defined in DT appears to be incorrect at the moment.
Actual clock source for the timer is MCU_SYSCLK0 / 4 which is 250MHz.
Earlier setup of 25MHz went unnoticed, as there was a separate issue
with omap-timer, which caused an error to the clock by a factor of 8
with j7 devices. This problem surfaced once the omap-timer was fixed.
Signed-off-by: Tero Kristo <kristo@kernel.org>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
AM62 StarterKit (SK) board is a low cost, small form factor board
designed for TI's AM625 SoC. It supports the following interfaces:
* 2 GB DDR4 RAM
* x2 Gigabit Ethernet interfaces capable of working in Switch and MAC mode
* x1 HDMI Port with audio + x1 OLDI/LVDS Display interface for Dual Display
* x1 Headphone Jack
* x1 USB2.0 Hub with two Type A host and x1 USB Type-C DRP Port
* x1 UHS-1 capable µSD card slot
* 2.4/5 GHz WLAN + Bluetooth 4.2 through WL1837
* 512 Mbit OSPI flash
* x4 UART through UART-USB bridge
* XDS110 for onboard JTAG debug using USB
* Temperature sensors, user push buttons and LEDs
* 40-pin User Expansion Connector
* 24-pin header for peripherals in MCU island (I2C, UART, SPI, IO)
* 20-pin header for Programmable Realtime Unit (PRU) IO pins
* 15-pin CSI header
Add basic support for AM62-SK.
Schematics: https://www.ti.com/lit/zip/sprr448
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Add basic support for AM64 SK. This has 2GB DDR.
Note that stack for R5 SPL is in OCRAM @ 0x7000ffff so that is away from
BSS and does not step on BSS section
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Introduce the basic AM62 SoC description dtsi files. While doing this,
lets reuse the DDR controller definition from AM64 as the instance is
the same
Signed-off-by: Gowtham Tammana <g-tammana@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Introduce autogenerated SoC data support clk and device data for the
AM62. Hook it upto to power-domain and clk frameworks of U-Boot.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The AM62 SoC family is the follow on AM335x built on K3 Multicore SoC
architecture platform, providing ultra-low-power modes, dual display,
multi-sensor edge compute, security and other BOM-saving integration.
The AM62 SoC targets broad market to enable applications such as
Industrial HMI, PLC/CNC/Robot control, Medical Equipment, Building
Automation, Appliances and more.
Some highlights of this SoC are:
* Quad-Cortex-A53s (running up to 1.4GHz) in a single cluster.
Pin-to-pin compatible options for single and quad core are available.
* Cortex-M4F for general-purpose or safety usage.
* Dual display support, providing 24-bit RBG parallel interface and
OLDI/LVDS-4 Lane x2, up to 200MHz pixel clock support for 2K display
resolution.
* Selectable GPUsupport, up to 8GFLOPS, providing better user experience
in 3D graphic display case and Android.
* PRU(Programmable Realtime Unit) support for customized programmable
interfaces/IOs.
* Integrated Giga-bit Ethernet switch supporting up to a total of two
external ports (TSN capable).
* 9xUARTs, 5xSPI, 6xI2C, 2xUSB2, 3xCAN-FD, 3x eMMC and SD, GPMC for
NAND/FPGA connection, OSPI memory controller, 3xMcASP for audio,
1x CSI-RX-4L for Camera, eCAP/eQEP, ePWM, among other peripherals.
* Dedicated Centralized System Controller for Security, Power, and
Resource Management.
* Multiple low power modes support, ex: Deep sleep,Standby, MCU-only,
enabling battery powered system design.
AM625 is the first device of the family. Add DT bindings for the same.
More details can be found in the Technical Reference Manual:
https://www.ti.com/lit/pdf/spruiv7
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Gowtham Tammana <g-tammana@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Add pinctrl macros for AM62x SoCs. These macro definitions are similar
to that of previous platforms, but adding new definitions to avoid any
naming confusions in the SoC dts files.
checkpatch insists the following error exists:
ERROR: Macros with complex values should be enclosed in parentheses
However, we do not need parentheses enclosing the values for this
macro as we do intend it to generate two separate values as has been
done for other similar platforms.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The phy used in the 8 bit instance has been changed to the phy used in 4
bit instance on AM62 SoC. This implies the phy configuration required for
both the instances of mmc are similar. Therefore, add a new compatible
for AM62 SoC using the driver data of am64 4 bit instance.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Fix below compile warnings
drivers/clk/clk-k3.c:329:10: warning: format â%uâ expects argument of type âunsigned intâ, but argument 3 has type âulongâ {aka âlong unsigned intâ} [-Wformat=]
329 | debug("%s: Using better rate %u that gives diff %d\n",
drivers/clk/clk-k3.c:329:10: warning: format â%dâ expects argument of type âintâ, but argument 4 has type âulongâ {aka âlong unsigned intâ} [-Wformat=]
329 | debug("%s: Using better rate %u that gives diff %d\n",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
commit 11326f3793 upstream.
The prescaler (PTV) setting must be taken into account even when the
timer input clock frequency has been set.
Signed-off-by: Dario Binacchi <dariobin@libero.it>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Initialization and power on operations of links have been moved under the
link device in the Sierra SerDes driver. Also, the UCLASS of
sierra_phy_provider has been changed to UCLASS_MISC.
Therefore, fix the probing of SerDes0 instance accordingly.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
In commit 54539583fb ("phy: cadence: Sierra: Add a UCLASS_PHY device for
links"), a separate udevice of type UCLASS_PHY was created for each link.
Therefore, move the corresponding link operations under the link device.
Also, change the uclass of sierra phy to UCLASS_MISC as it is no longer the
phy device.
Fixes: 54539583fb ("phy: cadence: Sierra: Add a UCLASS_PHY device for links")
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Tested-by: Georgi Vlaev <g-vlaev@ti.com>
Reviewed-by: Georgi Vlaev <g-vlaev@ti.com>
Add the command "boot_rprocs" that is required for booting remote
processors in U-Boot.
Fixes: 10b387cfae ("include: configs: j721e_evm: Add support to boot ethfw core in j721e")
Fixes: d08dd5f879 ("configs: j721e_hs_evm_a72_defconfig: Sync up the bootcmd with GP configs")
Reported-by: Jesse Villarreal <jesse.villarreal@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
QSGMII PHY initialization should only be done for J721E EVMs and not for
J721E-SK boards. Therefore, fix the environment variables accordingly.
Also, by default remote processors should not be booted in U-Boot but
rather be left to the users to enable this by setting dorprocboot.
Therefore, remove dorprocboot that is being set by default.
Fixes: 10b387cfae ("include: configs: j721e_evm: Add support to boot ethfw core in j721e")
Reported-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
If CONFIG_BINMAN is set then don't generate tispl.bin and u-boot.img
files using tools/k3_fit_atf.sh
Fixes: 7650825383 ("k3-am642-evm-u-boot: Use binman to generate u-boot.img and tispl.bin")
Signed-off-by: Roger Quadros <rogerq@kernel.org>
For HS devices we need to secure each binary before packing
it into the FIT image. The resulting image names need to have
a "_HS" appended to it.
Also ensure that we use SPL DT blobs for tispl.bin
Signed-off-by: Roger Quadros <rogerq@kernel.org>
We need to add u-boot,dm-spl to these nodes so they are available
in the SPL DTB. This is required for NAND to work at SPL.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
This entry type is used to create a secured binary
for use with K3 High Security (HS) devices.
This allows us to no longer depend on k3_fit_atf.sh for
A53 SPL and u-boot image generation even for HS devices.
We still depend on the availability of an external
tool provided by the TI_SECURE_DEV_PKG environment
variable to secure the binaries.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
tee-os is a more appropriate name for OP-TEE binary.
Fixes: dd0bb6313c ("binman: Add support for TEE BL32")
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Andre Przywara
Aswath Govindraju
Peter Hoyes
Mark Kettenis
Dave Gerlach
Vignesh Raghavendra
Roger Quadros
Tero Kristo
Nishanth Menon
Suman Anna
Dario Binacchi