RE: [PATCH 2/2] Adding PCI-E MSI support for PowerPC 460SX SOC.
Please see my answers in line.
-Original Message-
From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
Sent: Sunday, January 03, 2010 10:25 PM
To: Tirumala Reddy Marri
Cc: jwbo...@linux.vnet.ibm.com; linuxppc-dev@lists.ozlabs.org;
linuxppc-...@ozlabs.org; writetoma...@yahoo.com
Subject: Re: [PATCH 2/2] Adding PCI-E MSI support for PowerPC 460SX SOC.
On Wed, 2009-12-23 at 23:28 -0800, tma...@amcc.com wrote:
From: Tirumala Marri tma...@amcc.com
Signed-off-by: Tirumala Marri tma...@amcc.com
---
When 460SX configured as root as a end point E1000(Intell Ethernet card)
was plugged into the one of the PCI-E ports. I was able to run the
traffic
with MSI interrupts.
So before I even ack or nack that patch, I need to better understand how
your HW works. I've read the doc of the 460EX twice and still don't
quite get it :-)
So my understanding so far is that when reception of MSIs is enabled,
writes to some magic address in the first 1K of BAR0 are interpreted ad
MSIs. The MSI interrupt value (low 16 bits of the 32-bit store in little
endian) is thus interpreted as an interrupt number and send to the UIC.
Is that correct ?
Marri: You are somewhat right. There are two ways to cause the interrupts.
In first case MSI is generated to root complex by writing to a Address region
from Endpoint which is mapped to root-complex side MSI Area.
In second case
root complex
writes the 64bit MSI address and data pattern in the Endpoint configuration
space. Then endpoint side cpu will write to register in the PCI-E interrupt
handler register MSIASS(MSI software assert ), this would trigger a memory
write transaction on the PCI-E bus with address from the config space and data
from data register. As soon as this trans action comes on the BUS PCI-E handler
on root complex snoops for this address and checks against the data received.
If it matches it would cause appropriate interrupt number based on the data
Received. For example for interrupt 1 , data would be 0x and interrupt
2 data would be 0x0001 .
Now, which UIC ? There are at least 3 in the 460EX for example :-)
Marri: Each of 4 MSI is mapped to UIC0 12,13,14 15 interrupt numbers
Also, UICs have a limited amount of inputs and I don't see many
interrupt sources reserved for use as MSIs, can you enlighten me a bit
more on how you get to choose an interrupt source to use as MSI ?
Marri: There are 4 MIS's or 15 MSI-X interrupts can be enabled. Each MSI is hard
Wired to UIC0 12 to 15. For MSI-X UIC-3 12 to 27.
Or is there some translation done ? IE. In the 460EX manual, there seem
to be specific interrupt numbers dedicated to PCI0 MSI 0, 1 2 and 3
spread between UIC0 and UIC1, and a block of 8 interrupts in UIC3
reserved for PCI-E MSIs. Is there a renumbering done in HW here ?
IE. Your table shows for 460EX for example that PCI-E MSI 2 is UIC3
input 26. Do I need thus to program the device to write a 2 in the MSI
message or 26 to hit that interrupt ?
IE. Are you running the input message through a binary decoder that then
spreads into various UIC input lines ?
Marri: Yes each MSI is hard wired to different interrupt number in UIC
registers.
MIS interrupt number to UIC is not programmable . It is fixed.
Now some comments:
diff --git a/arch/powerpc/boot/dts/redwood.dts
b/arch/powerpc/boot/dts/redwood.dts
index 81636c0..6c20faf 100644
--- a/arch/powerpc/boot/dts/redwood.dts
+++ b/arch/powerpc/boot/dts/redwood.dts
@@ -357,6 +357,21 @@
0x0 0x0 0x0 0x3 UIC3 0xa 0x4 /* swizzled int C
*/
0x0 0x0 0x0 0x4 UIC3 0xb 0x4 /* swizzled int D
*/;
};
+ MSI: ppc4xx-...@40030 {
+ compatible = amcc,ppc4xx-460sx-msi, ppc4xx-msi;
+ reg = 0x4 0x0030 0x100
+ 0x4 0x0030 0x100;
+ sdr-base = 0x3B0;
+ interrupts =0 1 2 3;
+ interrupt-parent = MSI;
+ #interrupt-cells = 1;
+ #address-cells = 0;
+ #size-cells = 0;
+ interrupt-map = 0 UIC0 0xC 1
+ 1 UIC0 0x0D 1
+ 2 UIC0 0x0E 1
+ 3 UIC0 0x0F 1;
+ };
Wow ! That's the mother of all device-tree hacks :-) So you are using
the interrupts property of the MSI node to represent the MSI
interrupts you hand out, and you make it its own interrupt-parent, using
an interrupt-map in itself to convert them into UIC interrupts :-)
Sneaky... Hell, it will work so why not ?
Marri: BTW there are some other processors using the similar way.
+static struct ppc4xx_msi *ppc4xx_msi;
+
+struct ppc4xx_msi_feature {
+ u32 ppc4xx_pic_ip;
+ u32 msiir_offset;
+};
+
+static int
RE: How to access PPC460EX SDRAM space from PCI/PCIe.
It should be able to access any region in 32bit mode as long as it is smaller than 4GB size. Usually whole SDRAM is mapped to inbound PCI memory region. -Original Message- From: linuxppc-dev-bounces+tmarri=amcc@lists.ozlabs.org [mailto:linuxppc-dev-bounces+tmarri=amcc@lists.ozlabs.org] On Behalf Of Lonsn Sent: Thursday, December 31, 2009 12:55 AM To: linuxppc-dev@lists.ozlabs.org Cc: s...@denx.de Subject: How to access PPC460EX SDRAM space from PCI/PCIe. Hi: I'm now using canyonlands board with latest u-boot and linux kernel from DENX git. A PCIe card is plugged in the PCIeX4 slot. The PCIe card is a PCIe-pci bridge(PI7C9X130) plus an Altera fpga. The PCIe card act as a PCI master and send data to SDRAM of 460EX space (total sdram 512MB, reserve 8M for PCI write data(0x1F80)). Now linux can identify this card, but CPU cann't receive any data from PCIe and no PCIe interrupt. I know about the PCI card works in 32bit mode and doesn't support 64bit address(No pci dual address cycle support). Does the PCI card can access PPC460EX sdram space using just 32bit physical address(0x1F80)? Best regards, Lonsn ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/2] Adding PCI-E MSI support for PowerPC 460SX SOC.
Thanks for the suggestions. I will try remove the extra lines . Add
changes you suggested.
-Marri
-Original Message-
From: linuxppc-dev-bounces+tmarri=amcc@lists.ozlabs.org
[mailto:linuxppc-dev-bounces+tmarri=amcc@lists.ozlabs.org] On Behalf
Of Stefan Roese
Sent: Wednesday, December 23, 2009 12:19 AM
To: linuxppc-dev@lists.ozlabs.org
Cc: linuxppc-...@ozlabs.org; writetoma...@yahoo.com; Tirumala Reddy
Marri
Subject: Re: [PATCH 2/2] Adding PCI-E MSI support for PowerPC 460SX SOC.
On Wednesday 23 December 2009 08:52:23 tma...@amcc.com wrote:
From: Tirumala Marri tma...@amcc.com
Please find some mostly nitpicking comments below.
BTW: Did you already test this on other 4xx platforms, like 440SPe or
405EX?
What are your plans here?
Signed-off-by: Tirumala Marri tma...@amcc.com
---
Kernel version: 2.6.33-rc1
Testing:
When 460SX configured as root as a end point E1000(Intell
Ethernet card)
was plugged into the one of the PCI-E ports. I was able to run
the traffic
with MSI interrupts.
---
arch/powerpc/boot/dts/redwood.dts | 15 ++
arch/powerpc/configs/44x/redwood_defconfig |5 +-
arch/powerpc/platforms/44x/Kconfig |1 +
arch/powerpc/sysdev/Kconfig|7 +
arch/powerpc/sysdev/Makefile |1 +
arch/powerpc/sysdev/ppc4xx_msi.c | 342
arch/powerpc/sysdev/ppc4xx_msi.h
|
39
7 files changed, 408 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/sysdev/ppc4xx_msi.c
create mode 100644 arch/powerpc/sysdev/ppc4xx_msi.h
diff --git a/arch/powerpc/boot/dts/redwood.dts
b/arch/powerpc/boot/dts/redwood.dts index 81636c0..412d5f9 100644
--- a/arch/powerpc/boot/dts/redwood.dts
+++ b/arch/powerpc/boot/dts/redwood.dts
@@ -357,6 +357,21 @@
0x0 0x0 0x0 0x3 UIC3 0xa 0x4 /*
swizzled int C */
0x0 0x0 0x0 0x4 UIC3 0xb 0x4 /*
swizzled int D */;
};
+ MSI: ppc4xx-...@40030 {
+ compatible = amcc,ppc4xx-msi, ppc4xx-msi;
Better use something like this:
compatible = amcc,ppc4xx-msi-ppc460sx,
amcc,ppc4xx-msi;
This way you could check for 460SX specials in the driver if needed.
+ reg = 0x4 0x0030 0x100
+ 0x4 0x0030 0x100;
+ sdr-base = 0x3B0;
+ interrupts =0 1 2 3;
+ interrupt-parent = MSI;
+ #interrupt-cells = 1;
+ #address-cells = 0;
+ #size-cells = 0;
+ interrupt-map = 0 UIC0 0xC 1
+ 1 UIC0 0x0D 1
+ 2 UIC0 0x0E 1
+ 3 UIC0 0x0F 1;
+ };
};
diff --git a/arch/powerpc/configs/44x/redwood_defconfig
b/arch/powerpc/configs/44x/redwood_defconfig index ed31d4f..5d16c88
100644
--- a/arch/powerpc/configs/44x/redwood_defconfig
+++ b/arch/powerpc/configs/44x/redwood_defconfig
@@ -158,6 +158,7 @@ CONFIG_DEFAULT_AS=y
CONFIG_DEFAULT_IOSCHED=anticipatory
# CONFIG_FREEZER is not set
CONFIG_PPC4xx_PCI_EXPRESS=y
+CONFIG_PPC_MSI_BITMAP=y
#
# Platform support
@@ -264,7 +265,7 @@ CONFIG_PCIEPORTBUS=y
CONFIG_PCIEAER=y
# CONFIG_PCIEASPM is not set
CONFIG_ARCH_SUPPORTS_MSI=y
-# CONFIG_PCI_MSI is not set
+CONFIG_PCI_MSI=y
# CONFIG_PCI_LEGACY is not set
# CONFIG_PCI_DEBUG is not set
# CONFIG_PCI_STUB is not set
@@ -1062,7 +1063,7 @@ CONFIG_PRINT_STACK_DEPTH=64
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_CODE_PATCHING_SELFTEST is not set
# CONFIG_FTR_FIXUP_SELFTEST is not set
-# CONFIG_MSI_BITMAP_SELFTEST is not set
+CONFIG_MSI_BITMAP_SELFTEST=y
# CONFIG_XMON is not set
# CONFIG_IRQSTACKS is not set
# CONFIG_VIRQ_DEBUG is not set
diff --git a/arch/powerpc/platforms/44x/Kconfig
b/arch/powerpc/platforms/44x/Kconfig index 7486bff..9c3b8ca 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -126,6 +126,7 @@ config REDWOOD
select 460SX
select PCI
select PPC4xx_PCI_EXPRESS
+ select PPC4xx_MSI
help
This option enables support for the AMCC PPC460SX Redwood
board.
diff --git a/arch/powerpc/sysdev/Kconfig b/arch/powerpc/sysdev/Kconfig
index 3965828..c8f1486 100644
--- a/arch/powerpc/sysdev/Kconfig
+++ b/arch/powerpc/sysdev/Kconfig
@@ -7,8 +7,15 @@ config PPC4xx_PCI_EXPRESS
depends on PCI 4xx
default n
+config PPC4xx_MSI
+ bool
+ depends on PCI_MSI
+ depends on PCI 4xx
+ default n
+
config PPC_MSI_BITMAP
bool
depends on PCI_MSI
default y if MPIC
default y if FSL_PCI
+ default y if PPC4xx_MSI
diff --git a/arch/powerpc/sysdev/Makefile
b/arch/powerpc/sysdev/Makefile
index 5642924..4c67d2d 100644
--- a/arch/powerpc/sysdev/Makefile
RE: [PATCH 2/2] Adding PCI-E MSI support for PowerPC 460SX SOC.
BTW once this patch gets in I will add the 405Ex,460Ex and 440Spe
support to the same.
-Original Message-
From: linuxppc-dev-bounces+tmarri=amcc@lists.ozlabs.org
[mailto:linuxppc-dev-bounces+tmarri=amcc@lists.ozlabs.org] On Behalf
Of Tirumala Reddy Marri
Sent: Wednesday, December 23, 2009 9:23 AM
To: Stefan Roese; linuxppc-dev@lists.ozlabs.org
Cc: linuxppc-...@ozlabs.org; writetoma...@yahoo.com
Subject: RE: [PATCH 2/2] Adding PCI-E MSI support for PowerPC 460SX SOC.
Thanks for the suggestions. I will try remove the extra lines . Add
changes you suggested.
-Marri
-Original Message-
From: linuxppc-dev-bounces+tmarri=amcc@lists.ozlabs.org
[mailto:linuxppc-dev-bounces+tmarri=amcc@lists.ozlabs.org] On Behalf
Of Stefan Roese
Sent: Wednesday, December 23, 2009 12:19 AM
To: linuxppc-dev@lists.ozlabs.org
Cc: linuxppc-...@ozlabs.org; writetoma...@yahoo.com; Tirumala Reddy
Marri
Subject: Re: [PATCH 2/2] Adding PCI-E MSI support for PowerPC 460SX SOC.
On Wednesday 23 December 2009 08:52:23 tma...@amcc.com wrote:
From: Tirumala Marri tma...@amcc.com
Please find some mostly nitpicking comments below.
BTW: Did you already test this on other 4xx platforms, like 440SPe or
405EX?
What are your plans here?
Signed-off-by: Tirumala Marri tma...@amcc.com
---
Kernel version: 2.6.33-rc1
Testing:
When 460SX configured as root as a end point E1000(Intell
Ethernet card)
was plugged into the one of the PCI-E ports. I was able to run
the traffic
with MSI interrupts.
---
arch/powerpc/boot/dts/redwood.dts | 15 ++
arch/powerpc/configs/44x/redwood_defconfig |5 +-
arch/powerpc/platforms/44x/Kconfig |1 +
arch/powerpc/sysdev/Kconfig|7 +
arch/powerpc/sysdev/Makefile |1 +
arch/powerpc/sysdev/ppc4xx_msi.c | 342
arch/powerpc/sysdev/ppc4xx_msi.h
|
39
7 files changed, 408 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/sysdev/ppc4xx_msi.c
create mode 100644 arch/powerpc/sysdev/ppc4xx_msi.h
diff --git a/arch/powerpc/boot/dts/redwood.dts
b/arch/powerpc/boot/dts/redwood.dts index 81636c0..412d5f9 100644
--- a/arch/powerpc/boot/dts/redwood.dts
+++ b/arch/powerpc/boot/dts/redwood.dts
@@ -357,6 +357,21 @@
0x0 0x0 0x0 0x3 UIC3 0xa 0x4 /*
swizzled int C */
0x0 0x0 0x0 0x4 UIC3 0xb 0x4 /*
swizzled int D */;
};
+ MSI: ppc4xx-...@40030 {
+ compatible = amcc,ppc4xx-msi, ppc4xx-msi;
Better use something like this:
compatible = amcc,ppc4xx-msi-ppc460sx,
amcc,ppc4xx-msi;
This way you could check for 460SX specials in the driver if needed.
+ reg = 0x4 0x0030 0x100
+ 0x4 0x0030 0x100;
+ sdr-base = 0x3B0;
+ interrupts =0 1 2 3;
+ interrupt-parent = MSI;
+ #interrupt-cells = 1;
+ #address-cells = 0;
+ #size-cells = 0;
+ interrupt-map = 0 UIC0 0xC 1
+ 1 UIC0 0x0D 1
+ 2 UIC0 0x0E 1
+ 3 UIC0 0x0F 1;
+ };
};
diff --git a/arch/powerpc/configs/44x/redwood_defconfig
b/arch/powerpc/configs/44x/redwood_defconfig index ed31d4f..5d16c88
100644
--- a/arch/powerpc/configs/44x/redwood_defconfig
+++ b/arch/powerpc/configs/44x/redwood_defconfig
@@ -158,6 +158,7 @@ CONFIG_DEFAULT_AS=y
CONFIG_DEFAULT_IOSCHED=anticipatory
# CONFIG_FREEZER is not set
CONFIG_PPC4xx_PCI_EXPRESS=y
+CONFIG_PPC_MSI_BITMAP=y
#
# Platform support
@@ -264,7 +265,7 @@ CONFIG_PCIEPORTBUS=y
CONFIG_PCIEAER=y
# CONFIG_PCIEASPM is not set
CONFIG_ARCH_SUPPORTS_MSI=y
-# CONFIG_PCI_MSI is not set
+CONFIG_PCI_MSI=y
# CONFIG_PCI_LEGACY is not set
# CONFIG_PCI_DEBUG is not set
# CONFIG_PCI_STUB is not set
@@ -1062,7 +1063,7 @@ CONFIG_PRINT_STACK_DEPTH=64
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_CODE_PATCHING_SELFTEST is not set
# CONFIG_FTR_FIXUP_SELFTEST is not set
-# CONFIG_MSI_BITMAP_SELFTEST is not set
+CONFIG_MSI_BITMAP_SELFTEST=y
# CONFIG_XMON is not set
# CONFIG_IRQSTACKS is not set
# CONFIG_VIRQ_DEBUG is not set
diff --git a/arch/powerpc/platforms/44x/Kconfig
b/arch/powerpc/platforms/44x/Kconfig index 7486bff..9c3b8ca 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -126,6 +126,7 @@ config REDWOOD
select 460SX
select PCI
select PPC4xx_PCI_EXPRESS
+ select PPC4xx_MSI
help
This option enables support for the AMCC PPC460SX Redwood
board.
diff --git a/arch/powerpc/sysdev/Kconfig b/arch/powerpc/sysdev/Kconfig
index 3965828..c8f1486 100644
--- a/arch/powerpc/sysdev/Kconfig
+++ b/arch/powerpc/sysdev
RE: [PATCH 2/2] Adding PCI-E MSI support for PowerPC 460SX SOC.
Josh,
Thanks for the comments. I will fix them re-submit it.
Regards,
Marri
-Original Message-
From: Josh Boyer [mailto:jwbo...@gmail.com] On Behalf Of Josh Boyer
Sent: Tuesday, December 22, 2009 4:08 AM
To: Tirumala Reddy Marri
Cc: linuxppc-dev@lists.ozlabs.org; writetoma...@yahoo.com
Subject: Re: [PATCH 2/2] Adding PCI-E MSI support for PowerPC 460SX SOC.
On Tue, Dec 22, 2009 at 12:49:51AM -0800, tma...@amcc.com wrote:
From: Tirumala Marri tma...@amcc.com
Signed-off-by: Tirumala Marri tma...@amcc.com
---
Kernel version: 2.6.33-rc1
Testing:
When 460SX configured as root as a end point E1000(Intell
Ethernet card)
was plugged into the one of the PCI-E ports. I was able to run
the traffic
with MSI interrupts.
---
arch/powerpc/boot/dts/redwood.dts | 15 ++
arch/powerpc/configs/44x/redwood_defconfig |5 +-
arch/powerpc/platforms/44x/Kconfig |1 +
arch/powerpc/sysdev/Kconfig|7 +
arch/powerpc/sysdev/Makefile |1 +
arch/powerpc/sysdev/ppc4xx_msi.c | 335
arch/powerpc/sysdev/ppc4xx_msi.h | 49
7 files changed, 411 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/sysdev/ppc4xx_msi.c
create mode 100644 arch/powerpc/sysdev/ppc4xx_msi.h
diff --git a/arch/powerpc/boot/dts/redwood.dts
b/arch/powerpc/boot/dts/redwood.dts
index 81636c0..412d5f9 100644
--- a/arch/powerpc/boot/dts/redwood.dts
+++ b/arch/powerpc/boot/dts/redwood.dts
@@ -357,6 +357,21 @@
0x0 0x0 0x0 0x3 UIC3 0xa 0x4 /*
swizzled int C */
0x0 0x0 0x0 0x4 UIC3 0xb 0x4 /*
swizzled int D */;
};
+ MSI: ppc4xx-...@40030 {
+ compatible = amcc,ppc4xx-msi, ppc4xx-msi;
+ reg = 0x4 0x0030 0x100
+ 0x4 0x0030 0x100;
+ sdr-base = 0x3B0;
+ interrupts =0 1 2 3;
+ interrupt-parent = MSI;
+ #interrupt-cells = 1;
+ #address-cells = 0;
+ #size-cells = 0;
+ interrupt-map = 0 UIC0 0xC 1
+ 1 UIC0 0x0D 1
+ 2 UIC0 0x0E 1
+ 3 UIC0 0x0F 1;
+ };
};
diff --git a/arch/powerpc/sysdev/Kconfig b/arch/powerpc/sysdev/Kconfig
index 3965828..32f5a40 100644
--- a/arch/powerpc/sysdev/Kconfig
+++ b/arch/powerpc/sysdev/Kconfig
@@ -7,8 +7,15 @@ config PPC4xx_PCI_EXPRESS
depends on PCI 4xx
default n
+config 4xx_MSI
This should probably be named PPC4xx_MSI, similar to how
PPC4xx_PCI_EXPRESS is named.
+ bool
+ depends on PCI_MSI
+ depends on PCI 4xx
+ default n
+
config PPC_MSI_BITMAP
bool
depends on PCI_MSI
default y if MPIC
default y if FSL_PCI
+ default y if 4xx_MSI
diff --git a/arch/powerpc/sysdev/ppc4xx_msi.c
b/arch/powerpc/sysdev/ppc4xx_msi.c
new file mode 100644
index 000..752da4b
--- /dev/null
+++ b/arch/powerpc/sysdev/ppc4xx_msi.c
@@ -0,0 +1,335 @@
+/*
+ * Copyright (C) 2009 Applied Micro Circuits corporation,
+ * All rights reserved.
Please don't add the 'All rights reserved.' to new files. It is
inaccurate and confusing given that it's a GPLv2 file.
+ *
+ * Author: Feng Kan f...@amcc.com
+ * Tirumala Marri tma...@amcc.com
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; version 2 of the
+ * License.
+ */
+#include linux/irq.h
+#include linux/bootmem.h
+#include linux/pci.h
+#include linux/msi.h
+#include linux/of_platform.h
+#include linux/interrupt.h
+#include linux/device.h
+#include asm/prom.h
+#include asm/hw_irq.h
+#include asm/ppc-pci.h
+#include asm/dcr.h
+#include asm/dcr-regs.h
+#include ppc4xx_msi.h
+
+
+static struct ppc4xx_msi *ppc4xx_msi;
+
+struct ppc4xx_msi_feature {
+ u32 ppc4xx_pic_ip;
+ u32 msiir_offset;
+};
+
+static int ppc4xx_msi_init_allocator(struct ppc4xx_msi *msi_data)
+{
+ int rc;
+
+ rc = msi_bitmap_alloc(msi_data-bitmap, NR_MSI_IRQS,
+ msi_data-irqhost-of_node);
+ if (rc)
+ return rc;
+ rc = msi_bitmap_reserve_dt_hwirqs(msi_data-bitmap);
+ if (rc 0) {
+ msi_bitmap_free(msi_data-bitmap);
+ return rc;
+ }
+ return 0;
+}
+
+
+static void ppc4xx_msi_cascade(unsigned int irq, struct irq_desc
*desc)
+{
+ unsigned int cascade_irq;
+ struct ppc4xx_msi *msi_data = ppc4xx_msi;
+ int msir_index = -1;
+
+ raw_spin_lock(desc-lock);
+ if (desc-chip-mask_ack) {
+ desc-chip-mask_ack(irq);
+ } else {
+ desc-chip-mask(irq);
+ desc-chip-ack(irq);
+ }
+
+ if (unlikely(desc-status
RE: [PATCH] Adding PCI-E support for 460SX based redwood board.
Testing and other information for this patch.
1. Kernel version: 2.6.32-rc6
2. Board: AMCC redwood validation board.
3. tests
a. Configured redwood boards PCI-E ports as root ports. And plugged
in 2 HBA sas cards with 8 drives each. XDD and IO
meter tests were ran. No issues found.
b. Configured redwood board PCI-E port as Endpoint and configured
second board as root complex. Boards were interconnected using PCI-E
cable. Then did lspci on root complex configured redwood board to see if
the endpoint can be scanned. Also using BDI I was able to do read and
writes to from root complex as well as endpoint.
Regards,
Marri
-Original Message-
From: tm...@amcc.com [mailto:tm...@amcc.com]
Sent: Monday, November 30, 2009 1:16 PM
To: b...@kernel.crashing.org
Cc: linuxppc-...@ozlabs.org; Tirumala Reddy Marri
Subject: [PATCH] Adding PCI-E support for 460SX based redwood board.
From: Tirumala Marri tma...@amcc.com
This patch would add PCI-E support for AMCC 460SX processor based
redwood board.
Signed-off-by: Tirumala Marri tma...@amcc.com
---
arch/powerpc/boot/dts/redwood.dts | 122
+
arch/powerpc/sysdev/ppc4xx_pci.c | 119
arch/powerpc/sysdev/ppc4xx_pci.h | 58 +
3 files changed, 299 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/redwood.dts
b/arch/powerpc/boot/dts/redwood.dts
index ad402c4..9eeec28 100644
--- a/arch/powerpc/boot/dts/redwood.dts
+++ b/arch/powerpc/boot/dts/redwood.dts
@@ -233,6 +233,128 @@
has-inverted-stacr-oc;
has-new-stacr-staopc;
};
+ PCIE0: pc...@d {
+ device_type = pci;
+ #interrupt-cells = 1;
+ #size-cells = 2;
+ #address-cells = 3;
+ compatible = ibm,plb-pciex-460sx,
ibm,plb-pciex;
+ primary;
+ port = 0x0; /* port number */
+ reg = 0x000d 0x 0x2000
/* Config space access */
+ 0x000c 0x1000
0x1000;/* Registers */
+ dcr-reg = 0x100 0x020;
+ sdr-base = 0x300;
+
+ /* Outbound ranges, one memory and one
IO,
+* later cannot be changed
+*/
+ ranges = 0x0200 0x
0x8000 0x000e 0x 0x 0x8000
+ 0x0100 0x
0x 0x000f 0x8000 0x 0x0001;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges = 0x4200 0x0 0x0 0x0 0x0
0x0 0x8000;
+
+ /* This drives busses 10 to 0x1f */
+ bus-range = 0x10 0x1f;
+
+ /* Legacy interrupts (note the weird
polarity, the bridge seems
+* to invert PCIe legacy interrupts).
+* We are de-swizzling here because the
numbers are actually for
+* port of the root complex virtual P2P
bridge. But I want
+* to avoid putting a node for it in the
tree, so the numbers
+* below are basically de-swizzled
numbers.
+* The real slot is on idsel 0, so the
swizzling is 1:1
+*/
+ interrupt-map-mask = 0x0 0x0 0x0 0x7;
+ interrupt-map =
+ 0x0 0x0 0x0 0x1 UIC3 0x0 0x4 /*
swizzled int A */
+ 0x0 0x0 0x0 0x2 UIC3 0x1 0x4 /*
swizzled int B */
+ 0x0 0x0 0x0 0x3 UIC3 0x2 0x4 /*
swizzled int C */
+ 0x0 0x0 0x0 0x4 UIC3 0x3 0x4 /*
swizzled int D */;
+ };
+
+ PCIE1: pc...@d2000 {
+ device_type = pci;
+ #interrupt-cells = 1;
+ #size-cells = 2;
+ #address-cells = 3;
+ compatible = ibm,plb-pciex-460sx,
ibm,plb-pciex;
+ primary;
+ port = 0x1; /* port number */
+ reg = 0x000d 0x2000 0x2000
/* Config space access */
+ 0x000c 0x10001000
0x1000;/* Registers */
+ dcr-reg = 0x120 0x020
RE: patch status
A URL to it would be fine. I still haven't managed to find it, but perhaps the 'ALL available documents/types listed' link on this page: http://www.appliedmicro.com/MyAMCC/jsp/public/productDetail/product_de tail.jsp?productID=PPC460SX doesn't really mean all? Looks like need a login to get the actual engineering manual. It is also whipped with CD of evaluation board. Just reply to the patch is fine. No need to send a new one if there are no code changes. There are no new changes. I will reply to the patch. Thanks, Marri ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
patch status
Hi Ben, Did you get the chance to review the patch I sent it on Dec-1 2009 http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/078436.html Regards, MArri ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: patch status
Josh, Sorry for my ignorance that I did not copy you first. From now on I will make sure you are cc'ed . I will send you the copy of user manual which is available on external website. Should I send new patch with what is tested with this change or is it enough to write in email ? Regards, Marri -Original Message- From: Josh Boyer [mailto:jwbo...@linux.vnet.ibm.com] Sent: Monday, December 07, 2009 4:53 PM To: Tirumala Reddy Marri Cc: b...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org Subject: Re: patch status On Mon, Dec 07, 2009 at 02:01:58PM -0800, Tirumala Reddy Marri wrote: Hi Ben, Did you get the chance to review the patch I sent it on Dec-1 2009 http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/078436.htm l Ben has to review lots of patches. Please be patient. Also, your patch is tracked via patchwork here: http://patchwork.ozlabs.org/patch/39865/ so you can see the state as it progresses. Further, it would have been helpful to CC the maintainer of the 4xx sub-arch (me) since it impacts that platform and you could have gotten some review more quickly. I didn't notice it until this afternoon. Lastly, your patch has lots of magical values in it. While I have no doubt they are correct, I can't find any documentation for 460SX on the AMCC website aside from some small product briefs. Perhaps I've overlooked the CPU manual, but since I don't have such a board or the manual for it, it would be nice to know what kind of testing has been done with this patch. A simple statement such as tested on kernel version with a network, raid, whatever pci-e card successfully would go a long way. This is not a rant or complaint about the code. Just a reminder that the community doesn't always move at the pace we would all like :). I'll try and look over the patch more carefully tomorrow. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2] ppc440spe-adma: adds updated ppc440spe adma driver
Sorry I meant drver/. Probably you should consider how the iop-dma is done. -Original Message- From: Anatolij Gustschin [mailto:ag...@denx.de] Sent: Friday, November 27, 2009 2:27 AM To: Tirumala Reddy Marri Cc: linux-r...@vger.kernel.org; w...@denx.de; d...@denx.de; Yuri Tikhonov; linuxppc-...@ozlabs.org; dan.j.willi...@intel.com Subject: Re: [PATCH v2] ppc440spe-adma: adds updated ppc440spe adma driver Tirumala Reddy Marri tma...@amcc.com wrote: Why are we having separate directory for 440spe. Can this be generalized arch/dma/ppc4xx/ppc4xx_dma.c ? currently there is only tested support for 440spe. If the driver will be extended to support other CPUs, then the renaming can be done while adding support for other CPUs. 'arch/' is not correct, it should be 'driver/'. Best regards, Anatolij -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] Adding PCI-E support for 460SX based redwood board.
Hi Ben,
Could you please review the patch I sent .
Thanks,
Marri
-Original Message-
From: tma...@amcc.com [mailto:tma...@amcc.com]
Sent: Wednesday, November 25, 2009 3:49 PM
To: linuxppc-...@ozlabs.org
Cc: tma...@macc.com; Tirumala Reddy Marri
Subject: [PATCH] Adding PCI-E support for 460SX based redwood board.
From: Tirumala Marri tma...@amcc.com
This patch would add PCI-E support for AMCC 460SX processor based
redwood board.
Signed-off-by: Tirumala Marri tma...@amcc.com
---
arch/powerpc/boot/dts/redwood.dts | 122
+
arch/powerpc/sysdev/ppc4xx_pci.c | 119
arch/powerpc/sysdev/ppc4xx_pci.h | 58 +
3 files changed, 299 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/redwood.dts
b/arch/powerpc/boot/dts/redwood.dts
index ad402c4..9eeec28 100644
--- a/arch/powerpc/boot/dts/redwood.dts
+++ b/arch/powerpc/boot/dts/redwood.dts
@@ -233,6 +233,128 @@
has-inverted-stacr-oc;
has-new-stacr-staopc;
};
+ PCIE0: pc...@d {
+ device_type = pci;
+ #interrupt-cells = 1;
+ #size-cells = 2;
+ #address-cells = 3;
+ compatible = ibm,plb-pciex-460sx,
ibm,plb-pciex;
+ primary;
+ port = 0x0; /* port number */
+ reg = 0x000d 0x 0x2000
/* Config space access */
+ 0x000c 0x1000
0x1000;/* Registers */
+ dcr-reg = 0x100 0x020;
+ sdr-base = 0x300;
+
+ /* Outbound ranges, one memory and one
IO,
+* later cannot be changed
+*/
+ ranges = 0x0200 0x
0x8000 0x000e 0x 0x 0x8000
+ 0x0100 0x
0x 0x000f 0x8000 0x 0x0001;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges = 0x4200 0x0 0x0 0x0 0x0
0x0 0x8000;
+
+ /* This drives busses 10 to 0x1f */
+ bus-range = 0x10 0x1f;
+
+ /* Legacy interrupts (note the weird
polarity, the bridge seems
+* to invert PCIe legacy interrupts).
+* We are de-swizzling here because the
numbers are actually for
+* port of the root complex virtual P2P
bridge. But I want
+* to avoid putting a node for it in the
tree, so the numbers
+* below are basically de-swizzled
numbers.
+* The real slot is on idsel 0, so the
swizzling is 1:1
+*/
+ interrupt-map-mask = 0x0 0x0 0x0 0x7;
+ interrupt-map =
+ 0x0 0x0 0x0 0x1 UIC3 0x0 0x4 /*
swizzled int A */
+ 0x0 0x0 0x0 0x2 UIC3 0x1 0x4 /*
swizzled int B */
+ 0x0 0x0 0x0 0x3 UIC3 0x2 0x4 /*
swizzled int C */
+ 0x0 0x0 0x0 0x4 UIC3 0x3 0x4 /*
swizzled int D */;
+ };
+
+ PCIE1: pc...@d2000 {
+ device_type = pci;
+ #interrupt-cells = 1;
+ #size-cells = 2;
+ #address-cells = 3;
+ compatible = ibm,plb-pciex-460sx,
ibm,plb-pciex;
+ primary;
+ port = 0x1; /* port number */
+ reg = 0x000d 0x2000 0x2000
/* Config space access */
+ 0x000c 0x10001000
0x1000;/* Registers */
+ dcr-reg = 0x120 0x020;
+ sdr-base = 0x340;
+
+ /* Outbound ranges, one memory and one
IO,
+* later cannot be changed
+*/
+ ranges = 0x0200 0x
0x8000 0x000e 0x8000 0x 0x8000
+ 0x0100 0x
0x 0x000f 0x8001 0x 0x0001;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges = 0x4200 0x0 0x0 0x0 0x0
0x0
FW: need help getting SPI controller working on 405EX [PPM2009081200000033]
1) It looks like the correct entry in kilauea.dts file should be:
208 IIC1: i...@ef600500 {
209 compatible = ibm,iic-405ex, ibm,iic;
210 reg = ef600500 14;
211 interrupt-parent = UIC0;
212 interrupts = 7 4;
213 #address-cells = 1;
214 #size-cells = 0;
215 };
216
217 SPI0: s...@ef600600 {
218 /* compatible = ibm,iic-405ex, ibm,iic; */
219 compatible = amcc,scp-405ex;
220 reg = ef600600 6;
221 interrupts = 8 4;
222 interrupt-parent = UIC0;
223 };
224
225 RGMII0: emac-rg...@ef600b00 {
226 compatible = ibm,rgmii-405ex, ibm,rgmii;
227 reg = ef600b00 104;
228 has-mdio;
229 };
230
231 EMAC0: ether...@ef600900 {
2) Right now the e.g. scp-dev.c is in drivers/scp directory in one of
the internal release I have found, NOT in the e.g. 2.6.29.
Additional comments:
- Ideally the file should be moved to drivers/spi, like all other spi
drivers.
- Even in the internal release, the files do NOT compile properly,
because of missing file, need CONFIG_PINE, etc
[supp...@localhost linux]$ make uImage
scripts/kconfig/conf -s arch/powerpc/Kconfig
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CALLscripts/checksyscalls.sh
CHK include/linux/compile.h
CALLarch/powerpc/kernel/systbl_chk.sh
CC drivers/scp/scp-dev.o
drivers/scp/scp-dev.c:84:24: error: asm/ibm4xx.h: No such file or
directory
drivers/scp/scp-dev.c:705: error: 'scpdev_init' undeclared here (not in
a function)
make[2]: *** [drivers/scp/scp-dev.o] Error 1
make[1]: *** [drivers/scp] Error 2
make: *** [drivers] Error 2
[supp...@localhost linux]
Q: Marri, what do we need to provide to Nathan French ?
Q: Fan, per Jinag-An's request, what is the procedure for cleaning this
up before releasing to Linux community ?
Regards, Samuel
-Original Message-
From: support_re...@amcc.com [mailto:support_re...@amcc.com]
Sent: Fri 8/7/2009 9:24 AM
To: Samuel Wang
Subject: FW: need help getting SPI controller working on 405EX
[PPM200908120033311192]
Sender : tma...@amcc.com
Tracking Number : PPM200908120033311192
Pool: PPC_MID
Sent to : AMCC Product Support support...@amcc.com
Date: 8/7/09 9:24 AM
---
Forwarded by: Alan Millard
(no comments entered)
---
-Original Message-
From: linuxppc-dev-bounces+tmarri=amcc@lists.ozlabs.org
[mailto:linuxppc-dev-bounces+tmarri=amcc@lists.ozlabs.org] On Behalf
Of Nathan French
Sent: Thursday, August 06, 2009 9:08 AM
To: linuxppc-dev@lists.ozlabs.org
Subject: need help getting SPI controller working on 405EX
Hi, I am trying to add support for the 405EX's SPI controller on a
Kilauea board. I've added the below to the device tree (under
plb/opb/):
[nfre...@nfrench-laptop linux-2.6-denx]$ diff -C2
arch/powerpc/boot/dts/kilauea.dts spi.dts
*** arch/powerpc/boot/dts/kilauea.dts 2009-05-05 15:56:16.0
-0700
--- spi.dts 2009-08-06 08:42:19.0 -0700
***
*** 207,210
--- 207,221
#size-cells = 0;
};
+
+ SPI0: s...@ef600600 {
+ cell-index = 0;
+ compatible = ibm,spi-405ex, ibm,spi;
+ reg = ef600600 6;
+ interrupts = 8 4;
+ interrupt-parent = UIC0;
+ mode = cpu;
+ };
RGMII0: emac-rg...@ef600b00 {
I've also compiled my kernel with the following enabled:
CONFIG_SPI=y
CONFIG_SPI_MASTER=y
CONFIG_SPI_SPIDEV=y
I see this make it into the device tree after boot:
[r...@10.2.3.28 /]$ find /proc/device-tree/ | grep spi
/proc/device-tree/plb/opb/s...@ef600600
/proc/device-tree/plb/opb/s...@ef600600/name
/proc/device-tree/plb/opb/s...@ef600600/mode
/proc/device-tree/plb/opb/s...@ef600600/interrupt-parent
/proc/device-tree/plb/opb/s...@ef600600/interrupts
/proc/device-tree/plb/opb/s...@ef600600/reg
/proc/device-tree/plb/opb/s...@ef600600/compatible
/proc/device-tree/plb/opb/s...@ef600600/cell-index
But I don't see any /dev/spidev* devices created or any mention of SPI
at boot time. I'm starting to suspect that I don't have the kernel
configured right, otherwise I would see at least the SPI driver
complaining about something, right?
Thanks,
Nathan French
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
RE: kilauea/405ex external interrupts
You will have to program GPIO's to select appropriate external IRQ as
they are shared .
From: linuxppc-dev-bounces+tmarri=amcc@lists.ozlabs.org
[mailto:linuxppc-dev-bounces+tmarri=amcc@lists.ozlabs.org] On Behalf
Of Lada Podivin
Sent: Friday, June 19, 2009 1:01 AM
To: linuxppc-dev@lists.ozlabs.org
Subject: kilauea/405ex external interrupts
Hi,
I'm writing a linux driver that uses an external interrupt (ppc 405ex).
I'm using GPIO pin 30 (external IRQ 1) connected to UIC1. I'm aware of
the virtual interrupt stuff, so I added a new node to my device tree in
order to get proper virtual IRQ number. This node describes an external
event and its connection to UIC via the mentioned ext. int. Here is a
sample of the divce-tree:
..
UIC1: interrupt-controller1 {
compatible = ibm,uic-405ex,ibm,uic;
interrupt-controller;
cell-index = 1;
dcr-reg = 0x0d0 0x009;
#address-cells = 0;
#size-cells = 0;
#interrupt-cells = 2;
interrupts = 0x1e 0x4 0x1f 0x4; /* cascade */
interrupt-parent = UIC0;
};
EXTEVENT: external_event {
device_type = external;
#address-cells = 0;
#size-cells = 0;
#interrupt-cells = 2;
interrupts = 0x1e 0x1;
interrupt-parent = UIC1;
};
...
Then I use function irq_of_parse_and_map() which returns the virtual
IRQ number 22. So, request_irq() seems to be satisfied with this
number. I can see this interrupt in the /proc/interrupts. But! When I
connect a signal source to the pin 30, nothing happens - the interrupt
service routine isn't called.
Am I suppose to configure anything else? (e. g. pin multiplexing,
further device-tree tuning...) Thank you!
Best regards,
Ladi
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
440SPE ADMA driver
Hi Ilya, Are you going to push further in submitting the ADMA driver for 440SPE ? If you are not I am planning to pursue this effort. I also have couple later version of Soc's needed to submit. Thank and Regards, Marri From: linux-raid-ow...@vger.kernel.org [mailto:linux-raid-ow...@vger.kernel.org] On Behalf Of Ilya Yanok Sent: Thursday, November 13, 2008 9:51 AM To: Josh Boyer Cc:; d...@denx.de; w...@denx.de Subject: Re: [PATCH 11/11] ppc440spe-adma: ADMA driver for PPC440SP(e) systems This message has been archived. View the original item http://sdcmailvault.ad.amcc.com/EnterpriseVault/ViewMessage.asp?VaultId =1E9560FDB597EB744B7F046F24F9462D9111sdcmailvault.ad.amcc.comSavese tId=705~20081113175043~2~2007F01CF3764FBC926BAD4B10FE5BC Josh Boyer wrote: On Thu, Nov 13, 2008 at 06:16:04PM +0300, Ilya Yanok wrote: Adds the platform device definitions and the architecture specific support routines for the ppc440spe adma driver. Any board equipped with PPC440SP(e) controller may utilize this driver. Signed-off-by: Yuri Tikhonov y...@emcraft.com Signed-off-by: Ilya Yanok ya...@emcraft.com Before I really dig into reviewing this driver, I'm going to ask you as simple question. This looks like a 1/2 completed port of an arch/ppc driver that uses the device tree (incorrectly) to get the interrupt resources and that's about it. Otherwise, it's just a straight up platform device driver. Is that correct? Yep, that's correct. If that is the case, I think the driver needs more work before it can be merged. It should get the DCR and MMIO resources from the device tree as well. It should be binding on compatible properties and not based on device tree paths. And it should probably be an of_platform device driver. Surely, you're right. I agree with you in that this driver isn't ready for merging. But it works so we'd like to publish it so interested people could use it and test it. Regards, Ilya. -- To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Question about DBCR0 initialization for 440
Some debuggers like BDI(Abatron) they setup the debug registers. If you have different debugger which doesn't support configuring debug registers I suggest you to program then in the head_44x.S file. From: linuxppc-dev-bounces+tmarri=amcc@ozlabs.org [mailto:linuxppc-dev-bounces+tmarri=amcc@ozlabs.org] On Behalf Of John Linn Sent: Tuesday, April 14, 2009 1:33 PM To: jwbo...@linux.vnet.ibm.com; grant.lik...@secretlab.ca; linuxppc-dev@ozlabs.org Subject: Question about DBCR0 initialization for 440 The kernel does not initialize the PPC440 DBCR0 register. This prevents (among other things) the use of software breakpoints with GDB. I realize that boot loaders probably do initialize this but we run a lot without a boot loader and so do our customers. The file, head_fsl_booke.S, does initialize the register for the freescale specific code (as shown at the end of the message). We are needing this also for Xilinx. What's the best method to incorporate this, is it possible to add to head_44x.S? Thanks, John #if !defined(CONFIG_BDI_SWITCH) /* * The Abatron BDI JTAG debugger does not tolerate others * mucking with the debug registers. */ lis r2,dbcr0_...@h mtspr SPRN_DBCR0,r2 isync /* clear any residual debug events */ li r2,-1 mtspr SPRN_DBSR,r2 #endif This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: tracking of PCI address space
I agree. Every processor(SOC) has unique of setting inbound window. What I noticed is Inbound regions are created big enough to map whole DDR region. And uses physical address of ram as a source/destination address. For example if a PCI-E SATA card wants to do DMA transfers to DDR region. It will create dma_alloc_noncoherent() region and uses physical address as source/destination address for data transfers. From: linuxppc-dev-bounces+tmarri=amcc@ozlabs.org on behalf of Benjamin Herrenschmidt Sent: Wed 4/8/2009 11:21 PM To: Kumar Gala Cc: linux-...@vger.kernel.org; Linux Kernel Mailing List; Jesse Barnes; Linux/PPC Development Subject: Re: tracking of PCI address space On Wed, 2009-04-08 at 15:53 -0500, Kumar Gala wrote: I was wondering if we have anything that tracks regions associated with the inbound side of a pci_bus. What I mean is on embedded PPC we have window/mapping registers for both inbound (accessing memory on the SoC) and outbound (access PCI device MMIO, IO etc). The combination of the inbound outbound convey what exists in the PCI address space vs CPU physical address space (and how to map from one to the other). Today in the PPC land we only attach outbound windows to the pci_bus. So technically the inbound side information (like what subset of physical memory is visible on the PCI bus) seems to be lost. On powerpc, we do keep track of the offset, but that's about it. Tracking inbound ranges is very platform specific though. You can have multiple inbound windows with different translations, in some cases some via iommu and some not, or windows aliasing the same target memory but with different attributes, etc... I don't think there's that much interest in trying to create generic code to keep track. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: early kernel debugging
I am not sure if I understand correctly. But Looks like you are not passing the device tree along with kernel image and RAMDISK(you may not need it if you are using NFS mount). You boot command should some what look like this bootm kernel_addr ramdisk_addr devtree_addr or bootm kernel_addr - devtree_addr . If you are already doing that I would check my bootargs for correct params. -Original Message- From: linuxppc-dev-bounces+tmarri=amcc@ozlabs.org [mailto:linuxppc-dev-bounces+tmarri=amcc@ozlabs.org] On Behalf Of Yigal Goldberger Sent: Thursday, April 02, 2009 1:06 PM To: linuxppc-dev@ozlabs.org Subject: early kernel debugging Hi All, I'm using u-boot to boot kernel 2.6.24.2 on a powerpc based board . I see that after uncompressing the kernel it hangs. I found a location (System.map) I think corresponds to the __log_buf (my SDRAM starts at physical address 0 (and u-boot performs - Load Address: Entry Point: ) . So I just removed the leading C0xx from the address leaving xx . And that's where I looked . I did see 2 error messages (though they were somewhat corrupt) the first designated a memory fault and the second a kernel oops at some address. I looked this address up on System.map and it's somewhere inside prom.c in of_scan_flat_dt( ) . I have a few question at this point : A)Am I looking at the right memory location for __log_buf ? B)What is printed to the buffer (printk's of what verbose level ?) C)In a previous kernel version 2.6.14 I don't remember explicitly using a flat device tree or pointing at such a tree through the bootm command) , but I used the ARCH=ppc then as opposed to ARCH=powerpc Now . I see a lot of stuff regarding the need to provide such a data structure upon booting via bootm .Do I need to explicitly prepare such a data structure and provide a pointer to it via bootm ? Might this be the cause for this early hang ? Best Regards, Yigal Goldberger. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: /dev/random on PPC40EXr
There is PKA/TRNG driver for sure. Let me check if it was accepted in opensource yet. Otherwise I will forward you the driver which may not be there in opensource yet. -Original Message- From: linuxppc-dev-bounces+tmarri=amcc@ozlabs.org [mailto:linuxppc-dev-bounces+tmarri=amcc@ozlabs.org] On Behalf Of Felix Radensky Sent: Wednesday, April 01, 2009 5:00 AM To: linuxppc-dev@ozlabs.org Subject: /dev/random on PPC40EXr Hi, On my custom board based on 405EXr /dev/random produces no output at all, and /dev/urandom is not random enough for our purposes. Saving entropy pool between reboots doesn't help much. What can be done to increase the entropy of the system ? I was thinking of adding IRQF_SAMPLE_RANDOM to network driver, but since not too many drivers implement it, I don't know whether it's a good idea or not. Is there any work in progress to develop hw_random driver for 4xx TRNG ? Thanks a lot. Felix. -- View this message in context: http://www.nabble.com/-dev-random-on-PPC40EXr-tp22824979p22824979.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: PowerPC 460EX AD7416 Temperature Sensor
Did you have dts entries for IIC in device tree ? also did you have I2C enabled
in make menuconfig
device drivers - i2c support -- I2C bus support - IBM ppc 4xx On chip I2C
support selected. Then you should i2c see an entry /proc/devices . Use that
major address and create a device node mknode /dev/i2c-0 c 89 0 .
Write a user level program to access this device. Here is an example user code.
--
cat fan.c
/* This program is an example of writing and reading an EEPROM device via
SMBus on a GE Fanuc Embedded Systems, Inc. VMIVME-7809 Single Board
Computer.
To compile this program:
gcc -O vmieep.c -o vmieep
Before running this program, log in as root, then load the following
modules using:
/sbin/modprobe i2c-core
/sbin/modprobe i2c-dev
/sbin/modprobe i2c-i801
Loading the i2c-i801 module will create /dev/i2c-0, with
permissions = CRW- --- ---. Either run the vmieep program as root,
or change the permissions to CRW- RW- RW- as shown:
chmod 666 /dev/i2c-0
*/
#include stdio.h
#include string.h
#include stdlib.h
#include errno.h
#include fcntl.h
//#include linux/i2c.h
//#include linux/i2c-dev.h
#include sys/time.h
/* The inline smbus function definitions may or may not be in i2c-dev.h,
depending on the Linux distribution. Comment or uncomment the following
#include as necessary. */
#include i2c-dev.h /* Use the file of lm_sensors */
#define EEPROM_SIZE 256/* Adjust for actual number of bytes in EEPROM */
#define EEPROM_SMBUS_ADDR 0x90 /* Do NOT change! */
int gef_eeprom_read(int fd, unsigned char start_offset, unsigned char *buffer,
unsigned short buflen);
int gef_eeprom_write(int fd, unsigned char start_offset, unsigned char *buffer,
unsigned short buflen);
void gef_msec_delay(unsigned int msecs);
int main(int argc, char *argv[])
{
int fd; /* File descriptor initialized with open() */
int adapter_num = 0;
int status;
char filename[20]; /* Name of special device file */
int i2c_addr = EEPROM_SMBUS_ADDR; /* SMBus address of EEPROM */
unsigned short offset; /* Which byte to access in the EEPROM */
unsigned char rbuffer; /* Data read from EEPROM */
if ((argc 3) || (argc 4))
{
printf(Usage: fan read addr or fan write addr data\n);
return 0;
}
/* Open the special device file for the SMBus */
sprintf(filename, /dev/i2c-%d, adapter_num);
fd = open(filename, O_RDWR);
if (fd 0)
{
printf(ERROR: open(%s) failed\n, filename);
printf(errno = %d, %s\n, errno, strerror(errno));
return -1;
}
//printf(SUCCESS: open(%s) passed\n, filename);
/* Specify the EEPROM as the device we want to access.
*** IMPORTANT ***
The address is actually in the 7 LSBs, so shift
i2c_addr one bit to the right.*/
status = ioctl(fd, I2C_SLAVE, i2c_addr1);
if (status 0)
{
printf(ERROR: ioctl(fd, I2C_SLAVE, 0x%02X) failed\n, i2c_addr);
printf(errno = %d, %s\n, errno, strerror(errno));
close(fd);
return -1;
}
//printf(SUCCESS: ioctl(fd, I2C_SLAVE, 0x%02X1) passed\n, i2c_addr);
if (strcmp(argv[1],read) == 0)
{
offset = atoi(argv[2]);
gef_eeprom_read(fd, offset, rbuffer, 1);
printf(Offset: %d Data: %d\n, offset, rbuffer);
}
if (strcmp(argv[1],write) == 0)
{
offset = (unsigned char)(atoi(argv[2]));
rbuffer =(unsigned char)(atoi(argv[3]));
gef_eeprom_write(fd, offset, rbuffer, 1);
printf(Offset: %d Data: %d\n, offset, rbuffer);
}
/* Close the special device file */
close(fd);
return 0;
}
//
//
// Function name : gef_eeprom_read
//
// Description : Read buflen bytes from the EEPROM beginning at start_offset
//
// Return type : 0 for success, -1 for failure
//
// Argument : int fd : File descriptor returned by open()
// Argument : unsigned char start_offset : Read bytes starting at this
// offset in the EEPROM. The sum of buflen and
// start_offset must not exceed the maximum size in bytes
// of the EEPROM
// Argument : unsigned char *buffer : Where to store the bytes read
// from the EEPROM. The buffer must be large enough
// to store buflen bytes read from the EEPROM.
// Argument : unsigned short buflen : The size in bytes of buffer, or
// how many bytes to read from the EEPROM. The sum of
// buflen and start_offset must not exceed the maximum
// size in bytes of the EEPROM.
//
int gef_eeprom_read(int fd, unsigned char start_offset, unsigned char *buffer,
unsigned short buflen)
{
int offset, index;
int data;
for (index=0,
RE: sata device failed to IDENTIFY...
What PCI Sata card is this ? Is you device tree entrees are correct for PCI ? Especially the interrupt numbers etc ? Also check your ioremap() function in the SATA driver. Make sure that data type of physical address in the driver using is unsigned long long instead of unsigned long -Original Message- From: linuxppc-dev-bounces+tmarri=amcc@ozlabs.org [mailto:linuxppc-dev-bounces+tmarri=amcc@ozlabs.org] On Behalf Of rizwan ahmad Sent: Thursday, March 26, 2009 6:57 AM To: linuxppc-dev@ozlabs.org Subject: Re: sata device failed to IDENTIFY... output of lspci -vv -bash-3.2# lspci -vv 00:0c.0 Class 0c03: Unknown device 1106:3038 (rev 62) Subsystem: Unknown device 1106:3038 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Ste-Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbor-Latency: 128 Interrupt: pin A routed to IRQ 25 Region 4: I/O ports at ffe0 [size=32] Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3)Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:0c.1 Class 0c03: Unknown device 1106:3038 (rev 62) Subsystem: Unknown device 1106:3038 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Ste-Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbor-Latency: 128 Interrupt: pin B routed to IRQ 25 Region 4: I/O ports at ffc0 [size=32] Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3)Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:0c.2 Class 0c03: Unknown device 1106:3104 (rev 65) (prog-if 20) Subsystem: Unknown device 1106:3104 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Ste-Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbor-Latency: 128 Interrupt: pin C routed to IRQ 25 Region 0: Memory at af00 (32-bit, non-prefetchable) [size=256] Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3)Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:0c.3 Class 0104: Unknown device 1106:3249 (rev 50) Subsystem: Unknown device 1106:3249 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Ste-Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbor-Latency: 128 Interrupt: pin A routed to IRQ 25 Region 0: I/O ports at ffb0 [size=16] Region 1: I/O ports at ffa0 [size=16] Region 2: I/O ports at ff90 [size=16] Region 3: I/O ports at ff80 [size=16] Region 4: I/O ports at ff60 [size=32] Region 5: I/O ports at fe00 [size=256] Expansion ROM at ignored [disabled] Capabilities: [e0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3ho)Status: D0 PME-Enable- DSel=0 DScale=0 PME- -bash-3.2# -- View this message in context: http://www.nabble.com/sata-device-failed-to-IDENTIFY...-tp22655709p22722 574.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: sata device failed to IDENTIFY...
Can you post your lspci -vvv dump . From: linuxppc-dev-bounces+tmarri=amcc@ozlabs.org on behalf of rizwan ahmad Sent: Mon 3/23/2009 1:07 AM To: linuxppc-dev@ozlabs.org Subject: sata device failed to IDENTIFY... BM/AMCC PowerPC 440 GR Rev. B Board: AMCC YELLOWSTONE VCO: 1066 MHz CPU: 533 MHz PLB: 133 MHz OPB: 66 MHz PER: 66 MHz PCI: 33 MHz I2C: ready DRAM: 256 MB FLASH: 32 MB PCI: Bus Dev VenId DevId Class Int 00 0c 1106 3038 0c03 00 00 0c 1106 3038 0c03 00 00 0c 1106 3104 0c03 00 00 0c 1106 3249 0104 0e In:serial Out: serial Err: serial Net: ppc_440x_eth0, ppc_440x_eth1 Hit any key to stop autoboot: 0 = tftp 20 z2 Waiting for PHY auto negotiation to complete.. done Using ppc_440x_eth0 device TFTP from server 192.168.0.100; our IP address is 192.168.0.101 Filename 'z2'. Load address: 0x20 Loading: T # # # done Bytes transferred = 1283382 (139536 hex) = bootm ## Booting image at 0020 ... Image Name: Linux-2.6.19 Created: 2009-03-22 9:52:51 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1283318 Bytes = 1.2 MB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK Linux version 2.6.19 (r...@debian) (gcc version 4.2.2) #10 Sun Mar 22 02:51:52 9AMCC PowerPC 440GR Yellowstone Platform Zone PFN ranges: DMA 0 -65536 Normal 65536 -65536 early_node_map[1] active PFN ranges 0:0 -65536 Built 1 zonelists. Total pages: 65024 Kernel command line: root=/dev/nfs rw nfsroot=192.168.0.100:/opt/eldk4.2/ppc_4xlMisrouted IRQ fixup and polling support enabled This may significantly impact system performance PID hash table entries: 1024 (order: 10, 4096 bytes) Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 257024k available (1940k kernel code, 668k data, 148k init, 0k highmem) Mount-cache hash table entries: 512 NET: Registered protocol family 16 PCI: Probing PCI hardware SCSI subsystem initialized NET: Registered protocol family 2 IP route cache hash table entries: 2048 (order: 1, 8192 bytes) TCP established hash table entries: 8192 (order: 3, 32768 bytes) TCP bind hash table entries: 4096 (order: 2, 16384 bytes) TCP: Hash tables configured (established 8192 bind 4096) TCP reno registered io scheduler noop registered io scheduler anticipatory registered (default) io scheduler deadline registered io scheduler cfq registered Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled serial8250: ttyS0 at MMIO 0x0 (irq = 0) is a 16550A serial8250: ttyS1 at MMIO 0x0 (irq = 1) is a 16550A RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize PPC 4xx OCP EMAC driver, version 3.54 mal0: initialized, 4 TX channels, 2 RX channels zmii0: bridge in RMII mode eth0: emac0, MAC 00:10:ec:00:89:89 eth0: found Generic MII PHY (0x01) eth1: emac1, MAC 00:10:ec:80:89:89 eth1: found Generic MII PHY (0x03) in init_module Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx sata_via :00:0c.3: routed to hard irq line 9 ata1: SATA max UDMA/133 cmd 0xFFB0 ctl 0xFFBA bmdma 0xFF60 irq 25 ata2: SATA max UDMA/133 cmd 0xFFA0 ctl 0xFFAA bmdma 0xFF68 irq 25 scsi0 : sata_via ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310) ata1.00: qc timeout (cmd 0xec) ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310) ata1.00: qc timeout (cmd 0xec) ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310) ata1.00: qc timeout (cmd 0xec) in err_mask becoz of exec ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310) scsi1 : sata_via ata2: SATA link down (SStatus 0 SControl 310) ATA: abnormal status 0x7F on port 0xFFA7 TCP cubic registered NET: Registered protocol family 1 NET: Registered protocol family 17 eth0: link is up, 100 FDX, pause enabled IP-Config: Complete: device=eth0, addr=192.168.0.101, mask=255.255.0.0, gw=192.168.0.100, host=ppc, domain=, nis-domain=(none), bootserver=192.168.0.100, rootserver=192.168.0.100, rootpath= Looking up port of RPC 13/2 on 192.168.0.100 Looking up port of RPC 15/1 on 192.168.0.100 VFS: Mounted root (nfs filesystem). Freeing unused kernel memory: 148k init INIT: version 2.86 booting Welcome to DENX Embedded Linux Environment
: [PATCH] Add_460SX_Initial_Framework
Josh,
I will be handling this patch from now on. I will modify the patch and
answer your queries soon.
Thanks,
Marri
Message: 2
Date: Mon, 1 Dec 2008 20:32:56 -0500
From: Josh Boyer jwbo...@linux.vnet.ibm.com
Subject: Re: [PATCH] Add_460SX_Initial_Framework
To: mmadishe...@amcc.com
Cc: linuxppc-dev@ozlabs.org
Message-ID: 20081202013256.gb25...@zod.rchland.ibm.com
Content-Type: text/plain; charset=us-ascii
On Mon, Dec 01, 2008 at 03:37:15PM -0800, mmadishe...@amcc.com wrote:
From: Madhulika Madishetty mmadishe...@amcc.com
This patch contains the initial framework for AMCC Redwood board.
Signed-off-by: Madhulika Madishetty mmadishe...@amcc.com, Tirumala
Reddy
Marri tma...@amcc.com,
Feng Kan f...@amcc.com, Vidhyananth Venkatasamy
vvenkatas...@amcc.com,
Preetesh Parekh ppar...@amcc.com
Acked-by: Loc Ho l...@amcc.com, Feng Kan f...@amcc.com
One Signed-off-by: per person, per line please. Don't use a single
with multiple names.
---
arch/powerpc/boot/dts/redwood_amcc.dts | 247 +++
arch/powerpc/configs/44x/redwood_defconfig | 1082
Parts of your patch are word-wrapped.
diff --git a/arch/powerpc/boot/dts/redwood_amcc.dts
b/arch/powerpc/boot/dts/redwood_amcc.dts
new file mode 100644
index 000..e4f5efd
--- /dev/null
+++ b/arch/powerpc/boot/dts/redwood_amcc.dts
Any particular reason you chose to call this redwood_amcc.dts? None
of the other boards do that.
Also, what possessed AMCC to create an entirely new board called
Redwood when there is already a 4xx board called Redwood? I realize
this isn't really something you can control, and the old board isn't
supported any longer, but still... yell at your marketing people or
something :).
@@ -0,0 +1,247 @@
+/*
+ * Device Tree Source for AMCC Redwood(460SX)
+ *
+ * Copyright 2008 AMCC tma...@amcc.com
+ *
+ * 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.
+ */
+
+/dts-v1/;
If this is really a dts-v1, I would expect all the values here to
look differently. See below.
+
+/ {
+ #address-cells = 2;
+ #size-cells = 1;
+ model = amcc,redwood;
+ compatible = amcc,redwood;
+ dcr-parent = /cpus/c...@0;
+
+ aliases {
+ ethernet0 = EMAC0;
+ serial0 = UART0;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ c...@0 {
+ device_type = cpu;
+ model = PowerPC,460SX;
+ reg = 0;
+ clock-frequency = 0; /* Filled in by U-Boot */
+ timebase-frequency = 0; /* Filled in by U-Boot
*/
+ i-cache-line-size = 20;
+ d-cache-line-size = 20;
Here. You have a i/d-cache line size of 20 bytes? That's odd...
+ i-cache-size = 8000;
+ d-cache-size = 8000;
And you have a cache size of 8000 bytes? Also odd. I would expect
these
lines to look like:
i-cache-line-size = 0x20;
i-cache-size = 0x8000;
or
i-cache-line-size = 32;
i-cache-size = 32768;
Please go through and verify all the values are properly filled out.
I'm
not even sure how this works with newer dtc versions.
+ dcr-controller;
+ dcr-access-method = native;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0 0 0; /* Filled in by U-Boot */
+ };
+
+ UIC0: interrupt-controller0 {
+ compatible = ibm,uic-460sx,ibm,uic;
+ interrupt-controller;
+ cell-index = 0;
+ dcr-reg = 0c0 009;
+ #address-cells = 0;
+ #size-cells = 0;
+ #interrupt-cells = 2;
+ };
+
+ UIC1: interrupt-controller1 {
+ compatible = ibm,uic-460sx,ibm,uic;
+ interrupt-controller;
+ cell-index = 1;
+ dcr-reg = 0d0 009;
+ #address-cells = 0;
+ #size-cells = 0;
+ #interrupt-cells = 2;
+ interrupts = 1e 4 1f 4; /* cascade */
+ interrupt-parent = UIC0;
+ };
+
+ UIC2: interrupt-controller2 {
+ compatible = ibm,uic-460sx,ibm,uic;
+ interrupt-controller;
+ cell-index = 2;
+ dcr-reg = 0e0 009;
+ #address-cells = 0;
+ #size-cells = 0;
+ #interrupt-cells = 2;
+ interrupts = a 4 b 4; /* cascade */
+ interrupt-parent = UIC0;
+ };
+
+ UIC3: interrupt-controller3 {
+ compatible = ibm,uic-460sx,ibm,uic;
+ interrupt-controller;
+ cell-index = 3;
+ dcr-reg = 0f0 009;
+ #address-cells = 0
RE: Disabling L1 D-cache and side effects
Ben, You are right. After I corrected copy_page and __copy_tofrom_user functions Linux booted normally. Thanks a lot for the suggestions. Thanks, Marri -Original Message- From: Benjamin Herrenschmidt [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 30, 2008 3:56 PM To: Tirumala Reddy Marri Cc: Olof Johansson; linuxppc-dev@ozlabs.org Subject: RE: Disabling L1 D-cache and side effects On Tue, 2008-09-30 at 15:26 -0700, Tirumala Reddy Marri wrote: Ben, I got to bring up Linux on one of the 440 processors with out L1 dcache to do some bench marking and compare with L1 d-cache enabled. I am avoiding any references to dcbz ,dcbt and dcbst . Also the TLB's are created with cache inhibited. I looked at lwarx/stwcx description, there seem to be no dependency on L1 cache. Ok. Well, they are generally implemented at the L2 level but maybe not on 440, architecturally, they must be used on cacheable memory but it's possible that 440 being not SMP coherent, the actual implementation of those is too dumb to care. I don't see any critical exceptions or traps. All I see is /init/bin failing to execute because data is corrupted. Have you properly replaced dcbz with multiple stores ? I did some bring up work internally on some stuff where dcbz wasn't quite there yet and one pitfall to be careful is that if you force-enable the alternate CONFIG_8xx implementation in the various copy memset routines in arch/powerpc/lib, you also need to fix those implementations to copy or clear 32 bytes instead of just 16, as 8xx has 16 byte cache lines. Typically failing to do so causes things like memset to fail to properly clear things such as page tables and thus random crap occurs. Cheers, Ben. Thanks, Marri -Original Message- From: Benjamin Herrenschmidt [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 30, 2008 2:31 PM To: Tirumala Reddy Marri Cc: Olof Johansson; linuxppc-dev@ozlabs.org Subject: RE: Disabling L1 D-cache and side effects On Tue, 2008-09-30 at 09:57 -0700, Tirumala Reddy Marri wrote: Ben, Thanks for the response. I am wondering how user space would get affected by absence of L1 Dcache. You didn't answer my question :-) Well, as I said, things like lwarx/stwcx not working, dcbz taking alignment exceptions, etc... Ben. Thanks, Marri -Original Message- From: Benjamin Herrenschmidt [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 30, 2008 12:16 AM To: Tirumala Reddy Marri Cc: Olof Johansson; linuxppc-dev@ozlabs.org Subject: RE: Disabling L1 D-cache and side effects On Mon, 2008-09-29 at 14:38 -0700, Tirumala Reddy Marri wrote: Could you please point me to the which does the Critical error (Machine Check) recovery. BTW I am successful booting the Linux until rootfs is being mounted. It fails to mount the Linux saying that blocks are corrupted in file system. I had to modify lots of initial bring up code to disable D-cache and make sure all TLB's are cache inhibited. Ando also made sure none of the misc_32.S , entry_32.S and head.S makes any references to d-cache. Why the heck are you doing that btw ? AFAIK, as Olof says, things like atomic operations will not work, dcbz neither etc... it's likely that even if you manage to plaster around all of this in the kernel, whatever userspace code you'll try to run in userspace will blow up too... Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Disabling L1 D-cache and side effects
Ben, Thanks for the response. I am wondering how user space would get affected by absence of L1 Dcache. Thanks, Marri -Original Message- From: Benjamin Herrenschmidt [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 30, 2008 12:16 AM To: Tirumala Reddy Marri Cc: Olof Johansson; linuxppc-dev@ozlabs.org Subject: RE: Disabling L1 D-cache and side effects On Mon, 2008-09-29 at 14:38 -0700, Tirumala Reddy Marri wrote: Could you please point me to the which does the Critical error (Machine Check) recovery. BTW I am successful booting the Linux until rootfs is being mounted. It fails to mount the Linux saying that blocks are corrupted in file system. I had to modify lots of initial bring up code to disable D-cache and make sure all TLB's are cache inhibited. Ando also made sure none of the misc_32.S , entry_32.S and head.S makes any references to d-cache. Why the heck are you doing that btw ? AFAIK, as Olof says, things like atomic operations will not work, dcbz neither etc... it's likely that even if you manage to plaster around all of this in the kernel, whatever userspace code you'll try to run in userspace will blow up too... Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Disabling L1 D-cache and side effects
Ben, I got to bring up Linux on one of the 440 processors with out L1 dcache to do some bench marking and compare with L1 d-cache enabled. I am avoiding any references to dcbz ,dcbt and dcbst . Also the TLB's are created with cache inhibited. I looked at lwarx/stwcx description, there seem to be no dependency on L1 cache. I don't see any critical exceptions or traps. All I see is /init/bin failing to execute because data is corrupted. Thanks, Marri -Original Message- From: Benjamin Herrenschmidt [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 30, 2008 2:31 PM To: Tirumala Reddy Marri Cc: Olof Johansson; linuxppc-dev@ozlabs.org Subject: RE: Disabling L1 D-cache and side effects On Tue, 2008-09-30 at 09:57 -0700, Tirumala Reddy Marri wrote: Ben, Thanks for the response. I am wondering how user space would get affected by absence of L1 Dcache. You didn't answer my question :-) Well, as I said, things like lwarx/stwcx not working, dcbz taking alignment exceptions, etc... Ben. Thanks, Marri -Original Message- From: Benjamin Herrenschmidt [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 30, 2008 12:16 AM To: Tirumala Reddy Marri Cc: Olof Johansson; linuxppc-dev@ozlabs.org Subject: RE: Disabling L1 D-cache and side effects On Mon, 2008-09-29 at 14:38 -0700, Tirumala Reddy Marri wrote: Could you please point me to the which does the Critical error (Machine Check) recovery. BTW I am successful booting the Linux until rootfs is being mounted. It fails to mount the Linux saying that blocks are corrupted in file system. I had to modify lots of initial bring up code to disable D-cache and make sure all TLB's are cache inhibited. Ando also made sure none of the misc_32.S , entry_32.S and head.S makes any references to d-cache. Why the heck are you doing that btw ? AFAIK, as Olof says, things like atomic operations will not work, dcbz neither etc... it's likely that even if you manage to plaster around all of this in the kernel, whatever userspace code you'll try to run in userspace will blow up too... Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Disabling L1 D-cache and side effects
Hi, I had to bring up a PPC based SOC with L1 dcache disabled. I did that and tried to boot Linux using RAMDISK/NFS mount. In RAMDISK I see the file system errors. In case of NFS mount I see error saying failed to load ld.so library. Could you guys please share thoughts what are the different side effects might be causing this. Thanks, Marri From: Tirumala Reddy Marri Sent: Saturday, September 27, 2008 2:37 PM To: linuxppc-dev@ozlabs.org Subject: rootfs mount problem Hi , I am trying to bring up a new SOC. I am seeing the following error. Has any one seen this error before. I am pretty sure RAMDISK is not corrupted. Thanks, Marri --- LOG --- NET: Registered protocol family 17 RPC: Registered udp transport module. RPC: Registered tcp transport module. prepare_namespace line 361 prepare_namespace line 385 RAMDISK: Compressed image found at block 0 invalid compressed format (err=1) EXT3-fs error (device ram0): ext3_check_descriptors: Block bitmap for group 0 not in group (block 14728687)! EXT3-fs: group descriptors corrupted! EXT2-fs error (device ram0): ext2_check_descriptors: Block bitmap for group 0 not in group (block 14728687)! EXT2-fs: group descriptors corrupted! List of all partitions: No filesystem could mount root, tried: ext3 ext2 cramfs Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) Rebooting in 180 seconds..? U-Boot 1.3.2 (Sep 24 2008 - 14:25:32) --- back trace --- (gdb) bt #0 __delay (loops=80) at include/asm/time.h:97 #1 0xc001f07c in panic (fmt=Variable fmt is not available. ) at kernel/panic.c:115 #2 0xc0248dc4 in mount_block_root (name=0xc020f9f4 /dev/root, flags=32768) at init/do_mounts.c:277 #3 0xc02491b0 in prepare_namespace () at init/do_mounts.c:403 #4 0xc02489a8 in kernel_init (unused=Variable unused is not available. ) at init/main.c:878 #5 0xc000cf08 in kernel_thread () Previous frame inner to this frame (corrupt stack?) (gdb) --- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Disabling L1 D-cache and side effects
Olof, Thanks for the response. Is there a piece of code in Linux which does the Machine check recovery and continue normal execution ? Thanks and Regards, Marri -Original Message- From: Olof Johansson [mailto:[EMAIL PROTECTED] Sent: Monday, September 29, 2008 11:05 AM To: Tirumala Reddy Marri Cc: linuxppc-dev@ozlabs.org Subject: Re: Disabling L1 D-cache and side effects On Mon, Sep 29, 2008 at 10:05:41AM -0700, Tirumala Reddy Marri wrote: Hi, I had to bring up a PPC based SOC with L1 dcache disabled. I did that and tried to boot Linux using RAMDISK/NFS mount. In RAMDISK I see the file system errors. In case of NFS mount I see error saying failed to load ld.so library. Could you guys please share thoughts what are the different side effects might be causing this. There are a number of things you have to be careful about when you disable caches. Depending on your implementation, you likely can't use lwarx/stwcx, cache ops will not work, etc. Also, are you 100% sure that this is caused only by disabling L1D, and not by any other problems with your silicon? If you're doing early bringup of you'll have a whole lot of debug work in front of you, and this mailing list is probably not the best place to bring your homework. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Disabling L1 D-cache and side effects
Hi Olof, I see code in arch/powerpc/kernel/traps.c . But only cbe_machine_check_handler() is the only function assigned to ppc_md.machine_check_exception. Which is also not doing any recovery. It just dumps the registers and return 0. Which would cause system Panic. Could you please point me to the which does the Critical error (Machine Check) recovery. BTW I am successful booting the Linux until rootfs is being mounted. It fails to mount the Linux saying that blocks are corrupted in file system. I had to modify lots of initial bring up code to disable D-cache and make sure all TLB's are cache inhibited. Ando also made sure none of the misc_32.S , entry_32.S and head.S makes any references to d-cache. Thanks, Marri -Original Message- From: Olof Johansson [mailto:[EMAIL PROTECTED] Sent: Monday, September 29, 2008 2:14 PM To: Tirumala Reddy Marri Cc: linuxppc-dev@ozlabs.org Subject: Re: Disabling L1 D-cache and side effects On Mon, Sep 29, 2008 at 02:00:06PM -0700, Tirumala Reddy Marri wrote: Olof, Thanks for the response. Is there a piece of code in Linux which does the Machine check recovery and continue normal execution ? Yes, there is. Several pieces, actually. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
rootfs mount problem
Hi , I am trying to bring up a new SOC. I am seeing the following error. Has any one seen this error before. I am pretty sure RAMDISK is not corrupted. Thanks, Marri --- LOG --- NET: Registered protocol family 17 RPC: Registered udp transport module. RPC: Registered tcp transport module. prepare_namespace line 361 prepare_namespace line 385 RAMDISK: Compressed image found at block 0 invalid compressed format (err=1) EXT3-fs error (device ram0): ext3_check_descriptors: Block bitmap for group 0 not in group (block 14728687)! EXT3-fs: group descriptors corrupted! EXT2-fs error (device ram0): ext2_check_descriptors: Block bitmap for group 0 not in group (block 14728687)! EXT2-fs: group descriptors corrupted! List of all partitions: No filesystem could mount root, tried: ext3 ext2 cramfs Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) Rebooting in 180 seconds..? U-Boot 1.3.2 (Sep 24 2008 - 14:25:32) --- back trace --- (gdb) bt #0 __delay (loops=80) at include/asm/time.h:97 #1 0xc001f07c in panic (fmt=Variable fmt is not available. ) at kernel/panic.c:115 #2 0xc0248dc4 in mount_block_root (name=0xc020f9f4 /dev/root, flags=32768) at init/do_mounts.c:277 #3 0xc02491b0 in prepare_namespace () at init/do_mounts.c:403 #4 0xc02489a8 in kernel_init (unused=Variable unused is not available. ) at init/main.c:878 #5 0xc000cf08 in kernel_thread () Previous frame inner to this frame (corrupt stack?) (gdb) --- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
