ARM: mvebu: Device Tree updates for Armada XP boards
cover ARM: mvebu: Device Tree updates for Armada XP boards
Hello,
This set of commits updates the Armada XP DB and Armada XP GP Device Trees to work with the newest DT capable bootloaders from Marvell that remap internal registers at 0xf1000000 and move the MBus Window base address to 0xf0000000.
Also, the last commit updates the available amount of RAM on the Armada XP Matrix board.
Thomas
Thomas Petazzoni (4):
ARM: mvebu: change the default PCIe apertures for Armada 370/XP
ARM: mvebu: switch the Armada XP DB to use internal registers at
0xf1000000
ARM: mvebu: switch the Armada XP GP to use internal registers at
0xf1000000ARM: mvebu: the Armada XP Matrix board has 4 GB
arch/arm/boot/dts/armada-370-xp.dtsi | 4 ++-- arch/arm/boot/dts/armada-xp-db.dts | 13 +++++++++++-- arch/arm/boot/dts/armada-xp-gp.dts | 22 ++++++++++++++++------ arch/arm/boot/dts/armada-xp-matrix.dts | 7 ++++++- 4 files changed, 35 insertions(+), 11 deletions(-)
Signature · 1 line
1.8.3.2
PATCH 1/4 ARM: mvebu: change the default PCIe apertures for Armada 370/XP
The latest Marvell bootloaders for various boards change the MBus Window base address from 0xC0000000 to 0xF0000000, in order to make more RAM in the first 4 GB actually usable by the kernel (RAM that is covered by the MBus window is "shadowed" and therefore not usable).
However, our default PCIe memory and I/O apertures where sitting at 0xe0000000 (for memory) and 0xe8000000 (for I/O), which will now be outside of the MBus Window range on those platforms. To make things work, we have to ensure those apertures use addresses in the 0xF0000000 -> 0xFFFFFFFF range.
Of course this change of the MBus Window base address from 0xC0000000 to 0xF0000000 also comes with a change of the internal register base address from 0xD0000000 to 0xF1000000.
We have therefore designed the following memory map:
* 0xF0000000 -> 0xF1000000: 16 MB, used for NOR flashes on Armada XP GP and Armada XP DB.
* 0xF1000000 -> 0xF1100000: 1 MB, used for internal registers.
* 0xF8000000 -> 0xFFE00000: 126 MB, used for PCIe memory.
* 0xFFE00000 -> 0xFFF00000: 1 MB, used for PCIe I/O.
* 0xFFF00000 -> 0xFFFFFFFF: 1 MB, used for the BootROM mapping
There is one exception to this layout: the Armada XP OpenBlocks, which has a 128 MB NOR flash, mapped from 0xF0000000 to 0xF8000000. This does not conflict with the current change for the PCIe I/O and memory apertures, and continues to work because on Armada XP OpenBlocks, the bootloader is an old one, and continues to have internal registers mapped at 0xD0000000.
--- arch/arm/boot/dts/armada-370-xp.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/arm/boot/dts/armada-370-xp.dtsi +2 -2
@@ -44,8 +44,8 @@ #size-cells = <1>; controller = <&mbusc>; interrupt-parent = <&mpic>; - pcie-mem-aperture = <0xe0000000 0x8000000>; - pcie-io-aperture = <0xe8000000 0x100000>; + pcie-mem-aperture = <0xf8000000 0x7e00000>; + pcie-io-aperture = <0xffe00000 0x100000>; devbus-bootcs { compatible = "marvell,mvebu-devbus";
Signature · 1 line
1.8.3.2
PATCH 2/4 ARM: mvebu: switch the Armada XP DB to use internal registers at 0xf1000000
In reply to Thomas PetazzoniMarvell has now provided bootloaders that are Device Tree capable for the Armada XP DB board, and that also remap the internal register base address to 0xf1000000. In addition, the bootloader now sets the MBus Window base address to 0xf0000000, but on this board, this change doesn't make much difference since the board is by default equipped with 2 GB of RAM.
Therefore this commit updates the soc->ranges Device Tree property with the fact that the internal registers are now mapped at 0xf1000000.
--- arch/arm/boot/dts/armada-xp-db.dts | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-)
arch/arm/boot/dts/armada-xp-db.dts +11 -2
@@ -2,7 +2,7 @@ * Device Tree file for Marvell Armada XP evaluation board * (DB-78460-BP) * - * Copyright (C) 2012 Marvell + * Copyright (C) 2012-2014 Marvell * * Lior Amsalem <[email protected]> * Gregory CLEMENT <[email protected]>
@@ -11,6 +11,15 @@ * This file is licensed under the terms of the GNU General Public * License version 2. This program is licensed "as is" without any * warranty of any kind, whether express or implied. + * + * 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/;
@@ -30,7 +39,7 @@ }; soc { - ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000 + ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xf1000000 0x100000 MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000 MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000>;
Signature · 1 line
1.8.3.2
PATCH 3/4 ARM: mvebu: switch the Armada XP GP to use internal registers at 0xf1000000
In reply to Thomas PetazzoniMarvell has now provided bootloaders that are Device Tree capable for the Armada XP GP board, and that also remap the internal register base address to 0xf1000000. In addition, the bootloader now sets the MBus Window base address to 0xf0000000, which allows to use much more RAM in the last GB of RAM before the 4 GB limit (the entire space from 0xC0000000 to 0xFFFFFFFF was not usable due to being used for I/O, not only the space from 0xF0000000 to 0xFFFFFFFF is used for I/O).
Therefore this commit:
* Updates the memory->reg Device Tree property with the fact that in the first bank of RAM, memory up to 0xf0000000 can be used.
* Updates the soc->ranges Device Tree property with the fact that the internal registers are now mapped at 0xf1000000.
--- arch/arm/boot/dts/armada-xp-gp.dts | 22 ++++++++++++++++------ 1 file changed, 16 insertions(+), 6 deletions(-)
arch/arm/boot/dts/armada-xp-gp.dts +16 -6
@@ -2,7 +2,7 @@ * Device Tree file for Marvell Armada XP development board * (DB-MV784MP-GP) * - * Copyright (C) 2013 Marvell + * Copyright (C) 2013-2014 Marvell * * Lior Amsalem <[email protected]> * Gregory CLEMENT <[email protected]>
@@ -11,6 +11,15 @@ * This file is licensed under the terms of the GNU General Public * License version 2. This program is licensed "as is" without any * warranty of any kind, whether express or implied. + * + * 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/;
@@ -30,16 +39,17 @@ * 8 GB of plug-in RAM modules by default.The amount * of memory available can be changed by the * bootloader according the size of the module - * actually plugged. Only 7GB are usable because - * addresses from 0xC0000000 to 0xffffffff are used by - * the internal registers of the SoC. + * actually plugged. However, memory between + * 0xF0000000 to 0xFFFFFFFF cannot be used, as it is + * the address range used for I/O (internal registers, + * MBus windows). */ - reg = <0x00000000 0x00000000 0x00000000 0xC0000000>, + reg = <0x00000000 0x00000000 0x00000000 0xf0000000>, <0x00000001 0x00000000 0x00000001 0x00000000>; }; soc { - ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000 + ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xf1000000 0x100000 MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000 MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000>;
Signature · 1 line
1.8.3.2
PATCH 4/4 ARM: mvebu: the Armada XP Matrix board has 4 GB
In reply to Thomas PetazzoniSince 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.
--- arch/arm/boot/dts/armada-xp-matrix.dts | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
arch/arm/boot/dts/armada-xp-matrix.dts +6 -1
@@ -23,7 +23,12 @@ memory { device_type = "memory"; - reg = <0 0x00000000 0 0x80000000>; /* 2 GB */ + /* + * This board has 4 GB of RAM, but the last 256 MB of + * RAM are not usable due to the overlap with the MBus + * Window address range + */ + reg = <0 0x00000000 0 0xf0000000>; }; soc {
Signature · 1 line
1.8.3.2
PATCH 4/4 ARM: mvebu: the Armada XP Matrix board has 4 GB
Quoted 5 lines · Thomas Petazzoni
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.
usually the bootloader (DT) or atags_to_fdt overwrites this. Is there a scenario when that doesn't happen?
thx,
Jason.
Quoted 26 lines
Signed-off-by Thomas Petazzoni <[email protected]>--- arch/arm/boot/dts/armada-xp-matrix.dts | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)arch/arm/boot/dts/armada-xp-matrix.dts +6
-1@@ -23,7 +23,12 @@ memory { device_type = "memory"; - reg = <0 0x00000000 0 0x80000000>; /* 2 GB */ + /* + * This board has 4 GB of RAM, but the last 256 MB of + * RAM are not usable due to the overlap with the MBus + * Window address range + */ + reg = <0 0x00000000 0 0xf0000000>; }; soc {Signature · 1 line
1.8.3.2
PATCH 4/4 ARM: mvebu: the Armada XP Matrix board has 4 GB
Dear Jason Cooper,
Quoted 9 lines · Jason Cooper
Quoted 5 lines · Thomas Petazzoni
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.
usually the bootloader (DT) or
atags_to_fdtoverwrites this. Is there a scenario when that doesn't happen?
ATAGs booting with CONFIG_ARM_ATAG_DTB_COMPAT disabled. Though mainly the intent here is that if the amount of memory is mentioned in the DT, it's nicer when it's actually correct :-)
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 4/4 ARM: mvebu: the Armada XP Matrix board has 4 GB
Quoted 10 lines · Thomas Petazzoni
Dear Jason Cooper,
Quoted 7 lines · Jason Cooper
Quoted 5 lines · Thomas Petazzoni
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.
Quoted 6 lines
Quoted 2 lines
usually the bootloader (DT) or
atags_to_fdtoverwrites this. Is there a scenario when that doesn't happen?ATAGs booting with
CONFIG_ARM_ATAG_DTB_COMPATdisabled. Though mainly the intent here is that if the amount of memory is mentioned in the DT, it's nicer when it's actually correct :-)
Ok, just wanted to make sure we weren't trying to work around broken bootloaders (DT aware, wrong idea of size) or something else silly like that.
thx,
Jason.
cover ARM: mvebu: Device Tree updates for Armada XP boards
In reply to Thomas PetazzoniQuoted 18 lines · Thomas Petazzoni
Hello,
This set of commits updates the Armada XP DB and Armada XP GP Device Trees to work with the newest DT capable bootloaders from Marvell that remap internal registers at
0xf1000000and move the MBus Window base address to0xf0000000.Also, the last commit updates the available amount of RAM on the Armada XP Matrix board.
Thomas
Thomas Petazzoni (4):
ARM: mvebu: change the default PCIe apertures for Armada 370/XP
ARM: mvebu: switch the Armada XP DB to use internal registers at0xf1000000 ARM: mvebu: switch the Armada XP GP to use internal registers at 0xf1000000
Quoted 7 lines
ARM: mvebu: the Armada XP Matrix board has 4 GB
arch/arm/boot/dts/armada-370-xp.dtsi | 4 ++-- arch/arm/boot/dts/armada-xp-db.dts | 13 +++++++++++-- arch/arm/boot/dts/armada-xp-gp.dts | 22 ++++++++++++++++------ arch/arm/boot/dts/armada-xp-matrix.dts | 7 ++++++- 4 files changed, 35 insertions(+), 11 deletions(-)
Whole series applied to mvebu/dt.
fyi - we only have one more day of -next (tonight, 7pm US East Coast time) before -rc6 drops.
I'm comfortable sending a lightly tested mvebu/dt pull request with all the stuff submitted in the last couple days, but I fear there isn't enough testing time before arm-soc stops taking pull requests.
I'm particularly concerned about the watchdog changes and the coherency fabric changes. I'll take those in when ready, and send pull requests when appropriate, but that will most likely fall after the cutoff. Which means those changes will carry over to v3.16...
thx,
Jason.
cover ARM: mvebu: Device Tree updates for Armada XP boards
Dear Jason Cooper,
Quoted 5 lines · Jason Cooper
Whole series applied to mvebu/dt.
fyi - we only have one more day of -next (tonight, 7pm US East Coast time) before -rc6 drops.
Quoted 8 lines
I'm comfortable sending a lightly tested mvebu/dt pull request with all the stuff submitted in the last couple days, but I fear there isn't enough testing time before arm-soc stops taking pull requests.
I'm particularly concerned about the watchdog changes and the coherency fabric changes. I'll take those in when ready, and send pull requests when appropriate, but that will most likely fall after the cutoff. Which means those changes will carry over to v3.16...
I'll let Ezequiel speak for the watchdog stuff.
For the coherency fabric stuff, our plan was clearly to get it merged on 3.16, not in 3.15. I'm sending it right now because we will have other things (such as SMP support) to stack on top of it for 3.16. IOW:
no problems with having this only in 3.16. Of course, if you feel comfortable about having it in 3.15, then that would be great, but it is clearly not mandatory.
Thanks!
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
cover ARM: mvebu: Device Tree updates for Armada XP boards
In reply to Jason CooperQuoted 29 lines · Jason Cooper
Quoted 18 lines · Thomas Petazzoni
Hello,
This set of commits updates the Armada XP DB and Armada XP GP Device Trees to work with the newest DT capable bootloaders from Marvell that remap internal registers at
0xf1000000and move the MBus Window base address to0xf0000000.Also, the last commit updates the available amount of RAM on the Armada XP Matrix board.
Thomas
Thomas Petazzoni (4):
ARM: mvebu: change the default PCIe apertures for Armada 370/XP
ARM: mvebu: switch the Armada XP DB to use internal registers at0xf1000000 ARM: mvebu: switch the Armada XP GP to use internal registers at 0xf1000000Quoted 7 lines
ARM: mvebu: the Armada XP Matrix board has 4 GB
arch/arm/boot/dts/armada-370-xp.dtsi | 4 ++-- arch/arm/boot/dts/armada-xp-db.dts | 13 +++++++++++-- arch/arm/boot/dts/armada-xp-gp.dts | 22 ++++++++++++++++------ arch/arm/boot/dts/armada-xp-matrix.dts | 7 ++++++- 4 files changed, 35 insertions(+), 11 deletions(-)Whole series applied to mvebu/dt.
Quoted 8 lines
fyi - we only have one more day of -next (tonight, 7pm US East Coast time) before -rc6 drops.
I'm comfortable sending a lightly tested mvebu/dt pull request with all the stuff submitted in the last couple days, but I fear there isn't enough testing time before arm-soc stops taking pull requests.
I'm particularly concerned about the watchdog changes and the coherency
Hm... I wasn't really aiming v3.15, as I thought it was already too late.
On the other side, if we can get someone to review the changes and someone to double-check them on 370/XP/Kirkwood, you could pull it soon enough?
Anyway, it's not a big deal if it gets pulled in v3.16. We are already doing *a lot* of mvebu movement in this release, IMHO.
Signature · 3 lines
Ezequiel Garc?a, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com
cover ARM: mvebu: Device Tree updates for Armada XP boards
Quoted 33 lines · Ezequiel Garcia
Quoted 32 lines · Jason Cooper
Quoted 18 lines · Thomas Petazzoni
Hello,
This set of commits updates the Armada XP DB and Armada XP GP Device Trees to work with the newest DT capable bootloaders from Marvell that remap internal registers at
0xf1000000and move the MBus Window base address to0xf0000000.Also, the last commit updates the available amount of RAM on the Armada XP Matrix board.
Thomas
Thomas Petazzoni (4):
ARM: mvebu: change the default PCIe apertures for Armada 370/XP
ARM: mvebu: switch the Armada XP DB to use internal registers at0xf1000000 ARM: mvebu: switch the Armada XP GP to use internal registers at 0xf1000000Quoted 7 lines
ARM: mvebu: the Armada XP Matrix board has 4 GB
arch/arm/boot/dts/armada-370-xp.dtsi | 4 ++-- arch/arm/boot/dts/armada-xp-db.dts | 13 +++++++++++-- arch/arm/boot/dts/armada-xp-gp.dts | 22 ++++++++++++++++------ arch/arm/boot/dts/armada-xp-matrix.dts | 7 ++++++- 4 files changed, 35 insertions(+), 11 deletions(-)Whole series applied to mvebu/dt.
fyi - we only have one more day of -next (tonight, 7pm US East Coast time) before -rc6 drops.
Quoted 7 lines
Quoted 5 lines
I'm comfortable sending a lightly tested mvebu/dt pull request with all the stuff submitted in the last couple days, but I fear there isn't enough testing time before arm-soc stops taking pull requests.
I'm particularly concerned about the watchdog changes and the coherency
Hm... I wasn't really aiming v3.15, as I thought it was already too late.
Ok, great. I just wanted to make sure everybody was on the same page. I'll hold off on pulling those two in until v3.15 is completely out of our hands (all in arm-soc and pinctrl).
Quoted 2 lines
On the other side, if we can get someone to review the changes and someone to double-check them on 370/XP/Kirkwood, you could pull it soon enough?
Now, now, I wasn't _asking_ for *more* work. ;-)
Quoted 2 lines
Anyway, it's not a big deal if it gets pulled in v3.16. We are already doing *a lot* of mvebu movement in this release, IMHO.
Agreed.
thx,
Jason.