* [PATCH] powerpc/mpc85xx: match with the pci bus address used by u-boot for all p1_p2_rdb_pc boards
From: Kevin Hao @ 2013-05-16 6:29 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc
All these boards use the same configuration file p1_p2_rdb_pc.h in
u-boot. So they have the same pci bus address set by the u-boot.
But in some of these boards the bus address set in dtb don't match
the one used by u-boot. And this will trigger a kernel bug in 32bit
kernel and cause the pci device malfunction. For example, on a
p2020rdb-pc board the u-boot use the 0xa0000000 as both bus address
and cpu address for one pci controller and then assign bus address
such as 0xa00004000 to some pci device. But in the kernel, the dtb
set the bus address to 0xe0000000 and the cpu address to 0xa0000000.
The kernel assumes mistakenly the assigned bus address 0xa0004000
in pci device is correct and keep it unchanged. This will definitely
cause the pci device malfunction. I have made two patches to fix
this in the pci subsystem.
http://patchwork.ozlabs.org/patch/243702/
http://patchwork.ozlabs.org/patch/243703/
But I still think it makes sense to set these bus address to match
with the u-boot. This issue can't be reproduced on 36bit kernel.
But I also tweak the 36bit dtb for the above reason.
The cpu address for the pci controller seems also not right in
p1025rdb_32b/36b.dts. So fix it at the same time.
Signed-off-by: Kevin Hao <haokexin@gmail.com>
---
I just tested this on a p2020rdb-pca board. All others just passed build test.
arch/powerpc/boot/dts/p1020mbg-pc_32b.dts | 4 ++--
arch/powerpc/boot/dts/p1020mbg-pc_36b.dts | 4 ++--
arch/powerpc/boot/dts/p1020utm-pc_32b.dts | 4 ++--
arch/powerpc/boot/dts/p1020utm-pc_36b.dts | 4 ++--
arch/powerpc/boot/dts/p1024rdb_32b.dts | 4 ++--
arch/powerpc/boot/dts/p1024rdb_36b.dts | 4 ++--
arch/powerpc/boot/dts/p1025rdb_32b.dts | 4 ++--
arch/powerpc/boot/dts/p1025rdb_36b.dts | 4 ++--
arch/powerpc/boot/dts/p2020rdb-pc_32b.dts | 4 ++--
arch/powerpc/boot/dts/p2020rdb-pc_36b.dts | 4 ++--
10 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/boot/dts/p1020mbg-pc_32b.dts b/arch/powerpc/boot/dts/p1020mbg-pc_32b.dts
index ab8f076..042bda5 100644
--- a/arch/powerpc/boot/dts/p1020mbg-pc_32b.dts
+++ b/arch/powerpc/boot/dts/p1020mbg-pc_32b.dts
@@ -56,7 +56,7 @@
pci0: pcie@ffe09000 {
reg = <0x0 0xffe09000 0x0 0x1000>;
- ranges = <0x2000000 0x0 0xe0000000 0x0 0xa0000000 0x0 0x20000000
+ ranges = <0x2000000 0x0 0xa0000000 0x0 0xa0000000 0x0 0x20000000
0x1000000 0x0 0x00000000 0x0 0xffc10000 0x0 0x10000>;
pcie@0 {
ranges = <0x2000000 0x0 0xe0000000
@@ -71,7 +71,7 @@
pci1: pcie@ffe0a000 {
reg = <0x0 0xffe0a000 0x0 0x1000>;
- ranges = <0x2000000 0x0 0xe0000000 0x0 0x80000000 0x0 0x20000000
+ ranges = <0x2000000 0x0 0x80000000 0x0 0x80000000 0x0 0x20000000
0x1000000 0x0 0x00000000 0x0 0xffc00000 0x0 0x10000>;
pcie@0 {
ranges = <0x2000000 0x0 0xe0000000
diff --git a/arch/powerpc/boot/dts/p1020mbg-pc_36b.dts b/arch/powerpc/boot/dts/p1020mbg-pc_36b.dts
index 9e9f401..3afbd1f 100644
--- a/arch/powerpc/boot/dts/p1020mbg-pc_36b.dts
+++ b/arch/powerpc/boot/dts/p1020mbg-pc_36b.dts
@@ -56,7 +56,7 @@
pci0: pcie@fffe09000 {
reg = <0xf 0xffe09000 0x0 0x1000>;
- ranges = <0x2000000 0x0 0xe0000000 0xc 0x20000000 0x0 0x20000000
+ ranges = <0x2000000 0x0 0xc0000000 0xc 0x20000000 0x0 0x20000000
0x1000000 0x0 0x00000000 0xf 0xffc10000 0x0 0x10000>;
pcie@0 {
ranges = <0x2000000 0x0 0xe0000000
@@ -71,7 +71,7 @@
pci1: pcie@fffe0a000 {
reg = <0xf 0xffe0a000 0 0x1000>;
- ranges = <0x2000000 0x0 0xe0000000 0xc 0x00000000 0x0 0x20000000
+ ranges = <0x2000000 0x0 0x80000000 0xc 0x00000000 0x0 0x20000000
0x1000000 0x0 0x00000000 0xf 0xffc00000 0x0 0x10000>;
pcie@0 {
ranges = <0x2000000 0x0 0xe0000000
diff --git a/arch/powerpc/boot/dts/p1020utm-pc_32b.dts b/arch/powerpc/boot/dts/p1020utm-pc_32b.dts
index 4bfdd89..27576eb 100644
--- a/arch/powerpc/boot/dts/p1020utm-pc_32b.dts
+++ b/arch/powerpc/boot/dts/p1020utm-pc_32b.dts
@@ -56,7 +56,7 @@
pci0: pcie@ffe09000 {
reg = <0x0 0xffe09000 0x0 0x1000>;
- ranges = <0x2000000 0x0 0xe0000000 0x0 0xa0000000 0x0 0x20000000
+ ranges = <0x2000000 0x0 0xa0000000 0x0 0xa0000000 0x0 0x20000000
0x1000000 0x0 0x00000000 0x0 0xffc10000 0x0 0x10000>;
pcie@0 {
ranges = <0x2000000 0x0 0xe0000000
@@ -71,7 +71,7 @@
pci1: pcie@ffe0a000 {
reg = <0x0 0xffe0a000 0x0 0x1000>;
- ranges = <0x2000000 0x0 0xe0000000 0x0 0x80000000 0x0 0x20000000
+ ranges = <0x2000000 0x0 0x80000000 0x0 0x80000000 0x0 0x20000000
0x1000000 0x0 0x00000000 0x0 0xffc00000 0x0 0x10000>;
pcie@0 {
ranges = <0x2000000 0x0 0xe0000000
diff --git a/arch/powerpc/boot/dts/p1020utm-pc_36b.dts b/arch/powerpc/boot/dts/p1020utm-pc_36b.dts
index abec535..52eabf9c 100644
--- a/arch/powerpc/boot/dts/p1020utm-pc_36b.dts
+++ b/arch/powerpc/boot/dts/p1020utm-pc_36b.dts
@@ -56,7 +56,7 @@
pci0: pcie@fffe09000 {
reg = <0xf 0xffe09000 0x0 0x1000>;
- ranges = <0x2000000 0x0 0xe0000000 0xc 0x20000000 0x0 0x20000000
+ ranges = <0x2000000 0x0 0xc0000000 0xc 0x20000000 0x0 0x20000000
0x1000000 0x0 0x00000000 0xf 0xffc10000 0x0 0x10000>;
pcie@0 {
ranges = <0x2000000 0x0 0xe0000000
@@ -71,7 +71,7 @@
pci1: pcie@fffe0a000 {
reg = <0xf 0xffe0a000 0 0x1000>;
- ranges = <0x2000000 0x0 0xe0000000 0xc 0x00000000 0x0 0x20000000
+ ranges = <0x2000000 0x0 0x80000000 0xc 0x00000000 0x0 0x20000000
0x1000000 0x0 0x00000000 0xf 0xffc00000 0x0 0x10000>;
pcie@0 {
ranges = <0x2000000 0x0 0xe0000000
diff --git a/arch/powerpc/boot/dts/p1024rdb_32b.dts b/arch/powerpc/boot/dts/p1024rdb_32b.dts
index 90e803e..ede1af6 100644
--- a/arch/powerpc/boot/dts/p1024rdb_32b.dts
+++ b/arch/powerpc/boot/dts/p1024rdb_32b.dts
@@ -53,7 +53,7 @@
pci0: pcie@ffe09000 {
reg = <0x0 0xffe09000 0 0x1000>;
- ranges = <0x2000000 0x0 0xe0000000 0x0 0xa0000000 0x0 0x20000000
+ ranges = <0x2000000 0x0 0xa0000000 0x0 0xa0000000 0x0 0x20000000
0x1000000 0x0 0x00000000 0x0 0xffc10000 0x0 0x10000>;
pcie@0 {
ranges = <0x2000000 0x0 0xe0000000
@@ -68,7 +68,7 @@
pci1: pcie@ffe0a000 {
reg = <0x0 0xffe0a000 0 0x1000>;
- ranges = <0x2000000 0x0 0xe0000000 0x0 0x80000000 0x0 0x20000000
+ ranges = <0x2000000 0x0 0x80000000 0x0 0x80000000 0x0 0x20000000
0x1000000 0x0 0x00000000 0x0 0xffc00000 0x0 0x10000>;
pcie@0 {
reg = <0x0 0x0 0x0 0x0 0x0>;
diff --git a/arch/powerpc/boot/dts/p1024rdb_36b.dts b/arch/powerpc/boot/dts/p1024rdb_36b.dts
index 3656825..7642783 100644
--- a/arch/powerpc/boot/dts/p1024rdb_36b.dts
+++ b/arch/powerpc/boot/dts/p1024rdb_36b.dts
@@ -53,7 +53,7 @@
pci0: pcie@fffe09000 {
reg = <0xf 0xffe09000 0 0x1000>;
- ranges = <0x2000000 0x0 0xe0000000 0xc 0x20000000 0x0 0x20000000
+ ranges = <0x2000000 0x0 0xc0000000 0xc 0x20000000 0x0 0x20000000
0x1000000 0x0 0x00000000 0xf 0xffc10000 0x0 0x10000>;
pcie@0 {
ranges = <0x2000000 0x0 0xe0000000
@@ -68,7 +68,7 @@
pci1: pcie@fffe0a000 {
reg = <0xf 0xffe0a000 0 0x1000>;
- ranges = <0x2000000 0x0 0xe0000000 0xc 0x00000000 0x0 0x20000000
+ ranges = <0x2000000 0x0 0x80000000 0xc 0x00000000 0x0 0x20000000
0x1000000 0x0 0x00000000 0xf 0xffc00000 0x0 0x10000>;
pcie@0 {
reg = <0x0 0x0 0x0 0x0 0x0>;
diff --git a/arch/powerpc/boot/dts/p1025rdb_32b.dts b/arch/powerpc/boot/dts/p1025rdb_32b.dts
index ac5729c..6ba7ddd 100644
--- a/arch/powerpc/boot/dts/p1025rdb_32b.dts
+++ b/arch/powerpc/boot/dts/p1025rdb_32b.dts
@@ -54,7 +54,7 @@
};
pci0: pcie@ffe09000 {
- ranges = <0x2000000 0x0 0xe0000000 0 0xe0000000 0x0 0x20000000
+ ranges = <0x2000000 0x0 0xa0000000 0 0xa0000000 0x0 0x20000000
0x1000000 0x0 0x00000000 0 0xffc10000 0x0 0x10000>;
reg = <0 0xffe09000 0 0x1000>;
pcie@0 {
@@ -70,7 +70,7 @@
pci1: pcie@ffe0a000 {
reg = <0 0xffe0a000 0 0x1000>;
- ranges = <0x2000000 0x0 0xe0000000 0 0xe0000000 0x0 0x20000000
+ ranges = <0x2000000 0x0 0x80000000 0 0x80000000 0x0 0x20000000
0x1000000 0x0 0x00000000 0 0xffc00000 0x0 0x10000>;
pcie@0 {
ranges = <0x2000000 0x0 0xe0000000
diff --git a/arch/powerpc/boot/dts/p1025rdb_36b.dts b/arch/powerpc/boot/dts/p1025rdb_36b.dts
index 06deb6f..4659e2d 100644
--- a/arch/powerpc/boot/dts/p1025rdb_36b.dts
+++ b/arch/powerpc/boot/dts/p1025rdb_36b.dts
@@ -55,7 +55,7 @@
pci0: pcie@fffe09000 {
reg = <0xf 0xffe09000 0 0x1000>;
- ranges = <0x2000000 0x0 0xe0000000 0xe 0x20000000 0x0 0x20000000
+ ranges = <0x2000000 0x0 0xc0000000 0xc 0x20000000 0x0 0x20000000
0x1000000 0x0 0x00000000 0xf 0xffc10000 0x0 0x10000>;
pcie@0 {
ranges = <0x2000000 0x0 0xe0000000
@@ -70,7 +70,7 @@
pci1: pcie@fffe0a000 {
reg = <0xf 0xffe0a000 0 0x1000>;
- ranges = <0x2000000 0x0 0xe0000000 0xc 0x00000000 0x0 0x20000000
+ ranges = <0x2000000 0x0 0x80000000 0xc 0x00000000 0x0 0x20000000
0x1000000 0x0 0x00000000 0xf 0xffc00000 0x0 0x10000>;
pcie@0 {
ranges = <0x2000000 0x0 0xe0000000
diff --git a/arch/powerpc/boot/dts/p2020rdb-pc_32b.dts b/arch/powerpc/boot/dts/p2020rdb-pc_32b.dts
index 57573bd..4ab21f8 100644
--- a/arch/powerpc/boot/dts/p2020rdb-pc_32b.dts
+++ b/arch/powerpc/boot/dts/p2020rdb-pc_32b.dts
@@ -63,7 +63,7 @@
pci1: pcie@ffe09000 {
reg = <0 0xffe09000 0 0x1000>;
- ranges = <0x2000000 0x0 0xe0000000 0 0xa0000000 0x0 0x20000000
+ ranges = <0x2000000 0x0 0xa0000000 0 0xa0000000 0x0 0x20000000
0x1000000 0x0 0x00000000 0 0xffc10000 0x0 0x10000>;
pcie@0 {
ranges = <0x2000000 0x0 0xe0000000
@@ -78,7 +78,7 @@
pci0: pcie@ffe0a000 {
reg = <0 0xffe0a000 0 0x1000>;
- ranges = <0x2000000 0x0 0xe0000000 0 0x80000000 0x0 0x20000000
+ ranges = <0x2000000 0x0 0x80000000 0 0x80000000 0x0 0x20000000
0x1000000 0x0 0x00000000 0 0xffc00000 0x0 0x10000>;
pcie@0 {
ranges = <0x2000000 0x0 0xe0000000
diff --git a/arch/powerpc/boot/dts/p2020rdb-pc_36b.dts b/arch/powerpc/boot/dts/p2020rdb-pc_36b.dts
index 470247e..488f1ad 100644
--- a/arch/powerpc/boot/dts/p2020rdb-pc_36b.dts
+++ b/arch/powerpc/boot/dts/p2020rdb-pc_36b.dts
@@ -63,7 +63,7 @@
pci1: pcie@fffe09000 {
reg = <0xf 0xffe09000 0 0x1000>;
- ranges = <0x2000000 0x0 0xe0000000 0xc 0x20000000 0x0 0x20000000
+ ranges = <0x2000000 0x0 0xc0000000 0xc 0x20000000 0x0 0x20000000
0x1000000 0x0 0x00000000 0xf 0xffc10000 0x0 0x10000>;
pcie@0 {
ranges = <0x2000000 0x0 0xe0000000
@@ -78,7 +78,7 @@
pci0: pcie@fffe0a000 {
reg = <0xf 0xffe0a000 0 0x1000>;
- ranges = <0x2000000 0x0 0xe0000000 0xc 0x00000000 0x0 0x20000000
+ ranges = <0x2000000 0x0 0x80000000 0xc 0x00000000 0x0 0x20000000
0x1000000 0x0 0x00000000 0xf 0xffc00000 0x0 0x10000>;
pcie@0 {
ranges = <0x2000000 0x0 0xe0000000
--
1.8.1.4
^ permalink raw reply related
* Re: SATA FSL and upstreaming
From: Benjamin Herrenschmidt @ 2013-05-16 6:26 UTC (permalink / raw)
To: Zang Roy-R61911
Cc: Xie Shaohui-B21989, Liu Qiang-B32616, tiejun.chen,
Fleming Andy-AFLEMING, Bhushan Bharat-R65777,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <3E027F8168735B46AC006B1D0C7BB0020B1E0461@039-SN2MPN1-011.039d.mgd.msft.net>
On Thu, 2013-05-16 at 06:20 +0000, Zang Roy-R61911 wrote:
> Why?
> Ben's on board RCW protocol is 0x36, which should work for PCIe1 (slot 7) and PCIe3 (slot4).
> Roy
I've put a card in slot 7 and a card in slot 4 and I still get:
PCIe1: Root Complex, no link, regs @ 0xfe200000
PCIe1: Bus 00 - 00
PCIe2: disabled
PCIe3: Root Complex, no link, regs @ 0xfe202000
PCIe3: Bus 01 - 01
PCIe4: disabled
And nothing in Linux... Could there be another issue (DIP ? jumpers ?)
Cheers,
Ben.
^ permalink raw reply
* Re: SATA FSL and upstreaming
From: tiejun.chen @ 2013-05-16 6:25 UTC (permalink / raw)
To: Zang Roy-R61911
Cc: Liu Qiang-B32616, Xie Shaohui-B21989, Fleming Andy-AFLEMING,
Bhushan Bharat-R65777, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <3E027F8168735B46AC006B1D0C7BB0020B1E0461@039-SN2MPN1-011.039d.mgd.msft.net>
On 05/16/2013 02:20 PM, Zang Roy-R61911 wrote:
>
>
>> -----Original Message-----
>> From: tiejun.chen [mailto:tiejun.chen@windriver.com]
>> Sent: Thursday, May 16, 2013 2:18 PM
>> To: Benjamin Herrenschmidt
>> Cc: Zang Roy-R61911; Liu Qiang-B32616; Fleming Andy-AFLEMING; linuxppc-
>> dev@lists.ozlabs.org; Xie Shaohui-B21989; Bhushan Bharat-R65777
>> Subject: Re: SATA FSL and upstreaming
>>
>> On 05/16/2013 02:09 PM, Benjamin Herrenschmidt wrote:
>>> On Thu, 2013-05-16 at 06:05 +0000, Zang Roy-R61911 wrote:
>>>> I do not suggest changing the RCW. If the RCW is broken on Ben's
>>>> side, it is not easy to recover for him.
>>>> Let's check the U-boot output first.
>>>
>>> U-Boot 2013.01-00009-g7bcd7f4 (Mar 14 2013 - 14:23:16)
>>>
>>> CPU0: P5020E, Version: 1.0, (0x82280010)
>>> Core: E5500, Version: 1.0, (0x80240010) Clock Configuration:
>>> CPU0:2000 MHz, CPU1:2000 MHz,
>>> CCB:800 MHz,
>>> DDR:666.667 MHz (1333.333 MT/s data rate) (Asynchronous),
>> LBC:100 MHz
>>> FMAN1: 600 MHz
>>> QMAN: 400 MHz
>>> PME: 400 MHz
>>> L1: D-cache 32 kB enabled
>>> I-cache 32 kB enabled
>>> Board: P5020DS, Sys ID: 0x1c, Sys Ver: 0x12, FPGA Ver: 0x05, vBank: 0
>>> Reset Configuration Word (RCW):
>>> 00000000: 0c540000 00000000 1e120000 00000000
>>> 00000010: d8984a01 03002000 de800000 41000000
>>> 00000020: 00000000 00000000 00000000 10070000
>>> 00000030: 00000000 00000000 00000000 00000000
>>
>> I think you can use Bharat's RCW, which seems RR_HXAPNSP_0x36, then
>> please take a look at this:
> Why?
I just believe Bharat should pick a proper RCW from SDK.
> Ben's on board RCW protocol is 0x36, which should work for PCIe1 (slot 7) and PCIe3 (slot4).
Didn't you see I'm also saying to use slot 7 and slot 4?
Tiejun
^ permalink raw reply
* RE: SATA FSL and upstreaming
From: Xie Shaohui-B21989 @ 2013-05-16 6:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Fleming Andy-AFLEMING
Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1368679657.9603.32.camel@pasglop>
SGksIEJlbiwNCg0KU2luY2UgdGhlIHA1MDIwZHMgeW91IHRlc3RlZCBpcyBhIHJldjEgY2hpcCwg
SSB0aGluayB0aGUgbW9zdCBwb3NzaWJpbGl0eSB0aGF0IFNBVEEgbm90IHdvcmsNCmlzIGR1ZSB0
byBhIFNBVEEgZXJyYXR1bSwgd2hpY2ggaXMgZml4ZWQgaW4gcmV2MS4xLCB3ZSBoYXZlIGEgcG9s
aWN5IHRoYXQgcGF0Y2hlcyBmb3IgZXJyYXRhIHRoYXQgDQphcmUgcHJlc2VudCBvbmx5IG9uIGVh
cmx5IHNpbGljb24gcmV2aXNpb25zLCB0eXBpY2FsbHkgb25seSByZXYxIHNpbGljb24gd2lsbCBu
b3Qgc2VuZCB1cHN0cmVhbS4NCllvdSBjYW4gZmluZCB0aGUgcGF0Y2ggYXQgYmVsb3cgbGluazoN
Cmh0dHA6Ly9naXQuZnJlZXNjYWxlLmNvbS9naXQvY2dpdC5jZ2kvcHBjL3Nkay9saW51eC5naXQv
Y29tbWl0Lz9pZD1iNzlhOGEwNTI4YjhhMDAwOGNiNzZmMzM5ODA2YjEyMDBiNWQ4ZjYzDQoNClNp
bmNlIGl0IGlzIG5vdCBzZW50IHRvIHVwc3RyZWFtLCBpdCBtYXkgbmVlZCB0byBiZSByZWJhc2Vk
IGlmIGFwcGx5IGl0IHRvIGxhdGVzdCB0cmVlLg0KDQpBbHNvIHRoZXJlIG1pZ2h0IGJlIGFub3Ro
ZXIgaXNzdWUoU0FUQSAmIFVTQikgaWYgeW91IHRlc3QgNjQgYml0IGtlcm5lbCBvbiBwNTAyMGRz
IHdpdGggRFJSID4gNEcsIHdlIGhhdmUgYSBwYXRjaA0KU2VudCB0byB1cHN0cmVhbSwgYnV0IG5v
dCBhY2NlcHRlZCB5ZXQuIExpbmsgYXMgYmVsb3c6DQpodHRwOi8vcGF0Y2h3b3JrLm96bGFicy5v
cmcvcGF0Y2gvMTc5ODI4Lw0KDQpUaGVyZSBhcmUgb25saW5lIGRvY3VtZW50cyBvZiBTREssIGZv
ciB0aGUgcDUwMjBkcyBoYXJkd2FyZSBwbGVhc2Ugc2VlIHRoZSBsaW5rOg0KaHR0cDovL3d3dy5m
cmVlc2NhbGUuY29tL2luZm9jZW50ZXIvaW5kZXguanNwP3RvcGljPSUyRlFPUklRU0RLJTJGMjk4
OTU1NC5odG1sDQoNCg0KQmVzdCBSZWdhcmRzLCANClNoYW9odWkgWGllDQo+IC0tLS0tT3JpZ2lu
YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJlbmphbWluIEhlcnJlbnNjaG1pZHQgW21haWx0bzpi
ZW5oQGtlcm5lbC5jcmFzaGluZy5vcmddDQo+IFNlbnQ6IFRodXJzZGF5LCBNYXkgMTYsIDIwMTMg
MTI6NDggUE0NCj4gVG86IExpdSBRaWFuZy1CMzI2MTY7IFhpZSBTaGFvaHVpLUIyMTk4OTsgRmxl
bWluZyBBbmR5LUFGTEVNSU5HDQo+IENjOiBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsg
S3VtYXIgR2FsYQ0KPiBTdWJqZWN0OiBTQVRBIEZTTCBhbmQgdXBzdHJlYW1pbmcNCj4gDQo+IEhp
IGZvbGtzICENCj4gDQo+IFNvIEkgd2FzIHRyeWluZyB0byB1c2UgbXkgNTAyMGRzIHRvIHRlc3Qg
c29tZSBzdHVmZiB0b2RheS4gU2luY2UgSSBoYWRuJ3QNCj4gdXNlZCBpdCBpbiBhIHdoaWxlLCBJ
IGRlY2lkZWQgdG8gInVwZ3JhZGUiIGl0IHRvIHRoZSBsYXRlc3QgTk9SIGV0Yy4uLg0KPiANCj4g
SW50ZXJlc3RpbmdseSBJIGRpc2NvdmVyZWQgdGhhdCB0aGUgU0FUQSAod2hpY2ggd2FzIHN1cHBv
c2VkbHkgZGVhZCBvbg0KPiB0aGUgcmV2MSBjaGlwKSB3YXMgYWN0dWFsbHkgd29ya2luZyB3aXRo
IHRoZSBTREsga2VybmVsLCB3aGlsZSBpdCdzIHN0aWxsDQo+IGNvbXBsZXRlbHkgYnVzdGVkIHVw
c3RyZWFtLg0KPiANCj4gQSBxdWljayBnaXQgY29tcGFyZSBzaG93cyBhYm91dCA1IG9yIDYgY29t
bWl0cyBpbiB0aGUgU0RLIHRyZWUsIHNvbWUgYXMNCj4gb2xkIGFzIDIwMTEsIGZpeGluZyB2YXJp
b3VzIGVycmF0YXMgaW4gdGhhdCBjaGlwLCB0aGF0IG5ldmVyIG1hZGUgdGhlaXINCj4gd2F5IHVw
c3RyZWFtLg0KPiANCj4gQW55IHJlYXNvbiBmb3IgdGhhdCA/IEJlaW5nIEdQTCwgSSBjYW4gc3Vi
bWl0IHRoZW0gdG8gVGVqdW4gbXlzZWxmIGJ1dCBpdA0KPiB3b3VsZCBiZSBiZXR0ZXIgZm9ybSBp
ZiB5b3UgZ3V5cyBkaWQgOi0pDQo+IA0KPiBCVFcuIEFsc28gd2hhdCdzIHRoZSBzdGF0dXMgd2l0
aCBnZXR0aW5nIHRoZSBuZXR3b3JrIHdvcmtpbmcgdXBzdHJlYW0gPw0KPiBFdmVuIGlmIHN1Yi1z
dGFuZGFyZCB0aGUgY29kZSBjb3VsZCBhdCBsZWFzdCBnbyBpbnRvIHN0YWdpbmcuLi4NCj4gDQo+
IENoZWVycywNCj4gQmVuLg0KPiANCj4gDQoNCg==
^ permalink raw reply
* Re: SATA FSL and upstreaming
From: Benjamin Herrenschmidt @ 2013-05-16 6:23 UTC (permalink / raw)
To: Zang Roy-R61911
Cc: Liu Qiang-B32616, Fleming Andy-AFLEMING,
linuxppc-dev@lists.ozlabs.org, Xie Shaohui-B21989,
Bhushan Bharat-R65777
In-Reply-To: <3E027F8168735B46AC006B1D0C7BB0020B1E0442@039-SN2MPN1-011.039d.mgd.msft.net>
On Thu, 2013-05-16 at 06:17 +0000, Zang Roy-R61911 wrote:
> Do you try slot7?
> PCIe1 connects to slot7 directly.
I tried all slots. None of them sees any card. The card also doesn't
seem to be powered up (none of the LEDs blink, it's an e1000 since I
don't have networking with upstream).
I also tried a different card and uboot is pretty adamant at saying "no
link" :-)
I'll try to update the RCW when I know how to do it :-)
Cheers,
Ben.
> Roy
>
> > -----Original Message-----
> > From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
> > Sent: Thursday, May 16, 2013 2:09 PM
> > To: Zang Roy-R61911
> > Cc: Bhushan Bharat-R65777; Liu Qiang-B32616; Fleming Andy-AFLEMING;
> > linuxppc-dev@lists.ozlabs.org; Xie Shaohui-B21989
> > Subject: Re: SATA FSL and upstreaming
> >
> > On Thu, 2013-05-16 at 06:05 +0000, Zang Roy-R61911 wrote:
> > > I do not suggest changing the RCW. If the RCW is broken on Ben's side,
> > > it is not easy to recover for him.
> > > Let's check the U-boot output first.
> >
> > U-Boot 2013.01-00009-g7bcd7f4 (Mar 14 2013 - 14:23:16)
> >
> > CPU0: P5020E, Version: 1.0, (0x82280010)
> > Core: E5500, Version: 1.0, (0x80240010)
> > Clock Configuration:
> > CPU0:2000 MHz, CPU1:2000 MHz,
> > CCB:800 MHz,
> > DDR:666.667 MHz (1333.333 MT/s data rate) (Asynchronous), LBC:100
> > MHz
> > FMAN1: 600 MHz
> > QMAN: 400 MHz
> > PME: 400 MHz
> > L1: D-cache 32 kB enabled
> > I-cache 32 kB enabled
> > Board: P5020DS, Sys ID: 0x1c, Sys Ver: 0x12, FPGA Ver: 0x05, vBank: 0
> > Reset Configuration Word (RCW):
> > 00000000: 0c540000 00000000 1e120000 00000000
> > 00000010: d8984a01 03002000 de800000 41000000
> > 00000020: 00000000 00000000 00000000 10070000
> > 00000030: 00000000 00000000 00000000 00000000
> > SERDES Reference Clocks: Bank1=100Mhz Bank2=125Mhz Bank3=125Mhz
> > I2C: ready
> > SPI: ready
> > DRAM: Initializing....using SPD
> > Detected UDIMM i-DIMM
> > Detected UDIMM i-DIMM
> > 2 GiB left unmapped
> > 4 GiB (DDR3, 64-bit, CL=9, ECC on)
> > DDR Controller Interleaving Mode: cache line
> > DDR Chip-Select Interleaving Mode: CS0+CS1
> > Testing 0x00000000 - 0x7fffffff
> > Testing 0x80000000 - 0xffffffff
> > Remap DDR 2 GiB left unmapped
> >
> > POST memory PASSED
> > Flash: 128 MiB
> > L2: 512 KB enabled
> > Corenet Platform Cache: 2048 KB enabled
> > SRIO1: disabled
> > SRIO2: disabled
> > NAND: 1024 MiB
> > MMC: FSL_SDHC: 0
> > EEPROM: NXID v1
> > PCIe1: Root Complex, no link, regs @ 0xfe200000
> > PCIe1: Bus 00 - 00
> > PCIe2: disabled
> > PCIe3: Root Complex, no link, regs @ 0xfe202000
> > PCIe3: Bus 01 - 01
> > PCIe4: disabled
> > In: serial
> > Out: serial
> > Err: serial
> > Net: Initializing Fman
> > Fman1: Uploading microcode version 106.1.7
> > PHY reset timed out
> > PHY reset timed out
> > PHY reset timed out
> > PHY reset timed out
> > FM1@DTSEC1, FM1@DTSEC2, FM1@DTSEC3, FM1@DTSEC4, FM1@DTSEC5, FM1@TGEC1
> > Hit any key to stop autoboot: 0
> > =>
> >
> > Cheers,
> > Ben.
> >
> >
>
^ permalink raw reply
* Re: SATA FSL and upstreaming
From: Benjamin Herrenschmidt @ 2013-05-16 6:21 UTC (permalink / raw)
To: tiejun.chen
Cc: Xie Shaohui-B21989, Liu Qiang-B32616, Zang Roy-R61911,
Fleming Andy-AFLEMING, Bhushan Bharat-R65777,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <51947A00.9010504@windriver.com>
On Thu, 2013-05-16 at 14:17 +0800, tiejun.chen wrote:
> I think you can use Bharat's RCW, which seems RR_HXAPNSP_0x36, then
> please take
> a look at this:
Ok, how do I update my RCW to bse Bharat's ?
Any DIP switch setting I need to be aware of ?
Thanks !
Cheers,
Ben.
^ permalink raw reply
* RE: SATA FSL and upstreaming
From: Zang Roy-R61911 @ 2013-05-16 6:20 UTC (permalink / raw)
To: tiejun.chen, Benjamin Herrenschmidt
Cc: Liu Qiang-B32616, Fleming Andy-AFLEMING,
linuxppc-dev@lists.ozlabs.org, Xie Shaohui-B21989,
Bhushan Bharat-R65777
In-Reply-To: <51947A00.9010504@windriver.com>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdGllanVuLmNoZW4gW21h
aWx0bzp0aWVqdW4uY2hlbkB3aW5kcml2ZXIuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgTWF5IDE2
LCAyMDEzIDI6MTggUE0NCj4gVG86IEJlbmphbWluIEhlcnJlbnNjaG1pZHQNCj4gQ2M6IFphbmcg
Um95LVI2MTkxMTsgTGl1IFFpYW5nLUIzMjYxNjsgRmxlbWluZyBBbmR5LUFGTEVNSU5HOyBsaW51
eHBwYy0NCj4gZGV2QGxpc3RzLm96bGFicy5vcmc7IFhpZSBTaGFvaHVpLUIyMTk4OTsgQmh1c2hh
biBCaGFyYXQtUjY1Nzc3DQo+IFN1YmplY3Q6IFJlOiBTQVRBIEZTTCBhbmQgdXBzdHJlYW1pbmcN
Cj4gDQo+IE9uIDA1LzE2LzIwMTMgMDI6MDkgUE0sIEJlbmphbWluIEhlcnJlbnNjaG1pZHQgd3Jv
dGU6DQo+ID4gT24gVGh1LCAyMDEzLTA1LTE2IGF0IDA2OjA1ICswMDAwLCBaYW5nIFJveS1SNjE5
MTEgd3JvdGU6DQo+ID4+IEkgZG8gbm90IHN1Z2dlc3QgY2hhbmdpbmcgdGhlIFJDVy4gSWYgdGhl
IFJDVyBpcyBicm9rZW4gb24gQmVuJ3MNCj4gPj4gc2lkZSwgaXQgaXMgbm90IGVhc3kgdG8gcmVj
b3ZlciBmb3IgaGltLg0KPiA+PiBMZXQncyBjaGVjayB0aGUgVS1ib290IG91dHB1dCBmaXJzdC4N
Cj4gPg0KPiA+IFUtQm9vdCAyMDEzLjAxLTAwMDA5LWc3YmNkN2Y0IChNYXIgMTQgMjAxMyAtIDE0
OjIzOjE2KQ0KPiA+DQo+ID4gQ1BVMDogIFA1MDIwRSwgVmVyc2lvbjogMS4wLCAoMHg4MjI4MDAx
MCkNCj4gPiBDb3JlOiAgRTU1MDAsIFZlcnNpb246IDEuMCwgKDB4ODAyNDAwMTApIENsb2NrIENv
bmZpZ3VyYXRpb246DQo+ID4gICAgICAgICBDUFUwOjIwMDAgTUh6LCBDUFUxOjIwMDAgTUh6LA0K
PiA+ICAgICAgICAgQ0NCOjgwMCAgTUh6LA0KPiA+ICAgICAgICAgRERSOjY2Ni42NjcgTUh6ICgx
MzMzLjMzMyBNVC9zIGRhdGEgcmF0ZSkgKEFzeW5jaHJvbm91cyksDQo+IExCQzoxMDAgIE1Ieg0K
PiA+ICAgICAgICAgRk1BTjE6IDYwMCBNSHoNCj4gPiAgICAgICAgIFFNQU46ICA0MDAgTUh6DQo+
ID4gICAgICAgICBQTUU6ICAgNDAwIE1Ieg0KPiA+IEwxOiAgICBELWNhY2hlIDMyIGtCIGVuYWJs
ZWQNCj4gPiAgICAgICAgIEktY2FjaGUgMzIga0IgZW5hYmxlZA0KPiA+IEJvYXJkOiBQNTAyMERT
LCBTeXMgSUQ6IDB4MWMsIFN5cyBWZXI6IDB4MTIsIEZQR0EgVmVyOiAweDA1LCB2QmFuazogMA0K
PiA+IFJlc2V0IENvbmZpZ3VyYXRpb24gV29yZCAoUkNXKToNCj4gPiAgICAgICAgIDAwMDAwMDAw
OiAwYzU0MDAwMCAwMDAwMDAwMCAxZTEyMDAwMCAwMDAwMDAwMA0KPiA+ICAgICAgICAgMDAwMDAw
MTA6IGQ4OTg0YTAxIDAzMDAyMDAwIGRlODAwMDAwIDQxMDAwMDAwDQo+ID4gICAgICAgICAwMDAw
MDAyMDogMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAgMTAwNzAwMDANCj4gPiAgICAgICAgIDAw
MDAwMDMwOiAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMA0KPiANCj4gSSB0aGlu
ayB5b3UgY2FuIHVzZSBCaGFyYXQncyBSQ1csIHdoaWNoIHNlZW1zIFJSX0hYQVBOU1BfMHgzNiwg
dGhlbg0KPiBwbGVhc2UgdGFrZSBhIGxvb2sgYXQgdGhpczoNCldoeT8NCkJlbidzIG9uIGJvYXJk
IFJDVyBwcm90b2NvbCBpcyAweDM2LCB3aGljaCBzaG91bGQgd29yayBmb3IgUENJZTEgKHNsb3Qg
NykgYW5kIFBDSWUzIChzbG90NCkuDQpSb3kNCg==
^ permalink raw reply
* [PATCH 2/2] powerpc/perf: Add missing SIER support
From: Michael Ellerman @ 2013-05-16 6:19 UTC (permalink / raw)
To: linuxppc-dev; +Cc: sukadev, Paul Mackerras
In-Reply-To: <1368685171-1948-1-git-send-email-michael@ellerman.id.au>
Commit 8f61aa3 "Add support for SIER" missed updates to siar_valid()
and perf_get_data_addr().
In both cases we need to check the SIER instead of mmcra.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/perf/core-book3s.c | 37 +++++++++++++++++++++++++------------
1 file changed, 25 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index b2f873b..845c867 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -136,22 +136,30 @@ static inline unsigned long perf_ip_adjust(struct pt_regs *regs)
* If we're not doing instruction sampling, give them the SDAR
* (sampled data address). If we are doing instruction sampling, then
* only give them the SDAR if it corresponds to the instruction
- * pointed to by SIAR; this is indicated by the [POWER6_]MMCRA_SDSYNC or
- * the [POWER7P_]MMCRA_SDAR_VALID bit in MMCRA.
+ * pointed to by SIAR; this is indicated by the [POWER6_]MMCRA_SDSYNC, the
+ * [POWER7P_]MMCRA_SDAR_VALID bit in MMCRA, or the SDAR_VALID bit in SIER.
*/
static inline void perf_get_data_addr(struct pt_regs *regs, u64 *addrp)
{
unsigned long mmcra = regs->dsisr;
- unsigned long sdsync;
+ bool sdar_valid;
- if (ppmu->flags & PPMU_SIAR_VALID)
- sdsync = POWER7P_MMCRA_SDAR_VALID;
- else if (ppmu->flags & PPMU_ALT_SIPR)
- sdsync = POWER6_MMCRA_SDSYNC;
- else
- sdsync = MMCRA_SDSYNC;
+ if (ppmu->flags & PPMU_HAS_SIER)
+ sdar_valid = regs->dar & SIER_SDAR_VALID;
+ else {
+ unsigned long sdsync;
+
+ if (ppmu->flags & PPMU_SIAR_VALID)
+ sdsync = POWER7P_MMCRA_SDAR_VALID;
+ else if (ppmu->flags & PPMU_ALT_SIPR)
+ sdsync = POWER6_MMCRA_SDSYNC;
+ else
+ sdsync = MMCRA_SDSYNC;
- if (!(mmcra & MMCRA_SAMPLE_ENABLE) || (mmcra & sdsync))
+ sdar_valid = mmcra & sdsync;
+ }
+
+ if (!(mmcra & MMCRA_SAMPLE_ENABLE) || sdar_valid)
*addrp = mfspr(SPRN_SDAR);
}
@@ -290,8 +298,13 @@ static inline int siar_valid(struct pt_regs *regs)
unsigned long mmcra = regs->dsisr;
int marked = mmcra & MMCRA_SAMPLE_ENABLE;
- if ((ppmu->flags & PPMU_SIAR_VALID) && marked)
- return mmcra & POWER7P_MMCRA_SIAR_VALID;
+ if (marked) {
+ if (ppmu->flags & PPMU_HAS_SIER)
+ return regs->dar & SIER_SIAR_VALID;
+
+ if (ppmu->flags & PPMU_SIAR_VALID)
+ return mmcra & POWER7P_MMCRA_SIAR_VALID;
+ }
return 1;
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/2] powerpc/perf: Revert to original NO_SIPR logic
From: Michael Ellerman @ 2013-05-16 6:19 UTC (permalink / raw)
To: linuxppc-dev; +Cc: sukadev, Paul Mackerras
This is a revert and then some of commit 860aad7 "Add regs_no_sipr()".
This workaround was only needed on early chip versions.
As before NO_SIPR becomes a static flag of the PMU struct.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/perf/core-book3s.c | 30 ++++++------------------------
1 file changed, 6 insertions(+), 24 deletions(-)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 426180b..b2f873b 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -110,7 +110,7 @@ static inline void power_pmu_bhrb_read(struct cpu_hw_events *cpuhw) {}
static bool regs_use_siar(struct pt_regs *regs)
{
- return !!(regs->result & 1);
+ return !!regs->result;
}
/*
@@ -181,11 +181,6 @@ static bool regs_sipr(struct pt_regs *regs)
return !!(regs->dsisr & sipr);
}
-static bool regs_no_sipr(struct pt_regs *regs)
-{
- return !!(regs->result & 2);
-}
-
static inline u32 perf_flags_from_msr(struct pt_regs *regs)
{
if (regs->msr & MSR_PR)
@@ -208,7 +203,7 @@ static inline u32 perf_get_misc_flags(struct pt_regs *regs)
* SIAR which should give slightly more reliable
* results
*/
- if (regs_no_sipr(regs)) {
+ if (ppmu->flags & PPMU_NO_SIPR) {
unsigned long siar = mfspr(SPRN_SIAR);
if (siar >= PAGE_OFFSET)
return PERF_RECORD_MISC_KERNEL;
@@ -239,22 +234,9 @@ static inline void perf_read_regs(struct pt_regs *regs)
int use_siar;
regs->dsisr = mmcra;
- regs->result = 0;
-
- if (ppmu->flags & PPMU_NO_SIPR)
- regs->result |= 2;
-
- /*
- * On power8 if we're in random sampling mode, the SIER is updated.
- * If we're in continuous sampling mode, we don't have SIPR.
- */
- if (ppmu->flags & PPMU_HAS_SIER) {
- if (marked)
- regs->dar = mfspr(SPRN_SIER);
- else
- regs->result |= 2;
- }
+ if (ppmu->flags & PPMU_HAS_SIER)
+ regs->dar = mfspr(SPRN_SIER);
/*
* If this isn't a PMU exception (eg a software event) the SIAR is
@@ -279,12 +261,12 @@ static inline void perf_read_regs(struct pt_regs *regs)
use_siar = 1;
else if ((ppmu->flags & PPMU_NO_CONT_SAMPLING))
use_siar = 0;
- else if (!regs_no_sipr(regs) && regs_sipr(regs))
+ else if (!(ppmu->flags & PPMU_NO_SIPR) && regs_sipr(regs))
use_siar = 0;
else
use_siar = 1;
- regs->result |= use_siar;
+ regs->result = use_siar;
}
/*
--
1.7.10.4
^ permalink raw reply related
* Re: SATA FSL and upstreaming
From: tiejun.chen @ 2013-05-16 6:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Xie Shaohui-B21989, Liu Qiang-B32616, Zang Roy-R61911,
Fleming Andy-AFLEMING, Bhushan Bharat-R65777,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1368684547.9603.38.camel@pasglop>
On 05/16/2013 02:09 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2013-05-16 at 06:05 +0000, Zang Roy-R61911 wrote:
>> I do not suggest changing the RCW. If the RCW is broken on Ben's side,
>> it is not easy to recover for him.
>> Let's check the U-boot output first.
>
> U-Boot 2013.01-00009-g7bcd7f4 (Mar 14 2013 - 14:23:16)
>
> CPU0: P5020E, Version: 1.0, (0x82280010)
> Core: E5500, Version: 1.0, (0x80240010)
> Clock Configuration:
> CPU0:2000 MHz, CPU1:2000 MHz,
> CCB:800 MHz,
> DDR:666.667 MHz (1333.333 MT/s data rate) (Asynchronous), LBC:100 MHz
> FMAN1: 600 MHz
> QMAN: 400 MHz
> PME: 400 MHz
> L1: D-cache 32 kB enabled
> I-cache 32 kB enabled
> Board: P5020DS, Sys ID: 0x1c, Sys Ver: 0x12, FPGA Ver: 0x05, vBank: 0
> Reset Configuration Word (RCW):
> 00000000: 0c540000 00000000 1e120000 00000000
> 00000010: d8984a01 03002000 de800000 41000000
> 00000020: 00000000 00000000 00000000 10070000
> 00000030: 00000000 00000000 00000000 00000000
I think you can use Bharat's RCW, which seems RR_HXAPNSP_0x36, then please take
a look at this:
The RCW directories names for the p5020ds board conform to the following naming
convention:
ab_bcdefghi_j:
a = 'R' if RGMII@DTSEC4 is supported / 'N' if not available/not used
b = 'R' if RGMII@DTSEC5 is supported / 'N" if not available/not used
c = What is available in Slot 1 or SATA
d = What is available in Slot 2
e = What is available in Slot 3
f = What is available in Slot 4
g = What is available in Slot 5
h = What is available in Slot 6
i = What is available in Slot 7
For the Slots (c..i):
'N' if not available/not used
'P' if PCIe
'X' if XAUI
'R' if SRIO
'S' if SGMII
'H' if SATA
'A' is AURORA
j = 'hex value of serdes protocol value'
So NR_HXAPNSP_0x36 means:
- no RGMII@DTSEC4
- RGMII@DTSEC5
- SATA [Slot 1 not used]
- XAUI on Slot 2
- AURORA on Slot 3
- PCIE on Slot 4
- SGMII on Slot 6
- PCIE on Slot 7
Slot 5 is not used, and the SERDES Protocol is 0x36.
So slot 7 and slot 4 can be as PCIe slot.
Tiejun
> SERDES Reference Clocks: Bank1=100Mhz Bank2=125Mhz Bank3=125Mhz
> I2C: ready
> SPI: ready
> DRAM: Initializing....using SPD
> Detected UDIMM i-DIMM
> Detected UDIMM i-DIMM
> 2 GiB left unmapped
> 4 GiB (DDR3, 64-bit, CL=9, ECC on)
> DDR Controller Interleaving Mode: cache line
> DDR Chip-Select Interleaving Mode: CS0+CS1
> Testing 0x00000000 - 0x7fffffff
> Testing 0x80000000 - 0xffffffff
> Remap DDR 2 GiB left unmapped
>
> POST memory PASSED
> Flash: 128 MiB
> L2: 512 KB enabled
> Corenet Platform Cache: 2048 KB enabled
> SRIO1: disabled
> SRIO2: disabled
> NAND: 1024 MiB
> MMC: FSL_SDHC: 0
> EEPROM: NXID v1
> PCIe1: Root Complex, no link, regs @ 0xfe200000
> PCIe1: Bus 00 - 00
> PCIe2: disabled
> PCIe3: Root Complex, no link, regs @ 0xfe202000
> PCIe3: Bus 01 - 01
> PCIe4: disabled
> In: serial
> Out: serial
> Err: serial
> Net: Initializing Fman
> Fman1: Uploading microcode version 106.1.7
> PHY reset timed out
> PHY reset timed out
> PHY reset timed out
> PHY reset timed out
> FM1@DTSEC1, FM1@DTSEC2, FM1@DTSEC3, FM1@DTSEC4, FM1@DTSEC5, FM1@TGEC1
> Hit any key to stop autoboot: 0
> =>
>
> Cheers,
> Ben.
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
>
^ permalink raw reply
* RE: SATA FSL and upstreaming
From: Zang Roy-R61911 @ 2013-05-16 6:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Liu Qiang-B32616, Fleming Andy-AFLEMING,
linuxppc-dev@lists.ozlabs.org, Xie Shaohui-B21989,
Bhushan Bharat-R65777
In-Reply-To: <1368684547.9603.38.camel@pasglop>
RG8geW91IHRyeSBzbG90Nz8NClBDSWUxIGNvbm5lY3RzIHRvIHNsb3Q3IGRpcmVjdGx5Lg0KUm95
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmVuamFtaW4gSGVycmVu
c2NobWlkdCBbbWFpbHRvOmJlbmhAa2VybmVsLmNyYXNoaW5nLm9yZ10NCj4gU2VudDogVGh1cnNk
YXksIE1heSAxNiwgMjAxMyAyOjA5IFBNDQo+IFRvOiBaYW5nIFJveS1SNjE5MTENCj4gQ2M6IEJo
dXNoYW4gQmhhcmF0LVI2NTc3NzsgTGl1IFFpYW5nLUIzMjYxNjsgRmxlbWluZyBBbmR5LUFGTEVN
SU5HOw0KPiBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsgWGllIFNoYW9odWktQjIxOTg5
DQo+IFN1YmplY3Q6IFJlOiBTQVRBIEZTTCBhbmQgdXBzdHJlYW1pbmcNCj4gDQo+IE9uIFRodSwg
MjAxMy0wNS0xNiBhdCAwNjowNSArMDAwMCwgWmFuZyBSb3ktUjYxOTExIHdyb3RlOg0KPiA+IEkg
ZG8gbm90IHN1Z2dlc3QgY2hhbmdpbmcgdGhlIFJDVy4gSWYgdGhlIFJDVyBpcyBicm9rZW4gb24g
QmVuJ3Mgc2lkZSwNCj4gPiBpdCBpcyBub3QgZWFzeSB0byByZWNvdmVyIGZvciBoaW0uDQo+ID4g
TGV0J3MgY2hlY2sgdGhlIFUtYm9vdCBvdXRwdXQgZmlyc3QuDQo+IA0KPiBVLUJvb3QgMjAxMy4w
MS0wMDAwOS1nN2JjZDdmNCAoTWFyIDE0IDIwMTMgLSAxNDoyMzoxNikNCj4gDQo+IENQVTA6ICBQ
NTAyMEUsIFZlcnNpb246IDEuMCwgKDB4ODIyODAwMTApDQo+IENvcmU6ICBFNTUwMCwgVmVyc2lv
bjogMS4wLCAoMHg4MDI0MDAxMCkNCj4gQ2xvY2sgQ29uZmlndXJhdGlvbjoNCj4gICAgICAgIENQ
VTA6MjAwMCBNSHosIENQVTE6MjAwMCBNSHosDQo+ICAgICAgICBDQ0I6ODAwICBNSHosDQo+ICAg
ICAgICBERFI6NjY2LjY2NyBNSHogKDEzMzMuMzMzIE1UL3MgZGF0YSByYXRlKSAoQXN5bmNocm9u
b3VzKSwgTEJDOjEwMA0KPiBNSHoNCj4gICAgICAgIEZNQU4xOiA2MDAgTUh6DQo+ICAgICAgICBR
TUFOOiAgNDAwIE1Ieg0KPiAgICAgICAgUE1FOiAgIDQwMCBNSHoNCj4gTDE6ICAgIEQtY2FjaGUg
MzIga0IgZW5hYmxlZA0KPiAgICAgICAgSS1jYWNoZSAzMiBrQiBlbmFibGVkDQo+IEJvYXJkOiBQ
NTAyMERTLCBTeXMgSUQ6IDB4MWMsIFN5cyBWZXI6IDB4MTIsIEZQR0EgVmVyOiAweDA1LCB2QmFu
azogMA0KPiBSZXNldCBDb25maWd1cmF0aW9uIFdvcmQgKFJDVyk6DQo+ICAgICAgICAwMDAwMDAw
MDogMGM1NDAwMDAgMDAwMDAwMDAgMWUxMjAwMDAgMDAwMDAwMDANCj4gICAgICAgIDAwMDAwMDEw
OiBkODk4NGEwMSAwMzAwMjAwMCBkZTgwMDAwMCA0MTAwMDAwMA0KPiAgICAgICAgMDAwMDAwMjA6
IDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIDEwMDcwMDAwDQo+ICAgICAgICAwMDAwMDAzMDog
MDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDANCj4gU0VSREVTIFJlZmVyZW5jZSBD
bG9ja3M6IEJhbmsxPTEwME1oeiBCYW5rMj0xMjVNaHogQmFuazM9MTI1TWh6DQo+IEkyQzogICBy
ZWFkeQ0KPiBTUEk6ICAgcmVhZHkNCj4gRFJBTTogIEluaXRpYWxpemluZy4uLi51c2luZyBTUEQN
Cj4gRGV0ZWN0ZWQgVURJTU0gaS1ESU1NDQo+IERldGVjdGVkIFVESU1NIGktRElNTQ0KPiAyIEdp
QiBsZWZ0IHVubWFwcGVkDQo+IDQgR2lCIChERFIzLCA2NC1iaXQsIENMPTksIEVDQyBvbikNCj4g
ICAgICAgIEREUiBDb250cm9sbGVyIEludGVybGVhdmluZyBNb2RlOiBjYWNoZSBsaW5lDQo+ICAg
ICAgICBERFIgQ2hpcC1TZWxlY3QgSW50ZXJsZWF2aW5nIE1vZGU6IENTMCtDUzENCj4gVGVzdGlu
ZyAweDAwMDAwMDAwIC0gMHg3ZmZmZmZmZg0KPiBUZXN0aW5nIDB4ODAwMDAwMDAgLSAweGZmZmZm
ZmZmDQo+IFJlbWFwIEREUiAyIEdpQiBsZWZ0IHVubWFwcGVkDQo+IA0KPiBQT1NUIG1lbW9yeSBQ
QVNTRUQNCj4gRmxhc2g6IDEyOCBNaUINCj4gTDI6ICAgIDUxMiBLQiBlbmFibGVkDQo+IENvcmVu
ZXQgUGxhdGZvcm0gQ2FjaGU6IDIwNDggS0IgZW5hYmxlZA0KPiBTUklPMTogZGlzYWJsZWQNCj4g
U1JJTzI6IGRpc2FibGVkDQo+IE5BTkQ6ICAxMDI0IE1pQg0KPiBNTUM6ICBGU0xfU0RIQzogMA0K
PiBFRVBST006IE5YSUQgdjENCj4gUENJZTE6IFJvb3QgQ29tcGxleCwgbm8gbGluaywgcmVncyBA
IDB4ZmUyMDAwMDANCj4gUENJZTE6IEJ1cyAwMCAtIDAwDQo+IFBDSWUyOiBkaXNhYmxlZA0KPiBQ
Q0llMzogUm9vdCBDb21wbGV4LCBubyBsaW5rLCByZWdzIEAgMHhmZTIwMjAwMA0KPiBQQ0llMzog
QnVzIDAxIC0gMDENCj4gUENJZTQ6IGRpc2FibGVkDQo+IEluOiAgICBzZXJpYWwNCj4gT3V0OiAg
IHNlcmlhbA0KPiBFcnI6ICAgc2VyaWFsDQo+IE5ldDogICBJbml0aWFsaXppbmcgRm1hbg0KPiBG
bWFuMTogVXBsb2FkaW5nIG1pY3JvY29kZSB2ZXJzaW9uIDEwNi4xLjcNCj4gUEhZIHJlc2V0IHRp
bWVkIG91dA0KPiBQSFkgcmVzZXQgdGltZWQgb3V0DQo+IFBIWSByZXNldCB0aW1lZCBvdXQNCj4g
UEhZIHJlc2V0IHRpbWVkIG91dA0KPiBGTTFARFRTRUMxLCBGTTFARFRTRUMyLCBGTTFARFRTRUMz
LCBGTTFARFRTRUM0LCBGTTFARFRTRUM1LCBGTTFAVEdFQzENCj4gSGl0IGFueSBrZXkgdG8gc3Rv
cCBhdXRvYm9vdDogIDANCj4gPT4NCj4gDQo+IENoZWVycywNCj4gQmVuLg0KPiANCj4gDQoNCg==
^ permalink raw reply
* Re: SATA FSL and upstreaming
From: Benjamin Herrenschmidt @ 2013-05-16 6:09 UTC (permalink / raw)
To: Zang Roy-R61911
Cc: Liu Qiang-B32616, Fleming Andy-AFLEMING,
linuxppc-dev@lists.ozlabs.org, Xie Shaohui-B21989,
Bhushan Bharat-R65777
In-Reply-To: <3E027F8168735B46AC006B1D0C7BB0020B1E040F@039-SN2MPN1-011.039d.mgd.msft.net>
On Thu, 2013-05-16 at 06:05 +0000, Zang Roy-R61911 wrote:
> I do not suggest changing the RCW. If the RCW is broken on Ben's side,
> it is not easy to recover for him.
> Let's check the U-boot output first.
U-Boot 2013.01-00009-g7bcd7f4 (Mar 14 2013 - 14:23:16)
CPU0: P5020E, Version: 1.0, (0x82280010)
Core: E5500, Version: 1.0, (0x80240010)
Clock Configuration:
CPU0:2000 MHz, CPU1:2000 MHz,
CCB:800 MHz,
DDR:666.667 MHz (1333.333 MT/s data rate) (Asynchronous), LBC:100 MHz
FMAN1: 600 MHz
QMAN: 400 MHz
PME: 400 MHz
L1: D-cache 32 kB enabled
I-cache 32 kB enabled
Board: P5020DS, Sys ID: 0x1c, Sys Ver: 0x12, FPGA Ver: 0x05, vBank: 0
Reset Configuration Word (RCW):
00000000: 0c540000 00000000 1e120000 00000000
00000010: d8984a01 03002000 de800000 41000000
00000020: 00000000 00000000 00000000 10070000
00000030: 00000000 00000000 00000000 00000000
SERDES Reference Clocks: Bank1=100Mhz Bank2=125Mhz Bank3=125Mhz
I2C: ready
SPI: ready
DRAM: Initializing....using SPD
Detected UDIMM i-DIMM
Detected UDIMM i-DIMM
2 GiB left unmapped
4 GiB (DDR3, 64-bit, CL=9, ECC on)
DDR Controller Interleaving Mode: cache line
DDR Chip-Select Interleaving Mode: CS0+CS1
Testing 0x00000000 - 0x7fffffff
Testing 0x80000000 - 0xffffffff
Remap DDR 2 GiB left unmapped
POST memory PASSED
Flash: 128 MiB
L2: 512 KB enabled
Corenet Platform Cache: 2048 KB enabled
SRIO1: disabled
SRIO2: disabled
NAND: 1024 MiB
MMC: FSL_SDHC: 0
EEPROM: NXID v1
PCIe1: Root Complex, no link, regs @ 0xfe200000
PCIe1: Bus 00 - 00
PCIe2: disabled
PCIe3: Root Complex, no link, regs @ 0xfe202000
PCIe3: Bus 01 - 01
PCIe4: disabled
In: serial
Out: serial
Err: serial
Net: Initializing Fman
Fman1: Uploading microcode version 106.1.7
PHY reset timed out
PHY reset timed out
PHY reset timed out
PHY reset timed out
FM1@DTSEC1, FM1@DTSEC2, FM1@DTSEC3, FM1@DTSEC4, FM1@DTSEC5, FM1@TGEC1
Hit any key to stop autoboot: 0
=>
Cheers,
Ben.
^ permalink raw reply
* Re: SATA FSL and upstreaming
From: Benjamin Herrenschmidt @ 2013-05-16 6:06 UTC (permalink / raw)
To: tiejun.chen; +Cc: Qiang Liu, Andy Fleming, linuxppc-dev, Shaohui Xie
In-Reply-To: <519474E4.9030705@windriver.com>
On Thu, 2013-05-16 at 13:55 +0800, tiejun.chen wrote:
> This should depend on the RCW.
>
> As I recall, slot 7 or slot 4 can be configured to support PCIe for
> P5020DS. And
> you can know this information according to RCW's README.
Somebody can hand hold me on irc ?
Cheers,
Ben.
^ permalink raw reply
* RE: SATA FSL and upstreaming
From: Zang Roy-R61911 @ 2013-05-16 6:05 UTC (permalink / raw)
To: Bhushan Bharat-R65777, Benjamin Herrenschmidt, Liu Qiang-B32616
Cc: linuxppc-dev@lists.ozlabs.org, Fleming Andy-AFLEMING,
Xie Shaohui-B21989
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D0701C307@039-SN2MPN1-012.039d.mgd.msft.net>
> -----Original Message-----
> From: Linuxppc-dev [mailto:linuxppc-dev-bounces+tie-
> fei.zang=3Dfreescale.com@lists.ozlabs.org] On Behalf Of Bhushan Bharat-
> R65777
> Sent: Thursday, May 16, 2013 2:02 PM
> To: Benjamin Herrenschmidt; Liu Qiang-B32616
> Cc: Fleming Andy-AFLEMING; linuxppc-dev@lists.ozlabs.org; Xie Shaohui-
> B21989
> Subject: RE: SATA FSL and upstreaming
>=20
>=20
>=20
> > -----Original Message-----
> > From: Linuxppc-dev [mailto:linuxppc-dev-
> > bounces+bharat.bhushan=3Dfreescale.com@lists.ozlabs.org] On Behalf Of
> > bounces+Benjamin
> > Herrenschmidt
> > Sent: Thursday, May 16, 2013 11:16 AM
> > To: Liu Qiang-B32616
> > Cc: linuxppc-dev@lists.ozlabs.org; Fleming Andy-AFLEMING; Xie
> > Shaohui-B21989
> > Subject: Re: SATA FSL and upstreaming
> >
> > On Thu, 2013-05-16 at 14:47 +1000, Benjamin Herrenschmidt wrote:
> > > Hi folks !
> > >
> > > So I was trying to use my 5020ds to test some stuff today. Since I
> > > hadn't used it in a while, I decided to "upgrade" it to the latest
> > > NOR etc...
> >
> > On another note, I can't seem to get any PCIe card recognized in any
> slot...
> >
> > Can you give me an example config of the DIP switches that is known to
> > work with some slots ? Is there some EEPROM config needed ? If yes,
> > any pointers ? (I can't quite make sense of either u-boot or the doc
> there).
>=20
> Can you give RCW dump?
> Or can try the attached RCW.
I do not suggest changing the RCW. If the RCW is broken on Ben's side, it i=
s not easy to recover for him.
Let's check the U-boot output first.
Thanks.
Roy
^ permalink raw reply
* RE: SATA FSL and upstreaming
From: Bhushan Bharat-R65777 @ 2013-05-16 6:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Liu Qiang-B32616
Cc: Fleming Andy-AFLEMING, linuxppc-dev@lists.ozlabs.org,
Xie Shaohui-B21989
In-Reply-To: <1368683156.9603.34.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 1200 bytes --]
> -----Original Message-----
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+bharat.bhushan=freescale.com@lists.ozlabs.org] On Behalf Of Benjamin
> Herrenschmidt
> Sent: Thursday, May 16, 2013 11:16 AM
> To: Liu Qiang-B32616
> Cc: linuxppc-dev@lists.ozlabs.org; Fleming Andy-AFLEMING; Xie Shaohui-B21989
> Subject: Re: SATA FSL and upstreaming
>
> On Thu, 2013-05-16 at 14:47 +1000, Benjamin Herrenschmidt wrote:
> > Hi folks !
> >
> > So I was trying to use my 5020ds to test some stuff today. Since I
> > hadn't used it in a while, I decided to "upgrade" it to the latest NOR
> > etc...
>
> On another note, I can't seem to get any PCIe card recognized in any slot...
>
> Can you give me an example config of the DIP switches that is known to work with
> some slots ? Is there some EEPROM config needed ? If yes, any pointers ? (I
> can't quite make sense of either u-boot or the doc there).
Can you give RCW dump?
Or can try the attached RCW.
Thanks
-Bharat
>
> Thanks,
> Ben.
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
[-- Attachment #2: rcw_15g_2000mhz.rcw --]
[-- Type: application/octet-stream, Size: 794 bytes --]
/*
* 15g configuration -- 3 SGMII 1g ports + 2 RGMII + 1 XAUI
*
* Frequencies:
*
* Sys Clock -- 133.33 Mhz
* SDREFCLK1_FSEL: 100 MHz
* SDREFCLK2_FSEL: 125 MHz
* SDREFCLK3_FSEL: 125 MHz
*
* Core -- 2000 MHz (Mul 15)
* Platform - 800 MHz (Mul 6)
* DDR -- 1333.33 MHz (Mul 10)
* FMAN -- 600 MHz (CC2 PLL)/2 (Mul 9)
*
* Serdes Bank1 -- Clock Ratio 50:1 /2 for PCIe and 50:1/1 for SGMII
* LANE A, B, C, D /2 for PCIe
* Bank2 -- 25:1 /1
* Bank3 -- 24:1 /1
*/
#include <p5020.rcwi>
SYS_PLL_RAT=6
MEM_PLL_CFG=1
MEM_PLL_RAT=10
CC1_PLL_RAT=15
CC2_PLL_RAT=9
SRDS_PRTCL=54
SRDS_RATIO_B1=4
SRDS_DIV_B1=24
SRDS_RATIO_B2=2
SRDS_RATIO_B3=5
SRDS_LPD_B1=4
SRDS_LPD_B3=12
SRDS_EN=1
PBI_SRC=0b1101
BOOT_LOC=29
FM_CLK_SEL=1
DRAM_LAT=1
I2C=4
GPIO=1
UART=6
// #include "../../a004580.rcw"
^ permalink raw reply
* RE: SATA FSL and upstreaming
From: Zang Roy-R61911 @ 2013-05-16 5:59 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Fleming Andy-AFLEMING, linuxppc-dev@lists.ozlabs.org,
Xie Shaohui-B21989
In-Reply-To: <1368683156.9603.34.camel@pasglop>
For PCIe issue, I might be related to your RCW (Reset Configuration Word).
Can you help to provide the u-boot log?
Roy
> -----Original Message-----
> From: Linuxppc-dev [mailto:linuxppc-dev-bounces+tie-
> fei.zang=3Dfreescale.com@lists.ozlabs.org] On Behalf Of Benjamin
> Herrenschmidt
> Sent: Thursday, May 16, 2013 1:46 PM
> To: Liu Qiang-B32616
> Cc: linuxppc-dev@lists.ozlabs.org; Fleming Andy-AFLEMING; Xie Shaohui-
> B21989
> Subject: Re: SATA FSL and upstreaming
>=20
> On Thu, 2013-05-16 at 14:47 +1000, Benjamin Herrenschmidt wrote:
> > Hi folks !
> >
> > So I was trying to use my 5020ds to test some stuff today. Since I
> > hadn't used it in a while, I decided to "upgrade" it to the latest NOR
> > etc...
>=20
> On another note, I can't seem to get any PCIe card recognized in any
> slot...
>=20
> Can you give me an example config of the DIP switches that is known to
> work with some slots ? Is there some EEPROM config needed ? If yes, any
> pointers ? (I can't quite make sense of either u-boot or the doc there).
>=20
> Thanks,
> Ben.
>=20
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: SATA FSL and upstreaming
From: tiejun.chen @ 2013-05-16 5:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Qiang Liu, Andy Fleming, linuxppc-dev, Shaohui Xie
In-Reply-To: <1368683156.9603.34.camel@pasglop>
On 05/16/2013 01:45 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2013-05-16 at 14:47 +1000, Benjamin Herrenschmidt wrote:
>> Hi folks !
>>
>> So I was trying to use my 5020ds to test some stuff today. Since I
>> hadn't used it in a while, I decided to "upgrade" it to the latest NOR
>> etc...
>
> On another note, I can't seem to get any PCIe card recognized in any
> slot...
This should depend on the RCW.
As I recall, slot 7 or slot 4 can be configured to support PCIe for P5020DS. And
you can know this information according to RCW's README.
Tiejun
^ permalink raw reply
* Re: SATA FSL and upstreaming
From: Benjamin Herrenschmidt @ 2013-05-16 5:45 UTC (permalink / raw)
To: Qiang Liu; +Cc: linuxppc-dev, Andy Fleming, Shaohui Xie
In-Reply-To: <1368679657.9603.32.camel@pasglop>
On Thu, 2013-05-16 at 14:47 +1000, Benjamin Herrenschmidt wrote:
> Hi folks !
>
> So I was trying to use my 5020ds to test some stuff today. Since I
> hadn't used it in a while, I decided to "upgrade" it to the latest NOR
> etc...
On another note, I can't seem to get any PCIe card recognized in any
slot...
Can you give me an example config of the DIP switches that is known to
work with some slots ? Is there some EEPROM config needed ? If yes, any
pointers ? (I can't quite make sense of either u-boot or the doc there).
Thanks,
Ben.
^ permalink raw reply
* [PATCH 2/2 v2] powerpc: restore dbcr0 on user space exit
From: Bharat Bhushan @ 2013-05-16 5:34 UTC (permalink / raw)
To: galak, benh, linuxppc-dev, scottwood, stuart.yoder, James.Yang
Cc: Bharat Bhushan
In-Reply-To: <1368682472-4268-2-git-send-email-Bharat.Bhushan@freescale.com>
On BookE (Branch taken + Single Step) is as same as Branch Taken
on BookS and in Linux we simulate BookS behavior for BookE as well.
When doing so, in Branch taken handling we want to set DBCR0_IC but
we update the current->thread->dbcr0 and not DBCR0.
Now on 64bit the current->thread.dbcr0 (and other debug registers)
is synchronized ONLY on context switch flow. But after handling
Branch taken in debug exception if we return back to user space
without context switch then single stepping change (DBCR0_ICMP)
does not get written in h/w DBCR0 and Instruction Complete exception
does not happen.
This fixes using ptrace reliably on BookE-PowerPC
Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com>
---
v1->v2
- Subject line was not having 2/2
arch/powerpc/kernel/asm-offsets.c | 1 +
arch/powerpc/kernel/entry_64.S | 24 ++++++++++++++++++++----
2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index b51a97c..1e2f450 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -103,6 +103,7 @@ int main(void)
#endif /* CONFIG_VSX */
#ifdef CONFIG_PPC64
DEFINE(KSP_VSID, offsetof(struct thread_struct, ksp_vsid));
+ DEFINE(THREAD_DBCR0, offsetof(struct thread_struct, dbcr0));
#else /* CONFIG_PPC64 */
DEFINE(PGDIR, offsetof(struct thread_struct, pgdir));
#if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 794889b..561630d 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -614,7 +614,9 @@ _GLOBAL(ret_from_except_lite)
* from the interrupt.
*/
#ifdef CONFIG_PPC_BOOK3E
+ ld r3,PACACURRENT(r13)
wrteei 0
+ lwz r10,(THREAD+THREAD_DBCR0)(r3)
#else
ld r10,PACAKMSR(r13) /* Get kernel MSR without EE */
mtmsrd r10,1 /* Update machine state */
@@ -628,15 +630,29 @@ _GLOBAL(ret_from_except_lite)
/* Check current_thread_info()->flags */
andi. r0,r4,_TIF_USER_WORK_MASK
+ bne 1f
+#ifdef CONFIG_PPC_BOOK3E
+ /*
+ * Check to see if the dbcr0 register is set up to debug.
+ * Use the internal debug mode bit to do this.
+ */
+ andis. r0,r10,DBCR0_IDM@h
beq restore
-
- andi. r0,r4,_TIF_NEED_RESCHED
- beq 1f
+ mfmsr r0
+ rlwinm r0,r0,0,~MSR_DE /* Clear MSR.DE */
+ mtmsr r0
+ mtspr SPRN_DBCR0,r10
+ li r10, -1
+ mtspr SPRN_DBSR,r10
+ b restore
+#endif
+1: andi. r0,r4,_TIF_NEED_RESCHED
+ beq 2f
bl .restore_interrupts
SCHEDULE_USER
b .ret_from_except_lite
-1: bl .save_nvgprs
+2: bl .save_nvgprs
bl .restore_interrupts
addi r3,r1,STACK_FRAME_OVERHEAD
bl .do_notify_resume
--
1.5.6.5
^ permalink raw reply related
* [PATCH 1/2 v2] powerpc: debug control and status registers are 32bit
From: Bharat Bhushan @ 2013-05-16 5:34 UTC (permalink / raw)
To: galak, benh, linuxppc-dev, scottwood, stuart.yoder, James.Yang
Cc: Bharat Bhushan
In-Reply-To: <1368682472-4268-1-git-send-email-Bharat.Bhushan@freescale.com>
Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com>
---
v1->v2
- Subject line was not having 1/2
arch/powerpc/include/asm/processor.h | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/processor.h b/arch/powerpc/include/asm/processor.h
index d7e67ca..5213577 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -168,10 +168,10 @@ struct thread_struct {
* The following help to manage the use of Debug Control Registers
* om the BookE platforms.
*/
- unsigned long dbcr0;
- unsigned long dbcr1;
+ uint32_t dbcr0;
+ uint32_t dbcr1;
#ifdef CONFIG_BOOKE
- unsigned long dbcr2;
+ uint32_t dbcr2;
#endif
/*
* The stored value of the DBSR register will be the value at the
@@ -179,7 +179,7 @@ struct thread_struct {
* user (will never be written to) and has value while helping to
* describe the reason for the last debug trap. Torez
*/
- unsigned long dbsr;
+ uint32_t dbsr;
/*
* The following will contain addresses used by debug applications
* to help trace and trap on particular address locations.
--
1.5.6.5
^ permalink raw reply related
* [PATCH 0/2 v2] powerpc: Make ptrace work reliably
From: Bharat Bhushan @ 2013-05-16 5:34 UTC (permalink / raw)
To: galak, benh, linuxppc-dev, scottwood, stuart.yoder, James.Yang
Cc: Bharat Bhushan
From: Bharat Bhushan <bharat.bhushan@freescale.com>
v1->v2
- Subject line was missing 0/2, 1/2, 2/2
Bharat Bhushan (2):
powerpc: debug control and status registers are 32bit
=> This patch makes debug control and status registers as 32bit as they are.
This does not fix anything
powerpc: restore dbcr0 on user space exit
=> This patch fixes the ptrace reliability issue. The description is the patch
describes one of the case where it does not work reliably
arch/powerpc/include/asm/processor.h | 8 ++++----
arch/powerpc/kernel/asm-offsets.c | 1 +
arch/powerpc/kernel/entry_64.S | 24 ++++++++++++++++++++----
3 files changed, 25 insertions(+), 8 deletions(-)
^ permalink raw reply
* [PATCH] powerpc: restore dbcr0 on user space exit
From: Bharat Bhushan @ 2013-05-16 5:29 UTC (permalink / raw)
To: galak, benh, linuxppc-dev, scottwood, stuart.yoder, James.Yang
Cc: Bharat Bhushan
In-Reply-To: <1368682191-4225-2-git-send-email-Bharat.Bhushan@freescale.com>
On BookE (Branch taken + Single Step) is as same as Branch Taken
on BookS and in Linux we simulate BookS behavior for BookE as well.
When doing so, in Branch taken handling we want to set DBCR0_IC but
we update the current->thread->dbcr0 and not DBCR0.
Now on 64bit the current->thread.dbcr0 (and other debug registers)
is synchronized ONLY on context switch flow. But after handling
Branch taken in debug exception if we return back to user space
without context switch then single stepping change (DBCR0_ICMP)
does not get written in h/w DBCR0 and Instruction Complete exception
does not happen.
This fixes using ptrace reliably on BookE-PowerPC
Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com>
---
arch/powerpc/kernel/asm-offsets.c | 1 +
arch/powerpc/kernel/entry_64.S | 24 ++++++++++++++++++++----
2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index b51a97c..1e2f450 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -103,6 +103,7 @@ int main(void)
#endif /* CONFIG_VSX */
#ifdef CONFIG_PPC64
DEFINE(KSP_VSID, offsetof(struct thread_struct, ksp_vsid));
+ DEFINE(THREAD_DBCR0, offsetof(struct thread_struct, dbcr0));
#else /* CONFIG_PPC64 */
DEFINE(PGDIR, offsetof(struct thread_struct, pgdir));
#if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 794889b..561630d 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -614,7 +614,9 @@ _GLOBAL(ret_from_except_lite)
* from the interrupt.
*/
#ifdef CONFIG_PPC_BOOK3E
+ ld r3,PACACURRENT(r13)
wrteei 0
+ lwz r10,(THREAD+THREAD_DBCR0)(r3)
#else
ld r10,PACAKMSR(r13) /* Get kernel MSR without EE */
mtmsrd r10,1 /* Update machine state */
@@ -628,15 +630,29 @@ _GLOBAL(ret_from_except_lite)
/* Check current_thread_info()->flags */
andi. r0,r4,_TIF_USER_WORK_MASK
+ bne 1f
+#ifdef CONFIG_PPC_BOOK3E
+ /*
+ * Check to see if the dbcr0 register is set up to debug.
+ * Use the internal debug mode bit to do this.
+ */
+ andis. r0,r10,DBCR0_IDM@h
beq restore
-
- andi. r0,r4,_TIF_NEED_RESCHED
- beq 1f
+ mfmsr r0
+ rlwinm r0,r0,0,~MSR_DE /* Clear MSR.DE */
+ mtmsr r0
+ mtspr SPRN_DBCR0,r10
+ li r10, -1
+ mtspr SPRN_DBSR,r10
+ b restore
+#endif
+1: andi. r0,r4,_TIF_NEED_RESCHED
+ beq 2f
bl .restore_interrupts
SCHEDULE_USER
b .ret_from_except_lite
-1: bl .save_nvgprs
+2: bl .save_nvgprs
bl .restore_interrupts
addi r3,r1,STACK_FRAME_OVERHEAD
bl .do_notify_resume
--
1.5.6.5
^ permalink raw reply related
* [PATCH] powerpc: debug control and status registers are 32bit
From: Bharat Bhushan @ 2013-05-16 5:29 UTC (permalink / raw)
To: galak, benh, linuxppc-dev, scottwood, stuart.yoder, James.Yang
Cc: Bharat Bhushan
In-Reply-To: <1368682191-4225-1-git-send-email-Bharat.Bhushan@freescale.com>
Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com>
---
arch/powerpc/include/asm/processor.h | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/processor.h b/arch/powerpc/include/asm/processor.h
index d7e67ca..5213577 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -168,10 +168,10 @@ struct thread_struct {
* The following help to manage the use of Debug Control Registers
* om the BookE platforms.
*/
- unsigned long dbcr0;
- unsigned long dbcr1;
+ uint32_t dbcr0;
+ uint32_t dbcr1;
#ifdef CONFIG_BOOKE
- unsigned long dbcr2;
+ uint32_t dbcr2;
#endif
/*
* The stored value of the DBSR register will be the value at the
@@ -179,7 +179,7 @@ struct thread_struct {
* user (will never be written to) and has value while helping to
* describe the reason for the last debug trap. Torez
*/
- unsigned long dbsr;
+ uint32_t dbsr;
/*
* The following will contain addresses used by debug applications
* to help trace and trap on particular address locations.
--
1.5.6.5
^ permalink raw reply related
* [PATCH] powerpc: Make ptrace work reliably
From: Bharat Bhushan @ 2013-05-16 5:29 UTC (permalink / raw)
To: galak, benh, linuxppc-dev, scottwood, stuart.yoder, James.Yang
Cc: Bharat Bhushan
From: Bharat Bhushan <bharat.bhushan@freescale.com>
Bharat Bhushan (2):
powerpc: debug control and status registers are 32bit
=> This patch makes debug control and status registers as 32bit as they are.
This does not fix anything
powerpc: restore dbcr0 on user space exit
=> This patch fixes the ptrace reliability issue. The description is the patch
describes one of the case where it does not work reliably
arch/powerpc/include/asm/processor.h | 8 ++++----
arch/powerpc/kernel/asm-offsets.c | 1 +
arch/powerpc/kernel/entry_64.S | 24 ++++++++++++++++++++----
3 files changed, 25 insertions(+), 8 deletions(-)
^ permalink raw reply
* SATA FSL and upstreaming
From: Benjamin Herrenschmidt @ 2013-05-16 4:47 UTC (permalink / raw)
To: Qiang Liu, Shaohui Xie, Andy Fleming; +Cc: linuxppc-dev
Hi folks !
So I was trying to use my 5020ds to test some stuff today. Since I
hadn't used it in a while, I decided to "upgrade" it to the latest NOR
etc...
Interestingly I discovered that the SATA (which was supposedly dead on
the rev1 chip) was actually working with the SDK kernel, while it's
still completely busted upstream.
A quick git compare shows about 5 or 6 commits in the SDK tree, some as
old as 2011, fixing various erratas in that chip, that never made their
way upstream.
Any reason for that ? Being GPL, I can submit them to Tejun myself but
it would be better form if you guys did :-)
BTW. Also what's the status with getting the network working upstream ?
Even if sub-standard the code could at least go into staging...
Cheers,
Ben.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox