summaryrefslogtreecommitdiffstats
path: root/arch/arm/boot/dts/armada-xp-matrix.dts
Commit message (Collapse)AuthorAgeFilesLines
* ARM: dts: mvebu: Correct license textAlexandre Belloni2017-01-031-5/+5
| | | | | | | | | | | | | | The license text has been mangled at some point then copy pasted across multiple files. Restore it to what it should be. Note that this is not intended as a license change. Acked-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Stefan Roese <sr@denx.de> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Rafał Miłecki <zajec5@gmail.com> Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
* ARM: dts: armada-370-xp: Fixup memory DT warningGregory CLEMENT2016-11-191-1/+1
| | | | | | memory has a reg property so the unit name should contain an address. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
* ARM: dts: armada-xp: Fixup pcie DT warningsGregory CLEMENT2016-11-191-9/+9
| | | | | | | PCIe has a range property, so the unit name should contain an address. Take the opportunity to use the node label instead of the full name. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
* ARM: dts: armada-xp-matrix: Fix the location of the pcie-controller nodeGregory CLEMENT2016-11-191-9/+9
| | | | | | | | | | | | | In the dts for the Marvell Armada XP Matrix board the pcie-controller was located under the internal-regs node whereas it belongs to the soc node. It means that, until this fix, the pcie could not work for this board because it didn't match the definition of the pcie-controller node in the dtsi file. If we had a look on the decompiled dtb file we saw two different instances of the pcie-controller node: one with the all the resource set but disabled and the other without any resource but enabled. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
* ARM: mvebu: fix overlap of Crypto SRAM with PCIe memory windowThomas Petazzoni2016-03-111-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the Crypto SRAM mappings were added to the Device Tree files describing the Armada XP boards in commit c466d997bb16 ("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: c466d997bb16 ("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>
* ARM: mvebu: define crypto SRAM ranges for all armada-xp boardsBoris Brezillon2015-09-291-1/+3
| | | | | | | | Define the crypto SRAM ranges so that the resources referenced by the sa-sram node can be properly extracted from the DT. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
* ARM: mvebu: use stdout-path in all armada-*.dtsThomas Petazzoni2015-03-041-1/+1
| | | | | | | | | | | This commit adds the stdout-path property in /chosen for all Armada boards that were not yet carrying this property, and gets rid of /chosen/bootargs which becomes unneeded: earlyprintk should not be used by default, and the console= parameter is replaced by the /chosen/stdout-path property. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
* ARM: mvebu: armada-xp-matrix: Relicense the device tree under GPLv2+/X11Gregory CLEMENT2015-01-261-3/+37
| | | | | | | | | | | | | The current GPL only licensing on the device tree makes it very impractical for other software components licensed under another license. In order to make it easier for them to reuse our device trees, relicense our device trees under a GPL/X11 dual-license. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Acked-by: Jason Cooper <jason@lakedaemon.net> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-nextLinus Torvalds2014-06-121-0/+4
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull networking updates from David Miller: 1) Seccomp BPF filters can now be JIT'd, from Alexei Starovoitov. 2) Multiqueue support in xen-netback and xen-netfront, from Andrew J Benniston. 3) Allow tweaking of aggregation settings in cdc_ncm driver, from Bjørn Mork. 4) BPF now has a "random" opcode, from Chema Gonzalez. 5) Add more BPF documentation and improve test framework, from Daniel Borkmann. 6) Support TCP fastopen over ipv6, from Daniel Lee. 7) Add software TSO helper functions and use them to support software TSO in mvneta and mv643xx_eth drivers. From Ezequiel Garcia. 8) Support software TSO in fec driver too, from Nimrod Andy. 9) Add Broadcom SYSTEMPORT driver, from Florian Fainelli. 10) Handle broadcasts more gracefully over macvlan when there are large numbers of interfaces configured, from Herbert Xu. 11) Allow more control over fwmark used for non-socket based responses, from Lorenzo Colitti. 12) Do TCP congestion window limiting based upon measurements, from Neal Cardwell. 13) Support busy polling in SCTP, from Neal Horman. 14) Allow RSS key to be configured via ethtool, from Venkata Duvvuru. 15) Bridge promisc mode handling improvements from Vlad Yasevich. 16) Don't use inetpeer entries to implement ID generation any more, it performs poorly, from Eric Dumazet. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next: (1522 commits) rtnetlink: fix userspace API breakage for iproute2 < v3.9.0 tcp: fixing TLP's FIN recovery net: fec: Add software TSO support net: fec: Add Scatter/gather support net: fec: Increase buffer descriptor entry number net: fec: Factorize feature setting net: fec: Enable IP header hardware checksum net: fec: Factorize the .xmit transmit function bridge: fix compile error when compiling without IPv6 support bridge: fix smatch warning / potential null pointer dereference via-rhine: fix full-duplex with autoneg disable bnx2x: Enlarge the dorq threshold for VFs bnx2x: Check for UNDI in uncommon branch bnx2x: Fix 1G-baseT link bnx2x: Fix link for KR with swapped polarity lane sctp: Fix sk_ack_backlog wrap-around problem net/core: Add VF link state control policy net/fsl: xgmac_mdio is dependent on OF_MDIO net/fsl: Make xgmac_mdio read error message useful net_sched: drr: warn when qdisc is not work conserving ...
| * ARM: mvebu: use the fixed-link PHY DT binding for the Armada XP Matrix boardThomas Petazzoni2014-05-161-0/+4
| | | | | | | | | | | | | | | | | | The Armada XP Matrix board has an Ethernet PHY that isn't configurable through the MDIO bus, so we use the newly introduced fixed-link PHY DT binding to represent the PHY of this platform and get network working. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | ARM: mvebu: remove clock-frequency of serial port Device Tree nodesThomas Petazzoni2014-04-261-4/+0
|/ | | | | | | | | | | | | | | Now that the Armada 370/375/38x/XP SoC-level Device Tree files have the proper "clocks" property in their UART controllers node, it is no longer useful to have the clock-frequency property defined in the board-level Device Tree files. Therefore, this commit gets rid of all the useless 'clock-frequency' properties. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Link: https://lkml.kernel.org/r/1397806908-7550-5-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
* ARM: mvebu: the Armada XP Matrix board has 4 GBThomas Petazzoni2014-03-061-1/+6
| | | | | | | | | | | Since the Armada XP Matrix board has 4 GB of RAM and not 2 GB, we update the Device Tree to take into account the correct amount of memory. As noted in the new comment, the last 256 MB of RAM are in fact not usable, due to the overlap with the MBus Window address range. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
* arm: mvebu: add support for the Armada XP Matrix boardThomas Petazzoni2013-10-031-0/+75
The Armada XP Matrix board is the mother board of a more complex system. The mother board uses an Armada XP MV78460, 4 serial ports, 2 SATA ports, one Ethernet connection, a PCIe port and a USB port. All those devices are enabled in the Device Tree added by this patch. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>