NB0 is bridge to SRAM and NB1 is bridge to DDR.
To ensure that SRAM transfers are not stalled due to delays during DDR
refreshes, SRAM traffic should be higher priority (threadmap=2) than
DDR traffic (threadmap=0).
This fixup is critical to provide deterministic access latency to
MSMC from ICSSG, it applies to all AM65 silicon revisions and is due
to incorrect reset values (has no erratum id) and statically setting
things up should be done independent of usecases and board.
This specific style of Northbridge configuration is specific only to
AM65x devices, follow-on K3 devices have different data prioritization
schemes (ASEL and the like) and hence the fixup applies purely to
AM65x.
Without this fix, ICSSG TX lock-ups due to delays in MSMC transfers in
case of SR1 devices, on SR2 devices, lockups were not observed so far
but high retry rates of ICSSG Ethernet (icssg-eth) and, thus, lower
throughput.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Acked-by: Andrew F. Davis <afd@ti.com>
Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Benoit Parrot <bparrot@ti.com>
[Jan: rebased, dropped used define, extended commit log]
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
[Nishanth: Provide relevant context in the commit message]
Signed-off-by: Nishanth Menon<nm@ti.com>
The board detection scheme employed on various TI EVMs makes use of
SRAM scratch space to share data read from an on-board EEPROM between
the different bootloading stages. Map the associated definition that's
used to locate this data into the SRAM scratch space we use on AM654x.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
On HS devices the 512b region of reset isolated memory called
MCU_PSRAM0 is firewalled by default. Until SYSFW is loaded we
cannot use this memory. It is only used to store a single value
left at the end of SRAM by ROM that will be needed later. Save
that value to a global variable stored in the .data section.
This section is used as .bss will be cleared between saving
this value and using it.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
For most devices the boot mode maps directly to the boot
device. For MMC this is not the case as we have two MMC
boot modes and two MMC boot devices (ports). Check the
boot port to determine which MMC device was our boot
device. Make this change for both primary and secondary
boot modes.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
By default the device control module registers are locked,
preventing any writes to its registers.
Unlock those registers as part of the init flow.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
AM654 allows for booting from primary or backup boot media.
Both media can be chosen individually based on switch settings.
ROM looks for a valid image in primary boot media, if not found
then looks in backup boot media. In order to pass this boot media
information to boot loader, ROM stores a value at a particular
address. Add support for reading this information and determining
the boot media correctly.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
