AuxXxilium/linux_dsm_epyc7002
1
0
Fork 0
mirror of https://github.com/AuxXxilium/linux_dsm_epyc7002.git synced 2024-12-02 05:16:47 +07:00
Code Issues Actions Packages Projects Releases Wiki Activity
6dc62f1263
linux_dsm_epyc7002/arch/arm/boot/dts/armada-xp-synology-ds414.dts
Thomas Petazzoni d7d5a43c0d ARM: mvebu: fix overlap of Crypto SRAM with PCIe memory window 
When the Crypto SRAM mappings were added to the Device Tree files
describing the Armada XP boards in commit c466d997bb ("ARM: mvebu:
define crypto SRAM ranges for all armada-xp boards"), the fact that
those mappings were overlaping with the PCIe memory aperture was
overlooked. Due to this, we currently have for all Armada XP platforms
a situation that looks like this:

Memory mapping on Armada XP boards with internal registers at
0xf1000000:

 - 0x00000000 -> 0xf0000000	3.75G 	RAM
 - 0xf0000000 -> 0xf1000000	16M	NOR flashes (AXP GP / AXP DB)
 - 0xf1000000 -> 0xf1100000	1M	internal registers
 - 0xf8000000 -> 0xffe0000	126M	PCIe memory aperture
 - 0xf8100000 -> 0xf8110000	64KB	Crypto SRAM #0	=> OVERLAPS WITH PCIE !
 - 0xf8110000 -> 0xf8120000	64KB	Crypto SRAM #1	=> OVERLAPS WITH PCIE !
 - 0xffe00000 -> 0xfff00000	1M	PCIe I/O aperture
 - 0xfff0000  -> 0xffffffff	1M	BootROM

The overlap means that when PCIe devices are added, depending on their
memory window needs, they might or might not be mapped into the
physical address space. Indeed, they will not be mapped if the area
allocated in the PCIe memory aperture by the PCI core overlaps with
one of the Crypto SRAM. Typically, a Intel IGB PCIe NIC that needs 8MB
of PCIe memory will see its PCIe memory window allocated from
0xf80000000 for 8MB, which overlaps with the Crypto SRAM windows. Due
to this, the PCIe window is not created, and any attempt to access the
PCIe window makes the kernel explode:

[    3.302213] igb: Copyright (c) 2007-2014 Intel Corporation.
[    3.307841] pci 0000:00:09.0: enabling device (0140 -> 0143)
[    3.313539] mvebu_mbus: cannot add window '4:f8', conflicts with another window
[    3.320870] mvebu-pcie soc:pcie-controller: Could not create MBus window at [mem 0xf8000000-0xf87fffff]: -22
[    3.330811] Unhandled fault: external abort on non-linefetch (0x1008) at 0xf08c0018

This problem does not occur on Armada 370 boards, because we use the
following memory mapping (for boards that have internal registers at
0xf1000000):

 - 0x00000000 -> 0xf0000000	3.75G 	RAM
 - 0xf0000000 -> 0xf1000000	16M	NOR flashes (AXP GP / AXP DB)
 - 0xf1000000 -> 0xf1100000	1M	internal registers
 - 0xf1100000 -> 0xf1110000	64KB	Crypto SRAM #0 => OK !
 - 0xf8000000 -> 0xffe0000	126M	PCIe memory
 - 0xffe00000 -> 0xfff00000	1M	PCIe I/O
 - 0xfff0000  -> 0xffffffff	1M	BootROM

Obviously, the solution is to align the location of the Crypto SRAM
mappings of Armada XP to be similar with the ones on Armada 370, i.e
have them between the "internal registers" area and the beginning of
the PCIe aperture.

However, we have a special case with the OpenBlocks AX3-4 platform,
which has a 128 MB NOR flash. Currently, this NOR flash is mapped from
0xf0000000 to 0xf8000000. This is possible because on OpenBlocks
AX3-4, the internal registers are not at 0xf1000000. And this explains
why the Crypto SRAM mappings were not configured at the same place on
Armada XP.

Hence, the solution is two-fold:

 (1) Move the NOR flash mapping on Armada XP OpenBlocks AX3-4 from
     0xe8000000 to 0xf0000000. This frees the 0xf0000000 ->
     0xf80000000 space.

 (2) Move the Crypto SRAM mappings on Armada XP to be similar to
     Armada 370 (except of course that Armada XP has two Crypto SRAM
     and not one).

After this patch, the memory mapping on Armada XP boards with
registers at 0xf1 is:

 - 0x00000000 -> 0xf0000000	3.75G 	RAM
 - 0xf0000000 -> 0xf1000000	16M	NOR flashes (AXP GP / AXP DB)
 - 0xf1000000 -> 0xf1100000	1M	internal registers
 - 0xf1100000 -> 0xf1110000	64KB	Crypto SRAM #0
 - 0xf1110000 -> 0xf1120000	64KB	Crypto SRAM #1
 - 0xf8000000 -> 0xffe0000	126M	PCIe memory
 - 0xffe00000 -> 0xfff00000	1M	PCIe I/O
 - 0xfff0000  -> 0xffffffff	1M	BootROM

And the memory mapping for the special case of the OpenBlocks AX3-4
(internal registers at 0xd0000000, NOR of 128 MB):

 - 0x00000000 -> 0xc0000000	3G 	RAM
 - 0xd0000000 -> 0xd1000000	1M	internal registers
 - 0xe800000  -> 0xf0000000	128M	NOR flash
 - 0xf1100000 -> 0xf1110000	64KB	Crypto SRAM #0
 - 0xf1110000 -> 0xf1120000	64KB	Crypto SRAM #1
 - 0xf8000000 -> 0xffe0000	126M	PCIe memory
 - 0xffe00000 -> 0xfff00000	1M	PCIe I/O
 - 0xfff0000  -> 0xffffffff	1M	BootROM

Fixes: c466d997bb ("ARM: mvebu: define crypto SRAM ranges for all armada-xp boards")
Reported-by: Phil Sutter <phil@nwl.cc>
Cc: Phil Sutter <phil@nwl.cc>
Cc: <stable@vger.kernel.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
2016-03-11 11:49:55 -08:00

365 lines
9.6 KiB
Plaintext
Raw Blame History

/*
* Device Tree file for Synology DS414
*
* Copyright (C) 2014, Arnaud EBALARD <arno@natisbad.org>
*
* 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.
*
* Note: this Device Tree assumes that the bootloader has remapped the
* internal registers to 0xf1000000 (instead of the old 0xd0000000).
* The 0xf1000000 is the default used by the recent, DT-capable, U-Boot
* bootloaders provided by Marvell. It is used in recent versions of
* DSM software provided by Synology. Nonetheless, some earlier boards
* were delivered with an older version of u-boot that left internal
* registers mapped at 0xd0000000. If you have such a device you will
* not be able to directly boot a kernel based on this Device Tree. In
* that case, the preferred solution is to update your bootloader (e.g.
* by upgrading to latest version of DSM, or building a new one and
* installing it from u-boot prompt) or adjust the Devive Tree
* (s/0xf1000000/0xd0000000/ in 'ranges' below).
*/
/dts-v1/;
#include <dt-bindings/input/input.h>
#include <dt-bindings/gpio/gpio.h>
#include "armada-xp-mv78230.dtsi"
/ {
model = "Synology DS414";
compatible = "synology,ds414", "marvell,armadaxp-mv78230",
"marvell,armadaxp", "marvell,armada-370-xp";
chosen {
stdout-path = "serial0:115200n8";
};
memory {
device_type = "memory";
reg = <0 0x00000000 0 0x40000000>; /* 1GB */
};
soc {
ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xf1000000 0x100000
MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
MBUS_ID(0x09, 0x09) 0 0 0xf1100000 0x10000
MBUS_ID(0x09, 0x05) 0 0 0xf1110000 0x10000>;
pcie-controller {
status = "okay";
/*
* Connected to Marvell 88SX7042 SATA-II controller
* handling the four disks.
*/
pcie@1,0 {
/* Port 0, Lane 0 */
status = "okay";
};
/*
* Connected to EtronTech EJ168A XHCI controller
* providing the two rear USB 3.0 ports.
*/
pcie@5,0 {
/* Port 1, Lane 0 */
status = "okay";
};
};
internal-regs {
/* RTC is provided by Seiko S-35390A below */
rtc@10300 {
status = "disabled";
};
spi0: spi@10600 {
status = "okay";
spi-flash@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "micron,n25q064", "jedec,spi-nor";
reg = <0>; /* Chip select 0 */
spi-max-frequency = <20000000>;
/*
* Warning!
*
* Synology u-boot uses its compiled-in environment
* and it seems Synology did not care to change u-boot
* default configuration in order to allow saving a
* modified environment at a sensible location. So,
* if you do a 'saveenv' under u-boot, your modified
* environment will be saved at 1MB after the start
* of the flash, i.e. in the middle of the uImage.
* For that reason, it is strongly advised not to
* change the default environment, unless you know
* what you are doing.
*/
partition@00000000 { /* u-boot */
label = "RedBoot";
reg = <0x00000000 0x000d0000>; /* 832KB */
};
partition@000c0000 { /* uImage */
label = "zImage";
reg = <0x000d0000 0x002d0000>; /* 2880KB */
};
partition@003a0000 { /* uInitramfs */
label = "rd.gz";
reg = <0x003a0000 0x00430000>; /* 4250KB */
};
partition@007d0000 { /* MAC address and serial number */
label = "vendor";
reg = <0x007d0000 0x00010000>; /* 64KB */
};
partition@007e0000 {
label = "RedBoot config";
reg = <0x007e0000 0x00010000>; /* 64KB */
};
partition@007f0000 {
label = "FIS directory";
reg = <0x007f0000 0x00010000>; /* 64KB */
};
};
};
i2c@11000 {
clock-frequency = <400000>;
status = "okay";
s35390a: s35390a@30 {
compatible = "sii,s35390a";
reg = <0x30>;
};
};
/* Connected to a header on device's PCB. This
* provides the main console for the device.
*
* Warning: the device may not boot with a 3.3V
* USB-serial converter connected when the power
* button is pressed. The converter needs to be
* connected a few seconds after pressing the
* power button. This is possibly due to UART0_TXD
* pin being sampled at reset (bit 0 of SAR).
*/
serial@12000 {
status = "okay";
};
/* Connected to a Microchip PIC16F883 for power control */
serial@12100 {
status = "okay";
};
poweroff@12100 {
compatible = "synology,power-off";
reg = <0x12100 0x100>;
clocks = <&coreclk 0>;
};
/* Front USB 2.0 port */
usb@50000 {
status = "okay";
};
mdio {
phy0: ethernet-phy@0 { /* Marvell 88E1512 */
reg = <0>;
};
phy1: ethernet-phy@1 { /* Marvell 88E1512 */
reg = <1>;
};
};
ethernet@70000 {
status = "okay";
pinctrl-0 = <&ge0_rgmii_pins>;
pinctrl-names = "default";
phy = <&phy1>;
phy-mode = "rgmii-id";
};
ethernet@74000 {
pinctrl-0 = <&ge1_rgmii_pins>;
pinctrl-names = "default";
status = "okay";
phy = <&phy0>;
phy-mode = "rgmii-id";
};
};
};
regulators {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <0>;
pinctrl-0 = <&sata1_pwr_pin &sata2_pwr_pin
&sata3_pwr_pin &sata4_pwr_pin>;
pinctrl-names = "default";
sata1_regulator: sata1-regulator {
compatible = "regulator-fixed";
reg = <1>;
regulator-name = "SATA1 Power";
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
startup-delay-us = <2000000>;
enable-active-high;
regulator-always-on;
regulator-boot-on;
gpio = <&gpio1 10 GPIO_ACTIVE_HIGH>;
};
sata2_regulator: sata2-regulator {
compatible = "regulator-fixed";
reg = <2>;
regulator-name = "SATA2 Power";
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
startup-delay-us = <4000000>;
enable-active-high;
regulator-always-on;
regulator-boot-on;
gpio = <&gpio1 12 GPIO_ACTIVE_HIGH>;
};
sata3_regulator: sata3-regulator {
compatible = "regulator-fixed";
reg = <3>;
regulator-name = "SATA3 Power";
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
startup-delay-us = <6000000>;
enable-active-high;
regulator-always-on;
regulator-boot-on;
gpio = <&gpio1 13 GPIO_ACTIVE_HIGH>;
};
sata4_regulator: sata4-regulator {
compatible = "regulator-fixed";
reg = <4>;
regulator-name = "SATA4 Power";
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
startup-delay-us = <8000000>;
enable-active-high;
regulator-always-on;
regulator-boot-on;
gpio = <&gpio1 14 GPIO_ACTIVE_HIGH>;
};
};
};
&pinctrl {
sata1_pwr_pin: sata1-pwr-pin {
marvell,pins = "mpp42";
marvell,function = "gpio";
};
sata2_pwr_pin: sata2-pwr-pin {
marvell,pins = "mpp44";
marvell,function = "gpio";
};
sata3_pwr_pin: sata3-pwr-pin {
marvell,pins = "mpp45";
marvell,function = "gpio";
};
sata4_pwr_pin: sata4-pwr-pin {
marvell,pins = "mpp46";
marvell,function = "gpio";
};
sata1_pres_pin: sata1-pres-pin {
marvell,pins = "mpp34";
marvell,function = "gpio";
};
sata2_pres_pin: sata2-pres-pin {
marvell,pins = "mpp35";
marvell,function = "gpio";
};
sata3_pres_pin: sata3-pres-pin {
marvell,pins = "mpp40";
marvell,function = "gpio";
};
sata4_pres_pin: sata4-pres-pin {
marvell,pins = "mpp41";
marvell,function = "gpio";
};
syno_id_bit0_pin: syno-id-bit0-pin {
marvell,pins = "mpp26";
marvell,function = "gpio";
};
syno_id_bit1_pin: syno-id-bit1-pin {
marvell,pins = "mpp28";
marvell,function = "gpio";
};
syno_id_bit2_pin: syno-id-bit2-pin {
marvell,pins = "mpp29";
marvell,function = "gpio";
};
fan1_alarm_pin: fan1-alarm-pin {
marvell,pins = "mpp33";
marvell,function = "gpio";
};
fan2_alarm_pin: fan2-alarm-pin {
marvell,pins = "mpp32";
marvell,function = "gpio";
};
};
Reference in New Issue View Git Blame Copy Permalink