arm: mvebu: DT fixes for 3.8

arm: mvebu: DT fixes for 3.8

[Thomas Petazzoni]

Jason, Andrew, Gr?gory,

Here is a set of fixes for the Device Tree data of Armada XP/Armada
370, suitable for inclusion in 3.8.

Thanks!

Thomas

[PATCH 1/4] arm: mvebu: limit OpenBlocks AX3-4 to 1 GB of RAM

[Thomas Petazzoni]

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
This is a fix for 3.8, should be pushed for some 3.8-rc.
---
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |    8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 72a9dd0..3e9ee1b 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -23,7 +23,13 @@
 
 	memory {
 		device_type = "memory";
-		reg = <0x00000000 0xC0000000>; /* 3 GB */
+		/*
+		 * The board has an additional 2 GB DRAM chip in an
+		 * expansion slot, but using it makes the system very
+		 * unstable: it even doesn't boot reliably. So we use
+		 * only the soldered 1 GB chip for now.
+		 */
+		reg = <0x00000000 0x40000000>; /* 1 GB */
 	};
 
 	soc {
-- 
1.7.9.5

[PATCH 1/4] arm: mvebu: limit OpenBlocks AX3-4 to 1 GB of RAM

[Andrew Lunn]

On 04/01/13 17:04, Thomas Petazzoni wrote:
> Signed-off-by: Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
> ---
> This is a fix for 3.8, should be pushed for some 3.8-rc.
> ---
>   arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |    8 +++++++-
>   1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
> index 72a9dd0..3e9ee1b 100644
> --- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
> +++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
> @@ -23,7 +23,13 @@
>
>   	memory {
>   		device_type = "memory";
> -		reg =<0x00000000 0xC0000000>; /* 3 GB */
> +		/*
> +		 * The board has an additional 2 GB DRAM chip in an
> +		 * expansion slot, but using it makes the system very
> +		 * unstable: it even doesn't boot reliably. So we use
> +		 * only the soldered 1 GB chip for now.
> +		 */
> +		reg =<0x00000000 0x40000000>; /* 1 GB */
>   	};
>
>   	soc {

Hi Thomas

How many different boards have you tried?

I've not had problems with the board i have. Using the plathome supplied 
kernel, i've rebuilt the kernel, which is a good memory test. Using 
mainline, i've booted a number of times when developing the thermal 
driver and not had problems.

I would hate to disable 2GB of RAM just because your board has a fault.

	Andrew

[PATCH 1/4] arm: mvebu: limit OpenBlocks AX3-4 to 1 GB of RAM

[Thomas Petazzoni]

Dear Andrew Lunn,

On Fri, 04 Jan 2013 18:26:35 +0100, Andrew Lunn wrote:

> How many different boards have you tried?

I've tried only one board, since I have only one.

> I've not had problems with the board i have. Using the plathome supplied 
> kernel, i've rebuilt the kernel, which is a good memory test. Using 
> mainline, i've booted a number of times when developing the thermal 
> driver and not had problems.
> 
> I would hate to disable 2GB of RAM just because your board has a fault.

Indeed. If you report that things work nicely on your board, then let's
discard this fix, and blame a hardware problem.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH 1/4] arm: mvebu: limit OpenBlocks AX3-4 to 1 GB of RAM

[Andrew Lunn]

On 04/01/13 18:31, Thomas Petazzoni wrote:
> Dear Andrew Lunn,
>
> On Fri, 04 Jan 2013 18:26:35 +0100, Andrew Lunn wrote:
>
>> How many different boards have you tried?
>
> I've tried only one board, since I have only one.
>
>> I've not had problems with the board i have. Using the plathome supplied
>> kernel, i've rebuilt the kernel, which is a good memory test. Using
>> mainline, i've booted a number of times when developing the thermal
>> driver and not had problems.
>>
>> I would hate to disable 2GB of RAM just because your board has a fault.
>
> Indeed. If you report that things work nicely on your board, then let's
> discard this fix, and blame a hardware problem.

Hi Thomas

It would be nice to have a sample size bigger than two.

Anybody else have a OpenBlocks AX3-4 and can report if it works or not?

Thomas, could you swap out the RAM module you have for a known good one?
Can you test the RAM module in some other board you know works?

Thanks
     Andrew

[PATCH 1/4] arm: mvebu: limit OpenBlocks AX3-4 to 1 GB of RAM

[Thomas Petazzoni]

Dear Andrew Lunn,

On Fri, 04 Jan 2013 18:37:26 +0100, Andrew Lunn wrote:

> It would be nice to have a sample size bigger than two.

Indeed.

> Anybody else have a OpenBlocks AX3-4 and can report if it works or not?

At least Gr?gory has one.

> Thomas, could you swap out the RAM module you have for a known good one?
> Can you test the RAM module in some other board you know works?

Unfortunately, I don't see off-hand which other board I have in which I
could test this RAM module, nor if I have a compatible RAM module to
test things with.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH 1/4] arm: mvebu: limit OpenBlocks AX3-4 to 1 GB of RAM

[Gregory CLEMENT]

On 01/04/2013 07:03 PM, Thomas Petazzoni wrote:
> Dear Andrew Lunn,
> 
> On Fri, 04 Jan 2013 18:37:26 +0100, Andrew Lunn wrote:
> 
>> It would be nice to have a sample size bigger than two.
> 
> Indeed.
> 
>> Anybody else have a OpenBlocks AX3-4 and can report if it works or not?
> 
> At least Gr?gory has one.

Until now I didn't notice any problem on this board with the 3GB enable.

I made more tests since I received this email, I booted (cold and hot boot)
the board dozens of times, and indeed every 5 or 10 reboot the kernel hanged
during boot at line:
"UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)"

After applying your patch, I didn't notice any hang after 20 boots. Do you
have a test pattern which make the kernel to hang each time to be sure that
it is the root of the problem?

> 
>> Thomas, could you swap out the RAM module you have for a known good one?
>> Can you test the RAM module in some other board you know works?
> 
> Unfortunately, I don't see off-hand which other board I have in which I
> could test this RAM module, nor if I have a compatible RAM module to
> test things with.
> 
> Thomas
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH 1/4] arm: mvebu: limit OpenBlocks AX3-4 to 1 GB of RAM

