arm: mvebu: DT fixes for 3.8
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
---
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(-)
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts +7 -1
@@ -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 {
Signature · 1 line
1.7.9.5
PATCH 1/4 arm: mvebu: limit OpenBlocks AX3-4 to 1 GB of RAM
Quoted 16 lines · Thomas Petazzoni
Signed-off-by Thomas Petazzoni<[email protected]>---
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(-)arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts +0
-1@@ -23,7 +23,13 @@ memory { device_type = "memory"; - reg =<0x00000000 0xC0000000>; /* 3 GB */
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts line 35
Quoted 10 lines
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts +7
-0+ /* + * 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
Dear Andrew Lunn,
Quoted 1 line · Andrew Lunn
How many different boards have you tried?
I've tried only one board, since I have only one.
Quoted 6 lines
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
Signature · 4 lines
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
Quoted 13 lines · Thomas Petazzoni
Dear Andrew Lunn,
Quoted 1 line · Andrew Lunn
How many different boards have you tried?
I've tried only one board, since I have only one.
Quoted 5 lines
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.
Quoted 4 lines
Quoted 1 line
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
Dear Andrew Lunn,
Quoted 1 line · Andrew Lunn
It would be nice to have a sample size bigger than two.
Indeed.
Quoted 1 line
Anybody else have a OpenBlocks AX3-4 and can report if it works or not?
At least Gr?gory has one.
Quoted 2 lines
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
Signature · 4 lines
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
Quoted 11 lines · Thomas Petazzoni
Dear Andrew Lunn,
Quoted 1 line · Andrew Lunn
It would be nice to have a sample size bigger than two.
Indeed.
Quoted 1 line
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?
Quoted 10 lines
Quoted 3 lines
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
Signature · 4 lines
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
Dear Gregory CLEMENT,
Quoted 6 lines · Gregory CLEMENT
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.
Quoted 3 lines
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
Signature · 4 lines
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
Quoted 13 lines · Thomas Petazzoni
Dear Gregory CLEMENT,
Quoted 6 lines · Gregory CLEMENT
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.
Quoted 7 lines
Quoted 3 lines
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
Quoted 22 lines · Andrew Lunn
Quoted 13 lines · Thomas Petazzoni
Dear Gregory CLEMENT,
Quoted 6 lines · Gregory CLEMENT
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.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 7 lines
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 GBThanks
Andrew
PATCH 1/4 arm: mvebu: limit OpenBlocks AX3-4 to 1 GB of RAM
Dear Andrew Lunn,
Quoted 11 lines · Andrew Lunn
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.
Quoted 8 lines
I'm tftpbooting:
setenv bootargs root=/dev/ram console=ttyS0,115200 earlyprintk ; tftpboot
0x80000000openblocks-dev; bootmMy 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
Signature · 4 lines
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
Quoted 5 lines
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 GBAddresses 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
Quoted 14 lines · Andrew Lunn
Quoted 5 lines
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
Quoted 6 lines
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)
Quoted 9 lines
Thanks
Andrew_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Signature · 4 lines
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
Quoted 2 lines
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.
Quoted 7 lines
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
Quoted 8 lines
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
In reply to Andrew LunnDear Andrew Lunn,
Quoted 14 lines · Andrew Lunn
Quoted 5 lines
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
Quoted 6 lines
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
Signature · 4 lines
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
Quoted 30 lines · Thomas Petazzoni
Dear Andrew Lunn,
Quoted 14 lines · Andrew Lunn
Quoted 5 lines
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 GBQuoted 6 lines
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:
Quoted 7 lines
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
Dear Andrew Lunn,
Quoted 9 lines · Andrew Lunn
Quoted 5 lines
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.
Quoted 2 lines
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
Signature · 4 lines
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
In reply to Thomas PetazzoniContrary 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.
---
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(+)
arch/arm/boot/dts/armada-xp-mv78230.dtsi +7 -0
@@ -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 {
Signature · 1 line
1.7.9.5
PATCH 3/4 arm: mvebu: Armada XP MV78230 has only three Ethernet interfaces
In reply to Thomas PetazzoniWe 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.
---
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(-)
arch/arm/boot/dts/armada-xp-mv78260.dtsi +8 -0
@@ -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"; + }; }; };
arch/arm/boot/dts/armada-xp-mv78460.dtsi +8 -0
@@ -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"; + }; }; };
arch/arm/boot/dts/armada-xp.dtsi +0 -8
@@ -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
Signature · 1 line
1.7.9.5
PATCH 4/4 arm: mvebu: indentation fixes for Armada 370/XP .dtsi files
In reply to Thomas PetazzoniThe 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.
---
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(-)
arch/arm/boot/dts/armada-370.dtsi +4 -4
@@ -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 {
arch/arm/boot/dts/armada-xp-mv78230.dtsi +15 -15
@@ -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 {
arch/arm/boot/dts/armada-xp-mv78260.dtsi +19 -19
@@ -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"; }; }; };
arch/arm/boot/dts/armada-xp-mv78460.dtsi +31 -31
78 lines not on this page · raw message
arch/arm/boot/dts/armada-xp.dtsi +22 -22
70 lines not on this page · raw message
Signature · 1 line
1.7.9.5
PATCH 4/4 arm: mvebu: indentation fixes for Armada 370/XP .dtsi files
Quoted 5 lines · 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.
Quoted 7 lines
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 <[email protected]>---
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
Quoted 296 lines
--- 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(-)arch/arm/boot/dts/armada-370.dtsi +4
-4@@ -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 {arch/arm/boot/dts/armada-xp-mv78230.dtsi +15
-15@@ -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 {arch/arm/boot/dts/armada-xp-mv78260.dtsi +19
-19@@ -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"; }; }; };arch/arm/boot/dts/armada-xp-mv78460.dtsi +31
-31@@ -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"; }; }; };arch/arm/boot/dts/armada-xp.dtsi +22
-22@@ -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 {Signature · 1 line
1.7.9.5
PATCH 4/4 arm: mvebu: indentation fixes for Armada 370/XP .dtsi files
Dear Andrew Lunn,
Quoted 4 lines · Andrew Lunn
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
Signature · 4 lines
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
Quoted 11 lines · Thomas Petazzoni
Dear Andrew Lunn,
Quoted 4 lines · Andrew Lunn
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
Dear Jason Cooper,
Quoted 2 lines · Jason Cooper
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
Signature · 4 lines
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
Quoted 9 lines · Thomas Petazzoni
Dear Jason Cooper,
Quoted 2 lines · Jason Cooper
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.