linux_dsm_epyc7002/arch/arm/boot/dts/armada-370-db.dts

278 lines
6.7 KiB
Plaintext
Raw Normal View History

/*
* 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>
*
* 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 19:23:03 +07: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.
*/
/dts-v1/;
#include "armada-370.dtsi"
/ {
model = "Marvell Armada 370 Evaluation Board";
compatible = "marvell,a370-db", "marvell,armada370", "marvell,armada-370-xp";
chosen {
stdout-path = "serial0:115200n8";
};
memory {
device_type = "memory";
reg = <0x00000000 0x40000000>; /* 1 GB */
};
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 19:23:03 +07:00
ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
MBUS_ID(0x01, 0xe0) 0 0xfff00000 0x100000
MBUS_ID(0x09, 0x01) 0 0xf1100000 0x10000>;
internal-regs {
serial@12000 {
status = "okay";
};
sata@a0000 {
nr-ports = <2>;
status = "okay";
};
mdio {
pinctrl-0 = <&mdio_pins>;
pinctrl-names = "default";
phy0: ethernet-phy@0 {
reg = <0>;
};
phy1: ethernet-phy@1 {
reg = <1>;
};
};
ethernet@70000 {
pinctrl-0 = <&ge0_rgmii_pins>;
pinctrl-names = "default";
status = "okay";
phy = <&phy0>;
phy-mode = "rgmii-id";
};
ethernet@74000 {
pinctrl-0 = <&ge1_rgmii_pins>;
pinctrl-names = "default";
status = "okay";
phy = <&phy1>;
phy-mode = "rgmii-id";
};
i2c@11000 {
pinctrl-0 = <&i2c0_pins>;
pinctrl-names = "default";
clock-frequency = <100000>;
status = "okay";
audio_codec: audio-codec@4a {
#sound-dai-cells = <0>;
compatible = "cirrus,cs42l51";
reg = <0x4a>;
};
};
audio-controller@30000 {
pinctrl-0 = <&i2s_pins2>;
pinctrl-names = "default";
status = "okay";
};
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 */
broken-cd;
};
usb@50000 {
status = "okay";
};
usb@51000 {
status = "okay";
};
nand@d0000 {
status = "okay";
num-cs = <1>;
marvell,nand-keep-config;
marvell,nand-enable-arbiter;
nand-on-flash-bbt;
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;
partition@0 {
label = "U-Boot";
reg = <0 0x800000>;
};
partition@800000 {
label = "Linux";
reg = <0x800000 0x800000>;
};
partition@1000000 {
label = "Filesystem";
reg = <0x1000000 0x3f000000>;
};
};
};
};
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";
};
pcie@2,0 {
/* Port 1, Lane 0 */
status = "okay";
};
};
};
sound {
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>;
};
};
};
spdif_out: spdif-out {
#sound-dai-cells = <0>;
compatible = "linux,spdif-dit";
};
spdif_in: spdif-in {
#sound-dai-cells = <0>;
compatible = "linux,spdif-dir";
};
};
&spi0 {
pinctrl-0 = <&spi0_pins2>;
pinctrl-names = "default";
status = "okay";
spi-flash@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "mx25l25635e", "jedec,spi-nor";
reg = <0>; /* Chip select 0 */
spi-max-frequency = <50000000>;
};
};