| fbde260b | 03-Apr-2023 |
Andre Przywara <andre.przywara@arm.com> |
feat(allwinner): add function to detect H616 die variant
Allwinner provides a number of SoCs that use the same die as the H616.
Some of those chips apparently use a slight variation of that die, tha
feat(allwinner): add function to detect H616 die variant
Allwinner provides a number of SoCs that use the same die as the H616.
Some of those chips apparently use a slight variation of that die, that
differs in the way the CPU cores' power and reset controls are handled.
This die variation can be detected by reading the SRAM version register.
Provide a predicate function that returns false if that die variant is
used. Since the CPU power control code is shared for all supported SoCs,
we provide an instance of this function for each SoC, as a static
inline, and return true on all other SoCs. This allows to always use
this function, and still let the compiler optimise away the unneeded
branch for those older SoCs.
This function is unused for now, but is needed in the next patch.
Change-Id: I49e014b895b7e2f55b4e7dc2b3d8aa31cee711b5
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
show more ...
|
| b15e2cda | 09-Dec-2022 |
Mikhail Kalashnikov <iuncuim@gmail.com> |
feat(allwinner): add extra CPU control registers
The die used in several variants of the Allwinner H616 SoC (H313, T507)
seems to produced in at least two revisions. The newer one differs from
the o
feat(allwinner): add extra CPU control registers
The die used in several variants of the Allwinner H616 SoC (H313, T507)
seems to produced in at least two revisions. The newer one differs from
the original by using a different CPU control register IP block.
Add those newly used register offsets to the respective header file. The
MMIO block itself is actually present in both variants, though the
registers are different. The new registers tend to use one register per
core, in contrast to one register per cluster in the older revisions.
Change-Id: Ifbda1bdc67a6a16fbb901dbc83996e4a148b7602
Signed-off-by: Mikhail Kalashnikov <iuncuim@gmail.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
show more ...
|
| e2b18771 | 23-Jan-2022 |
Samuel Holland <samuel@sholland.org> |
feat(allwinner): provide CPU idle states to the rich OS
When using SCPI as the PSCI backend, firmware can wake up the CPUs and
cluster from sleep, so CPU idle states are available for the rich OS to
feat(allwinner): provide CPU idle states to the rich OS
When using SCPI as the PSCI backend, firmware can wake up the CPUs and
cluster from sleep, so CPU idle states are available for the rich OS to
use. In that case, advertise them to the rich OS via the DTB.
Change-Id: I718ef6ef41212fe5213b11b4799613adbbe6e0eb
Signed-off-by: Samuel Holland <samuel@sholland.org>
show more ...
|
| 159c36fd | 19-Mar-2021 |
Samuel Holland <samuel@sholland.org> |
feat(allwinner): choose PSCI states to avoid translation
Aligning the PSCI and SCPI power states avoids some code to translate
between the two. This also makes room for an intermediate power state,
feat(allwinner): choose PSCI states to avoid translation
Aligning the PSCI and SCPI power states avoids some code to translate
between the two. This also makes room for an intermediate power state,
for future firmware capability growth.
Change-Id: I26691085f277a96bd405e3305ab0fe390a92b418
Signed-off-by: Samuel Holland <samuel@sholland.org>
show more ...
|
| 0e54a789 | 04-Apr-2021 |
Samuel Holland <samuel@sholland.org> |
refactor(plat/allwinner): clean up platform definitions
Group the SCP base/size definitions in a more logical location.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Change-Id: Id43f9b468d7d8
refactor(plat/allwinner): clean up platform definitions
Group the SCP base/size definitions in a more logical location.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Change-Id: Id43f9b468d7d855a2413173d674a5ee666527808
show more ...
|
| 8d9efdf8 | 14-Dec-2020 |
Samuel Holland <samuel@sholland.org> |
refactor(plat/allwinner): do not map BL32 DRAM at EL3
BL31 does not appear to ever access the DRAM allocated to BL32,
so there is no need to map it at EL3.
Signed-off-by: Samuel Holland <samuel@sho
refactor(plat/allwinner): do not map BL32 DRAM at EL3
BL31 does not appear to ever access the DRAM allocated to BL32,
so there is no need to map it at EL3.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Change-Id: Ie8727b793e53ea14517894942266f6da0333eb74
show more ...
|
| ab74206b | 14-Dec-2020 |
Samuel Holland <samuel@sholland.org> |
refactor(plat/allwinner): map SRAM as device memory by default
The SRAM on Allwinner platforms is shared between BL31 and coprocessor
firmware. Previously, SRAM was mapped as normal memory by defaul
refactor(plat/allwinner): map SRAM as device memory by default
The SRAM on Allwinner platforms is shared between BL31 and coprocessor
firmware. Previously, SRAM was mapped as normal memory by default.
This scheme requires carveouts and cache maintenance code for proper
synchronization with the coprocessor.
A better scheme is to only map pages owned by BL31 as normal memory,
and leave everything else as device memory. This removes the need for
cache maintenance, and it makes the mapping for BL31 RW data explicit
instead of magic.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Change-Id: I820ddeba2dfa2396361c2322308c0db51b55c348
show more ...
|
| 0be10ee3 | 14-Dec-2020 |
Andre Przywara <andre.przywara@arm.com> |
allwinner: H616: Add reserved-memory node to DT
When the BL31 for the Allwinner H616 runs in DRAM, we need to make sure
we tell the non-secure world about the memory region it uses.
Add a reserved-
allwinner: H616: Add reserved-memory node to DT
When the BL31 for the Allwinner H616 runs in DRAM, we need to make sure
we tell the non-secure world about the memory region it uses.
Add a reserved-memory node to the DT, which covers the area that BL31
could occupy. The "no-map" property will prevent OSes from mapping
the area, so there would be no speculative accesses.
Change-Id: I808f3e1a8089da53bbe4fc6435a808e9159831e1
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
show more ...
|
| 26123ca3 | 28-Nov-2020 |
Andre Przywara <andre.przywara@arm.com> |
allwinner: Add Allwinner H616 SoC support
The new Allwinner H616 SoC lacks the management controller and the secure
SRAM A2, so we need to tweak the memory map quite substantially:
We run BL31 in DR
allwinner: Add Allwinner H616 SoC support
The new Allwinner H616 SoC lacks the management controller and the secure
SRAM A2, so we need to tweak the memory map quite substantially:
We run BL31 in DRAM. Since the DRAM starts at 1GB, we cannot use our
compressed virtual address space (max 256MB) anymore, so we revert to
the full 32bit VA space and use a flat mapping throughout all of it.
The missing controller also means we need to always use the native PSCI
ops, using the CPUIDLE hardware, as SCPI and suspend depend on the ARISC.
Change-Id: I77169b452cb7f5dc2ef734f3fc6e5d931749141d
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
show more ...
|
| b23ab8eb | 20-Jan-2021 |
Andre Przywara <andre.przywara@arm.com> |
allwinner: Allow conditional compilation of SCPI and native PSCI ops
Now that we have split the native and the SCPI version of the PSCI ops,
we can introduce build options to compile in either or bo
allwinner: Allow conditional compilation of SCPI and native PSCI ops
Now that we have split the native and the SCPI version of the PSCI ops,
we can introduce build options to compile in either or both of them.
If one version is not compiled in, some stub functions make sure the
common code still compiles and makes the right decisions.
By default both version are enabled (as before), but one of them can be
disabled on the make command line, or via a platform specific Makefile.
Change-Id: I0c019d8700c0208365eacf57809fb8bc608eb9c0
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Samuel Holland <samuel@sholland.org>
show more ...
|
| fe753c97 | 16-Jan-2021 |
Samuel Holland <samuel@sholland.org> |
allwinner: Split native and SCPI-based PSCI implementations
In order to keep SCP firmware as optional, the original, limited native
PSCI implementation was kept around as a fallback. This turned out
allwinner: Split native and SCPI-based PSCI implementations
In order to keep SCP firmware as optional, the original, limited native
PSCI implementation was kept around as a fallback. This turned out to be
a good decision, as some newer SoCs omit the ARISC, and thus cannot run
SCP firmware.
However, keeping the two implementations in one file makes things
unnecessarily messy. First, it is difficult to compile out the
SCPI-based implementation where it is not applicable. Second the check
is done in each callback, while scpi_available is only updated at boot.
This makes the individual callbacks unnecessarily complicated.
It is cleaner to provide two entirely separate implementations in two
separate files. The native implementation does not support any kind of
CPU suspend, so its callbacks are greatly simplified. One function,
sunxi_validate_ns_entrypoint, is shared between the two implementations.
Finally, the logic for choosing between implementations is kept in a
third file, to provide for platforms where only one implementation is
applicable and the other is compiled out.
Change-Id: I4914f07d8e693dbce218e0e2394bef15c42945f8
Signed-off-by: Samuel Holland <samuel@sholland.org>
show more ...
|
| e382c88e | 21-Oct-2018 |
Samuel Holland <samuel@sholland.org> |
allwinner: Implement PSCI system suspend using SCPI
If an SCP firmware is present and able to communicate via SCPI, then use
that to implement CPU and system power state transitions, including CPU
h
allwinner: Implement PSCI system suspend using SCPI
If an SCP firmware is present and able to communicate via SCPI, then use
that to implement CPU and system power state transitions, including CPU
hotplug and system suspend. Otherwise, fall back to the existing CPU
power control implementation.
The last 16 KiB of SRAM A2 are reserved for the SCP firmware, and the
SCPI shared memory is at the very end of this region (and therefore the
end of SRAM A2). BL31 continues to start at the beginning of SRAM A2
(not counting the ARISC exception vector area) and fills up to the
beginning of the SCP firmware.
Because the SCP firmware is not loaded adjacent to the ARISC exception
vector area, the jump instructions used for exception handling cannot be
included in the SCP firmware image, and must be initialized here before
turning on the SCP.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Change-Id: I37b9b9636f94d4125230423726f3ac5e9cdb551c
show more ...
|
| 57b36632 | 29-Dec-2019 |
Samuel Holland <samuel@sholland.org> |
allwinner: Reserve and map space for the SCP firmware
The SCP firmware is allocated the last 16KiB of SRAM A2. This includes
the SCPI shared memory area, which must be mapped as MT_DEVICE to
prevent
allwinner: Reserve and map space for the SCP firmware
The SCP firmware is allocated the last 16KiB of SRAM A2. This includes
the SCPI shared memory area, which must be mapped as MT_DEVICE to
prevent problems with cache coherency between the AP CPUs and the SCP.
For simplicity, map the whole SCP region as MT_DEVICE.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Change-Id: Ie39eb5ff281b8898a3c1d9748dc08755f528e2f8
show more ...
|