GPU <-> CPU memory inconsistencies have been found in BXS and J721s2.
Every once in a while, the GPU's view of the physical memory differs
from the CPU's view of the physical memory. In such cases, the data
written by CPU to be read by GPU, is not seen by the GPU. This needs
a fix in the Linux GPU driver.
The temporary workaround for now is:
- Set GPU aType to 3 (bypass MSMC coherency)
- Have L3 cache disabled (default in SDK)
This is a temporary fix that will be removed after the 8.4 release.
The GPU driver will then been rewritten to not access memory with
mismatched attributes. Until then undefined behavior will occur
and the following should be avoided:
* Passing the GPU cached buffers (no EXT_image_dma_buf_import)
* Using L3 cache (do not enable it in board config)
* Reuse memory used by the GPU
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
[afd: Rebased on ti-u-boot-2021.01, fixed build warning, fixed commit message]
Signed-off-by: Andrew Davis <afd@ti.com>
DDR configuration for a Jacinto specific board is generated using the
Jacinto 7 DDRSS RegConfig tool. Latest version of the tool is v0.9.1.
It can be obtained from https://www.ti.com/product/TDA4VM#tech-docs under
Technical Documentation > Application note > Jacinto7 DDRSS Register
Configuration Tool.
Updating to contain the generated config of the latest version of the tool.
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
commit 75acccd29c ("soc: ti: k3-navss-ringacc: Initialize base address of ring cfg registers")
while adding support for ETHBOOT in AM62x, retrieved "cfg" register address
from AM62x DMSS's main_pktdma and main_bcdma device tree node.
However for AM64x, the "cfg" register entry was not present for the
main_pktdma and main_bcdma nodes, causing network functionality to break in uboot
Fix it here by adding base addresses for "cfg", "tchan", "rchan", "rflow" in main_pktdma
and "cfg", "tchan", "rchan" for main_bcdma.
Fixes: 75acccd29c ("soc: ti: k3-navss-ringacc: Initialize base address of ring cfg registers")
Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
The entry for DDRSS_PI_321_DATA was accidentally repeated leading to the
last few PI registers being incorrectly programmed.
Fix this.
Reported-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Anand Gadiyar <gadiyar@ti.com>
This reverts commit dcbd681188.
Boot from SD card was broken on dra71-evm, and the breakage was
bisected to this commit. Reverting this commit gets dra71-evm
booting again.
Fixes: LCPD-27102
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
If FIT_IMAGE_POST_PROCESS is set but not SPL_FIT_IMAGE_POST_PROCESS
then board_fit_image_post_process() will not be defined and build
will fail. Use CONFIG_IS_ENABLED to check each at the right stage.
This should not make any change in practice as all boards that define
FIT_IMAGE_POST_PROCESS also define SPL_FIT_IMAGE_POST_PROCESS but this
is more correct.
Signed-off-by: Andrew Davis <afd@ti.com>
Acked-by: Anand Gadiyar <gadiyar@ti.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>
Acked-by: Anand Gadiyar <gadiyar@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>
implement overrides for spl_spi_boot_bus() lookup function
according to bootmode selection, so as to support both QSPI
and OSPI boot using the same build.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Add OSPI1 description and pinmux node in j721s2-r5 dts which
is necessary for enabling QSPI boot support.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
The spl_enable_dcache() function calls dram_init_banksize()
to get the total memory size used in get_effective_memsize().
Normally, the dram_init_banksize() will set the memory bank
configuration, while the total size is reported in ddr_init().
Since we want to switch to lib/fdtdec for parsing the memory
bank configuration, a call to dram_init_banksize() will no
longer work here. This was possible so far as we set
gd->ram_size in the board's dram_init_banksize().
Signed-off-by: Georgi Vlaev <g-vlaev@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>
Acked-by: Andrew Davis <afd@ti.com>
Commit 4d5ca00405 added an spl_spi_boot_cs() override but this has
been removed upstream. So drop that override.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
implement overrides for spl_spi_boot_bus() and spl_spi_boot_cs()
lookup functions according to bootmode selection, so as to support
both QSPI and OSPI boot using the same build.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Both ddr_init() and dram_bank_init() have switched to fdtdec
for getting the memory configuration from the am64xx dts files
instead of using hardcoded values. This requires an accessible
memory node in SPL as we already have in k3-am642-r5-evm.dts.
Make the memory node available in A53 SPL for both am642-sk
and am642-evm and in am642-sk R5 SPL.
Link: https://lore.kernel.org/u-boot/20220520123026.19818-1-g-vlaev@ti.com/
Signed-off-by: Georgi Vlaev <g-vlaev@ti.com>
commit 1a40ddffec upstream
Add 'ss_cfg' memory region for memorycontroller node which is required
to enable ECC.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
[g-vlaev@ti.com: backport from upstream]
Signed-off-by: Georgi Vlaev <g-vlaev@ti.com>
commit adbe138a90 upstream
Mark the memory node with u-boot,dm-spl so we can use it from early SPL.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
[g-vlaev@ti.com: backport from upstream]
Signed-off-by: Georgi Vlaev <g-vlaev@ti.com>
add wkup_gpio pinmux setting which will be used for performing the
DT fixup for hbmc node according to mux selection state, on J721E
EVM, hypermux sel is tied to ·WKUP_GPIO0_8.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Update DT node for HyperBus Memory Controller in the FSS.
hbmc-am654 driver uses syscon_get_regmap() call which fails
with current compatible setting.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Add a sysreset controller node as a child of the DMSC node to enable
the "reset" command from U-Boot prompt for the AM625 SK.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Since commit 75acccd29c ("soc: ti: k3-navss-ringacc: Initialize base
address of ring cfg registers") and commit 8dc8661ec1 ("dma: ti: k3-udma:
Add support for native configuration of chan/flow")' additional register
ranges are required for UDMA and ring drivers. This adds additional register
ranges and TIFS phandle to re enable BCDMA to probe in order for enable
OSPI mem to mem DMA
Without this OSPI boot is broken.
Fixes: 75acccd29c ("soc: ti: k3-navss-ringacc: Initialize base address of ring cfg registers")
Fixes: 8dc8661ec1 ("dma: ti: k3-udma: Add support for native configuration of chan/flow")'
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
For enabling UHS speed modes in SPL, the following devices are required to
be enabled
-> voltage regulators
-> main_i2c1 and gpio expander connected to it
-> main_gpio0
Therefore, add u-boot,dm-spl tags in all the above mentioned dt nodes.
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Add base addresses for "cfg", "tchan", "rchan", "rflow" in
main_pktdma required for native configuration in the absence of
DM services.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Add erratum i2327 work around for initialization for RTC
interrupt where interrupt is stuck for ever at startup. Unfortunately,
this workaround needs to be applied under 1 second of boot.
Signed-off-by: Nishanth Menon <nm@ti.com>
The two instance of USB IP in AM62 SoC are brought out on the SK board. The
zeroth instance is brought out through a USB TYPE C port and the first
instance through a USB TYPE A port. As role switching is supported in
U-Boot and dfu support is required, fix the role of zeroth instance to
peripheral in the U-Boot dts file.
Signed-off-by: Aswath Govindraju <a-govindraju@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>