Commit Graph

9 Commits

Author SHA1 Message Date
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
Boris Brezillon c466d997bb ARM: mvebu: define crypto SRAM ranges for all armada-xp boards
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>
2015-09-29 16:16:11 +02:00
Thomas Petazzoni 9552203cb0 ARM: mvebu: use stdout-path in all armada-*.dts
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>
2015-03-04 15:02:28 +01:00
Gregory CLEMENT 395076eada ARM: mvebu: armada-xp-matrix: Relicense the device tree under GPLv2+/X11
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>
2015-01-26 19:28:13 -06:00
Linus Torvalds f9da455b93 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
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
  ...
2014-06-12 14:27:40 -07:00
Thomas Petazzoni 84f6e11f21 ARM: mvebu: use the fixed-link PHY DT binding for the Armada XP Matrix board
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>
2014-05-16 17:19:26 -04:00
Thomas Petazzoni 0d9179fb33 ARM: mvebu: remove clock-frequency of serial port Device Tree nodes
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>
2014-04-26 00:34:44 +00:00
Thomas Petazzoni ebe021e268 ARM: mvebu: the Armada XP Matrix board has 4 GB
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>
2014-03-06 19:59:38 +00:00
Thomas Petazzoni 7837feff0d arm: mvebu: add support for the Armada XP Matrix board
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>
2013-10-03 15:13:01 +00:00