There is a mistmatch between Allwinner's dram_para BSP definitions and the
parameters names in mainline u-boot for TPR1-3. What we call TPR1 is actually
MR22 while TPR2 is TPR0 and TPR3 is TPR1. MR22 does get written to the
corresponding register. This only concerns LPDDR4 support.

Introduce a new Kconfig entry for MR22 and proceed with the rename.
Update the only config currently using it.

See the list of parameters from the Allwinner BSP at the end of:
https://linux-sunxi.org/A133/DRAMC

Note that the H616/H6 code is coherent with this new TPR0 definition
(and does not use TPR1 and MR22).

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Sponsored-by: MEC Electronics GmbH <https://www.mec.at/>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>

Add missing NAND controller-related clock registers

The NAND controller on H6/H616 uses one clock for its internal logic
(NAND0_CLK) and one clock for ECC engine (NAND1_CLK) in addition to AHB
and MBUS clocks.

As NAND{0,1}_CLKs and MBUS_GATE are missing, add them.

The bit locations are from H616/H6 User Manual.

Signed-off-by: Richard Genoud <richard.genoud@bootlin.com>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>

The sunxi_ccm_reg is legacy, drop its usage from nand related code

For that, CCU_NAND0_CLK_CFG and CCU_AHB_GATE1 are added to the clock
files when missing.
And clock code in sunxi_nand{,_spl}.c and board.c are changed to use the
new scheme.

Moreover, drop AHB_DIV_1 in favor of the more readable CCM_NAND_CTRL_M/N

Suggested-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Richard Genoud <richard.genoud@bootlin.com>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>

Some boards feature an "odd" DRAM size, where the total RAM is 1.5GB or
3GB. Our existing DRAM size detection routines can only detect power-of-2
sized configuration, and on those boards the DRAM size is overestimated,
so this typically breaks the boot quite early.

There doesn't seem to be an easy explicit way to detect those odd-sized
chips, but we can test whether the later part of the memory behaves like
memory, by verifying that a written pattern can be read back.
Experiments show that there is no aliasing effect here, as all locations
in the unimplemented range always return some fixed pattern, and cannot
be changed.

Also so far all those boards use a factor of 3 of some lower power-of-2
number, or 3/4th of some higher number. The size detection routine
discovers the higher number, so we can check for some memory cells beyond
75% of the detected size to be legit.

Add a routine the inverts all bits at a given location in memory, and
reads that back to prove that the new value was stored.
Then test the memory cell at exactly 3/4th of the detected size, and cap
the size of the memory to 75% when this test fails. For good measure
also make sure that memory just below the assumed memory end really
works.

This enables boards which ship with such odd memory sizes.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>

DRAM init code, as per reverse engineering and matching against
previous SoCs. As usual no real documentation, and the DRAM controller
is the usual mixture of close-to-previous IP and new inventions.

This version supports LPDDR4 for now only, as seen on the early boards.

This needs improvements, but it can be done later.

Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

This adds the early A523 clock setup code, for the basic peripheral PLL
and the basic bus clocks (APB/AHB). This is quite close to the existing
H6 and H616 clock code, so this shares the same file. A few bits and bobs
are different, though, so filter for the A523 in a few occasions.

Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

The cpu_sunxi_ncat2.h header file contains addresses of some peripherals
that are needed for the SPL, for chips that belong to the "NCAT2"
generation.
The Allwinner A523 is a member of this group, but a few addresses
differ, and we need a few more addresses, for playing with the core
reset, for instance.

Add the new addresses needed for the A523 and guard existing definitions
that conflict with that new chip.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>

The watchdog in the Allwinner A523 SoC differs a bit from the one in the
previous SoCs: it lives in a separate register frame, so no longer
inside some timer device, and it manages to shuffle around some
registers a bit. But it also conveniently adds a direct reset
functionality, so we don't need to use a dummy timeout period.

Avoid introducing a new MMIO register frame C struct, but just define
the one needed register offset as a macro. Then just trigger this new
direct reset functionality in the A523 specific reset_cpu()
implementation.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>

The Allwinner A523 features 8 CPU cores, organised in two clusters, both
driven by separate PLLs. Also there is the DSU PLL, which clocks the
hardware that connects the cores to the rest of the system.
And while the PLL registers itself are very similar, they are located in
a separate register frame, outside the main CCU, and also the register
controlling the CPU clock source (mux) is different.

Provide a separate function that reparents the two clusters and the DSU,
while their PLLs are programmed. For the actual PLL programming, we rely
on the existing shared routine.

The selection between the new A523 routine and the existing code is made
with C if statements, but since the choice is effectively made at compile
time already, the compiler optimises away the other code paths, leaving
just the one required function in.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>

The SPL initial clock setup code for the Allwinner H6 and H616 SoCs uses
a simple CPU PLL setup routine, which programs all register bits at once,
then waits for the LOCK bit to clear.
The manual suggests to follow a certain procedure for bringing up any
PLLs, which involves several register writes, one at a time, and some
delays. Also the H616 and the new A523 require some tiny changes in this
sequence, and the different SoCs also feature some extra bits here and
there, which we should not just clear.

So factor out the PLL setup routine, and make it follow the manual's
suggestion. This will read the PLL register at the beginning, then tweak
the bits we need to manipulate, and writes the register several times on
the way. This allows to cover the specific bits for different SoCs.

Besides improving the reliability of the PLL setup, this helps with the
A523, which requires *three* CPU PLLs to be programmed.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>