Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 05 5月, 2015 10 次提交
  3. 28 4月, 2015 1 次提交
  5. 27 4月, 2015 6 次提交
  7. 22 4月, 2015 1 次提交
  9. 14 4月, 2015 2 次提交
  11. 08 4月, 2015 1 次提交
    • T
      ARM: mvebu: use 0xf1000000 as internal registers on Armada 370 DB · 4f054d44
      由 Thomas Petazzoni 提交于 
      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 82066bdb and for the Armada XP GP in
commit 91ed3220 (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: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: NAndrew Lunn <andrew@lunn.ch>
Acked-by: NJason Cooper <jason@lakedameon.net>
Acked-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
      4f054d44
  13. 04 4月, 2015 17 次提交
  15. 03 4月, 2015 2 次提交