[Thomas Petazzoni]

Dear Gregory CLEMENT,

On Sun, 06 Jan 2013 22:36:58 +0100, Gregory CLEMENT wrote:

> Until now I didn't notice any problem on this board with the 3GB enable.
> 
> I made more tests since I received this email, I booted (cold and hot boot)
> the board dozens of times, and indeed every 5 or 10 reboot the kernel hanged
> during boot at line:
> "UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)"

I think it hangs at the same place here.

> After applying your patch, I didn't notice any hang after 20 boots. Do you
> have a test pattern which make the kernel to hang each time to be sure that
> it is the root of the problem?

No, I don't have a specific pattern. It just hangs from time to time.
Maybe 1 boot out of 5 or something like that. And it just hangs like it
did for you.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH 1/4] arm: mvebu: limit OpenBlocks AX3-4 to 1 GB of RAM

[Andrew Lunn]

On Sun, Jan 06, 2013 at 11:53:12PM +0100, Thomas Petazzoni wrote:
> Dear Gregory CLEMENT,
> 
> On Sun, 06 Jan 2013 22:36:58 +0100, Gregory CLEMENT wrote:
> 
> > Until now I didn't notice any problem on this board with the 3GB enable.
> > 
> > I made more tests since I received this email, I booted (cold and hot boot)
> > the board dozens of times, and indeed every 5 or 10 reboot the kernel hanged
> > during boot at line:
> > "UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)"
> 
> I think it hangs at the same place here.
> 
> > After applying your patch, I didn't notice any hang after 20 boots. Do you
> > have a test pattern which make the kernel to hang each time to be sure that
> > it is the root of the problem?
> 
> No, I don't have a specific pattern. It just hangs from time to time.
> Maybe 1 boot out of 5 or something like that. And it just hangs like it
> did for you.

Hi Thomas, Gregory

I've been testing my board some more, using the PlatHome kernel
installed on the device as i received it. I've rebooted the device 20
times and not had a single problem.

I will now swap to a mainline kernel, 3.8-rc2 plus UART patch.

  Andrew

[PATCH 1/4] arm: mvebu: limit OpenBlocks AX3-4 to 1 GB of RAM

[Andrew Lunn]

On Mon, Jan 07, 2013 at 10:47:47AM +0100, Andrew Lunn wrote:
> On Sun, Jan 06, 2013 at 11:53:12PM +0100, Thomas Petazzoni wrote:
> > Dear Gregory CLEMENT,
> > 
> > On Sun, 06 Jan 2013 22:36:58 +0100, Gregory CLEMENT wrote:
> > 
> > > Until now I didn't notice any problem on this board with the 3GB enable.
> > > 
> > > I made more tests since I received this email, I booted (cold and hot boot)
> > > the board dozens of times, and indeed every 5 or 10 reboot the kernel hanged
> > > during boot at line:
> > > "UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)"
> > 
> > I think it hangs at the same place here.
> > 
> > > After applying your patch, I didn't notice any hang after 20 boots. Do you
> > > have a test pattern which make the kernel to hang each time to be sure that
> > > it is the root of the problem?
> > 
> > No, I don't have a specific pattern. It just hangs from time to time.
> > Maybe 1 boot out of 5 or something like that. And it just hangs like it
> > did for you.
> 
> Hi Thomas, Gregory
> 
> I've been testing my board some more, using the PlatHome kernel
> installed on the device as i received it. I've rebooted the device 20
> times and not had a single problem.
> 
> I will now swap to a mainline kernel, 3.8-rc2 plus UART patch.

Hi Thomas, Gregory

So, twenty reboots later, no problems at all with 3.8-rc2. Got to
user space every time.

So, what are we doing differently?

BootROM 1.15
Booting from NOR flash
DDR3 Training Sequence - Ver 2.5.DDR3 Training Sequence - Registered DIMM WL -  
BootROM: Image checksum verification PASSED
 ** LOADER **


U-Boot 2009.08 (Jul 27 2012 - 18:23:11)
Plat'Home version: 1.1.1 (Base: Marvell BSP  2.2.3 NQ)

Do you have the same version?

I'm tftpbooting:

setenv bootargs root=/dev/ram console=ttyS0,115200 earlyprintk ; tftpboot 0x80000000 openblocks-dev; bootm

My image contain the kernel and a buildroot rootfs included within the
kernel image and DT is appended. I load it to address 0x80000000,
which puts it at the beginning of CS 3:

DRAM:   3 GB
       CS 0: base 0x00000000 size  1 GB
       CS 2: base 0x40000000 size  1 GB
       CS 3: base 0x80000000 size  1 GB

Thanks
	Andrew

[PATCH 1/4] arm: mvebu: limit OpenBlocks AX3-4 to 1 GB of RAM

[Thomas Petazzoni]

Dear Andrew Lunn,

On Mon, 7 Jan 2013 12:07:12 +0100, Andrew Lunn wrote:

> BootROM 1.15
> Booting from NOR flash
> DDR3 Training Sequence - Ver 2.5.DDR3 Training Sequence - Registered
> DIMM WL - BootROM: Image checksum verification PASSED
>  ** LOADER **
> 
> 
> U-Boot 2009.08 (Jul 27 2012 - 18:23:11)
> Plat'Home version: 1.1.1 (Base: Marvell BSP  2.2.3 NQ)
> 
> Do you have the same version?

BootROM 1.15
Booting from NOR flash
DDR3 Training Sequence - Ver 2.5.DDR3 Training Sequence - Registered
DIMM WL - SKIP BootROM: Image checksum verification PASSED
 ** LOADER **


U-Boot 2009.08 (Jul 27 2012 - 18:23:11)
Plat'Home version: 1.1.1 (Base: Marvell BSP  2.2.3 NQ)

Seems like we do have the same version.

