2012-06-14 01:01:28 +08:00
|
|
|
/*
|
|
|
|
* Device Tree file for Marvell Armada 370 evaluation board
|
|
|
|
* (DB-88F6710-BP-DDR3)
|
|
|
|
*
|
|
|
|
* Copyright (C) 2012 Marvell
|
|
|
|
*
|
|
|
|
* Lior Amsalem <alior@marvell.com>
|
|
|
|
* Gregory CLEMENT <gregory.clement@free-electrons.com>
|
|
|
|
* Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
|
|
|
|
*
|
2015-01-26 22:15:45 +08:00
|
|
|
* This file is dual-licensed: you can use it either under the terms
|
|
|
|
* of the GPL or the X11 license, at your option. Note that this dual
|
|
|
|
* licensing only applies to this file, and not this project as a
|
|
|
|
* whole.
|
|
|
|
*
|
|
|
|
* a) This file is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License as
|
|
|
|
* published by the Free Software Foundation; either version 2 of the
|
|
|
|
* License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This file is distributed in the hope that it will be useful
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* Or, alternatively
|
|
|
|
*
|
|
|
|
* b) Permission is hereby granted, free of charge, to any person
|
|
|
|
* obtaining a copy of this software and associated documentation
|
|
|
|
* files (the "Software"), to deal in the Software without
|
|
|
|
* restriction, including without limitation the rights to use
|
|
|
|
* copy, modify, merge, publish, distribute, sublicense, and/or
|
|
|
|
* sell copies of the Software, and to permit persons to whom the
|
|
|
|
* Software is furnished to do so, subject to the following
|
|
|
|
* conditions:
|
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice shall be
|
|
|
|
* included in all copies or substantial portions of the Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
|
|
|
|
* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
|
|
|
|
* OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
|
|
|
|
* NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
|
|
|
|
* HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
|
|
|
|
* WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
|
|
|
|
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
|
|
|
|
* OTHER DEALINGS IN THE SOFTWARE.
|
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 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@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-07 20:23:03 +08:00
|
|
|
*
|
|
|
|
* Note: this Device Tree assumes that the bootloader has remapped the
|
|
|
|
* internal registers to 0xf1000000 (instead of the default
|
|
|
|
* 0xd0000000). The 0xf1000000 is the default used by the recent,
|
|
|
|
* DT-capable, U-Boot bootloaders provided by Marvell. Some earlier
|
|
|
|
* boards were delivered with an older version of the bootloader that
|
|
|
|
* left internal registers mapped at 0xd0000000. If you are in this
|
|
|
|
* situation, you should either update your bootloader (preferred
|
|
|
|
* solution) or the below Device Tree should be adjusted.
|
2012-06-14 01:01:28 +08:00
|
|
|
*/
|
|
|
|
|
|
|
|
/dts-v1/;
|
2013-07-26 21:17:56 +08:00
|
|
|
#include "armada-370.dtsi"
|
2012-06-14 01:01:28 +08:00
|
|
|
|
|
|
|
/ {
|
|
|
|
model = "Marvell Armada 370 Evaluation Board";
|
|
|
|
compatible = "marvell,a370-db", "marvell,armada370", "marvell,armada-370-xp";
|
|
|
|
|
|
|
|
chosen {
|
2015-03-03 22:41:02 +08:00
|
|
|
stdout-path = "serial0:115200n8";
|
2012-06-14 01:01:28 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
memory {
|
|
|
|
device_type = "memory";
|
2013-01-10 20:15:14 +08:00
|
|
|
reg = <0x00000000 0x40000000>; /* 1 GB */
|
2012-06-14 01:01:28 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
soc {
|
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 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@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-07 20:23:03 +08:00
|
|
|
ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
|
2015-08-18 16:08:55 +08:00
|
|
|
MBUS_ID(0x01, 0xe0) 0 0xfff00000 0x100000
|
|
|
|
MBUS_ID(0x09, 0x01) 0 0xf1100000 0x10000>;
|
2013-07-26 21:17:57 +08:00
|
|
|
|
2013-04-12 22:29:09 +08:00
|
|
|
internal-regs {
|
|
|
|
serial@12000 {
|
|
|
|
status = "okay";
|
2012-09-04 21:06:44 +08:00
|
|
|
};
|
2013-04-12 22:29:09 +08:00
|
|
|
sata@a0000 {
|
|
|
|
nr-ports = <2>;
|
|
|
|
status = "okay";
|
2012-09-04 21:06:44 +08:00
|
|
|
};
|
|
|
|
|
2013-04-12 22:29:09 +08:00
|
|
|
mdio {
|
2014-08-11 20:14:38 +08:00
|
|
|
pinctrl-0 = <&mdio_pins>;
|
|
|
|
pinctrl-names = "default";
|
2013-04-12 22:29:09 +08:00
|
|
|
phy0: ethernet-phy@0 {
|
|
|
|
reg = <0>;
|
|
|
|
};
|
2012-12-21 22:49:08 +08:00
|
|
|
|
2013-04-12 22:29:09 +08:00
|
|
|
phy1: ethernet-phy@1 {
|
|
|
|
reg = <1>;
|
|
|
|
};
|
|
|
|
};
|
2013-01-23 23:26:31 +08:00
|
|
|
|
2013-04-12 22:29:09 +08:00
|
|
|
ethernet@70000 {
|
2014-08-11 20:14:38 +08:00
|
|
|
pinctrl-0 = <&ge0_rgmii_pins>;
|
|
|
|
pinctrl-names = "default";
|
2013-04-12 22:29:09 +08:00
|
|
|
status = "okay";
|
|
|
|
phy = <&phy0>;
|
|
|
|
phy-mode = "rgmii-id";
|
|
|
|
};
|
|
|
|
ethernet@74000 {
|
2014-08-11 20:14:38 +08:00
|
|
|
pinctrl-0 = <&ge1_rgmii_pins>;
|
|
|
|
pinctrl-names = "default";
|
2013-04-12 22:29:09 +08:00
|
|
|
status = "okay";
|
|
|
|
phy = <&phy1>;
|
|
|
|
phy-mode = "rgmii-id";
|
|
|
|
};
|
2013-01-23 23:26:31 +08:00
|
|
|
|
2014-02-13 01:21:00 +08:00
|
|
|
i2c@11000 {
|
|
|
|
pinctrl-0 = <&i2c0_pins>;
|
|
|
|
pinctrl-names = "default";
|
2014-04-18 15:41:44 +08:00
|
|
|
clock-frequency = <100000>;
|
2014-02-13 01:21:00 +08:00
|
|
|
status = "okay";
|
|
|
|
audio_codec: audio-codec@4a {
|
2014-10-29 00:08:43 +08:00
|
|
|
#sound-dai-cells = <0>;
|
2014-02-13 01:21:00 +08:00
|
|
|
compatible = "cirrus,cs42l51";
|
|
|
|
reg = <0x4a>;
|
|
|
|
};
|
|
|
|
};
|
|
|
|
|
|
|
|
audio-controller@30000 {
|
|
|
|
pinctrl-0 = <&i2s_pins2>;
|
|
|
|
pinctrl-names = "default";
|
|
|
|
status = "okay";
|
|
|
|
};
|
|
|
|
|
2013-04-12 22:29:09 +08:00
|
|
|
mvsdio@d4000 {
|
|
|
|
pinctrl-0 = <&sdio_pins1>;
|
|
|
|
pinctrl-names = "default";
|
|
|
|
/*
|
|
|
|
* This device is disabled by default, because
|
|
|
|
* using the SD card connector requires
|
|
|
|
* changing the default CON40 connector
|
|
|
|
* "DB-88F6710_MPP_2xRGMII_DEVICE_Jumper" to a
|
|
|
|
* different connector
|
|
|
|
* "DB-88F6710_MPP_RGMII_SD_Jumper".
|
|
|
|
*/
|
|
|
|
status = "disabled";
|
|
|
|
/* No CD or WP GPIOs */
|
2013-05-14 05:18:58 +08:00
|
|
|
broken-cd;
|
2013-04-12 22:29:09 +08:00
|
|
|
};
|
2013-02-06 04:54:55 +08:00
|
|
|
|
2013-04-12 22:29:09 +08:00
|
|
|
usb@50000 {
|
|
|
|
status = "okay";
|
|
|
|
};
|
2013-02-06 04:54:55 +08:00
|
|
|
|
2013-04-12 22:29:09 +08:00
|
|
|
usb@51000 {
|
|
|
|
status = "okay";
|
2013-02-06 04:54:55 +08:00
|
|
|
};
|
2013-04-10 05:06:38 +08:00
|
|
|
|
2013-04-12 22:29:09 +08:00
|
|
|
spi0: spi@10600 {
|
2014-11-22 07:46:10 +08:00
|
|
|
pinctrl-0 = <&spi0_pins2>;
|
|
|
|
pinctrl-names = "default";
|
2013-04-10 05:06:38 +08:00
|
|
|
status = "okay";
|
2013-04-12 22:29:09 +08:00
|
|
|
|
|
|
|
spi-flash@0 {
|
|
|
|
#address-cells = <1>;
|
|
|
|
#size-cells = <1>;
|
2015-05-19 19:30:46 +08:00
|
|
|
compatible = "mx25l25635e", "jedec,spi-nor";
|
2013-04-12 22:29:09 +08:00
|
|
|
reg = <0>; /* Chip select 0 */
|
|
|
|
spi-max-frequency = <50000000>;
|
|
|
|
};
|
2013-04-10 05:06:38 +08:00
|
|
|
};
|
2013-11-26 00:26:47 +08:00
|
|
|
};
|
2013-04-12 22:29:09 +08:00
|
|
|
|
2013-11-26 00:26:47 +08:00
|
|
|
pcie-controller {
|
|
|
|
status = "okay";
|
|
|
|
/*
|
|
|
|
* The two PCIe units are accessible through
|
|
|
|
* both standard PCIe slots and mini-PCIe
|
|
|
|
* slots on the board.
|
|
|
|
*/
|
|
|
|
pcie@1,0 {
|
|
|
|
/* Port 0, Lane 0 */
|
|
|
|
status = "okay";
|
|
|
|
};
|
2014-02-13 01:21:00 +08:00
|
|
|
|
2013-11-26 00:26:47 +08:00
|
|
|
pcie@2,0 {
|
|
|
|
/* Port 1, Lane 0 */
|
2013-04-10 05:06:38 +08:00
|
|
|
status = "okay";
|
|
|
|
};
|
|
|
|
};
|
2012-06-14 01:01:28 +08:00
|
|
|
};
|
2014-02-13 01:21:00 +08:00
|
|
|
|
|
|
|
sound {
|
2014-10-29 00:08:43 +08:00
|
|
|
compatible = "simple-audio-card";
|
|
|
|
simple-audio-card,name = "Armada 370 DB Audio";
|
|
|
|
simple-audio-card,mclk-fs = <256>;
|
|
|
|
simple-audio-card,widgets =
|
|
|
|
"Headphone", "Out Jack",
|
|
|
|
"Line", "In Jack";
|
|
|
|
simple-audio-card,routing =
|
|
|
|
"Out Jack", "HPL",
|
|
|
|
"Out Jack", "HPR",
|
|
|
|
"AIN1L", "In Jack",
|
|
|
|
"AIN1L", "In Jack";
|
|
|
|
status = "okay";
|
|
|
|
|
|
|
|
simple-audio-card,dai-link@0 {
|
|
|
|
format = "i2s";
|
|
|
|
cpu {
|
|
|
|
sound-dai = <&audio_controller 0>;
|
|
|
|
};
|
|
|
|
|
|
|
|
codec {
|
|
|
|
sound-dai = <&audio_codec>;
|
|
|
|
};
|
|
|
|
};
|
|
|
|
|
|
|
|
simple-audio-card,dai-link@1 {
|
|
|
|
format = "i2s";
|
|
|
|
cpu {
|
|
|
|
sound-dai = <&audio_controller 1>;
|
|
|
|
};
|
|
|
|
|
|
|
|
codec {
|
|
|
|
sound-dai = <&spdif_out>;
|
|
|
|
};
|
|
|
|
};
|
|
|
|
|
|
|
|
simple-audio-card,dai-link@2 {
|
|
|
|
format = "i2s";
|
|
|
|
cpu {
|
|
|
|
sound-dai = <&audio_controller 1>;
|
|
|
|
};
|
|
|
|
|
|
|
|
codec {
|
|
|
|
sound-dai = <&spdif_in>;
|
|
|
|
};
|
|
|
|
};
|
2014-02-13 01:21:00 +08:00
|
|
|
};
|
2014-02-13 01:21:01 +08:00
|
|
|
|
|
|
|
spdif_out: spdif-out {
|
2014-10-29 00:08:43 +08:00
|
|
|
#sound-dai-cells = <0>;
|
|
|
|
compatible = "linux,spdif-dit";
|
2014-02-13 01:21:01 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
spdif_in: spdif-in {
|
2014-10-29 00:08:43 +08:00
|
|
|
#sound-dai-cells = <0>;
|
|
|
|
compatible = "linux,spdif-dir";
|
2014-02-13 01:21:01 +08:00
|
|
|
};
|
2012-06-14 01:01:28 +08:00
|
|
|
};
|