summaryrefslogtreecommitdiff
path: root/arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts
AgeCommit message (Collapse)Author
2016-03-16ARM: mvebu: fix overlap of Crypto SRAM with PCIe memory windowThomas Petazzoni
commit d7d5a43c0d16760f25d892bf9329848167a8b8a4 upstream. 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> 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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-29ARM: mvebu: define crypto SRAM ranges for all armada-xp boardsBoris Brezillon
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-03-04ARM: mvebu: use stdout-path in all armada-*.dtsThomas Petazzoni
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-01-26ARM: mvebu: armada-xp-lenovo-ix4-300d: Relicense the device tree under ↵Gregory CLEMENT
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: Arnaud Ebalard <arno@natisbad.org> Acked-by: Benoit Masson <yahoo@perenite.com> Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
2014-11-26arm: mvebu: normalize pinctrl entries for Armada SoCsArnaud Ebalard
There are currently 2 differents naming conventions used between the existing Armada SoC DT files for pinctrl entries (*_pin(s): *-pin(s) and pmx_*: pmx-*) with a vast majority of files using the former: $ grep _pin arch/arm/boot/dts/armada-*.dts* | wc -l 155 $ grep pmx arch/arm/boot/dts/armada-*.dts* | wc -l 13 In fact, only some Armada XP files are using the second variant. This patch normalizes those files (mainly ge0/1 entries) to use the first variant. Signed-off-by: Arnaud Ebalard <arno@natisbad.org> Link: https://lkml.kernel.org/r/00114c3169e1d93259ff4150ed46ee36eae16b1e.1416670812.git.arno@natisbad.org Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-11-22arm: mvebu: use recently introduced uart label for stdout-pathArnaud Ebalard
Now that labels for uartX are available in Marvell Armada .dtsi files, this patch replaces the "/soc/internal-regs/serial@12000" found in armada-xp-lenovo-ix4-300d.dts file for stdout-path property by the more concise &uart0. Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Suggested-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Arnaud Ebalard <arno@natisbad.org> Link: https://lkml.kernel.org/r/d1a883510e01f7f212a385e826dccbef903fae42.1416613429.git.arno@natisbad.org Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-11-02ARM: mvebu: armada-xp: Fix 74hc595 count for Lenovo ix4-300dSebastian Hesselbarth
There is only one 74hc595 connected to GPIO but two were given in the registers-number property. Fix it up. Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Tested-By: Benoit Masson <yahoo@perenite.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-11-02ARM: mvebu: armada-xp: Add I2C eeprom on Lenovo ix4-300dSebastian Hesselbarth
There is an I2C eeprom connected on Lenovo ix4-300d, add the corresponding node. Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Tested-By: Benoit Masson <yahoo@perenite.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-11-02ARM: mvebu: armada-xp: Add RGMII pinctrl to Lenovo ix4-300dSebastian Hesselbarth
Lenovo ix4-300d has two ethernet PHYs connected via RGMII. Add the corresponding pinctrl settings. Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Tested-By: Benoit Masson <yahoo@perenite.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-11-02ARM: mvebu: armada-xp: Use pinctrl node aliasSebastian Hesselbarth
Armada XP pinctrl node gained an alias, make use of it. Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Tested-By: Benoit Masson <yahoo@perenite.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-11-02ARM: mvebu: armada-xp: Add node alias to pinctrl and add base addressSebastian Hesselbarth
In other MVEBU SoCs, the pin controller node is called pin-ctrl with its base address added. Also, we have a node alias to access the pinctrl node easily. Fix this for Armada XP pinctrl nodes to be consistent with other SoCs. Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Tested-By: Benoit Masson <yahoo@perenite.com> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-07-28ARM: mvebu: Add dts definition for Lenovo Iomega ix4-300d NASBenoit Masson
The Lenovo Iomega ix4-300d is a 4-Bay sata NAS with dual Gb, USB2.0 & 3.0, powered by a Marvell Armada XP MV78230 dual core CPU. http://shop.lenovo.com/us/en/servers/network-storage/lenovoemc/ix4-300d/ Signed-off-by: Benoit Masson <yahoo@perenite.com> Link: https://lkml.kernel.org/r/1406503839-4662-1-git-send-email-yahoo@perenite.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
generated by cgit v1.2.3 (git 2.0.4) at 2024-05-14 00:36:38 +0000