> I'm tftpbooting:
> 
> setenv bootargs root=/dev/ram console=ttyS0,115200 earlyprintk ;
> tftpboot 0x80000000 openblocks-dev; bootm
> 
> My image contain the kernel and a buildroot rootfs included within the
> kernel image and DT is appended. I load it to address 0x80000000,
> which puts it at the beginning of CS 3:

Image is also with an initramfs + appended DTB. My boot command is:

tftp 1000000 192.168.0.14:uImage.armada-xp-openblocks-ax3-4; bootm

So I'm loading to a different address than you.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH 1/4] arm: mvebu: limit OpenBlocks AX3-4 to 1 GB of RAM

[Andrew Lunn]

> Image is also with an initramfs + appended DTB. My boot command is:
> 
> tftp 1000000 192.168.0.14:uImage.armada-xp-openblocks-ax3-4; bootm
> 
> So I'm loading to a different address than you.

Hi Thomas

Uboot tells me:

DRAM:   3 GB
       CS 0: base 0x00000000 size  1 GB
       CS 2: base 0x40000000 size  1 GB
       CS 3: base 0x80000000 size  1 GB
       Addresses 14M - 0M are saved for the U-Boot usage.

1000000 would be towards the beginning of this area reserved for uboot.

Could you try moving to somewhere outside of the first 14Mbytes and
see if that helps.

    Thanks
	Andrew

[PATCH 1/4] arm: mvebu: limit OpenBlocks AX3-4 to 1 GB of RAM

[Gregory CLEMENT]

On 01/07/2013 12:34 PM, Andrew Lunn wrote:
>> Image is also with an initramfs + appended DTB. My boot command is:
>>
>> tftp 1000000 192.168.0.14:uImage.armada-xp-openblocks-ax3-4; bootm
>>
>> So I'm loading to a different address than you.
> 
> Hi Thomas
> 
> Uboot tells me:
> 
> DRAM:   3 GB
>        CS 0: base 0x00000000 size  1 GB
>        CS 2: base 0x40000000 size  1 GB
>        CS 3: base 0x80000000 size  1 GB
>        Addresses 14M - 0M are saved for the U-Boot usage.
> 
> 1000000 would be towards the beginning of this area reserved for uboot.
> 
> Could you try moving to somewhere outside of the first 14Mbytes and
> see if that helps.

I tried to load the kernel at the same address as you (0x80000000) and
it still hanged after 3 or 4 boots.

Now we have to be sure that we use the same .config and the same compiler.
My compiler is :
arm-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.6/lto-wrapper
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++
--prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.6.3 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb
--disable-werror --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=arm-linux-gnueabi --program-prefix=arm-linux-gnueabi-
--includedir=/usr/arm-linux-gnueabi/include --with-headers=/usr/arm-linux-gnueabi/include --with-libs=/usr/arm-linux-gnueabi/lib
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)



> 
>     Thanks
> 	Andrew
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH 1/4] arm: mvebu: limit OpenBlocks AX3-4 to 1 GB of RAM

[Andrew Lunn]

> I tried to load the kernel at the same address as you (0x80000000) and
> it still hanged after 3 or 4 boots.

O.K. Thanks for testing that.
 
> Now we have to be sure that we use the same .config and the same compiler.
> My compiler is :
> arm-linux-gnueabi-gcc -v
> Using built-in specs.
> COLLECT_GCC=arm-linux-gnueabi-gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.6/lto-wrapper
> Target: arm-linux-gnueabi
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++
> --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
> --with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.6.3 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
> --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb
> --disable-werror --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=arm-linux-gnueabi --program-prefix=arm-linux-gnueabi-
> --includedir=/usr/arm-linux-gnueabi/include --with-headers=/usr/arm-linux-gnueabi/include --with-libs=/usr/arm-linux-gnueabi/lib
> Thread model: posix
> gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)

I Gregory

I have an older compile:

 arm-linux-gnueabi-gcc -v
Using built-in specs.
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.4.5 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --disable-sjlj-exceptions --enable-checking=release --program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include --build=i486-linux-gnu --host=i486-linux-gnu --target=arm-linux-gnueabi --with-headers=/usr/arm-linux-gnueabi/include --with-libs=/usr/arm-linux-gnueabi/lib
Thread model: posix
gcc version 4.4.5 (Debian 4.4.5-8) 

I'm using mvebu_defconfig and the only option i change is
CONFIG_INITRAMFS_SOURCE to point to my rootfs.cpio.gz file.

But of a long shot. Do you have much broadcast traffic in your
network? I just wonder if u-boot has left the ethernet interface
running, and during boot the hardware received a broadcast packet, DMAs
it into memory corrupting something? My board is on a very quiet
subnet, with virtually no broadcasts.

	Andrew

[PATCH 1/4] arm: mvebu: limit OpenBlocks AX3-4 to 1 GB of RAM

[Thomas Petazzoni]

Dear Andrew Lunn,

On Mon, 7 Jan 2013 12:34:11 +0100, Andrew Lunn wrote:
> > Image is also with an initramfs + appended DTB. My boot command is:
> > 
> > tftp 1000000 192.168.0.14:uImage.armada-xp-openblocks-ax3-4; bootm
> > 
> > So I'm loading to a different address than you.
> 
> Hi Thomas
> 
> Uboot tells me:
> 
> DRAM:   3 GB
>        CS 0: base 0x00000000 size  1 GB
>        CS 2: base 0x40000000 size  1 GB
>        CS 3: base 0x80000000 size  1 GB
>        Addresses 14M - 0M are saved for the U-Boot usage.
> 
> 1000000 would be towards the beginning of this area reserved for uboot.
> 
> Could you try moving to somewhere outside of the first 14Mbytes and
> see if that helps.

Jumping back on this old topic of the OpenBlocks AX3 not being stable
with 3 GB of RAM for Gr?gory and me, but being stable for you. Could
you check which revision of the Armada XP you have? Is it A0 or B0?

I.e, check the message:

 SoC:   MV78460 B0

in U-Boot. Gr?gory and I are using OpenBlocks AX3 based on the A0
version of the silicon (so the message I copy/pasted above is *not*
from our OpenBlocks, but a different Armada XP board). However,
PlatHome has been shipping since some time B0 revisions. Maybe it could
explain the difference we're seeing?

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH 1/4] arm: mvebu: limit OpenBlocks AX3-4 to 1 GB of RAM

