[PATCHv2] ARM: mvebu: use 0xf1000000 as internal registers on Armada 370 DB

[Jason Cooper]

On Tue, Apr 07, 2015 at 02:23:03PM +0200, Thomas Petazzoni wrote:
> All Marvell EBU SoCs (Kirkwood, Dove, Orion, Armada) have the
> capability of changing the location of their internal registers (i.e
> the registers for most hardware blocks inside the SoC). When coming
> out of reset, the internal registers are mapped at 0xd0000000, but
> since years and years, the tradition has been to have the internal
> registers remapped at 0xf1000000 by the bootloader, and Linux has
> since then assumed that the internal registers for the SoC were
> located at 0xf1000000 on Kirkwood, Dove, Orion, etc. Linux has never
> been aware that those registers are remappable (and there is no way to
> know where they are mapped at runtime, since the register to configure
> the address of the registers is itself within the internal registers).
> 
> Then came the Armada 370 and Armada XP, in which some of the very
> early silicon steppings had an issue, which forced to use 0xd0000000:
> the SoC was no longer working properly when the internal registers
> were remapped at 0xf1000000. This issue is only affecting very early
> silicon steppings and production steppings are not affected: the issue
> has been fixed in between.
> 
> Since what we (Free Electrons) used to do the initial submission of
> the Armada 370 and Armada XP platforms was evaluation boards with
> those very early steppings, we submitted Device Tree that assumed the
> internal registers were mapped at 0xd0000000. This is the case for
> Armada 370 DB, Armada XP DB and Armada XP GP.
> 
> However, in practice, since Marvell has been shipping the evaluation
> boards with production steppings of the SoC, they are shipping those
> boards with bootloaders that remap the registers to 0xf1000000. We
> have already changed this internal register address to 0xf1000000 for
> the Armada XP DB in commit 82066bdb5a75 and for the Armada XP GP in
> commit 91ed32200e6e (both merged in v3.15).
> 
> We only recently got our hand on an Armada 370 DB with a production
> stepping of the SoC, which uses a bootloader that remaps internal
> registers at 0xf1000000. Therefore, this commit aligns the Armada 370
> DB to be like the Armada XP DB and Armada XP GP: assume that the
> internal registers are mapped at 0xf1000000.
> 
> We would like to stress out the fact that the usage of 0xd0000000 as
> the internal register base address was a temporary workaround for
> early steppings deficiencies, and that the real long-term solution is
> the usage of 0xf1000000. Having 0xd0000000 is an *accident* in the
> life of the Marvell platform support in the kernel, as is confirmed by
> the usage of 0xf1000000 in all previous Marvell platforms (Dove,
> Kirkwood, Orion).
> 
> There are unfortunately a number of commercial devices that continue
> to use 0xd0000000 even though they use production steppings of the
> SoC, simply because the vendors of such devices have never bothered
> using a more recent bootloader version from Marvell. There is not much
> we can do about it, and we plan on keeping 0xd0000000 in the Device
> Tree of such devices.
> 
> The main reason for remapping the internal registers at 0xf1000000
> instead of 0xd0000000 is that it leaves more space in the 0 -> 4 GB
> part of the physical address space for RAM. With registers at
> 0xd0000000, all RAM between 0xd0000000 to 0xffffffff is lost because
> it's covered by the I/O registers.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
> Changes since v1:
>  - Improved commit log.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
>  arch/arm/boot/dts/armada-370-db.dts | 11 ++++++++++-
>  1 file changed, 10 insertions(+), 1 deletion(-)

Acked-by: Jason Cooper <jason at lakedaemon.net>

thx,

Jason.