At the moment we can search for a specific SoC in our supported SoC
table by looking for its SoC ID, but we cannot otherwise enumerate all
supported SoCs.
Add a get_next_soc() function that allows iterating over our (internal)
table: The first call will take NULL as an argument, subsequent calls
pass in the pointer returned by the previous call. When we reach the end
of the list, the function returns NULL.
Signed-off-by: Andre Przywara <osp@andrep.de>
The Allwinner H616 ships in at least two die variants, sometime under a
different name (H618, T507), but sometimes labeled as a normal "H616".
The die variants differ in their CPU cluster control subsystem, which
affects the location of the RVBAR shadow register used to reset the core
into 64-bit mode. We use that in the "reset64" command, but also as part
of the boot process using the "uboot" command, on ARMv8 cores.
Add code to detect the die variant by reading the VER_REG MMIO register,
where the original die reports 0x00 in the lower 8 bits, but the newer
die variants apparently 0x02. In the latter case let the aw_rmr_request()
function use the alternative RVBAR address to do the 64-bit switch.
This matches what we do in U-Boot and Trusted Firmware.
Signed-off-by: Andre Przywara <osp@andrep.de>
On some new Allwinner SoCs, I-Cache is enabled by BROM but FEL write
command cannot correctly invalidate I-Cache, so thunks will not get
properly executed.
Implement a hack that tries to disable I-Cache each time trying to write
data via FEL, to prevent stall thunks in I-Cache.
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
At the moment we assume the SPL load size to be limited to 32KB, even
though many SoCs have more SRAM A1 or a large SRAM C directly after SRAM
A1.
To later allow to extend the SPL load size, let's introduce a SoC
specific variable to hold the SRAM size after the SPL load address. This
could either cover the whole of SRAM A1, or even SRAM C, if that is
contiguous to SRAM A1.
Eventually this variable is meant to hold the *usable* SRAM size, so not
including regions that are used by the BROM code. However this value is
very SoC specific and not documented, and the SPL size is limited by the
thunk and stack buffers anyway at the moment, so the values used here
right now are just taken from the respective manuals.
Signed-off-by: Andre Przywara <osp@andrep.de>
If an SoC has the "secure boot" fuse burned, it will enter FEL mode in
non-secure state, so with the SCR.NS bit set. Since in this mode the
secure/non-secure state restrictions are actually observed, we suffer
from several restrictions:
- No access to the SID information (both via memory mapped and "register").
- No access to secure SRAM (SRAM A2 on H3/A64/H5).
- No access to the secure side of the GIC, so it can't be configured to
be accessible from non-secure world.
- No RMR trigger on ARMv8 cores to bring the core into AArch64.
Those limitations make a board pretty useless for many applications.
However it has been found out that a simple "smc" call will immediately
return from monitor mode, but with the NS bit cleared, so access to all
secure peripherals is suddenly possible.
Add all the necessary support code for doing a runtime check and
activating this workaround. Affected SoCs need to have the "smc"
workaround enabled in their soc_info struct.
Signed-off-by: Andre Przywara <osp@andrep.de>
["sunxi-fel smc" command changed to automatic detection by Siarhei]
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
H3 SID controller has some bug, that makes the initial value at
0x01c14200 wrong.
This commit workarounds this bug by reading them with register access
first.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Reviewed-by: Bernhard Nortmann <bernhard.nortmann@web.de>
This is a preparatory step. Instead of using memory-based access,
we might want to retrieve SID keys (e-fuses) via SID registers.
For this, it's convenient if the plain base address is available.
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
open_fel_device() will automatically provide this member field,
based on the SoC ID from FEL/BROM version data. The field will
either receive a human-readable identifier, or the ID in 4-digit
hexadecimal representation (for unknown SoCs).
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
While at it, modify the former "sram_info" identifiers
to carry a broader "soc_info" meaning.
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