[Andrew Lunn]

On Tue, Feb 26, 2013 at 04:20:23PM +0100, Thomas Petazzoni wrote:
> Dear Andrew Lunn,
> 
> On Mon, 7 Jan 2013 12:34:11 +0100, Andrew Lunn wrote:
> > > Image is also with an initramfs + appended DTB. My boot command is:
> > > 
> > > tftp 1000000 192.168.0.14:uImage.armada-xp-openblocks-ax3-4; bootm
> > > 
> > > So I'm loading to a different address than you.
> > 
> > Hi Thomas
> > 
> > Uboot tells me:
> > 
> > DRAM:   3 GB
> >        CS 0: base 0x00000000 size  1 GB
> >        CS 2: base 0x40000000 size  1 GB
> >        CS 3: base 0x80000000 size  1 GB
> >        Addresses 14M - 0M are saved for the U-Boot usage.
> > 
> > 1000000 would be towards the beginning of this area reserved for uboot.
> > 
> > Could you try moving to somewhere outside of the first 14Mbytes and
> > see if that helps.
> 
> Jumping back on this old topic of the OpenBlocks AX3 not being stable
> with 3 GB of RAM for Gr??gory and me, but being stable for you. Could
> you check which revision of the Armada XP you have? Is it A0 or B0?
> 
> I.e, check the message:
> 
>  SoC:   MV78460 B0
> 
> in U-Boot. Gr??gory and I are using OpenBlocks AX3 based on the A0
> version of the silicon (so the message I copy/pasted above is *not*
> from our OpenBlocks, but a different Armada XP board). However,
> PlatHome has been shipping since some time B0 revisions. Maybe it could
> explain the difference we're seeing?

Hi Thomas

My machine is an A0.

U-Boot 2009.08 (Jul 27 2012 - 18:23:11)
Plat'Home version: 1.1.1 (Base: Marvell BSP  2.2.3 NQ)

U-Boot Addressing:
       Code:            00600000:006BFFF0
       BSS:             0070D6A0
       Stack:           0x5fff70
       PageTable:       0x8e0000
       Heap address:    0x900000:0xe00000
Board: OpenBlocks AX3
SoC:   MV78260 A0
       running 2 CPUs
       Custom configuration
CPU:   Marvell PJ4B (584) v7 (Rev 2) LE
       CPU # 0
       CPU @ 1333Mhz, L2 @ 667Mhz
       DDR @ 667Mhz, TClock @ 250Mhz
       DDR 64Bit Width, FastPath Memory Access
       DDR ECC Disabled
PEX 0.0(0): Detected No Link.
PEX 0.1(1): Detected No Link.
DRAM:   3 GB
       CS 0: base 0x00000000 size  1 GB
       CS 2: base 0x40000000 size  1 GB
       CS 3: base 0x80000000 size  1 GB
       Addresses 14M - 0M are saved for the U-Boot usage.
Flash: 128 MB
POST:  mac verify Eth0 PASSED Eth1 PASSED Eth2 PASSED Eth3 PASSED 
FPU initialized to Run Fast Mode.
USB 0: Host Mode
USB 1: Host Mode
USB 2: Device Mode
Power Off External Interface
Modules Detected:
MMC:   MRVL_MMC: 0
Net:   egiga0, egiga1, egiga2, egiga3

I know you recently found some issue with windows. Could that explain
something?

       Andrew

[PATCH 1/4] arm: mvebu: limit OpenBlocks AX3-4 to 1 GB of RAM

[Thomas Petazzoni]

Dear Andrew Lunn,

On Wed, 27 Feb 2013 08:03:33 +0100, Andrew Lunn wrote:

> > in U-Boot. Gr??gory and I are using OpenBlocks AX3 based on the A0
> > version of the silicon (so the message I copy/pasted above is *not*
> > from our OpenBlocks, but a different Armada XP board). However,
> > PlatHome has been shipping since some time B0 revisions. Maybe it
> > could explain the difference we're seeing?
> 
> Hi Thomas
> 
> My machine is an A0.

Hum, ok, so that doesn't explain the problem.

> I know you recently found some issue with windows. Could that explain
> something?

No, the issue with the window was only that devices can only access the
first 32 bits of the physical address space, so if there is a DRAM CS
configured with a base address higher than 4 GB, then devices shouldn't
configure a window to access this part of the DRAM, because it creates
two overlapping windows (both starting at base 0x0, since in the device
address decoding window registers, the base only has 32 bits, while it
has 35 bits for the SDRAM address decoding registers). And the issue
with window was that the devices were really not working at all. What
we're seeing with the OpenBlocks is some instability: sometimes it
boots, sometimes not.

We're going to discuss this issue further with PlatHome.

Thanks for reporting!

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH 2/4] arm: mvebu: Armada XP MV78230 has two cores, not one

[Thomas Petazzoni]

Contrary to our understanding at the time armada-xp-mv78230.dtsi was
written, the MV78230 variant of the Armada XP SoC has two cores and
not one. This patch updates the .dtsi file to take into account this
reality.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
This is a fix for 3.8, should be pushed for some 3.8-rc.
---
 arch/arm/boot/dts/armada-xp-mv78230.dtsi |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/armada-xp-mv78230.dtsi b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
index c45c7b4..8f90fac 100644
--- a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
@@ -34,6 +34,13 @@
 		reg = <0>;
 		clocks = <&cpuclk 0>;
 	    };
