[PATCH 0/4] ARM: mvebu: Device Tree updates for Armada XP boards

[PATCH 0/4] ARM: mvebu: Device Tree updates for Armada XP boards

[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 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
    0xf1000000
  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(-)

-- 
1.8.3.2

[PATCH 1/4] ARM: mvebu: change the default PCIe apertures for Armada 370/XP

[Thomas Petazzoni]

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.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 arch/arm/boot/dts/armada-370-xp.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 74b5964..2188ce6 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -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";
-- 
1.8.3.2

[PATCH 2/4] ARM: mvebu: switch the Armada XP DB to use internal registers at 0xf1000000

[Thomas Petazzoni]

Marvell 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.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 arch/arm/boot/dts/armada-xp-db.dts | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index bcf6d79..448373c 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -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 <alior@marvell.com>
  * Gregory CLEMENT <gregory.clement@free-electrons.com>
@@ -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>;
 
-- 
1.8.3.2

[PATCH 3/4] ARM: mvebu: switch the Armada XP GP to use internal registers at 0xf1000000

[Thomas Petazzoni]

Marvell 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.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 arch/arm/boot/dts/armada-xp-gp.dts | 22 ++++++++++++++++------
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 274e2ad..61bda68 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -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 <alior@marvell.com>
  * Gregory CLEMENT <gregory.clement@free-electrons.com>
@@ -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>;
 
-- 
1.8.3.2

[PATCH 4/4] ARM: mvebu: the Armada XP Matrix board has 4 GB

[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.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 arch/arm/boot/dts/armada-xp-matrix.dts | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/armada-xp-matrix.dts b/arch/arm/boot/dts/armada-xp-matrix.dts
index e47c49e..c224274 100644
--- a/arch/arm/boot/dts/armada-xp-matrix.dts
+++ b/arch/arm/boot/dts/armada-xp-matrix.dts
@@ -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 {
-- 
1.8.3.2

[PATCH 4/4] ARM: mvebu: the Armada XP Matrix board has 4 GB

[Jason Cooper]

On Tue, Mar 04, 2014 at 05:37:02PM +0100, Thomas Petazzoni wrote:
> 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.

> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
>  arch/arm/boot/dts/armada-xp-matrix.dts | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/armada-xp-matrix.dts b/arch/arm/boot/dts/armada-xp-matrix.dts
> index e47c49e..c224274 100644
> --- a/arch/arm/boot/dts/armada-xp-matrix.dts
> +++ b/arch/arm/boot/dts/armada-xp-matrix.dts
> @@ -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 {
> -- 
> 1.8.3.2
> 

[PATCH 4/4] ARM: mvebu: the Armada XP Matrix board has 4 GB

[Thomas Petazzoni]

Dear Jason Cooper,

On Tue, 4 Mar 2014 13:55:12 -0500, Jason Cooper wrote:
> On Tue, Mar 04, 2014 at 05:37:02PM +0100, Thomas Petazzoni wrote:
> > 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?

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
-- 
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

[Jason Cooper]

On Tue, Mar 04, 2014 at 08:02:15PM +0100, Thomas Petazzoni wrote:
> Dear Jason Cooper,
> 
> On Tue, 4 Mar 2014 13:55:12 -0500, Jason Cooper wrote:
> > On Tue, Mar 04, 2014 at 05:37:02PM +0100, Thomas Petazzoni wrote:
> > > 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?
> 
> 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 :-)

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.

[PATCH 0/4] ARM: mvebu: Device Tree updates for Armada XP boards

[Jason Cooper]

On Tue, Mar 04, 2014 at 05:36:58PM +0100, Thomas Petazzoni wrote:
> 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
>     0xf1000000
>   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.

[PATCH 0/4] ARM: mvebu: Device Tree updates for Armada XP boards

[Thomas Petazzoni]

Dear Jason Cooper,

On Thu, 6 Mar 2014 15:05:43 -0500, Jason Cooper wrote:

> 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...

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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH 0/4] ARM: mvebu: Device Tree updates for Armada XP boards

[Ezequiel Garcia]

On Mar 06, Jason Cooper wrote:
> On Tue, Mar 04, 2014 at 05:36:58PM +0100, Thomas Petazzoni wrote:
> > 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
> >     0xf1000000
> >   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

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.
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

[PATCH 0/4] ARM: mvebu: Device Tree updates for Armada XP boards

[Jason Cooper]

On Thu, Mar 06, 2014 at 09:10:01PM -0300, Ezequiel Garcia wrote:
> On Mar 06, Jason Cooper wrote:
> > On Tue, Mar 04, 2014 at 05:36:58PM +0100, Thomas Petazzoni wrote:
> > > 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
> > >     0xf1000000
> > >   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
> 
> 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).

> 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.  ;-)

> 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.