Thomas Petazzoni 4f054d4451 ARM: mvebu: use 0xf1000000 as internal registers on Armada 370 DB ... 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 82066bdb5a and for the Armada XP GP in commit 91ed32200e (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@free-electrons.com> Acked-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Jason Cooper <jason@lakedameon.net> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>		2015-04-08 16:37:02 +02:00
..
bootp	ARM: 8153/1: Enable gcov support on the ARM architecture	2014-09-26 14:39:57 +01:00
compressed	Merge branches 'debug', 'fixes', 'l2c' (early part), 'misc' and 'sa1100' into for-next	2015-02-10 10:26:27 +00:00
dts	ARM: mvebu: use 0xf1000000 as internal registers on Armada 370 DB	2015-04-08 16:37:02 +02:00
.gitignore
install.sh
Makefile