+
+	    cpu at 1 {
+		device_type = "cpu";
+		compatible = "marvell,sheeva-v7";
+		reg = <1>;
+		clocks = <&cpuclk 1>;
+	    };
 	}
 
 	soc {
-- 
1.7.9.5

[PATCH 3/4] arm: mvebu: Armada XP MV78230 has only three Ethernet interfaces

[Thomas Petazzoni]

We originally thought that the MV78230 variant of the Armada XP had
four Ethernet interfaces, like the other variants MV78260 and
MV78460. In fact, this is not true, and the MV78230 has only three
Ethernet interfaces.

So, the definitions of the Ethernet interfaces is now done as follows:

 * armada-370-xp.dtsi: definitions of the first two interfaces, that
   are common to Armada 370 and Armada XP

 * armada-xp.dtsi: definition of the third interface, common to all
   Armada XP variants.

 * armada-xp-mv78260.dtsi and armada-xp-mv78460.dtsi: definition of
   the fourth interface.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
This is a fix for 3.8, should be pushed for some 3.8-rc.
---
 arch/arm/boot/dts/armada-xp-mv78260.dtsi |    8 ++++++++
 arch/arm/boot/dts/armada-xp-mv78460.dtsi |    8 ++++++++
 arch/arm/boot/dts/armada-xp.dtsi         |    8 --------
 3 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index a2aee57..1c1937d 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -85,5 +85,13 @@
 			#interrupts-cells = <2>;
 			interrupts = <24>;
 		};
+
+		ethernet at d0034000 {
+				compatible = "marvell,armada-370-neta";
+				reg = <0xd0034000 0x2500>;
+				interrupts = <14>;
+				clocks = <&gateclk 1>;
+				status = "disabled";
+		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index da03a12..4905cf3 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -100,5 +100,13 @@
 			#interrupts-cells = <2>;
 			interrupts = <24>;
 		};
+
+		ethernet at d0034000 {
+				compatible = "marvell,armada-370-neta";
+				reg = <0xd0034000 0x2500>;
+				interrupts = <14>;
+				clocks = <&gateclk 1>;
+				status = "disabled";
+		};
 	};
  };
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 5996c69..390ba98 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -95,14 +95,6 @@
 				status = "disabled";
 		};
 
-		ethernet at d0034000 {
-				compatible = "marvell,armada-370-neta";
-				reg = <0xd0034000 0x2500>;
-				interrupts = <14>;
-				clocks = <&gateclk 1>;
-				status = "disabled";
-		};
-
 		xor at d0060900 {
 			compatible = "marvell,orion-xor";
 			reg = <0xd0060900 0x100
-- 
1.7.9.5

[PATCH 4/4] arm: mvebu: indentation fixes for Armada 370/XP .dtsi files

[Thomas Petazzoni]

The Armada 370 and Armada XP .dtsi files contained a mix of
space-based and tabulation-based indentation, with not even the same
width. This commit homogenize the indentation by using tabs everywhere
and making the indentation level match the DT information level.

The only non-whitespace change in this patch is the addition of a
semi-colon at the end of the cpus { }; section in
armada-xp-mv78230.dtsi.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
This is a fix for 3.8, should be pushed for some 3.8-rc.
---
 arch/arm/boot/dts/armada-370.dtsi        |    8 ++--
 arch/arm/boot/dts/armada-xp-mv78230.dtsi |   30 +++++++--------
 arch/arm/boot/dts/armada-xp-mv78260.dtsi |   38 +++++++++---------
 arch/arm/boot/dts/armada-xp-mv78460.dtsi |   62 +++++++++++++++---------------
 arch/arm/boot/dts/armada-xp.dtsi         |   44 ++++++++++-----------
 5 files changed, 91 insertions(+), 91 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index 636cf7d..a5c447d 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -34,14 +34,14 @@
 	};
 
 	mpic: interrupt-controller at d0020000 {
-	      reg = <0xd0020a00 0x1d0>,
-		    <0xd0021870 0x58>;
+		reg = <0xd0020a00 0x1d0>,
+		      <0xd0021870 0x58>;
 	};
 
 	soc {
 		system-controller at d0018200 {
-				compatible = "marvell,armada-370-xp-system-controller";
-				reg = <0xd0018200 0x100>;
+			compatible = "marvell,armada-370-xp-system-controller";
+			reg = <0xd0018200 0x100>;
 		};
 
 		pinctrl {
diff --git a/arch/arm/boot/dts/armada-xp-mv78230.dtsi b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
index 8f90fac..dff3750 100644
--- a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
@@ -25,23 +25,23 @@
 	};
 
 	cpus {
-	    #address-cells = <1>;
-	    #size-cells = <0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
 
-	    cpu at 0 {
-		device_type = "cpu";
-		compatible = "marvell,sheeva-v7";
-		reg = <0>;
-		clocks = <&cpuclk 0>;
-	    };
+		cpu at 0 {
+			device_type = "cpu";
+			compatible = "marvell,sheeva-v7";
+			reg = <0>;
+			clocks = <&cpuclk 0>;
+		};
 
-	    cpu at 1 {
-		device_type = "cpu";
-		compatible = "marvell,sheeva-v7";
-		reg = <1>;
-		clocks = <&cpuclk 1>;
-	    };
-	}
+		cpu at 1 {
+			device_type = "cpu";
+			compatible = "marvell,sheeva-v7";
+			reg = <1>;
+			clocks = <&cpuclk 1>;
+		};
+	};
 
 	soc {
 		pinctrl {
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index 1c1937d..10511e6 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -26,22 +26,22 @@
 	};
 
 	cpus {
-	    #address-cells = <1>;
-	    #size-cells = <0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
 
-	    cpu at 0 {
-		device_type = "cpu";
-		compatible = "marvell,sheeva-v7";
-		reg = <0>;
-		clocks = <&cpuclk 0>;
-	    };
+		cpu at 0 {
+			device_type = "cpu";
+			compatible = "marvell,sheeva-v7";
+			reg = <0>;
+			clocks = <&cpuclk 0>;
+		};
 
-	    cpu at 1 {
-		device_type = "cpu";
-		compatible = "marvell,sheeva-v7";
-		reg = <1>;
-		clocks = <&cpuclk 1>;
-	    };
+		cpu at 1 {
+			device_type = "cpu";
+			compatible = "marvell,sheeva-v7";
+			reg = <1>;
+			clocks = <&cpuclk 1>;
+		};
 	};
 
 	soc {
@@ -87,11 +87,11 @@
 		};
 
 		ethernet at d0034000 {
-				compatible = "marvell,armada-370-neta";
-				reg = <0xd0034000 0x2500>;
-				interrupts = <14>;
-				clocks = <&gateclk 1>;
-				status = "disabled";
+			compatible = "marvell,armada-370-neta";
+			reg = <0xd0034000 0x2500>;
+			interrupts = <14>;
+			clocks = <&gateclk 1>;
+			status = "disabled";
 		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index 4905cf3..c76a18b 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -27,36 +27,36 @@
 
 
 	cpus {
-	    #address-cells = <1>;
-	    #size-cells = <0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
 
-	    cpu at 0 {
-		device_type = "cpu";
-		compatible = "marvell,sheeva-v7";
-		reg = <0>;
-		clocks = <&cpuclk 0>;
-	    };
+		cpu at 0 {
+			device_type = "cpu";
+			compatible = "marvell,sheeva-v7";
+			reg = <0>;
+			clocks = <&cpuclk 0>;
+		};
 
-	    cpu at 1 {
-		device_type = "cpu";
-		compatible = "marvell,sheeva-v7";
-		reg = <1>;
-		clocks = <&cpuclk 1>;
-	    };
+		cpu at 1 {
+			device_type = "cpu";
+			compatible = "marvell,sheeva-v7";
+			reg = <1>;
+			clocks = <&cpuclk 1>;
+		};
 
-	    cpu at 2 {
-		device_type = "cpu";
-		compatible = "marvell,sheeva-v7";
-		reg = <2>;
-		clocks = <&cpuclk 2>;
-	    };
+		cpu at 2 {
+			device_type = "cpu";
+			compatible = "marvell,sheeva-v7";
+			reg = <2>;
+			clocks = <&cpuclk 2>;
+		};
 
-	    cpu at 3 {
-		device_type = "cpu";
-		compatible = "marvell,sheeva-v7";
-		reg = <3>;
-		clocks = <&cpuclk 3>;
-	    };
+		cpu at 3 {
+			device_type = "cpu";
+			compatible = "marvell,sheeva-v7";
+			reg = <3>;
+			clocks = <&cpuclk 3>;
+		};
 	};
 
 	soc {
@@ -102,11 +102,11 @@
 		};
 
 		ethernet at d0034000 {
-				compatible = "marvell,armada-370-neta";
-				reg = <0xd0034000 0x2500>;
-				interrupts = <14>;
-				clocks = <&gateclk 1>;
-				status = "disabled";
+			compatible = "marvell,armada-370-neta";
+			reg = <0xd0034000 0x2500>;
+			interrupts = <14>;
+			clocks = <&gateclk 1>;
+			status = "disabled";
 		};
 	};
  };
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 390ba98..95d43ec 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -30,8 +30,8 @@
 	};
 
 	mpic: interrupt-controller at d0020000 {
-	      reg = <0xd0020a00 0x2d0>,
-		    <0xd0021070 0x58>;
+		reg = <0xd0020a00 0x2d0>,
+		      <0xd0021070 0x58>;
 	};
 
 	armada-370-xp-pmsu at d0022000 {
@@ -42,24 +42,24 @@
 
 	soc {
 		serial at d0012200 {
-				compatible = "snps,dw-apb-uart";
-				reg = <0xd0012200 0x100>;
-				reg-shift = <2>;
-				interrupts = <43>;
-				reg-io-width = <4>;
-				status = "disabled";
+			compatible = "snps,dw-apb-uart";
+			reg = <0xd0012200 0x100>;
+			reg-shift = <2>;
+			interrupts = <43>;
+			reg-io-width = <4>;
+			status = "disabled";
 		};
 		serial at d0012300 {
-				compatible = "snps,dw-apb-uart";
-				reg = <0xd0012300 0x100>;
-				reg-shift = <2>;
-				interrupts = <44>;
-				reg-io-width = <4>;
-				status = "disabled";
+			compatible = "snps,dw-apb-uart";
+			reg = <0xd0012300 0x100>;
+			reg-shift = <2>;
+			interrupts = <44>;
+			reg-io-width = <4>;
+			status = "disabled";
 		};
 
 		timer at d0020300 {
-				marvell,timer-25Mhz;
+			marvell,timer-25Mhz;
 		};
 
 		coreclk: mvebu-sar at d0018230 {
@@ -83,16 +83,16 @@
 		};
 
 		system-controller at d0018200 {
-				compatible = "marvell,armada-370-xp-system-controller";
-				reg = <0xd0018200 0x500>;
+			compatible = "marvell,armada-370-xp-system-controller";
+			reg = <0xd0018200 0x500>;
 		};
 
 		ethernet at d0030000 {
-				compatible = "marvell,armada-370-neta";
-				reg = <0xd0030000 0x2500>;
-				interrupts = <12>;
-				clocks = <&gateclk 2>;
-				status = "disabled";
+			compatible = "marvell,armada-370-neta";
+			reg = <0xd0030000 0x2500>;
+			interrupts = <12>;
+			clocks = <&gateclk 2>;
+			status = "disabled";
 		};
 
 		xor at d0060900 {
-- 
1.7.9.5

[PATCH 4/4] arm: mvebu: indentation fixes for Armada 370/XP .dtsi files

[Andrew Lunn]

On Fri, Jan 04, 2013 at 05:04:58PM +0100, Thomas Petazzoni wrote:
> The Armada 370 and Armada XP .dtsi files contained a mix of
> space-based and tabulation-based indentation, with not even the same
> width. This commit homogenize the indentation by using tabs everywhere
> and making the indentation level match the DT information level.
> 
> The only non-whitespace change in this patch is the addition of a
> semi-colon at the end of the cpus { }; section in
> armada-xp-mv78230.dtsi.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> This is a fix for 3.8, should be pushed for some 3.8-rc.

Hi Thomas

White space changes are not fixes, so should not really be submitted
for 3.8-rc. Lets commit these as cleanup in 3.9.

I will however create and submit a patch to add the missing ;

Thanks
	Andrew

> ---
>  arch/arm/boot/dts/armada-370.dtsi        |    8 ++--
>  arch/arm/boot/dts/armada-xp-mv78230.dtsi |   30 +++++++--------
>  arch/arm/boot/dts/armada-xp-mv78260.dtsi |   38 +++++++++---------
>  arch/arm/boot/dts/armada-xp-mv78460.dtsi |   62 +++++++++++++++---------------
>  arch/arm/boot/dts/armada-xp.dtsi         |   44 ++++++++++-----------
>  5 files changed, 91 insertions(+), 91 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
> index 636cf7d..a5c447d 100644
> --- a/arch/arm/boot/dts/armada-370.dtsi
> +++ b/arch/arm/boot/dts/armada-370.dtsi
> @@ -34,14 +34,14 @@
>  	};
>  
>  	mpic: interrupt-controller at d0020000 {
> -	      reg = <0xd0020a00 0x1d0>,
> -		    <0xd0021870 0x58>;
> +		reg = <0xd0020a00 0x1d0>,
> +		      <0xd0021870 0x58>;
>  	};
>  
>  	soc {
>  		system-controller at d0018200 {
> -				compatible = "marvell,armada-370-xp-system-controller";
> -				reg = <0xd0018200 0x100>;
> +			compatible = "marvell,armada-370-xp-system-controller";
> +			reg = <0xd0018200 0x100>;
>  		};
>  
>  		pinctrl {
> diff --git a/arch/arm/boot/dts/armada-xp-mv78230.dtsi b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
> index 8f90fac..dff3750 100644
> --- a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
> +++ b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
> @@ -25,23 +25,23 @@
>  	};
>  
>  	cpus {
> -	    #address-cells = <1>;
> -	    #size-cells = <0>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;
>  
> -	    cpu at 0 {
> -		device_type = "cpu";
> -		compatible = "marvell,sheeva-v7";
> -		reg = <0>;
> -		clocks = <&cpuclk 0>;
> -	    };
> +		cpu at 0 {
> +			device_type = "cpu";
> +			compatible = "marvell,sheeva-v7";
> +			reg = <0>;
> +			clocks = <&cpuclk 0>;
> +		};
>  
> -	    cpu at 1 {
> -		device_type = "cpu";
> -		compatible = "marvell,sheeva-v7";
> -		reg = <1>;
> -		clocks = <&cpuclk 1>;
> -	    };
> -	}
> +		cpu at 1 {
> +			device_type = "cpu";
> +			compatible = "marvell,sheeva-v7";
> +			reg = <1>;
> +			clocks = <&cpuclk 1>;
> +		};
> +	};
>  
>  	soc {
>  		pinctrl {
> diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
> index 1c1937d..10511e6 100644
> --- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
> +++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
> @@ -26,22 +26,22 @@
>  	};
>  
>  	cpus {
> -	    #address-cells = <1>;
> -	    #size-cells = <0>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;
>  
> -	    cpu at 0 {
> -		device_type = "cpu";
> -		compatible = "marvell,sheeva-v7";
> -		reg = <0>;
> -		clocks = <&cpuclk 0>;
> -	    };
> +		cpu at 0 {
> +			device_type = "cpu";
> +			compatible = "marvell,sheeva-v7";
> +			reg = <0>;
> +			clocks = <&cpuclk 0>;
> +		};
>  
> -	    cpu at 1 {
> -		device_type = "cpu";
> -		compatible = "marvell,sheeva-v7";
> -		reg = <1>;
> -		clocks = <&cpuclk 1>;
> -	    };
> +		cpu at 1 {
> +			device_type = "cpu";
> +			compatible = "marvell,sheeva-v7";
> +			reg = <1>;
> +			clocks = <&cpuclk 1>;
> +		};
>  	};
>  
>  	soc {
> @@ -87,11 +87,11 @@
>  		};
>  
>  		ethernet at d0034000 {
> -				compatible = "marvell,armada-370-neta";
> -				reg = <0xd0034000 0x2500>;
> -				interrupts = <14>;
> -				clocks = <&gateclk 1>;
> -				status = "disabled";
> +			compatible = "marvell,armada-370-neta";
> +			reg = <0xd0034000 0x2500>;
> +			interrupts = <14>;
> +			clocks = <&gateclk 1>;
> +			status = "disabled";
>  		};
>  	};
>  };
> diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
> index 4905cf3..c76a18b 100644
> --- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
> +++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
> @@ -27,36 +27,36 @@
>  
>  
>  	cpus {
> -	    #address-cells = <1>;
> -	    #size-cells = <0>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;
>  
> -	    cpu at 0 {
> -		device_type = "cpu";
> -		compatible = "marvell,sheeva-v7";
> -		reg = <0>;
> -		clocks = <&cpuclk 0>;
> -	    };
> +		cpu at 0 {
> +			device_type = "cpu";
> +			compatible = "marvell,sheeva-v7";
> +			reg = <0>;
> +			clocks = <&cpuclk 0>;
> +		};
>  
> -	    cpu at 1 {
> -		device_type = "cpu";
> -		compatible = "marvell,sheeva-v7";
> -		reg = <1>;
> -		clocks = <&cpuclk 1>;
> -	    };
> +		cpu at 1 {
> +			device_type = "cpu";
> +			compatible = "marvell,sheeva-v7";
> +			reg = <1>;
> +			clocks = <&cpuclk 1>;
> +		};
>  
> -	    cpu at 2 {
> -		device_type = "cpu";
> -		compatible = "marvell,sheeva-v7";
> -		reg = <2>;
> -		clocks = <&cpuclk 2>;
> -	    };
> +		cpu at 2 {
> +			device_type = "cpu";
> +			compatible = "marvell,sheeva-v7";
> +			reg = <2>;
> +			clocks = <&cpuclk 2>;
> +		};
>  
> -	    cpu at 3 {
> -		device_type = "cpu";
> -		compatible = "marvell,sheeva-v7";
> -		reg = <3>;
> -		clocks = <&cpuclk 3>;
> -	    };
> +		cpu at 3 {
> +			device_type = "cpu";
> +			compatible = "marvell,sheeva-v7";
> +			reg = <3>;
> +			clocks = <&cpuclk 3>;
> +		};
>  	};
>  
>  	soc {
> @@ -102,11 +102,11 @@
>  		};
>  
>  		ethernet at d0034000 {
> -				compatible = "marvell,armada-370-neta";
> -				reg = <0xd0034000 0x2500>;
> -				interrupts = <14>;
> -				clocks = <&gateclk 1>;
> -				status = "disabled";
> +			compatible = "marvell,armada-370-neta";
> +			reg = <0xd0034000 0x2500>;
> +			interrupts = <14>;
> +			clocks = <&gateclk 1>;
> +			status = "disabled";
>  		};
>  	};
>   };
> diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
> index 390ba98..95d43ec 100644
> --- a/arch/arm/boot/dts/armada-xp.dtsi
> +++ b/arch/arm/boot/dts/armada-xp.dtsi
> @@ -30,8 +30,8 @@
>  	};
>  
>  	mpic: interrupt-controller at d0020000 {
> -	      reg = <0xd0020a00 0x2d0>,
> -		    <0xd0021070 0x58>;
> +		reg = <0xd0020a00 0x2d0>,
> +		      <0xd0021070 0x58>;
>  	};
>  
>  	armada-370-xp-pmsu at d0022000 {
> @@ -42,24 +42,24 @@
>  
>  	soc {
>  		serial at d0012200 {
> -				compatible = "snps,dw-apb-uart";
> -				reg = <0xd0012200 0x100>;
> -				reg-shift = <2>;
> -				interrupts = <43>;
> -				reg-io-width = <4>;
> -				status = "disabled";
> +			compatible = "snps,dw-apb-uart";
> +			reg = <0xd0012200 0x100>;
> +			reg-shift = <2>;
> +			interrupts = <43>;
> +			reg-io-width = <4>;
> +			status = "disabled";
>  		};
>  		serial at d0012300 {
> -				compatible = "snps,dw-apb-uart";
> -				reg = <0xd0012300 0x100>;
> -				reg-shift = <2>;
> -				interrupts = <44>;
> -				reg-io-width = <4>;
> -				status = "disabled";
> +			compatible = "snps,dw-apb-uart";
> +			reg = <0xd0012300 0x100>;
> +			reg-shift = <2>;
> +			interrupts = <44>;
> +			reg-io-width = <4>;
> +			status = "disabled";
>  		};
>  
>  		timer at d0020300 {
> -				marvell,timer-25Mhz;
> +			marvell,timer-25Mhz;
>  		};
>  
>  		coreclk: mvebu-sar at d0018230 {
> @@ -83,16 +83,16 @@
>  		};
>  
>  		system-controller at d0018200 {
> -				compatible = "marvell,armada-370-xp-system-controller";
> -				reg = <0xd0018200 0x500>;
> +			compatible = "marvell,armada-370-xp-system-controller";
> +			reg = <0xd0018200 0x500>;
>  		};
>  
>  		ethernet at d0030000 {
> -				compatible = "marvell,armada-370-neta";
> -				reg = <0xd0030000 0x2500>;
> -				interrupts = <12>;
> -				clocks = <&gateclk 2>;
> -				status = "disabled";
> +			compatible = "marvell,armada-370-neta";
> +			reg = <0xd0030000 0x2500>;
> +			interrupts = <12>;
> +			clocks = <&gateclk 2>;
> +			status = "disabled";
>  		};
>  
>  		xor at d0060900 {
> -- 
> 1.7.9.5
> 

[PATCH 4/4] arm: mvebu: indentation fixes for Armada 370/XP .dtsi files

[Thomas Petazzoni]

Dear Andrew Lunn,

On Sun, 6 Jan 2013 10:03:13 +0100, Andrew Lunn wrote:

> White space changes are not fixes, so should not really be submitted
> for 3.8-rc. Lets commit these as cleanup in 3.9.
> 
> I will however create and submit a patch to add the missing ;

Indeed, thanks. I'll resubmit an updated patch for 3.9 for some
whitespace changes.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH 4/4] arm: mvebu: indentation fixes for Armada 370/XP .dtsi files

[Jason Cooper]

On Mon, Jan 07, 2013 at 05:53:11PM +0100, Thomas Petazzoni wrote:
> Dear Andrew Lunn,
> 
> On Sun, 6 Jan 2013 10:03:13 +0100, Andrew Lunn wrote:
> 
> > White space changes are not fixes, so should not really be submitted
> > for 3.8-rc. Lets commit these as cleanup in 3.9.
> > 
> > I will however create and submit a patch to add the missing ;
> 
> Indeed, thanks. I'll resubmit an updated patch for 3.9 for some
> whitespace changes.

Thomas,

I assume you're running a sed script of some sort.  If so, could you
also hit kirkwood-*.dts*, dove, orion5x?

thx,

Jason.

[PATCH 4/4] arm: mvebu: indentation fixes for Armada 370/XP .dtsi files

[Thomas Petazzoni]

Dear Jason Cooper,

On Mon, 7 Jan 2013 11:55:46 -0500, Jason Cooper wrote:

> I assume you're running a sed script of some sort.  If so, could you
> also hit kirkwood-*.dts*, dove, orion5x?

I am not running a sed script of some sort for now, but I'll come up
with the  kirkwood, dove and orion5x changes as well.

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH 4/4] arm: mvebu: indentation fixes for Armada 370/XP .dtsi files

[Jason Cooper]

On Mon, Jan 07, 2013 at 06:04:21PM +0100, Thomas Petazzoni wrote:
> Dear Jason Cooper,
> 
> On Mon, 7 Jan 2013 11:55:46 -0500, Jason Cooper wrote:
> 
> > I assume you're running a sed script of some sort.  If so, could you
> > also hit kirkwood-*.dts*, dove, orion5x?
> 
> I am not running a sed script of some sort for now, but I'll come up
> with the  kirkwood, dove and orion5x changes as well.

It's not critical, I was only asking in case it was scripted.  There are
a lot more kirkwood dts files than there are armada.  Please don't do
that by hand, that makes my head hurt. ;-)

thx,

Jason.