SATA FSL and upstreaming

SATA FSL and upstreaming

[Benjamin Herrenschmidt]

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.

Re: SATA FSL and upstreaming

[Benjamin Herrenschmidt]

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.

Re: SATA FSL and upstreaming

[tiejun.chen]

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

Re: SATA FSL and upstreaming

[Benjamin Herrenschmidt]

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.

RE: SATA FSL and upstreaming

[Zang Roy-R61911]

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

RE: SATA FSL and upstreaming

[Bhushan Bharat-R65777]

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

RE: SATA FSL and upstreaming

[Zang Roy-R61911]

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

Re: SATA FSL and upstreaming

[Benjamin Herrenschmidt]

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.

Re: SATA FSL and upstreaming

[tiejun.chen]

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

RE: SATA FSL and upstreaming

[Zang Roy-R61911]

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

Re: SATA FSL and upstreaming

[tiejun.chen]

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

RE: SATA FSL and upstreaming

[Zang Roy-R61911]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdGllanVuLmNoZW4gW21h
aWx0bzp0aWVqdW4uY2hlbkB3aW5kcml2ZXIuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgTWF5IDE2
LCAyMDEzIDI6MjUgUE0NCj4gVG86IFphbmcgUm95LVI2MTkxMQ0KPiBDYzogQmVuamFtaW4gSGVy
cmVuc2NobWlkdDsgTGl1IFFpYW5nLUIzMjYxNjsgRmxlbWluZyBBbmR5LUFGTEVNSU5HOw0KPiBs
aW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsgWGllIFNoYW9odWktQjIxOTg5OyBCaHVzaGFu
IEJoYXJhdC1SNjU3NzcNCj4gU3ViamVjdDogUmU6IFNBVEEgRlNMIGFuZCB1cHN0cmVhbWluZw0K
PiANCj4gT24gMDUvMTYvMjAxMyAwMjoyMCBQTSwgWmFuZyBSb3ktUjYxOTExIHdyb3RlOg0KPiA+
DQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogdGllanVu
LmNoZW4gW21haWx0bzp0aWVqdW4uY2hlbkB3aW5kcml2ZXIuY29tXQ0KPiA+PiBTZW50OiBUaHVy
c2RheSwgTWF5IDE2LCAyMDEzIDI6MTggUE0NCj4gPj4gVG86IEJlbmphbWluIEhlcnJlbnNjaG1p
ZHQNCj4gPj4gQ2M6IFphbmcgUm95LVI2MTkxMTsgTGl1IFFpYW5nLUIzMjYxNjsgRmxlbWluZyBB
bmR5LUFGTEVNSU5HOw0KPiA+PiBsaW51eHBwYy0gZGV2QGxpc3RzLm96bGFicy5vcmc7IFhpZSBT
aGFvaHVpLUIyMTk4OTsgQmh1c2hhbg0KPiA+PiBCaGFyYXQtUjY1Nzc3DQo+ID4+IFN1YmplY3Q6
IFJlOiBTQVRBIEZTTCBhbmQgdXBzdHJlYW1pbmcNCj4gPj4NCj4gPj4gT24gMDUvMTYvMjAxMyAw
MjowOSBQTSwgQmVuamFtaW4gSGVycmVuc2NobWlkdCB3cm90ZToNCj4gPj4+IE9uIFRodSwgMjAx
My0wNS0xNiBhdCAwNjowNSArMDAwMCwgWmFuZyBSb3ktUjYxOTExIHdyb3RlOg0KPiA+Pj4+IEkg
ZG8gbm90IHN1Z2dlc3QgY2hhbmdpbmcgdGhlIFJDVy4gSWYgdGhlIFJDVyBpcyBicm9rZW4gb24g
QmVuJ3MNCj4gPj4+PiBzaWRlLCBpdCBpcyBub3QgZWFzeSB0byByZWNvdmVyIGZvciBoaW0uDQo+
ID4+Pj4gTGV0J3MgY2hlY2sgdGhlIFUtYm9vdCBvdXRwdXQgZmlyc3QuDQo+ID4+Pg0KPiA+Pj4g
VS1Cb290IDIwMTMuMDEtMDAwMDktZzdiY2Q3ZjQgKE1hciAxNCAyMDEzIC0gMTQ6MjM6MTYpDQo+
ID4+Pg0KPiA+Pj4gQ1BVMDogIFA1MDIwRSwgVmVyc2lvbjogMS4wLCAoMHg4MjI4MDAxMCkNCj4g
Pj4+IENvcmU6ICBFNTUwMCwgVmVyc2lvbjogMS4wLCAoMHg4MDI0MDAxMCkgQ2xvY2sgQ29uZmln
dXJhdGlvbjoNCj4gPj4+ICAgICAgICAgIENQVTA6MjAwMCBNSHosIENQVTE6MjAwMCBNSHosDQo+
ID4+PiAgICAgICAgICBDQ0I6ODAwICBNSHosDQo+ID4+PiAgICAgICAgICBERFI6NjY2LjY2NyBN
SHogKDEzMzMuMzMzIE1UL3MgZGF0YSByYXRlKSAoQXN5bmNocm9ub3VzKSwNCj4gPj4gTEJDOjEw
MCAgTUh6DQo+ID4+PiAgICAgICAgICBGTUFOMTogNjAwIE1Ieg0KPiA+Pj4gICAgICAgICAgUU1B
TjogIDQwMCBNSHoNCj4gPj4+ICAgICAgICAgIFBNRTogICA0MDAgTUh6DQo+ID4+PiBMMTogICAg
RC1jYWNoZSAzMiBrQiBlbmFibGVkDQo+ID4+PiAgICAgICAgICBJLWNhY2hlIDMyIGtCIGVuYWJs
ZWQNCj4gPj4+IEJvYXJkOiBQNTAyMERTLCBTeXMgSUQ6IDB4MWMsIFN5cyBWZXI6IDB4MTIsIEZQ
R0EgVmVyOiAweDA1LCB2QmFuazoNCj4gPj4+IDAgUmVzZXQgQ29uZmlndXJhdGlvbiBXb3JkIChS
Q1cpOg0KPiA+Pj4gICAgICAgICAgMDAwMDAwMDA6IDBjNTQwMDAwIDAwMDAwMDAwIDFlMTIwMDAw
IDAwMDAwMDAwDQo+ID4+PiAgICAgICAgICAwMDAwMDAxMDogZDg5ODRhMDEgMDMwMDIwMDAgZGU4
MDAwMDAgNDEwMDAwMDANCj4gPj4+ICAgICAgICAgIDAwMDAwMDIwOiAwMDAwMDAwMCAwMDAwMDAw
MCAwMDAwMDAwMCAxMDA3MDAwMA0KPiA+Pj4gICAgICAgICAgMDAwMDAwMzA6IDAwMDAwMDAwIDAw
MDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwDQo+ID4+DQo+ID4+IEkgdGhpbmsgeW91IGNhbiB1c2Ug
QmhhcmF0J3MgUkNXLCB3aGljaCBzZWVtcyBSUl9IWEFQTlNQXzB4MzYsIHRoZW4NCj4gPj4gcGxl
YXNlIHRha2UgYSBsb29rIGF0IHRoaXM6DQo+ID4gV2h5Pw0KPiANCj4gSSBqdXN0IGJlbGlldmUg
QmhhcmF0IHNob3VsZCBwaWNrIGEgcHJvcGVyIFJDVyBmcm9tIFNESy4NCldlIG1heSBhbHNvIG5l
ZWQgdG8gY2hlY2sgdGhlIG9yaWdpbmFsIFJDVyB3aHkgaXQgZG9lcyBub3Qgd29yayENCg0KPiAN
Cj4gPiBCZW4ncyBvbiBib2FyZCBSQ1cgcHJvdG9jb2wgaXMgMHgzNiwgd2hpY2ggc2hvdWxkIHdv
cmsgZm9yIFBDSWUxIChzbG90DQo+IDcpIGFuZCBQQ0llMyAoc2xvdDQpLg0KPiANCj4gRGlkbid0
IHlvdSBzZWUgSSdtIGFsc28gc2F5aW5nIHRvIHVzZSBzbG90IDcgYW5kIHNsb3QgND8NCldoaWNo
IHNsb3QgZGVwZW5kcyBvbiBTZXJkZXMgcHJvdG9jb2wuIHNsb3Q3IGlzIGZpeGVkIHRvIHBjaWUx
Lg0KUm95DQo=

Re: SATA FSL and upstreaming

[Benjamin Herrenschmidt]

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.

Re: SATA FSL and upstreaming

[Benjamin Herrenschmidt]

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.

Re: SATA FSL and upstreaming

[tiejun.chen]

On 05/16/2013 02:21 PM, Benjamin Herrenschmidt wrote:
> 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 ?


Firstly please check which flash bank is used since we have to know where should 
be updated RCW.

What is SW7[1:4]?

Or we have another simple way in u-boot prompt:

=> md.b ffdf002c
ffdf002c: 4f 00 fe 00 39 00 00 00 00 00 00 00 00 00 00 00    O...9...........
...

This means we're on bank4.

>
> Any DIP switch setting I need to be aware of ?

No.

Tiejun

RE: SATA FSL and upstreaming

[Zang Roy-R61911]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdGllanVuLmNoZW4gW21h
aWx0bzp0aWVqdW4uY2hlbkB3aW5kcml2ZXIuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgTWF5IDE2
LCAyMDEzIDI6MzYgUE0NCj4gVG86IEJlbmphbWluIEhlcnJlbnNjaG1pZHQNCj4gQ2M6IFphbmcg
Um95LVI2MTkxMTsgTGl1IFFpYW5nLUIzMjYxNjsgRmxlbWluZyBBbmR5LUFGTEVNSU5HOyBsaW51
eHBwYy0NCj4gZGV2QGxpc3RzLm96bGFicy5vcmc7IFhpZSBTaGFvaHVpLUIyMTk4OTsgQmh1c2hh
biBCaGFyYXQtUjY1Nzc3DQo+IFN1YmplY3Q6IFJlOiBTQVRBIEZTTCBhbmQgdXBzdHJlYW1pbmcN
Cj4gDQo+IE9uIDA1LzE2LzIwMTMgMDI6MjEgUE0sIEJlbmphbWluIEhlcnJlbnNjaG1pZHQgd3Jv
dGU6DQo+ID4gT24gVGh1LCAyMDEzLTA1LTE2IGF0IDE0OjE3ICswODAwLCB0aWVqdW4uY2hlbiB3
cm90ZToNCj4gPj4gSSB0aGluayB5b3UgY2FuIHVzZSBCaGFyYXQncyBSQ1csIHdoaWNoIHNlZW1z
IFJSX0hYQVBOU1BfMHgzNiwgdGhlbg0KPiA+PiBwbGVhc2UgdGFrZSBhIGxvb2sgYXQgdGhpczoN
Cj4gPg0KPiA+IE9rLCBob3cgZG8gSSB1cGRhdGUgbXkgUkNXIHRvIGJzZSBCaGFyYXQncyA/DQo+
IA0KPiANCj4gRmlyc3RseSBwbGVhc2UgY2hlY2sgd2hpY2ggZmxhc2ggYmFuayBpcyB1c2VkIHNp
bmNlIHdlIGhhdmUgdG8ga25vdyB3aGVyZQ0KPiBzaG91bGQgYmUgdXBkYXRlZCBSQ1cuDQo+IA0K
PiBXaGF0IGlzIFNXN1sxOjRdPw0KPiANCj4gT3Igd2UgaGF2ZSBhbm90aGVyIHNpbXBsZSB3YXkg
aW4gdS1ib290IHByb21wdDoNCj4gDQo+ID0+IG1kLmIgZmZkZjAwMmMNCj4gZmZkZjAwMmM6IDRm
IDAwIGZlIDAwIDM5IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwDQo+IE8uLi45Li4u
Li4uLi4uLi4NCj4gLi4uDQo+IA0KPiBUaGlzIG1lYW5zIHdlJ3JlIG9uIGJhbms0Lg0KQmVuJ3Mg
bG9nIHNob3dzIGl0IGlzIGJhbmswLg0KDQpCb2FyZDogUDUwMjBEUywgU3lzIElEOiAweDFjLCBT
eXMgVmVyOiAweDEyLCBGUEdBIFZlcjogMHgwNSwgdkJhbms6IDANCg0KUm95DQo=

Re: SATA FSL and upstreaming

[Benjamin Herrenschmidt]

On Thu, 2013-05-16 at 14:35 +0800, tiejun.chen wrote:
> On 05/16/2013 02:21 PM, Benjamin Herrenschmidt wrote:
> > 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 ?
> 
> 
> Firstly please check which flash bank is used since we have to know where should 
> be updated RCW.
> 
> What is SW7[1:4]?
> 
> Or we have another simple way in u-boot prompt:
> 
> => md.b ffdf002c
> ffdf002c: 4f 00 fe 00 39 00 00 00 00 00 00 00 00 00 00 00    O...9...........
> ...

ffdf002c: 0f 00 fe 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

> This means we're on bank4.

I assume that means bank0 ?

> >
> > Any DIP switch setting I need to be aware of ?
> 
> No.
> 
> Tiejun

Re: SATA FSL and upstreaming

[tiejun.chen]

On 05/16/2013 02:40 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2013-05-16 at 14:35 +0800, tiejun.chen wrote:
>> On 05/16/2013 02:21 PM, Benjamin Herrenschmidt wrote:
>>> 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 ?
>>
>>
>> Firstly please check which flash bank is used since we have to know where should
>> be updated RCW.
>>
>> What is SW7[1:4]?
>>
>> Or we have another simple way in u-boot prompt:
>>
>> => md.b ffdf002c
>> ffdf002c: 4f 00 fe 00 39 00 00 00 00 00 00 00 00 00 00 00    O...9...........
>> ...
>
> ffdf002c: 0f 00 fe 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
>
>> This means we're on bank4.
>
> I assume that means bank0 ?

Yes, RCW should be burned to 0xec000000.

In u-boot prompt:

=> loady
## Ready for binary (ymodem) download to 0x01000000 at 115200 bps...
C

Then send that RCW with ymodem in your terminal client.

Tiejun

RE: SATA FSL and upstreaming

[Bhushan Bharat-R65777]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdGllanVuLmNoZW4gW21h
aWx0bzp0aWVqdW4uY2hlbkB3aW5kcml2ZXIuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgTWF5IDE2
LCAyMDEzIDEyOjEzIFBNDQo+IFRvOiBCZW5qYW1pbiBIZXJyZW5zY2htaWR0DQo+IENjOiBaYW5n
IFJveS1SNjE5MTE7IExpdSBRaWFuZy1CMzI2MTY7IEZsZW1pbmcgQW5keS1BRkxFTUlORzsgbGlu
dXhwcGMtDQo+IGRldkBsaXN0cy5vemxhYnMub3JnOyBYaWUgU2hhb2h1aS1CMjE5ODk7IEJodXNo
YW4gQmhhcmF0LVI2NTc3Nw0KPiBTdWJqZWN0OiBSZTogU0FUQSBGU0wgYW5kIHVwc3RyZWFtaW5n
DQo+IA0KPiBPbiAwNS8xNi8yMDEzIDAyOjQwIFBNLCBCZW5qYW1pbiBIZXJyZW5zY2htaWR0IHdy
b3RlOg0KPiA+IE9uIFRodSwgMjAxMy0wNS0xNiBhdCAxNDozNSArMDgwMCwgdGllanVuLmNoZW4g
d3JvdGU6DQo+ID4+IE9uIDA1LzE2LzIwMTMgMDI6MjEgUE0sIEJlbmphbWluIEhlcnJlbnNjaG1p
ZHQgd3JvdGU6DQo+ID4+PiBPbiBUaHUsIDIwMTMtMDUtMTYgYXQgMTQ6MTcgKzA4MDAsIHRpZWp1
bi5jaGVuIHdyb3RlOg0KPiA+Pj4+IEkgdGhpbmsgeW91IGNhbiB1c2UgQmhhcmF0J3MgUkNXLCB3
aGljaCBzZWVtcyBSUl9IWEFQTlNQXzB4MzYsIHRoZW4NCj4gPj4+PiBwbGVhc2UgdGFrZSBhIGxv
b2sgYXQgdGhpczoNCj4gPj4+DQo+ID4+PiBPaywgaG93IGRvIEkgdXBkYXRlIG15IFJDVyB0byBi
c2UgQmhhcmF0J3MgPw0KPiA+Pg0KPiA+Pg0KPiA+PiBGaXJzdGx5IHBsZWFzZSBjaGVjayB3aGlj
aCBmbGFzaCBiYW5rIGlzIHVzZWQgc2luY2Ugd2UgaGF2ZSB0byBrbm93DQo+ID4+IHdoZXJlIHNo
b3VsZCBiZSB1cGRhdGVkIFJDVy4NCj4gPj4NCj4gPj4gV2hhdCBpcyBTVzdbMTo0XT8NCj4gPj4N
Cj4gPj4gT3Igd2UgaGF2ZSBhbm90aGVyIHNpbXBsZSB3YXkgaW4gdS1ib290IHByb21wdDoNCj4g
Pj4NCj4gPj4gPT4gbWQuYiBmZmRmMDAyYw0KPiA+PiBmZmRmMDAyYzogNGYgMDAgZmUgMDAgMzkg
MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgICAgTy4uLjkuLi4uLi4uLi4uLg0KPiA+
PiAuLi4NCj4gPg0KPiA+IGZmZGYwMDJjOiAwZiAwMCBmZSAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw
MCAwMCAwMCAwMCAwMCAwMCAgICAuLi4uLi4uLi4uLi4uLi4uDQo+ID4NCj4gPj4gVGhpcyBtZWFu
cyB3ZSdyZSBvbiBiYW5rNC4NCj4gPg0KPiA+IEkgYXNzdW1lIHRoYXQgbWVhbnMgYmFuazAgPw0K
PiANCj4gWWVzLCBSQ1cgc2hvdWxkIGJlIGJ1cm5lZCB0byAweGVjMDAwMDAwLg0KPiANCj4gSW4g
dS1ib290IHByb21wdDoNCj4gDQo+ID0+IGxvYWR5DQo+ICMjIFJlYWR5IGZvciBiaW5hcnkgKHlt
b2RlbSkgZG93bmxvYWQgdG8gMHgwMTAwMDAwMCBhdCAxMTUyMDAgYnBzLi4uDQo+IEMNCj4gDQo+
IFRoZW4gc2VuZCB0aGF0IFJDVyB3aXRoIHltb2RlbSBpbiB5b3VyIHRlcm1pbmFsIGNsaWVudC4N
Cg0KMSkgTG9hZCBSQ1cgYXMgVGllanVuIG9uIHNvbWUgYWRkcmVzcyBpbiBERFIuDQoNCjIpIEJy
dW4gUkNXIGF0IDB4ZWMwMDAwMDA6DQpwcm90ZWN0IG9mZiAweGVjMDAwMDAwICskZmlsZXNpemU7
IGVyYXNlIDB4ZWMwMDAwMDAgKyRmaWxlc2l6ZTsgY3AuYiAweDEwMDAwMDAgMHhlYzAwMDAwMCAk
ZmlsZXNpemUNCg0KMykgcnVuICIgcGl4IGFsdGJhayIgY29tbWFuZA0KDQo0KSBjaGVjayB5b3Ug
YXJlIG9uIGJhbms0DQoNCjUpIElmIHlvdSBhcmUgbHVja2llciB0aGVuIG5ldHdvcmtpbmcgd2ls
bCB3b3JrIGZvciB5b3UuDQoNClRoYW5rcw0KLUJoYXJhdA0KDQo+IA0KPiBUaWVqdW4NCg0K

RE: SATA FSL and upstreaming

[Zang Roy-R61911]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmh1c2hhbiBCaGFyYXQt
UjY1Nzc3DQo+IFNlbnQ6IFRodXJzZGF5LCBNYXkgMTYsIDIwMTMgMjo0OCBQTQ0KPiBUbzogdGll
anVuLmNoZW47IEJlbmphbWluIEhlcnJlbnNjaG1pZHQNCj4gQ2M6IFphbmcgUm95LVI2MTkxMTsg
TGl1IFFpYW5nLUIzMjYxNjsgRmxlbWluZyBBbmR5LUFGTEVNSU5HOyBsaW51eHBwYy0NCj4gZGV2
QGxpc3RzLm96bGFicy5vcmc7IFhpZSBTaGFvaHVpLUIyMTk4OQ0KPiBTdWJqZWN0OiBSRTogU0FU
QSBGU0wgYW5kIHVwc3RyZWFtaW5nDQo+IA0KPiANCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS0NCj4gPiBGcm9tOiB0aWVqdW4uY2hlbiBbbWFpbHRvOnRpZWp1bi5jaGVuQHdpbmRy
aXZlci5jb21dDQo+ID4gU2VudDogVGh1cnNkYXksIE1heSAxNiwgMjAxMyAxMjoxMyBQTQ0KPiA+
IFRvOiBCZW5qYW1pbiBIZXJyZW5zY2htaWR0DQo+ID4gQ2M6IFphbmcgUm95LVI2MTkxMTsgTGl1
IFFpYW5nLUIzMjYxNjsgRmxlbWluZyBBbmR5LUFGTEVNSU5HOw0KPiA+IGxpbnV4cHBjLSBkZXZA
bGlzdHMub3psYWJzLm9yZzsgWGllIFNoYW9odWktQjIxOTg5OyBCaHVzaGFuDQo+ID4gQmhhcmF0
LVI2NTc3Nw0KPiA+IFN1YmplY3Q6IFJlOiBTQVRBIEZTTCBhbmQgdXBzdHJlYW1pbmcNCj4gPg0K
PiA+IE9uIDA1LzE2LzIwMTMgMDI6NDAgUE0sIEJlbmphbWluIEhlcnJlbnNjaG1pZHQgd3JvdGU6
DQo+ID4gPiBPbiBUaHUsIDIwMTMtMDUtMTYgYXQgMTQ6MzUgKzA4MDAsIHRpZWp1bi5jaGVuIHdy
b3RlOg0KPiA+ID4+IE9uIDA1LzE2LzIwMTMgMDI6MjEgUE0sIEJlbmphbWluIEhlcnJlbnNjaG1p
ZHQgd3JvdGU6DQo+ID4gPj4+IE9uIFRodSwgMjAxMy0wNS0xNiBhdCAxNDoxNyArMDgwMCwgdGll
anVuLmNoZW4gd3JvdGU6DQo+ID4gPj4+PiBJIHRoaW5rIHlvdSBjYW4gdXNlIEJoYXJhdCdzIFJD
Vywgd2hpY2ggc2VlbXMgUlJfSFhBUE5TUF8weDM2LA0KPiA+ID4+Pj4gdGhlbiBwbGVhc2UgdGFr
ZSBhIGxvb2sgYXQgdGhpczoNCj4gPiA+Pj4NCj4gPiA+Pj4gT2ssIGhvdyBkbyBJIHVwZGF0ZSBt
eSBSQ1cgdG8gYnNlIEJoYXJhdCdzID8NCj4gPiA+Pg0KPiA+ID4+DQo+ID4gPj4gRmlyc3RseSBw
bGVhc2UgY2hlY2sgd2hpY2ggZmxhc2ggYmFuayBpcyB1c2VkIHNpbmNlIHdlIGhhdmUgdG8ga25v
dw0KPiA+ID4+IHdoZXJlIHNob3VsZCBiZSB1cGRhdGVkIFJDVy4NCj4gPiA+Pg0KPiA+ID4+IFdo
YXQgaXMgU1c3WzE6NF0/DQo+ID4gPj4NCj4gPiA+PiBPciB3ZSBoYXZlIGFub3RoZXIgc2ltcGxl
IHdheSBpbiB1LWJvb3QgcHJvbXB0Og0KPiA+ID4+DQo+ID4gPj4gPT4gbWQuYiBmZmRmMDAyYw0K
PiA+ID4+IGZmZGYwMDJjOiA0ZiAwMCBmZSAwMCAzOSAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw
MCAwMCAwMA0KPiBPLi4uOS4uLi4uLi4uLi4uDQo+ID4gPj4gLi4uDQo+ID4gPg0KPiA+ID4gZmZk
ZjAwMmM6IDBmIDAwIGZlIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwDQo+IDAw
ICAgIC4uLi4uLi4uLi4uLi4uLi4NCj4gPiA+DQo+ID4gPj4gVGhpcyBtZWFucyB3ZSdyZSBvbiBi
YW5rNC4NCj4gPiA+DQo+ID4gPiBJIGFzc3VtZSB0aGF0IG1lYW5zIGJhbmswID8NCj4gPg0KPiA+
IFllcywgUkNXIHNob3VsZCBiZSBidXJuZWQgdG8gMHhlYzAwMDAwMC4NCj4gPg0KPiA+IEluIHUt
Ym9vdCBwcm9tcHQ6DQo+ID4NCj4gPiA9PiBsb2FkeQ0KPiA+ICMjIFJlYWR5IGZvciBiaW5hcnkg
KHltb2RlbSkgZG93bmxvYWQgdG8gMHgwMTAwMDAwMCBhdCAxMTUyMDAgYnBzLi4uDQo+ID4gQw0K
PiA+DQo+ID4gVGhlbiBzZW5kIHRoYXQgUkNXIHdpdGggeW1vZGVtIGluIHlvdXIgdGVybWluYWwg
Y2xpZW50Lg0KPiANCj4gMSkgTG9hZCBSQ1cgYXMgVGllanVuIG9uIHNvbWUgYWRkcmVzcyBpbiBE
RFIuDQo+IA0KPiAyKSBCcnVuIFJDVyBhdCAweGVjMDAwMDAwOg0KPiBwcm90ZWN0IG9mZiAweGVj
MDAwMDAwICskZmlsZXNpemU7IGVyYXNlIDB4ZWMwMDAwMDAgKyRmaWxlc2l6ZTsgY3AuYg0KPiAw
eDEwMDAwMDAgMHhlYzAwMDAwMCAkZmlsZXNpemUNCj4gDQo+IDMpIHJ1biAiIHBpeCBhbHRiYWsi
IGNvbW1hbmQNCj4gDQo+IDQpIGNoZWNrIHlvdSBhcmUgb24gYmFuazQNCj4gDQo+IDUpIElmIHlv
dSBhcmUgbHVja2llciB0aGVuIG5ldHdvcmtpbmcgd2lsbCB3b3JrIGZvciB5b3UuDQp0aGUgc3Rl
cHMgbG9vayBnb29kLg0KUGxlYXNlIGFsc28gcHJvdmlkZSBhIFJDVyBiaW5hcnkgdG8gQmVuLCBp
ZiB5b3VyIGd1eXMgaW5zaXN0IHVwZGF0aW5nICB0aGUgUkNXLg0KUm95DQo=

Re: SATA FSL and upstreaming

[Benjamin Herrenschmidt]

On Thu, 2013-05-16 at 06:49 +0000, Zang Roy-R61911 wrote:
> 

> Please also provide a RCW binary to Ben, if your guys insist updating  the RCW.

right, I just noticed it's ascii :-) That isn't going to work well...

Cheers,
Ben.

Re: SATA FSL and upstreaming

[tiejun.chen]

On 05/16/2013 02:53 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2013-05-16 at 06:49 +0000, Zang Roy-R61911 wrote:
>>
>
>> Please also provide a RCW binary to Ben, if your guys insist updating  the RCW.
>
> right, I just noticed it's ascii :-) That isn't going to work well...

Ben,

I already send my workable combination of u-boot and RCW privately to you, 
please take a try.

Tiejun

RE: SATA FSL and upstreaming

[Zang Roy-R61911]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmVuamFtaW4gSGVycmVu
c2NobWlkdCBbbWFpbHRvOmJlbmhAa2VybmVsLmNyYXNoaW5nLm9yZ10NCj4gU2VudDogVGh1cnNk
YXksIE1heSAxNiwgMjAxMyAyOjU0IFBNDQo+IFRvOiBaYW5nIFJveS1SNjE5MTENCj4gQ2M6IEJo
dXNoYW4gQmhhcmF0LVI2NTc3NzsgdGllanVuLmNoZW47IExpdSBRaWFuZy1CMzI2MTY7IEZsZW1p
bmcgQW5keS0NCj4gQUZMRU1JTkc7IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnOyBYaWUg
U2hhb2h1aS1CMjE5ODkNCj4gU3ViamVjdDogUmU6IFNBVEEgRlNMIGFuZCB1cHN0cmVhbWluZw0K
PiANCj4gT24gVGh1LCAyMDEzLTA1LTE2IGF0IDA2OjQ5ICswMDAwLCBaYW5nIFJveS1SNjE5MTEg
d3JvdGU6DQo+ID4NCj4gDQo+ID4gUGxlYXNlIGFsc28gcHJvdmlkZSBhIFJDVyBiaW5hcnkgdG8g
QmVuLCBpZiB5b3VyIGd1eXMgaW5zaXN0IHVwZGF0aW5nDQo+IHRoZSBSQ1cuDQo+IA0KPiByaWdo
dCwgSSBqdXN0IG5vdGljZWQgaXQncyBhc2NpaSA6LSkgVGhhdCBpc24ndCBnb2luZyB0byB3b3Jr
IHdlbGwuLi4NCkkganVzdCB0cmllZCB5b3VyIFJDVy4gb25lIGUxMDAwIGNhcmQgd29ya3MgaW4g
c2xvdDcuDQp3ZSBtYXkgbmVlZCB0byBjaGVjayBvdGhlcnMgLi4uDQpVLUJvb3QgMjAxMy4wMS0w
MDA3OC1nMjc0MWM5OSAoTWF5IDAzIDIwMTMgLSAwMDoyMDo0MSkNCg0KQ1BVMDogIFA1MDIwRSwg
VmVyc2lvbjogMi4wLCAoMHg4MjI4MDAyMCkNCkNvcmU6ICBFNTUwMCwgVmVyc2lvbjogMS4yLCAo
MHg4MDI0MDAxMikNCkNsb2NrIENvbmZpZ3VyYXRpb246DQogICAgICAgQ1BVMDoyMDAwIE1Ieiwg
Q1BVMToyMDAwIE1IeiwgDQogICAgICAgQ0NCOjgwMCAgTUh6LA0KICAgICAgIEREUjo2NjYuNjY3
IE1IeiAoMTMzMy4zMzMgTVQvcyBkYXRhIHJhdGUpIChBc3luY2hyb25vdXMpLCBMQkM6MTAwICBN
SHoNCiAgICAgICBGTUFOMTogNjAwIE1Ieg0KICAgICAgIFFNQU46ICA0MDAgTUh6DQogICAgICAg
UE1FOiAgIDQwMCBNSHoNCkwxOiAgICBELWNhY2hlIDMyIGtCIGVuYWJsZWQNCiAgICAgICBJLWNh
Y2hlIDMyIGtCIGVuYWJsZWQNClJlc2V0IENvbmZpZ3VyYXRpb24gV29yZCAoUkNXKToNCiAgICAg
ICAwMDAwMDAwMDogMGM1NDAwMDAgMDAwMDAwMDAgMWUxMjAwMDAgMDAwMDAwMDANCiAgICAgICAw
MDAwMDAxMDogZDg5ODRhMDEgMDMwMDIwMDAgZGU4MDAwMDAgNDEwMDAwMDANCiAgICAgICAwMDAw
MDAyMDogMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAgMTAwNzAwMDANCiAgICAgICAwMDAwMDAz
MDogMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDANCkJvYXJkOiBQNTAyMERTLCBT
eXMgSUQ6IDB4MWMsIFN5cyBWZXI6IDB4MDIsIEZQR0EgVmVyOiAweDA0LCB2QmFuazogNA0KU0VS
REVTIFJlZmVyZW5jZSBDbG9ja3M6IEJhbmsxPTEwME1oeiBCYW5rMj0xMjVNaHogQmFuazM9MTI1
TWh6IA0KSTJDOiAgIHJlYWR5DQpTUEk6ICAgcmVhZHkNCkRSQU06ICBJbml0aWFsaXppbmcuLi4u
dXNpbmcgU1BEDQpEZXRlY3RlZCBVRElNTSBpLURJTU0NCkRldGVjdGVkIFVESU1NIGktRElNTQ0K
MiBHaUIgbGVmdCB1bm1hcHBlZA0KNCBHaUIgKEREUjMsIDY0LWJpdCwgQ0w9OSwgRUNDIG9uKQ0K
ICAgICAgIEREUiBDb250cm9sbGVyIEludGVybGVhdmluZyBNb2RlOiBjYWNoZSBsaW5lDQogICAg
ICAgRERSIENoaXAtU2VsZWN0IEludGVybGVhdmluZyBNb2RlOiBDUzArQ1MxDQpUZXN0aW5nIDB4
MDAwMDAwMDAgLSAweDdmZmZmZmZmDQpUZXN0aW5nIDB4ODAwMDAwMDAgLSAweGZmZmZmZmZmDQpS
ZW1hcCBERFIgMiBHaUIgbGVmdCB1bm1hcHBlZA0KDQpQT1NUIG1lbW9yeSBQQVNTRUQNCkZsYXNo
OiAxMjggTWlCDQpMMjogICAgNTEyIEtCIGVuYWJsZWQNCkNvcmVuZXQgUGxhdGZvcm0gQ2FjaGU6
IDIwNDggS0IgZW5hYmxlZA0KU1JJTzE6IGRpc2FibGVkDQpTUklPMjogZGlzYWJsZWQNCk5BTkQ6
ICAxMDI0IE1pQg0KTU1DOiAgRlNMX1NESEM6IDANCkVFUFJPTTogSW52YWxpZCBJRCAoZmYgZmYg
ZmYgZmYpDQpQQ0llMTogUm9vdCBDb21wbGV4LCB4MiwgcmVncyBAIDB4ZmUyMDAwMDANCiAgMDE6
MDAuMCAgICAgLSA4MDg2OjEwNWUgLSBOZXR3b3JrIGNvbnRyb2xsZXINCiAgMDE6MDAuMSAgICAg
LSA4MDg2OjEwNWUgLSBOZXR3b3JrIGNvbnRyb2xsZXINClBDSWUxOiBCdXMgMDAgLSAwMQ0KUENJ
ZTI6IGRpc2FibGVkDQpQQ0llMzogUm9vdCBDb21wbGV4LCBubyBsaW5rLCByZWdzIEAgMHhmZTIw
MjAwMA0KUENJZTM6IEJ1cyAwMiAtIDAyDQpQQ0llNDogZGlzYWJsZWQNCkluOiAgICBzZXJpYWwN
Ck91dDogICBzZXJpYWwNCkVycjogICBzZXJpYWwNCk5ldDogICBJbml0aWFsaXppbmcgRm1hbg0K
Rm1hbjE6IFVwbG9hZGluZyBtaWNyb2NvZGUgdmVyc2lvbiAxMDYuMS42DQpQSFkgcmVzZXQgdGlt
ZWQgb3V0DQpQSFkgcmVzZXQgdGltZWQgb3V0DQpQSFkgcmVzZXQgdGltZWQgb3V0DQpQSFkgcmVz
ZXQgdGltZWQgb3V0DQplMTAwMDogMDA6MTU6MTc6MTY6Y2U6YjgNCiAgICAgICBlMTAwMDogMDA6
MTU6MTc6MTY6Y2U6YjkNCiAgICAgICBGTTFARFRTRUMxLCBGTTFARFRTRUMyLCBGTTFARFRTRUMz
LCBGTTFARFRTRUM0IFtQUklNRV0sIEZNMUBEVFNFQzUsIEZNMUBUR0VDMSwgZTEwMDAjMA0KV2Fy
bmluZzogZTEwMDAjMCBNQUMgYWRkcmVzc2VzIGRvbid0IG1hdGNoOg0KQWRkcmVzcyBpbiBTUk9N
IGlzICAgICAgICAgMDA6MTU6MTc6MTY6Y2U6YjgNCkFkZHJlc3MgaW4gZW52aXJvbm1lbnQgaXMg
IDAwOjFiOjIxOjY4OjVlOmQ0DQosIGUxMDAwIzENCldhcm5pbmc6IGUxMDAwIzEgdXNpbmcgTUFD
IGFkZHJlc3MgZnJvbSBuZXQgZGV2aWNlDQoNCj0+DQo=

Re: SATA FSL and upstreaming

[Benjamin Herrenschmidt]

On Thu, 2013-05-16 at 07:01 +0000, Zang Roy-R61911 wrote:

> I just tried your RCW. one e1000 card works in slot7.
> we may need to check others ...

Tried 4 and 7 ...

Note that this *used* to work. Last year I had this machine up with 2
cards doing things. Not sure what changed, it's possible that the DIP
got inadvertently changed. Or somebody stole a jumper from it in the
lab :-)

> U-Boot 2013.01-00078-g2741c99 (May 03 2013 - 00:20:41)
> 
> CPU0:  P5020E, Version: 2.0, (0x82280020)
> Core:  E5500, Version: 1.2, (0x80240012)
> 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
> Reset Configuration Word (RCW):
>        00000000: 0c540000 00000000 1e120000 00000000
>        00000010: d8984a01 03002000 de800000 41000000
>        00000020: 00000000 00000000 00000000 10070000
>        00000030: 00000000 00000000 00000000 00000000

My RCW is identical

> Board: P5020DS, Sys ID: 0x1c, Sys Ver: 0x02, FPGA Ver: 0x04, vBank: 4

Mine is:
Board: P5020DS, Sys ID: 0x1c, Sys Ver: 0x12, FPGA Ver: 0x05, vBank: 4                                                        

> SERDES Reference Clocks: Bank1=100Mhz Bank2=125Mhz Bank3=125Mhz 

Same.

> 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: Invalid ID (ff ff ff ff)
> PCIe1: Root Complex, x2, regs @ 0xfe200000
>   01:00.0     - 8086:105e - Network controller
>   01:00.1     - 8086:105e - Network controller
> PCIe1: Bus 00 - 01
> PCIe2: disabled
> PCIe3: Root Complex, no link, regs @ 0xfe202000
> PCIe3: Bus 02 - 02
> PCIe4: disabled

And I never see anything here anymore...

> In:    serial
> Out:   serial
> Err:   serial
> Net:   Initializing Fman
> Fman1: Uploading microcode version 106.1.6
> PHY reset timed out
> PHY reset timed out
> PHY reset timed out
> PHY reset timed out
> e1000: 00:15:17:16:ce:b8
>        e1000: 00:15:17:16:ce:b9
>        FM1@DTSEC1, FM1@DTSEC2, FM1@DTSEC3, FM1@DTSEC4 [PRIME], FM1@DTSEC5, FM1@TGEC1, e1000#0
> Warning: e1000#0 MAC addresses don't match:
> Address in SROM is         00:15:17:16:ce:b8
> Address in environment is  00:1b:21:68:5e:d4
> , e1000#1
> Warning: e1000#1 using MAC address from net device
> 
> =>

RE: SATA FSL and upstreaming

[Bhushan Bharat-R65777]

QmVuLCBXaGljaCBTREsgeW91IGFyZSB1c2luZz8NCg0KLUJoYXJhdA0KDQo+IC0tLS0tT3JpZ2lu
YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJlbmphbWluIEhlcnJlbnNjaG1pZHQgW21haWx0bzpi
ZW5oQGtlcm5lbC5jcmFzaGluZy5vcmddDQo+IFNlbnQ6IFRodXJzZGF5LCBNYXkgMTYsIDIwMTMg
MTI6MzYgUE0NCj4gVG86IFphbmcgUm95LVI2MTkxMQ0KPiBDYzogQmh1c2hhbiBCaGFyYXQtUjY1
Nzc3OyB0aWVqdW4uY2hlbjsgTGl1IFFpYW5nLUIzMjYxNjsgRmxlbWluZyBBbmR5LUFGTEVNSU5H
Ow0KPiBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsgWGllIFNoYW9odWktQjIxOTg5DQo+
IFN1YmplY3Q6IFJlOiBTQVRBIEZTTCBhbmQgdXBzdHJlYW1pbmcNCj4gDQo+IE9uIFRodSwgMjAx
My0wNS0xNiBhdCAwNzowMSArMDAwMCwgWmFuZyBSb3ktUjYxOTExIHdyb3RlOg0KPiANCj4gPiBJ
IGp1c3QgdHJpZWQgeW91ciBSQ1cuIG9uZSBlMTAwMCBjYXJkIHdvcmtzIGluIHNsb3Q3Lg0KPiA+
IHdlIG1heSBuZWVkIHRvIGNoZWNrIG90aGVycyAuLi4NCj4gDQo+IFRyaWVkIDQgYW5kIDcgLi4u
DQo+IA0KPiBOb3RlIHRoYXQgdGhpcyAqdXNlZCogdG8gd29yay4gTGFzdCB5ZWFyIEkgaGFkIHRo
aXMgbWFjaGluZSB1cCB3aXRoIDIgY2FyZHMNCj4gZG9pbmcgdGhpbmdzLiBOb3Qgc3VyZSB3aGF0
IGNoYW5nZWQsIGl0J3MgcG9zc2libGUgdGhhdCB0aGUgRElQIGdvdA0KPiBpbmFkdmVydGVudGx5
IGNoYW5nZWQuIE9yIHNvbWVib2R5IHN0b2xlIGEganVtcGVyIGZyb20gaXQgaW4gdGhlIGxhYiA6
LSkNCj4gDQo+ID4gVS1Cb290IDIwMTMuMDEtMDAwNzgtZzI3NDFjOTkgKE1heSAwMyAyMDEzIC0g
MDA6MjA6NDEpDQo+ID4NCj4gPiBDUFUwOiAgUDUwMjBFLCBWZXJzaW9uOiAyLjAsICgweDgyMjgw
MDIwKQ0KPiA+IENvcmU6ICBFNTUwMCwgVmVyc2lvbjogMS4yLCAoMHg4MDI0MDAxMikgQ2xvY2sg
Q29uZmlndXJhdGlvbjoNCj4gPiAgICAgICAgQ1BVMDoyMDAwIE1IeiwgQ1BVMToyMDAwIE1IeiwN
Cj4gPiAgICAgICAgQ0NCOjgwMCAgTUh6LA0KPiA+ICAgICAgICBERFI6NjY2LjY2NyBNSHogKDEz
MzMuMzMzIE1UL3MgZGF0YSByYXRlKSAoQXN5bmNocm9ub3VzKSwgTEJDOjEwMCAgTUh6DQo+ID4g
ICAgICAgIEZNQU4xOiA2MDAgTUh6DQo+ID4gICAgICAgIFFNQU46ICA0MDAgTUh6DQo+ID4gICAg
ICAgIFBNRTogICA0MDAgTUh6DQo+ID4gTDE6ICAgIEQtY2FjaGUgMzIga0IgZW5hYmxlZA0KPiA+
ICAgICAgICBJLWNhY2hlIDMyIGtCIGVuYWJsZWQNCj4gPiBSZXNldCBDb25maWd1cmF0aW9uIFdv
cmQgKFJDVyk6DQo+ID4gICAgICAgIDAwMDAwMDAwOiAwYzU0MDAwMCAwMDAwMDAwMCAxZTEyMDAw
MCAwMDAwMDAwMA0KPiA+ICAgICAgICAwMDAwMDAxMDogZDg5ODRhMDEgMDMwMDIwMDAgZGU4MDAw
MDAgNDEwMDAwMDANCj4gPiAgICAgICAgMDAwMDAwMjA6IDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAw
MDAwIDEwMDcwMDAwDQo+ID4gICAgICAgIDAwMDAwMDMwOiAwMDAwMDAwMCAwMDAwMDAwMCAwMDAw
MDAwMCAwMDAwMDAwMA0KPiANCj4gTXkgUkNXIGlzIGlkZW50aWNhbA0KPiANCj4gPiBCb2FyZDog
UDUwMjBEUywgU3lzIElEOiAweDFjLCBTeXMgVmVyOiAweDAyLCBGUEdBIFZlcjogMHgwNCwgdkJh
bms6IDQNCj4gDQo+IE1pbmUgaXM6DQo+IEJvYXJkOiBQNTAyMERTLCBTeXMgSUQ6IDB4MWMsIFN5
cyBWZXI6IDB4MTIsIEZQR0EgVmVyOiAweDA1LCB2QmFuazogNA0KPiANCj4gPiBTRVJERVMgUmVm
ZXJlbmNlIENsb2NrczogQmFuazE9MTAwTWh6IEJhbmsyPTEyNU1oeiBCYW5rMz0xMjVNaHoNCj4g
DQo+IFNhbWUuDQo+IA0KPiA+IEkyQzogICByZWFkeQ0KPiA+IFNQSTogICByZWFkeQ0KPiA+IERS
QU06ICBJbml0aWFsaXppbmcuLi4udXNpbmcgU1BEDQo+ID4gRGV0ZWN0ZWQgVURJTU0gaS1ESU1N
DQo+ID4gRGV0ZWN0ZWQgVURJTU0gaS1ESU1NDQo+ID4gMiBHaUIgbGVmdCB1bm1hcHBlZA0KPiA+
IDQgR2lCIChERFIzLCA2NC1iaXQsIENMPTksIEVDQyBvbikNCj4gPiAgICAgICAgRERSIENvbnRy
b2xsZXIgSW50ZXJsZWF2aW5nIE1vZGU6IGNhY2hlIGxpbmUNCj4gPiAgICAgICAgRERSIENoaXAt
U2VsZWN0IEludGVybGVhdmluZyBNb2RlOiBDUzArQ1MxIFRlc3RpbmcgMHgwMDAwMDAwMCAtDQo+
ID4gMHg3ZmZmZmZmZiBUZXN0aW5nIDB4ODAwMDAwMDAgLSAweGZmZmZmZmZmIFJlbWFwIEREUiAy
IEdpQiBsZWZ0DQo+ID4gdW5tYXBwZWQNCj4gPg0KPiA+IFBPU1QgbWVtb3J5IFBBU1NFRA0KPiA+
IEZsYXNoOiAxMjggTWlCDQo+ID4gTDI6ICAgIDUxMiBLQiBlbmFibGVkDQo+ID4gQ29yZW5ldCBQ
bGF0Zm9ybSBDYWNoZTogMjA0OCBLQiBlbmFibGVkDQo+ID4gU1JJTzE6IGRpc2FibGVkDQo+ID4g
U1JJTzI6IGRpc2FibGVkDQo+ID4gTkFORDogIDEwMjQgTWlCDQo+ID4gTU1DOiAgRlNMX1NESEM6
IDANCj4gPiBFRVBST006IEludmFsaWQgSUQgKGZmIGZmIGZmIGZmKQ0KPiA+IFBDSWUxOiBSb290
IENvbXBsZXgsIHgyLCByZWdzIEAgMHhmZTIwMDAwMA0KPiA+ICAgMDE6MDAuMCAgICAgLSA4MDg2
OjEwNWUgLSBOZXR3b3JrIGNvbnRyb2xsZXINCj4gPiAgIDAxOjAwLjEgICAgIC0gODA4NjoxMDVl
IC0gTmV0d29yayBjb250cm9sbGVyDQo+ID4gUENJZTE6IEJ1cyAwMCAtIDAxDQo+ID4gUENJZTI6
IGRpc2FibGVkDQo+ID4gUENJZTM6IFJvb3QgQ29tcGxleCwgbm8gbGluaywgcmVncyBAIDB4ZmUy
MDIwMDANCj4gPiBQQ0llMzogQnVzIDAyIC0gMDINCj4gPiBQQ0llNDogZGlzYWJsZWQNCj4gDQo+
IEFuZCBJIG5ldmVyIHNlZSBhbnl0aGluZyBoZXJlIGFueW1vcmUuLi4NCj4gDQo+ID4gSW46ICAg
IHNlcmlhbA0KPiA+IE91dDogICBzZXJpYWwNCj4gPiBFcnI6ICAgc2VyaWFsDQo+ID4gTmV0OiAg
IEluaXRpYWxpemluZyBGbWFuDQo+ID4gRm1hbjE6IFVwbG9hZGluZyBtaWNyb2NvZGUgdmVyc2lv
biAxMDYuMS42IFBIWSByZXNldCB0aW1lZCBvdXQgUEhZDQo+ID4gcmVzZXQgdGltZWQgb3V0IFBI
WSByZXNldCB0aW1lZCBvdXQgUEhZIHJlc2V0IHRpbWVkIG91dA0KPiA+IGUxMDAwOiAwMDoxNTox
NzoxNjpjZTpiOA0KPiA+ICAgICAgICBlMTAwMDogMDA6MTU6MTc6MTY6Y2U6YjkNCj4gPiAgICAg
ICAgRk0xQERUU0VDMSwgRk0xQERUU0VDMiwgRk0xQERUU0VDMywgRk0xQERUU0VDNCBbUFJJTUVd
LA0KPiA+IEZNMUBEVFNFQzUsIEZNMUBUR0VDMSwgZTEwMDAjMA0KPiA+IFdhcm5pbmc6IGUxMDAw
IzAgTUFDIGFkZHJlc3NlcyBkb24ndCBtYXRjaDoNCj4gPiBBZGRyZXNzIGluIFNST00gaXMgICAg
ICAgICAwMDoxNToxNzoxNjpjZTpiOA0KPiA+IEFkZHJlc3MgaW4gZW52aXJvbm1lbnQgaXMgIDAw
OjFiOjIxOjY4OjVlOmQ0ICwgZTEwMDAjMQ0KPiA+IFdhcm5pbmc6IGUxMDAwIzEgdXNpbmcgTUFD
IGFkZHJlc3MgZnJvbSBuZXQgZGV2aWNlDQo+ID4NCj4gPiA9Pg0KPiANCj4gDQoNCg==

Re: SATA FSL and upstreaming

[Benjamin Herrenschmidt]

On Thu, 2013-05-16 at 07:13 +0000, Bhushan Bharat-R65777 wrote:
> Ben, Which SDK you are using?

QorIQ-SDK-V1.3.2-PPC64E5500-20130325-yocto.iso

Cheers,
Ben.

RE: SATA FSL and upstreaming

[Xie Shaohui-B21989]

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCZW5qYW1pbiBIZXJyZW5zY2ht
aWR0IFttYWlsdG86YmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnXQ0KPiBTZW50OiBUaHVyc2RheSwg
TWF5IDE2LCAyMDEzIDM6MDYgUE0NCj4gVG86IFphbmcgUm95LVI2MTkxMQ0KPiBDYzogQmh1c2hh
biBCaGFyYXQtUjY1Nzc3OyB0aWVqdW4uY2hlbjsgTGl1IFFpYW5nLUIzMjYxNjsgRmxlbWluZyBB
bmR5LQ0KPiBBRkxFTUlORzsgbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7IFhpZSBTaGFv
aHVpLUIyMTk4OQ0KPiBTdWJqZWN0OiBSZTogU0FUQSBGU0wgYW5kIHVwc3RyZWFtaW5nDQo+IA0K
PiBPbiBUaHUsIDIwMTMtMDUtMTYgYXQgMDc6MDEgKzAwMDAsIFphbmcgUm95LVI2MTkxMSB3cm90
ZToNCj4gDQo+ID4gSSBqdXN0IHRyaWVkIHlvdXIgUkNXLiBvbmUgZTEwMDAgY2FyZCB3b3JrcyBp
biBzbG90Ny4NCj4gPiB3ZSBtYXkgbmVlZCB0byBjaGVjayBvdGhlcnMgLi4uDQo+IA0KPiBUcmll
ZCA0IGFuZCA3IC4uLg0KPiANCj4gTm90ZSB0aGF0IHRoaXMgKnVzZWQqIHRvIHdvcmsuIExhc3Qg
eWVhciBJIGhhZCB0aGlzIG1hY2hpbmUgdXAgd2l0aCAyDQo+IGNhcmRzIGRvaW5nIHRoaW5ncy4g
Tm90IHN1cmUgd2hhdCBjaGFuZ2VkLCBpdCdzIHBvc3NpYmxlIHRoYXQgdGhlIERJUCBnb3QNCj4g
aW5hZHZlcnRlbnRseSBjaGFuZ2VkLiANCltTLkhdIFBsZWFzZSBjaGVjayB0aGUgU1cyWzE6NF0s
IHNob3VsZCBiZTogb2ZmIG9mZiBvbiBvZmYNCg0KW1MuSF0gQmVzdCBSZWdhcmRzLCANClNoYW9o
dWkgWGllDQo=

RE: SATA FSL and upstreaming

[Bhushan Bharat-R65777]

QmVuLA0KDQpJZiB5b3UgYXJlIHVzaW5nIFNESzEuMyBhbmQgbGF0ZXIgdGhlbiB0aGUgc3VwcG9y
dCBmb3IgcDUwMjBkcyByZXYgMS4wIHN1cHBvcnQgaXMgcmVtb3ZlZC4NClNvIHVzZSBlYXJsaWVy
IHNkayBmb3IgcmV2IDEuMCBvciB3YWl0IGZvciByZXYyLjAgOikNCg0KVGhhbmtzDQotQmhhcmF0
DQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCZW5qYW1pbiBIZXJy
ZW5zY2htaWR0IFttYWlsdG86YmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnXQ0KPiBTZW50OiBUaHVy
c2RheSwgTWF5IDE2LCAyMDEzIDEyOjM2IFBNDQo+IFRvOiBaYW5nIFJveS1SNjE5MTENCj4gQ2M6
IEJodXNoYW4gQmhhcmF0LVI2NTc3NzsgdGllanVuLmNoZW47IExpdSBRaWFuZy1CMzI2MTY7IEZs
ZW1pbmcgQW5keS1BRkxFTUlORzsNCj4gbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7IFhp
ZSBTaGFvaHVpLUIyMTk4OQ0KPiBTdWJqZWN0OiBSZTogU0FUQSBGU0wgYW5kIHVwc3RyZWFtaW5n
DQo+IA0KPiBPbiBUaHUsIDIwMTMtMDUtMTYgYXQgMDc6MDEgKzAwMDAsIFphbmcgUm95LVI2MTkx
MSB3cm90ZToNCj4gDQo+ID4gSSBqdXN0IHRyaWVkIHlvdXIgUkNXLiBvbmUgZTEwMDAgY2FyZCB3
b3JrcyBpbiBzbG90Ny4NCj4gPiB3ZSBtYXkgbmVlZCB0byBjaGVjayBvdGhlcnMgLi4uDQo+IA0K
PiBUcmllZCA0IGFuZCA3IC4uLg0KPiANCj4gTm90ZSB0aGF0IHRoaXMgKnVzZWQqIHRvIHdvcmsu
IExhc3QgeWVhciBJIGhhZCB0aGlzIG1hY2hpbmUgdXAgd2l0aCAyIGNhcmRzDQo+IGRvaW5nIHRo
aW5ncy4gTm90IHN1cmUgd2hhdCBjaGFuZ2VkLCBpdCdzIHBvc3NpYmxlIHRoYXQgdGhlIERJUCBn
b3QNCj4gaW5hZHZlcnRlbnRseSBjaGFuZ2VkLiBPciBzb21lYm9keSBzdG9sZSBhIGp1bXBlciBm
cm9tIGl0IGluIHRoZSBsYWIgOi0pDQo+IA0KPiA+IFUtQm9vdCAyMDEzLjAxLTAwMDc4LWcyNzQx
Yzk5IChNYXkgMDMgMjAxMyAtIDAwOjIwOjQxKQ0KPiA+DQo+ID4gQ1BVMDogIFA1MDIwRSwgVmVy
c2lvbjogMi4wLCAoMHg4MjI4MDAyMCkNCj4gPiBDb3JlOiAgRTU1MDAsIFZlcnNpb246IDEuMiwg
KDB4ODAyNDAwMTIpIENsb2NrIENvbmZpZ3VyYXRpb246DQo+ID4gICAgICAgIENQVTA6MjAwMCBN
SHosIENQVTE6MjAwMCBNSHosDQo+ID4gICAgICAgIENDQjo4MDAgIE1IeiwNCj4gPiAgICAgICAg
RERSOjY2Ni42NjcgTUh6ICgxMzMzLjMzMyBNVC9zIGRhdGEgcmF0ZSkgKEFzeW5jaHJvbm91cyks
IExCQzoxMDAgIE1Ieg0KPiA+ICAgICAgICBGTUFOMTogNjAwIE1Ieg0KPiA+ICAgICAgICBRTUFO
OiAgNDAwIE1Ieg0KPiA+ICAgICAgICBQTUU6ICAgNDAwIE1Ieg0KPiA+IEwxOiAgICBELWNhY2hl
IDMyIGtCIGVuYWJsZWQNCj4gPiAgICAgICAgSS1jYWNoZSAzMiBrQiBlbmFibGVkDQo+ID4gUmVz
ZXQgQ29uZmlndXJhdGlvbiBXb3JkIChSQ1cpOg0KPiA+ICAgICAgICAwMDAwMDAwMDogMGM1NDAw
MDAgMDAwMDAwMDAgMWUxMjAwMDAgMDAwMDAwMDANCj4gPiAgICAgICAgMDAwMDAwMTA6IGQ4OTg0
YTAxIDAzMDAyMDAwIGRlODAwMDAwIDQxMDAwMDAwDQo+ID4gICAgICAgIDAwMDAwMDIwOiAwMDAw
MDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAxMDA3MDAwMA0KPiA+ICAgICAgICAwMDAwMDAzMDogMDAw
MDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDANCj4gDQo+IE15IFJDVyBpcyBpZGVudGlj
YWwNCj4gDQo+ID4gQm9hcmQ6IFA1MDIwRFMsIFN5cyBJRDogMHgxYywgU3lzIFZlcjogMHgwMiwg
RlBHQSBWZXI6IDB4MDQsIHZCYW5rOiA0DQo+IA0KPiBNaW5lIGlzOg0KPiBCb2FyZDogUDUwMjBE
UywgU3lzIElEOiAweDFjLCBTeXMgVmVyOiAweDEyLCBGUEdBIFZlcjogMHgwNSwgdkJhbms6IDQN
Cj4gDQo+ID4gU0VSREVTIFJlZmVyZW5jZSBDbG9ja3M6IEJhbmsxPTEwME1oeiBCYW5rMj0xMjVN
aHogQmFuazM9MTI1TWh6DQo+IA0KPiBTYW1lLg0KPiANCj4gPiBJMkM6ICAgcmVhZHkNCj4gPiBT
UEk6ICAgcmVhZHkNCj4gPiBEUkFNOiAgSW5pdGlhbGl6aW5nLi4uLnVzaW5nIFNQRA0KPiA+IERl
dGVjdGVkIFVESU1NIGktRElNTQ0KPiA+IERldGVjdGVkIFVESU1NIGktRElNTQ0KPiA+IDIgR2lC
IGxlZnQgdW5tYXBwZWQNCj4gPiA0IEdpQiAoRERSMywgNjQtYml0LCBDTD05LCBFQ0Mgb24pDQo+
ID4gICAgICAgIEREUiBDb250cm9sbGVyIEludGVybGVhdmluZyBNb2RlOiBjYWNoZSBsaW5lDQo+
ID4gICAgICAgIEREUiBDaGlwLVNlbGVjdCBJbnRlcmxlYXZpbmcgTW9kZTogQ1MwK0NTMSBUZXN0
aW5nIDB4MDAwMDAwMDAgLQ0KPiA+IDB4N2ZmZmZmZmYgVGVzdGluZyAweDgwMDAwMDAwIC0gMHhm
ZmZmZmZmZiBSZW1hcCBERFIgMiBHaUIgbGVmdA0KPiA+IHVubWFwcGVkDQo+ID4NCj4gPiBQT1NU
IG1lbW9yeSBQQVNTRUQNCj4gPiBGbGFzaDogMTI4IE1pQg0KPiA+IEwyOiAgICA1MTIgS0IgZW5h
YmxlZA0KPiA+IENvcmVuZXQgUGxhdGZvcm0gQ2FjaGU6IDIwNDggS0IgZW5hYmxlZA0KPiA+IFNS
SU8xOiBkaXNhYmxlZA0KPiA+IFNSSU8yOiBkaXNhYmxlZA0KPiA+IE5BTkQ6ICAxMDI0IE1pQg0K
PiA+IE1NQzogIEZTTF9TREhDOiAwDQo+ID4gRUVQUk9NOiBJbnZhbGlkIElEIChmZiBmZiBmZiBm
ZikNCj4gPiBQQ0llMTogUm9vdCBDb21wbGV4LCB4MiwgcmVncyBAIDB4ZmUyMDAwMDANCj4gPiAg
IDAxOjAwLjAgICAgIC0gODA4NjoxMDVlIC0gTmV0d29yayBjb250cm9sbGVyDQo+ID4gICAwMTow
MC4xICAgICAtIDgwODY6MTA1ZSAtIE5ldHdvcmsgY29udHJvbGxlcg0KPiA+IFBDSWUxOiBCdXMg
MDAgLSAwMQ0KPiA+IFBDSWUyOiBkaXNhYmxlZA0KPiA+IFBDSWUzOiBSb290IENvbXBsZXgsIG5v
IGxpbmssIHJlZ3MgQCAweGZlMjAyMDAwDQo+ID4gUENJZTM6IEJ1cyAwMiAtIDAyDQo+ID4gUENJ
ZTQ6IGRpc2FibGVkDQo+IA0KPiBBbmQgSSBuZXZlciBzZWUgYW55dGhpbmcgaGVyZSBhbnltb3Jl
Li4uDQo+IA0KPiA+IEluOiAgICBzZXJpYWwNCj4gPiBPdXQ6ICAgc2VyaWFsDQo+ID4gRXJyOiAg
IHNlcmlhbA0KPiA+IE5ldDogICBJbml0aWFsaXppbmcgRm1hbg0KPiA+IEZtYW4xOiBVcGxvYWRp
bmcgbWljcm9jb2RlIHZlcnNpb24gMTA2LjEuNiBQSFkgcmVzZXQgdGltZWQgb3V0IFBIWQ0KPiA+
IHJlc2V0IHRpbWVkIG91dCBQSFkgcmVzZXQgdGltZWQgb3V0IFBIWSByZXNldCB0aW1lZCBvdXQN
Cj4gPiBlMTAwMDogMDA6MTU6MTc6MTY6Y2U6YjgNCj4gPiAgICAgICAgZTEwMDA6IDAwOjE1OjE3
OjE2OmNlOmI5DQo+ID4gICAgICAgIEZNMUBEVFNFQzEsIEZNMUBEVFNFQzIsIEZNMUBEVFNFQzMs
IEZNMUBEVFNFQzQgW1BSSU1FXSwNCj4gPiBGTTFARFRTRUM1LCBGTTFAVEdFQzEsIGUxMDAwIzAN
Cj4gPiBXYXJuaW5nOiBlMTAwMCMwIE1BQyBhZGRyZXNzZXMgZG9uJ3QgbWF0Y2g6DQo+ID4gQWRk
cmVzcyBpbiBTUk9NIGlzICAgICAgICAgMDA6MTU6MTc6MTY6Y2U6YjgNCj4gPiBBZGRyZXNzIGlu
IGVudmlyb25tZW50IGlzICAwMDoxYjoyMTo2ODo1ZTpkNCAsIGUxMDAwIzENCj4gPiBXYXJuaW5n
OiBlMTAwMCMxIHVzaW5nIE1BQyBhZGRyZXNzIGZyb20gbmV0IGRldmljZQ0KPiA+DQo+ID4gPT4N
Cj4gDQo+IA0KDQo=

Re: SATA FSL and upstreaming

[Benjamin Herrenschmidt]

Ok, so I found this one on the SDK ISO: rcw_15g_2000mhz.bin

I flashed that, did pix altbank, I'm now booted from Bank 4 ... and PCIe
is still showing nothing. I have cards in slots 4 and 7 (assuming that's
the right numbering, ie, 7 is the top one).

Are we sure we don't have a problem with some DIP ? I saw some of them
control some SERDES stuff (SW5 iirc)

Cheers,
Ben.

RE: SATA FSL and upstreaming

[Zang Roy-R61911]

> -----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 2:59 PM
> To: Zang Roy-R61911
> Cc: Xie Shaohui-B21989; Liu Qiang-B32616; tiejun.chen; Fleming Andy-
> AFLEMING; Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org
> Subject: Re: SATA FSL and upstreaming
>=20
> Ok, so I found this one on the SDK ISO: rcw_15g_2000mhz.bin
>=20
> I flashed that, did pix altbank, I'm now booted from Bank 4 ... and PCIe
> is still showing nothing. I have cards in slots 4 and 7 (assuming that's
> the right numbering, ie, 7 is the top one).
Right.
>=20
> Are we sure we don't have a problem with some DIP ? I saw some of them
> control some SERDES stuff (SW5 iirc)
Your serdes1 clock is 100MHz,which is correct.
Slot7 (PCIe1) does not need extra DIP to make it work.
Maybe you also need to update the U-boot.
Roy

Re: SATA FSL and upstreaming

[Benjamin Herrenschmidt]

On Thu, 2013-05-16 at 06:48 +0000, Bhushan Bharat-R65777 wrote:

> 1) Load RCW as Tiejun on some address in DDR.
> 
> 2) Brun RCW at 0xec000000:
> protect off 0xec000000 +$filesize; erase 0xec000000 +$filesize; cp.b 0x1000000 0xec000000 $filesize

Done.

> 3) run " pix altbak" command
> 
> 4) check you are on bank4

It stays on bank 0

Also, before I flashed the rcw, I tried messing with SW7[1:4] and got it
to book to bank 4 once (I think I changed DIP 2 or 3). Now, after the
new RCW is in, it won't boot with any other setting than bank 0 however.

Cheers,
Ben.

> 5) If you are luckier then networking will work for you.
> 
> Thanks
> -Bharat
> 
> > 
> > Tiejun
> 

Re: SATA FSL and upstreaming

[Timur Tabi]

On Thu, May 16, 2013 at 1:52 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
>> 3) run " pix altbak" command
>>
>> 4) check you are on bank4
>
> It stays on bank 0

pix altbank

Re: SATA FSL and upstreaming

[Benjamin Herrenschmidt]

On Thu, 2013-05-16 at 09:56 -0500, Timur Tabi wrote:
> On Thu, May 16, 2013 at 1:52 AM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> >> 3) run " pix altbak" command
> >>
> >> 4) check you are on bank4
> >
> > It stays on bank 0
> 
> pix altbank

So I got the rev2 chip today, put it in, and PCI-E is still not getting
a link. Since the LEDs of the e1000 aren't coming up at all, I *suspect*
the slots are getting no power.

Is there a power control somewhere ? Maybe some DIP or jumpers that
might have gone off ?

Cheers,
Ben.

Re: SATA FSL and upstreaming

[Benjamin Herrenschmidt]

On Fri, 2013-06-07 at 13:52 +1000, Benjamin Herrenschmidt wrote:

> So I got the rev2 chip today, put it in, and PCI-E is still not getting
> a link. Since the LEDs of the e1000 aren't coming up at all, I *suspect*
> the slots are getting no power.
> 
> Is there a power control somewhere ? Maybe some DIP or jumpers that
> might have gone off ?

Forget it, reset all the jumpers to the default setup (found the doc !)
and they come up now in slot 4 and 7. It also looks like uBoot now
has an e1000 driver so I don't have to use fman (for which I believe
there is still no upstream driver right ?)

BTW. Is that normal during boot ?

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

Cheers,
Ben.

RE: SATA FSL and upstreaming

[Zang Roy-R61911]

> -----Original Message-----
> From: Linuxppc-dev [mailto:linuxppc-dev-bounces+tie-
> fei.zang=3Dfreescale.com@lists.ozlabs.org] On Behalf Of Benjamin
> Herrenschmidt
> Sent: Friday, June 07, 2013 12:40 PM
> To: Timur Tabi
> Cc: Xie Shaohui-B21989; Liu Qiang-B32616; Zang Roy-R61911; tiejun.chen;
> Fleming Andy-AFLEMING; Bhushan Bharat-R65777; linuxppc-
> dev@lists.ozlabs.org
> Subject: Re: SATA FSL and upstreaming
>=20
> On Fri, 2013-06-07 at 13:52 +1000, Benjamin Herrenschmidt wrote:
>=20
> > So I got the rev2 chip today, put it in, and PCI-E is still not
> > getting a link. Since the LEDs of the e1000 aren't coming up at all, I
> > *suspect* the slots are getting no power.
> >
> > Is there a power control somewhere ? Maybe some DIP or jumpers that
> > might have gone off ?
>=20
> Forget it, reset all the jumpers to the default setup (found the doc !)
> and they come up now in slot 4 and 7. It also looks like uBoot now has an
> e1000 driver so I don't have to use fman (for which I believe there is
> still no upstream driver right ?)
fman in u-boot has been up streamed.  It should work.
>=20
> BTW. Is that normal during boot ?
>=20
> 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
You can ignore the timeout.=20
Do you plug other card (for example SGMII card) on the board?
u-boot detects some card in the slot and tries to init the PHY but fails.
Roy

Re: SATA FSL and upstreaming

[Benjamin Herrenschmidt]

On Fri, 2013-06-07 at 04:45 +0000, Zang Roy-R61911 wrote:
> 
> > Forget it, reset all the jumpers to the default setup (found the doc !)
> > and they come up now in slot 4 and 7. It also looks like uBoot now has an
> > e1000 driver so I don't have to use fman (for which I believe there is
> > still no upstream driver right ?)

> fman in u-boot has been up streamed.  It should work.

I don't care much about u-boot :-) It's the kernel that matters to me.

> > 
> > BTW. Is that normal during boot ?
> > 
> > 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
> You can ignore the timeout. 
> Do you plug other card (for example SGMII card) on the board?

No, only PCIe in slot 4 and 7.

> u-boot detects some card in the slot and tries to init the PHY but fails.

Cheers,
Ben.

RE: SATA FSL and upstreaming

[Zang Roy-R61911]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmVuamFtaW4gSGVycmVu
c2NobWlkdCBbbWFpbHRvOmJlbmhAa2VybmVsLmNyYXNoaW5nLm9yZ10NCj4gU2VudDogRnJpZGF5
LCBKdW5lIDA3LCAyMDEzIDEyOjQ3IFBNDQo+IFRvOiBaYW5nIFJveS1SNjE5MTENCj4gQ2M6IFRp
bXVyIFRhYmk7IFhpZSBTaGFvaHVpLUIyMTk4OTsgTGl1IFFpYW5nLUIzMjYxNjsgdGllanVuLmNo
ZW47DQo+IEZsZW1pbmcgQW5keS1BRkxFTUlORzsgQmh1c2hhbiBCaGFyYXQtUjY1Nzc3OyBsaW51
eHBwYy0NCj4gZGV2QGxpc3RzLm96bGFicy5vcmcNCj4gU3ViamVjdDogUmU6IFNBVEEgRlNMIGFu
ZCB1cHN0cmVhbWluZw0KPiANCj4gT24gRnJpLCAyMDEzLTA2LTA3IGF0IDA0OjQ1ICswMDAwLCBa
YW5nIFJveS1SNjE5MTEgd3JvdGU6DQo+ID4NCj4gPiA+IEZvcmdldCBpdCwgcmVzZXQgYWxsIHRo
ZSBqdW1wZXJzIHRvIHRoZSBkZWZhdWx0IHNldHVwIChmb3VuZCB0aGUgZG9jDQo+ID4gPiAhKSBh
bmQgdGhleSBjb21lIHVwIG5vdyBpbiBzbG90IDQgYW5kIDcuIEl0IGFsc28gbG9va3MgbGlrZSB1
Qm9vdA0KPiA+ID4gbm93IGhhcyBhbiBlMTAwMCBkcml2ZXIgc28gSSBkb24ndCBoYXZlIHRvIHVz
ZSBmbWFuIChmb3Igd2hpY2ggSQ0KPiA+ID4gYmVsaWV2ZSB0aGVyZSBpcyBzdGlsbCBubyB1cHN0
cmVhbSBkcml2ZXIgcmlnaHQgPykNCj4gDQo+ID4gZm1hbiBpbiB1LWJvb3QgaGFzIGJlZW4gdXAg
c3RyZWFtZWQuICBJdCBzaG91bGQgd29yay4NCj4gDQo+IEkgZG9uJ3QgY2FyZSBtdWNoIGFib3V0
IHUtYm9vdCA6LSkgSXQncyB0aGUga2VybmVsIHRoYXQgbWF0dGVycyB0byBtZS4NCllvdSBzaG91
bGQgbWF0dGVyIGEgd29ya2luZyBFdGhlcm5ldCBwb3J0IDotKSBpbiB1LWJvb3QuDQoNCj4gDQo+
ID4gPg0KPiA+ID4gQlRXLiBJcyB0aGF0IG5vcm1hbCBkdXJpbmcgYm9vdCA/DQo+ID4gPg0KPiA+
ID4gTmV0OiAgIEluaXRpYWxpemluZyBGbWFuDQo+ID4gPiBGbWFuMTogVXBsb2FkaW5nIG1pY3Jv
Y29kZSB2ZXJzaW9uIDEwNi4xLjcgUEhZIHJlc2V0IHRpbWVkIG91dCBQSFkNCj4gPiA+IHJlc2V0
IHRpbWVkIG91dCBQSFkgcmVzZXQgdGltZWQgb3V0IFBIWSByZXNldCB0aW1lZCBvdXQNCj4gPiBZ
b3UgY2FuIGlnbm9yZSB0aGUgdGltZW91dC4NCj4gPiBEbyB5b3UgcGx1ZyBvdGhlciBjYXJkIChm
b3IgZXhhbXBsZSBTR01JSSBjYXJkKSBvbiB0aGUgYm9hcmQ/DQo+IA0KPiBObywgb25seSBQQ0ll
IGluIHNsb3QgNCBhbmQgNy4NCkdvIGFoZWFkIC4uLg0KVW5sZXNzIHRoZXJlIGlzIGEgY29tcGxl
dGUgdS1ib290IGxvZywgSSBjYW4gY29tbWVudCBtb3JlLiBidXQgSSBkbyBub3QgdGhpbmsgaXQg
aXMgdGhlIGZvY3VzIG5vdyAuLi4NCnRoYW5rcy4NClJveQ0K

fsqrt

[Benjamin Herrenschmidt]

Another question...

Do you guys happen to have a patch to emulate fsqrt in the kernel ?

Fedora 19 seems to be using it ... among others.

Cheers,
Ben.

RE: fsqrt

[Zang Roy-R61911]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmVuamFtaW4gSGVycmVu
c2NobWlkdCBbbWFpbHRvOmJlbmhAa2VybmVsLmNyYXNoaW5nLm9yZ10NCj4gQW5vdGhlciBxdWVz
dGlvbi4uLg0KPiANCj4gRG8geW91IGd1eXMgaGFwcGVuIHRvIGhhdmUgYSBwYXRjaCB0byBlbXVs
YXRlIGZzcXJ0IGluIHRoZSBrZXJuZWwgPw0KPiANCj4gRmVkb3JhIDE5IHNlZW1zIHRvIGJlIHVz
aW5nIGl0IC4uLiBhbW9uZyBvdGhlcnMuDQpZb3UgbWVhbiB0aGlzIG9uZQ0KYXJjaC9wb3dlcnBj
L21hdGgtZW11L2ZzcXJ0LmMgPw0KWWVzLg0KUm95DQo=

Re: fsqrt

[Benjamin Herrenschmidt]

On Fri, 2013-06-07 at 07:45 +0000, Zang Roy-R61911 wrote:
> 
> > -----Original Message-----
> > From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
> > Another question...
> > 
> > Do you guys happen to have a patch to emulate fsqrt in the kernel ?
> > 
> > Fedora 19 seems to be using it ... among others.
> You mean this one
> arch/powerpc/math-emu/fsqrt.c ?

No. This is for setups that have no FPU, I don't think that will work
with an actual FPU.

fsqrt is an optional instruction in the architecture and FSL chips don't
use it. However it looks like Fedora is compiled with a toolchain that
generates it.

I've successfully launched the Fedora installer using this hack in the
kernel:

>From f75adba1ee91691d431e283184e15412114000d1 Mon Sep 17 00:00:00 2001
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Fri, 7 Jun 2013 18:42:44 +1000
Subject: [PATCH] Gross hack

---
 arch/powerpc/include/asm/ppc-opcode.h |    2 ++
 arch/powerpc/kernel/Makefile          |    4 ++-
 arch/powerpc/kernel/fsqrt-emu.c       |   44 +++++++++++++++++++++++++++++++++
 arch/powerpc/kernel/traps.c           |    7 ++++++
 4 files changed, 56 insertions(+), 1 deletion(-)
 create mode 100644 arch/powerpc/kernel/fsqrt-emu.c

diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/asm/ppc-opcode.h
index eccfc16..146c5e9 100644
--- a/arch/powerpc/include/asm/ppc-opcode.h
+++ b/arch/powerpc/include/asm/ppc-opcode.h
@@ -88,6 +88,8 @@
 #define PPC_INST_DCBA_MASK		0xfc0007fe
 #define PPC_INST_DCBAL			0x7c2005ec
 #define PPC_INST_DCBZL			0x7c2007ec
+#define PPC_INST_FSQRT			0xfc00002c
+#define PPC_INST_FSQRT_MASK		0xfc1f07fe
 #define PPC_INST_ICBT			0x7c00002c
 #define PPC_INST_ISEL			0x7c00001e
 #define PPC_INST_ISEL_MASK		0xfc00003e
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index f960a79..64c9962 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -26,6 +26,8 @@ CFLAGS_REMOVE_ftrace.o = -pg -mno-sched-epilog
 CFLAGS_REMOVE_time.o = -pg -mno-sched-epilog
 endif
 
+CFLAGS_REMOVE_fsqrt-emu.o = -msoft-float
+
 obj-y				:= cputable.o ptrace.o syscalls.o \
 				   irq.o align.o signal_32.o pmc.o vdso.o \
 				   process.o systbl.o idle.o \
@@ -34,7 +36,7 @@ obj-y				:= cputable.o ptrace.o syscalls.o \
 				   udbg.o misc.o io.o dma.o \
 				   misc_$(CONFIG_WORD_SIZE).o vdso32/
 obj-$(CONFIG_PPC64)		+= setup_64.o sys_ppc32.o \
-				   signal_64.o ptrace32.o \
+				   signal_64.o ptrace32.o fsqrt-emu.o \
 				   paca.o nvram_64.o firmware.o
 obj-$(CONFIG_HAVE_HW_BREAKPOINT)	+= hw_breakpoint.o
 obj-$(CONFIG_PPC_BOOK3S_64)	+= cpu_setup_ppc970.o cpu_setup_pa6t.o
diff --git a/arch/powerpc/kernel/fsqrt-emu.c b/arch/powerpc/kernel/fsqrt-emu.c
new file mode 100644
index 0000000..2da4f71
--- /dev/null
+++ b/arch/powerpc/kernel/fsqrt-emu.c
@@ -0,0 +1,44 @@
+#include <linux/kernel.h>
+#include <linux/preempt.h>
+#include <linux/sched.h>
+#include <asm/ptrace.h>
+#include <asm/processor.h>
+#include <asm/switch_to.h>
+
+static double crackpot_sqrt(double val)
+{
+    int i;
+    float x, y;
+    const float f = 1.5F;
+
+    x = val * 0.5F;
+    y  = val;
+    i  = * ( int * ) &y;
+    i  = 0x5f3759df - ( i >> 1 );
+    y  = * ( float * ) &i;
+    y  = y * ( f - ( x * y * y ) );
+    y  = y * ( f - ( x * y * y ) );
+    return val * y;
+}
+
+int emulate_fsqrt_inst(struct pt_regs *regs, u32 instword)
+{
+	unsigned int frt_r = (instword >> 21) & 0x1f;
+	unsigned int frb_r = (instword >> 21) & 0x1f;
+	double frt, frb;
+
+	/* XXX THIS WHOLE THING IS JUST A HACK ! */
+	preempt_disable();
+	enable_kernel_fp();
+	frb = current->thread.fpr[frb_r][0];
+	frt = crackpot_sqrt(frb);
+	current->thread.fpr[frt_r][0] = frt;
+	if (instword & 1)
+		regs->ccr &= 0xff00ffff;
+	preempt_enable();
+
+	return 0;
+}
+
+
+
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 6dfbb38..e677792 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -938,6 +938,8 @@ static int emulate_isel(struct pt_regs *regs, u32 instword)
 	return 0;
 }
 
+extern int emulate_fsqrt_inst(struct pt_regs *regs, u32 instword);
+
 #ifdef CONFIG_PPC_TRANSACTIONAL_MEM
 static inline bool tm_abort_check(struct pt_regs *regs, int cause)
 {
@@ -1018,6 +1020,11 @@ static int emulate_instruction(struct pt_regs *regs)
 		return emulate_isel(regs, instword);
 	}
 
+	if ((instword & PPC_INST_FSQRT_MASK) == PPC_INST_FSQRT) {
+		PPC_WARN_EMULATED(isel, regs);
+		return emulate_fsqrt_inst(regs, instword);
+	}
+
 #ifdef CONFIG_PPC64
 	/* Emulate the mfspr rD, DSCR. */
 	if ((((instword & PPC_INST_MFSPR_DSCR_USER_MASK) ==
-- 
1.7.10.4

Re: fsqrt

[Benjamin Herrenschmidt]

On Fri, 2013-06-07 at 18:53 +1000, Benjamin Herrenschmidt wrote:

> +
> +static double crackpot_sqrt(double val)
> +{
> +    int i;
> +    float x, y;
> +    const float f = 1.5F;
> +
> +    x = val * 0.5F;
> +    y  = val;
> +    i  = * ( int * ) &y;
> +    i  = 0x5f3759df - ( i >> 1 );
> +    y  = * ( float * ) &i;
> +    y  = y * ( f - ( x * y * y ) );
> +    y  = y * ( f - ( x * y * y ) );
> +    return val * y;
> +}
> +

For those interested, this is the Quake3 sqrt from Carmack ... there's
plenty of literature about it one or two google clicks away :-)

Cheers,
Ben.

RE: fsqrt

[David Laight]

> > +
> > +static double crackpot_sqrt(double val)
> > +{
> > +    int i;
> > +    float x, y;
> > +    const float f =3D 1.5F;
> > +
> > +    x =3D val * 0.5F;
> > +    y  =3D val;
> > +    i  =3D * ( int * ) &y;
> > +    i  =3D 0x5f3759df - ( i >> 1 );
> > +    y  =3D * ( float * ) &i;
> > +    y  =3D y * ( f - ( x * y * y ) );
> > +    y  =3D y * ( f - ( x * y * y ) );
> > +    return val * y;
> > +}
> > +
>=20
> For those interested, this is the Quake3 sqrt from Carmack ... there's
> plenty of literature about it one or two google clicks away :-)

I guess that is a rough enough approximation for graphics.

However it will be miscompiled unless i and y are put in a union.

	David

Re: fsqrt

[Benjamin Herrenschmidt]

On Fri, 2013-06-07 at 11:48 +0100, David Laight wrote:
> > For those interested, this is the Quake3 sqrt from Carmack ...
> there's
> > plenty of literature about it one or two google clicks away :-)
> 
> I guess that is a rough enough approximation for graphics.
> 
> However it will be miscompiled unless i and y are put in a union.

It won't in the kernel disables strict aliasing :-)

Anyway, that was just a hack and plenty enough to get anaconda going,
the bloody thing only uses fsqrt because it's python crappola does
something like exp(1.0) / sqrt(2.0) as part of its random number stuff.

Honestly I could have made it just return 1.0 and it would probably have
worked :-)

However, my point remains, it would be very much worthwhile for the
kernel to have some reasonable emulation of those missing instructions
(afaik only a handful) like we have for isel, popcnt* etc... especially
since distros seem to be keen on enabling the use of them in their
toolchain.

I don't personally have the bandwidth to do a clean implementation (that
handles FP exceptions, NaNs, FPSCR, etc...) but I believe it would be
valuable if somebody else did (hint hint hint :-) since without this,
Fedora ppc64 is basically going to be a non-started on those chips.

BTW. Did you guys (ie. FSL) finally add fsqrt to e6500 or it's still
out ? 

Cheers,
Ben.

Re: fsqrt

[Kumar Gala]

On Jun 7, 2013, at 7:14 AM, Benjamin Herrenschmidt wrote:

> On Fri, 2013-06-07 at 11:48 +0100, David Laight wrote:
>>> For those interested, this is the Quake3 sqrt from Carmack ...
>> there's
>>> plenty of literature about it one or two google clicks away :-)
>> 
>> I guess that is a rough enough approximation for graphics.
>> 
>> However it will be miscompiled unless i and y are put in a union.
> 
> It won't in the kernel disables strict aliasing :-)
> 
> Anyway, that was just a hack and plenty enough to get anaconda going,
> the bloody thing only uses fsqrt because it's python crappola does
> something like exp(1.0) / sqrt(2.0) as part of its random number stuff.
> 
> Honestly I could have made it just return 1.0 and it would probably have
> worked :-)
> 
> However, my point remains, it would be very much worthwhile for the
> kernel to have some reasonable emulation of those missing instructions
> (afaik only a handful) like we have for isel, popcnt* etc... especially
> since distros seem to be keen on enabling the use of them in their
> toolchain.
> 
> I don't personally have the bandwidth to do a clean implementation (that
> handles FP exceptions, NaNs, FPSCR, etc...) but I believe it would be
> valuable if somebody else did (hint hint hint :-) since without this,
> Fedora ppc64 is basically going to be a non-started on those chips.
> 
> BTW. Did you guys (ie. FSL) finally add fsqrt to e6500 or it's still
> out ? 
> 
> Cheers,
> Ben.

Pretty sure fsqrt is still out of e6500.

- k

Re: fsqrt

[Benjamin Herrenschmidt]

On Fri, 2013-06-07 at 14:19 -0500, Kumar Gala wrote:
> > I don't personally have the bandwidth to do a clean implementation (that
> > handles FP exceptions, NaNs, FPSCR, etc...) but I believe it would be
> > valuable if somebody else did (hint hint hint :-) since without this,
> > Fedora ppc64 is basically going to be a non-started on those chips.
> > 
> > BTW. Did you guys (ie. FSL) finally add fsqrt to e6500 or it's still
> > out ? 
> > 
> > Cheers,
> > Ben.
> 
> Pretty sure fsqrt is still out of e6500.

Ok, thinking out loud... looks like we might be able to just use existing 
math-emu for that. From what I can tell, all it needs (other than enabling
the config option), is a call to flush_fp_to_thread(current);

While talking math-emu... we seem to have some duplication between the
code on do_mathemu which can be compiled without CONFIG_MATH_EMULATION and
in this case only just emulates loads/stores/fmr and the code in
arch/powerpc/kernel/softemu8xx.c.

Is there any reason we can't just get rid of the latter ?

Cheers,
Ben.

Re: fsqrt

[Benjamin Herrenschmidt]

On Sat, 2013-06-08 at 09:23 +1000, Benjamin Herrenschmidt wrote:
> Ok, thinking out loud... looks like we might be able to just use existing 
> math-emu for that. From what I can tell, all it needs (other than enabling
> the config option), is a call to flush_fp_to_thread(current);
> 
> While talking math-emu... we seem to have some duplication between the
> code on do_mathemu which can be compiled without CONFIG_MATH_EMULATION and
> in this case only just emulates loads/stores/fmr and the code in
> arch/powerpc/kernel/softemu8xx.c.
> 
> Is there any reason we can't just get rid of the latter ?

Or just git completely rid of that "minimal emulation" ...

Cheers,
Ben.

Re: fsqrt

[Benjamin Herrenschmidt]

On Sat, 2013-06-08 at 09:25 +1000, Benjamin Herrenschmidt wrote:
> On Sat, 2013-06-08 at 09:23 +1000, Benjamin Herrenschmidt wrote:
> > Ok, thinking out loud... looks like we might be able to just use existing 
> > math-emu for that. From what I can tell, all it needs (other than enabling
> > the config option), is a call to flush_fp_to_thread(current);
> > 
> > While talking math-emu... we seem to have some duplication between the
> > code on do_mathemu which can be compiled without CONFIG_MATH_EMULATION and
> > in this case only just emulates loads/stores/fmr and the code in
> > arch/powerpc/kernel/softemu8xx.c.
> > 
> > Is there any reason we can't just get rid of the latter ?
> 
> Or just git completely rid of that "minimal emulation" ...

Right, looking more, the code really sucks. Either you use the existing
apparent ability for MATH_EMU to operate in minimal mode, ie,
load/store/fmr only (which seems to do exactly the same thing as the
code in softemu8xx.c which we can then get rid of), or just get rid of
that minimal mode alltogether.

And while at it make it a general config option for all soft-emu
processors (there is no bloody reason why that should be 8xx specfic) or
just get rid of the whole concept of half-emulation.

Ie. CONFIG_MATH_EMULATION/CONFIG_MATH_HALF_ASSED_EMULATION

Ben.

Re: fsqrt

[Dan Malek]

On Jun 7, 2013, at 4:30 PM, Benjamin Herrenschmidt =
<benh@kernel.crashing.org> wrote:

> Right, looking more, the code really sucks.

Hey!  :)

> =85.  Either you use the existing
> apparent ability for MATH_EMU to operate in minimal mode, ie,
> load/store/fmr only (which seems to do exactly the same thing as the
> code in softemu8xx.c which we can then get rid of), or just get rid of
> that minimal mode altogether.

The purpose for that "minimal code" was the signal handlers were =
hand-coded assembly that always did the FPU load/store regardless of =
compiler flags.  Over time, it became convenient to emulate a few =
others, even with user space math emulation, for similar reasons.

> And while at it make it a general config option for all soft-emu
> processors (there is no bloody reason why that should be 8xx specfic) =
or
> just get rid of the whole concept of half-emulation.

Looks like the code just evolved and the 8xx was never cleaned up.

The partial emulation is a convenience for the libraries that may still =
have FP instructions directly coded.  There are also permutations of =
real FPU but not all instructions, and no FPU to consider for fetching =
operands and storing results to be considered for the various =
configuration options.

Thanks.

	-- Dan

Re: fsqrt

[Benjamin Herrenschmidt]

On Fri, 2013-06-07 at 17:20 -0700, Dan Malek wrote:

> The purpose for that "minimal code" was the signal handlers were
> hand-coded assembly that always did the FPU load/store regardless of
> compiler flags.  Over time, it became convenient to emulate a few
> others, even with user space math emulation, for similar reasons.

The question is whether this is still relevant ? And if the answer is
yes, we still want that "minimum" emulation of load/stores/fmr as an
option, is there any reason why we can't replace the one in softemu8xx
with the existing (and unused) equivalent in do_mathemu ?

Cheers,
Ben.

Re: fsqrt

[Dan Malek]

Hi Ben.

On Jun 7, 2013, at 5:34 PM, Benjamin Herrenschmidt =
<benh@kernel.crashing.org> wrote:

> The question is whether this is still relevant ?

The only answer I could provide is that it's dependent upon the =
libraries and how the distributions are built.  It's also dependent upon =
processors with hardware FP that don't implement all instructions in =
hardware (who had that bright idea? :))  If distributions are fully all =
soft-fp in user space or all hardware FP, it removes the one reason that =
started the whole partial emulation option.

> =85  And if the answer is
> yes,

There are multiple options, but I believe they are solved today.  One is =
the libraries coded with hardware load/store that are used by soft-fp, =
another is hardware FP that doesn't implement all instructions in =
hardware (which it seems is the basis of this thread, although I thought =
was already solved).  The variation here is that in the first case you =
have to read/write user space soft-fp stack "registers," while in the =
latter you read/write real FP registers.  There used to be the third =
variation where the stack was allocated and the emulation had to write =
both places due to compiler function APIs or optimizations.  Of course, =
then there is the full-up kernel emulation where hardware is entirely =
lacking.

> =85 we still want that "minimum" emulation of load/stores/fmr as an
> option, is there any reason why we can't replace the one in softemu8xx
> with the existing (and unused) equivalent in do_mathemu ?

It appears to me that 8xx custom code can be removed.  I guess I should =
try to boot it up, if anyone even cares these days. :)

Thanks.

	-- Dan

Re: fsqrt

[Benjamin Herrenschmidt]

On Fri, 2013-06-07 at 18:13 -0700, Dan Malek wrote:
> Hi Ben.
> 
> On Jun 7, 2013, at 5:34 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> 
> > The question is whether this is still relevant ?
> 
> The only answer I could provide is that it's dependent upon the
> libraries and how the distributions are built.  It's also dependent
> upon processors with hardware FP that don't implement all instructions
> in hardware (who had that bright idea? :))  If distributions are fully
> all soft-fp in user space or all hardware FP, it removes the one
> reason that started the whole partial emulation option.

I'm not questioning the relevance of math-emu as a whole, but of the
tiny subset which is duplicated in math-emu and softemu8xx, which
emulates only load/stores/fmr.

If userspace is built with hard FP it is likely to use more than just
those handful of instructions...

> > …  And if the answer is
> > yes,
> 
> There are multiple options, but I believe they are solved today.  One
> is the libraries coded with hardware load/store that are used by
> soft-fp, another is hardware FP that doesn't implement all
> instructions in hardware (which it seems is the basis of this thread,
> although I thought was already solved). 

Yes, it's indeed the basis of that thread, and yes, I though it was
already solved as well but unless I missed something it is not, because
the current Program Check handler calls do_mathemu without first
flushing the hard FP state into the thread_struct.

However it's quite possible (I'll test when I get back to the office)
that this it the only fix necessary, which is a one liner, to make
CONFIG_MATH_EMULATION work just fine in that case.

> The variation here is that in the first case you have to read/write
> user space soft-fp stack "registers," while in the latter you
> read/write real FP registers. 

We never do any "user space soft-fp stack registers" handling in the
kernel. If we use full math emu (ie, no FP at all in HW), we simply use
the normal thread_struct storage of FPRs to store the "virtual" user FP
regs used by the emulation.

If use space uses full soft-fp (ie, -msoft-float), we should never see
any of it in the kernel.

>  There used to be the third variation where the stack was allocated
> and the emulation had to write both places due to compiler function
> APIs or optimizations.  Of course, then there is the full-up kernel
> emulation where hardware is entirely lacking.

I don't know anything about that "3rd option", it certainly doesn't have
any kernel impact that I can see :-) Full up emulation is of course
still there.

> > … we still want that "minimum" emulation of load/stores/fmr as an
> > option, is there any reason why we can't replace the one in
> softemu8xx
> > with the existing (and unused) equivalent in do_mathemu ?
> 
> It appears to me that 8xx custom code can be removed.  I guess I
> should try to boot it up, if anyone even cares these days. :)

Thanks,

Cheers,
Ben.

Re: fsqrt

[Benjamin Herrenschmidt]

The interesting thing I'm finding is that our math-emu is actually
quite busted :-)

For example look at fsqrt. It's defined as type AB which is incorrect,
it should be type XB. It ends up looking for it's arguments in the wrong
registers, same for fsrqts, fre, and a few others.

Also quite a few functions are simply left unimplemented... (fre is
completely missing from the decode, fres is there but returns -ENOSYS,
as does frsqrte, etc...)

I'll post a quick for for fsqrt{s} that I need for anaconda, but I
would strongly encourage somebody from FSL (primary users of that
stuff still) to have a close look at the rest. It shouldn't be terribly
hard to fix them up and add the few missing instructions, even if not
with the amount of precision requested by the spec (better than -ENOSYS)

Cheers,
Ben.

Re: fsqrt

[tiejun.chen]

On 06/07/2013 03:41 PM, Benjamin Herrenschmidt wrote:
> Another question...
>
> Do you guys happen to have a patch to emulate fsqrt in the kernel ?

Seems this is already emulated:

arch/powerpc/math-emu/fsqrt.c

You can enable CONFIG_MATH_EMULATION to try.

Tiejun

Re: fsqrt

[Benjamin Herrenschmidt]

On Fri, 2013-06-07 at 15:46 +0800, tiejun.chen wrote:
> On 06/07/2013 03:41 PM, Benjamin Herrenschmidt wrote:
> > Another question...
> >
> > Do you guys happen to have a patch to emulate fsqrt in the kernel ?
> 
> Seems this is already emulated:
> 
> arch/powerpc/math-emu/fsqrt.c
> 
> You can enable CONFIG_MATH_EMULATION to try.

Is math emu expected to work at all on top of a real FPU ? I though it
didn't ... maybe I'm wrong.

Cheers,
Ben.

Re: fsqrt

[tiejun.chen]

On 06/07/2013 04:53 PM, Benjamin Herrenschmidt wrote:
> On Fri, 2013-06-07 at 15:46 +0800, tiejun.chen wrote:
>> On 06/07/2013 03:41 PM, Benjamin Herrenschmidt wrote:
>>> Another question...
>>>
>>> Do you guys happen to have a patch to emulate fsqrt in the kernel ?
>>
>> Seems this is already emulated:
>>
>> arch/powerpc/math-emu/fsqrt.c
>>
>> You can enable CONFIG_MATH_EMULATION to try.
>
> Is math emu expected to work at all on top of a real FPU ? I though it
> didn't ... maybe I'm wrong.

As I understand often the real FPU can't support all float instructions, so we 
have to enable this to emulate those unsupported float instructions in that 
scenario.

Tiejun

Re: fsqrt

[Benjamin Herrenschmidt]

On Fri, 2013-06-07 at 17:02 +0800, tiejun.chen wrote:
> On 06/07/2013 04:53 PM, Benjamin Herrenschmidt wrote:
> > On Fri, 2013-06-07 at 15:46 +0800, tiejun.chen wrote:
> >> On 06/07/2013 03:41 PM, Benjamin Herrenschmidt wrote:
> >>> Another question...
> >>>
> >>> Do you guys happen to have a patch to emulate fsqrt in the kernel ?
> >>
> >> Seems this is already emulated:
> >>
> >> arch/powerpc/math-emu/fsqrt.c
> >>
> >> You can enable CONFIG_MATH_EMULATION to try.
> >
> > Is math emu expected to work at all on top of a real FPU ? I though it
> > didn't ... maybe I'm wrong.
> 
> As I understand often the real FPU can't support all float instructions, so we 
> have to enable this to emulate those unsupported float instructions in that 
> scenario.

Ok, two things come to mind here:

  - do_mathemu doesn't do giveup_fpu() so the FPU state might still be
in the "live" FP registers and not in the thread_struct, so it can't
work... unless I missed something.

  - mathemu uses solely integers. For something like fsqrt it's going to
suck a lot more than implementing using floating points in the kernel.

Cheers,
Ben.

FSL 64-bit DMA window question

[Benjamin Herrenschmidt]

Hi Folks !

Is there any specific reason why you chose 1T (40 bit) as the location
of the 64-bit DMA window ?

It happens that most current radeon adapters cannot DMA there, they have
a 40-bit DMA limit. I seem to be getting things to work fine using a
39-bit window, but I suppose that might collide with something else ?

Can you guys consider changing the default ?

Cheers,
Ben.

RE: FSL 64-bit DMA window question

[Zang Roy-R61911]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmVuamFtaW4gSGVycmVu
c2NobWlkdCBbbWFpbHRvOmJlbmhAa2VybmVsLmNyYXNoaW5nLm9yZ10NCj4gDQo+IEhpIEZvbGtz
ICENCj4gDQo+IElzIHRoZXJlIGFueSBzcGVjaWZpYyByZWFzb24gd2h5IHlvdSBjaG9zZSAxVCAo
NDAgYml0KSBhcyB0aGUgbG9jYXRpb24gb2YNCj4gdGhlIDY0LWJpdCBETUEgd2luZG93ID8NCj4g
DQo+IEl0IGhhcHBlbnMgdGhhdCBtb3N0IGN1cnJlbnQgcmFkZW9uIGFkYXB0ZXJzIGNhbm5vdCBE
TUEgdGhlcmUsIHRoZXkgaGF2ZQ0KPiBhIDQwLWJpdCBETUEgbGltaXQuIEkgc2VlbSB0byBiZSBn
ZXR0aW5nIHRoaW5ncyB0byB3b3JrIGZpbmUgdXNpbmcgYSAzOS0NCj4gYml0IHdpbmRvdywgYnV0
IEkgc3VwcG9zZSB0aGF0IG1pZ2h0IGNvbGxpZGUgd2l0aCBzb21ldGhpbmcgZWxzZSA/DQpUNDI0
MCBoYXMgNDBiaXQgcGh5c2ljYWwgYWRkcmVzcyBhYmlsaXR5Lg0KIg0KVGhpcyBjaGlwJ3MgNDAt
Yml0LCBwaHlzaWNhbCBhZGRyZXNzIG1hcCBjb25zaXN0cyBvZiBsb2NhbCBzcGFjZSBhbmQgZXh0
ZXJuYWwgYWRkcmVzcw0Kc3BhY2UuIEZvciB0aGUgbG9jYWwgYWRkcmVzcyBtYXAsIDMyIGxvY2Fs
IGFjY2VzcyB3aW5kb3dzIChMQVdzKSBkZWZpbmUgbWFwcGluZw0Kd2l0aGluIHRoZSBsb2NhbCA0
MC1iaXQgKDEgVEIpIGFkZHJlc3Mgc3BhY2UuIEluYm91bmQgYW5kIG91dGJvdW5kIHRyYW5zbGF0
aW9uIHdpbmRvd3MNCmNhbiBtYXAgdGhlIGNoaXAgaW50byBhIGxhcmdlciBzeXN0ZW0gYWRkcmVz
cyBzcGFjZSBzdWNoIGFzIHRoZSBSYXBpZElPIG9yIFBDSWUgNjQtYml0DQphZGRyZXNzIGVudmly
b25tZW50LiBUaGlzIGZ1bmN0aW9uYWxpdHkgaXMgaW5jbHVkZWQgaW4gdGhlIGFkZHJlc3MgdHJh
bnNsYXRpb24gYW5kDQptYXBwaW5nIHVuaXRzIChBVE1VcykuDQoNCiINClRoYXQgc2hvdWxkIGJl
IHRoZSByZWFzb24gdG8gc2V0IHRoZSBETUEgd2luZG93IHRvIDQwLWJpdC4NCg0KPiANCj4gQ2Fu
IHlvdSBndXlzIGNvbnNpZGVyIGNoYW5naW5nIHRoZSBkZWZhdWx0ID8NCkFueSBjb2xsaWRlIGZv
ciA0MGJpdD8NClJveQ0K

Re: FSL 64-bit DMA window question

[Benjamin Herrenschmidt]

On Fri, 2013-06-07 at 07:58 +0000, Zang Roy-R61911 wrote:
> 
> > -----Original Message-----
> > From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
> > 
> > Hi Folks !
> > 
> > Is there any specific reason why you chose 1T (40 bit) as the location of
> > the 64-bit DMA window ?
> > 
> > It happens that most current radeon adapters cannot DMA there, they have
> > a 40-bit DMA limit. I seem to be getting things to work fine using a 39-
> > bit window, but I suppose that might collide with something else ?
> T4240 has 40bit physical address ability.
> "
> This chip's 40-bit, physical address map consists of local space and external address
> space. For the local address map, 32 local access windows (LAWs) define mapping
> within the local 40-bit (1 TB) address space. Inbound and outbound translation windows
> can map the chip into a larger system address space such as the RapidIO or PCIe 64-bit
> address environment. This functionality is included in the address translation and
> mapping units (ATMUs).
> 
> "
> That should be the reason to set the DMA window to 40-bit.

I see. However if the top half of that space isn't used by default with
whatever is our current setup, it makes sense to move down the 64-bit
DMA window to allow those adapters to function don't you think ?

I'm trying to turn those FSL boxes into nice ppc64 dev. workstations :-)

Cheers,
Ben.

> > 
> > Can you guys consider changing the default ?
> Any collide for 40bit?
> Roy

RE: FSL 64-bit DMA window question

[Zang Roy-R61911]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmVuamFtaW4gSGVycmVu
c2NobWlkdCBbbWFpbHRvOmJlbmhAa2VybmVsLmNyYXNoaW5nLm9yZ10NCj4gDQo+IE9uIEZyaSwg
MjAxMy0wNi0wNyBhdCAwNzo1OCArMDAwMCwgWmFuZyBSb3ktUjYxOTExIHdyb3RlOg0KPiA+DQo+
ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogQmVuamFtaW4gSGVy
cmVuc2NobWlkdCBbbWFpbHRvOmJlbmhAa2VybmVsLmNyYXNoaW5nLm9yZ10NCj4gPiA+DQo+ID4g
PiBIaSBGb2xrcyAhDQo+ID4gPg0KPiA+ID4gSXMgdGhlcmUgYW55IHNwZWNpZmljIHJlYXNvbiB3
aHkgeW91IGNob3NlIDFUICg0MCBiaXQpIGFzIHRoZQ0KPiBsb2NhdGlvbiBvZg0KPiA+ID4gdGhl
IDY0LWJpdCBETUEgd2luZG93ID8NCj4gPiA+DQo+ID4gPiBJdCBoYXBwZW5zIHRoYXQgbW9zdCBj
dXJyZW50IHJhZGVvbiBhZGFwdGVycyBjYW5ub3QgRE1BIHRoZXJlLCB0aGV5DQo+IGhhdmUNCj4g
PiA+IGEgNDAtYml0IERNQSBsaW1pdC4gSSBzZWVtIHRvIGJlIGdldHRpbmcgdGhpbmdzIHRvIHdv
cmsgZmluZSB1c2luZyBhDQo+IDM5LQ0KPiA+ID4gYml0IHdpbmRvdywgYnV0IEkgc3VwcG9zZSB0
aGF0IG1pZ2h0IGNvbGxpZGUgd2l0aCBzb21ldGhpbmcgZWxzZSA/DQo+ID4gVDQyNDAgaGFzIDQw
Yml0IHBoeXNpY2FsIGFkZHJlc3MgYWJpbGl0eS4NCj4gPiAiDQo+ID4gVGhpcyBjaGlwJ3MgNDAt
Yml0LCBwaHlzaWNhbCBhZGRyZXNzIG1hcCBjb25zaXN0cyBvZiBsb2NhbCBzcGFjZSBhbmQNCj4g
ZXh0ZXJuYWwgYWRkcmVzcw0KPiA+IHNwYWNlLiBGb3IgdGhlIGxvY2FsIGFkZHJlc3MgbWFwLCAz
MiBsb2NhbCBhY2Nlc3Mgd2luZG93cyAoTEFXcykgZGVmaW5lDQo+IG1hcHBpbmcNCj4gPiB3aXRo
aW4gdGhlIGxvY2FsIDQwLWJpdCAoMSBUQikgYWRkcmVzcyBzcGFjZS4gSW5ib3VuZCBhbmQgb3V0
Ym91bmQNCj4gdHJhbnNsYXRpb24gd2luZG93cw0KPiA+IGNhbiBtYXAgdGhlIGNoaXAgaW50byBh
IGxhcmdlciBzeXN0ZW0gYWRkcmVzcyBzcGFjZSBzdWNoIGFzIHRoZSBSYXBpZElPDQo+IG9yIFBD
SWUgNjQtYml0DQo+ID4gYWRkcmVzcyBlbnZpcm9ubWVudC4gVGhpcyBmdW5jdGlvbmFsaXR5IGlz
IGluY2x1ZGVkIGluIHRoZSBhZGRyZXNzDQo+IHRyYW5zbGF0aW9uIGFuZA0KPiA+IG1hcHBpbmcg
dW5pdHMgKEFUTVVzKS4NCj4gPg0KPiA+ICINCj4gPiBUaGF0IHNob3VsZCBiZSB0aGUgcmVhc29u
IHRvIHNldCB0aGUgRE1BIHdpbmRvdyB0byA0MC1iaXQuDQo+IEkgc2VlLiBIb3dldmVyIGlmIHRo
ZSB0b3AgaGFsZiBvZiB0aGF0IHNwYWNlIGlzbid0IHVzZWQgYnkgZGVmYXVsdCB3aXRoDQo+IHdo
YXRldmVyIGlzIG91ciBjdXJyZW50IHNldHVwLCBpdCBtYWtlcyBzZW5zZSB0byBtb3ZlIGRvd24g
dGhlIDY0LWJpdA0KPiBETUEgd2luZG93IHRvIGFsbG93IHRob3NlIGFkYXB0ZXJzIHRvIGZ1bmN0
aW9uIGRvbid0IHlvdSB0aGluayA/DQpHb29kIHRvIG1lLg0KNDAgYml0IERNQSB3aWxsIHByZXZl
bnQgeW91ciByYWRlb24gdmlkZW8gY2FyZCBmcm9tIHdvcmtpbmcuIFJpZ2h0Pw0KWW91ciBQNTAy
MCBEUyBzeXN0ZW0gb25seSBzdXBwb3J0IDM2IGJpdCBwaHlzaWNhbCBhZGRyZXNzLg0KDQo+IA0K
PiBJJ20gdHJ5aW5nIHRvIHR1cm4gdGhvc2UgRlNMIGJveGVzIGludG8gbmljZSBwcGM2NCBkZXYu
IHdvcmtzdGF0aW9ucyA6LSkNClRoYXQgaXMgZ29vZC4gSSdkIGxpa2UgdG8gc2VlIGhvdyBsb25n
IGl0IHdpbGwgYnVpbGQgYSBrZXJuZWwgLi4uDQp0aGFua3MuDQpSb3kNCg==

Re: FSL 64-bit DMA window question

[Benjamin Herrenschmidt]

On Fri, 2013-06-07 at 09:44 +0000, Zang Roy-R61911 wrote:
> 
> > -----Original Message-----
> > From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
> > 
> > On Fri, 2013-06-07 at 07:58 +0000, Zang Roy-R61911 wrote:
> > >
> > > > -----Original Message-----
> > > > From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
> > > >
> > > > Hi Folks !
> > > >
> > > > Is there any specific reason why you chose 1T (40 bit) as the
> > location of
> > > > the 64-bit DMA window ?
> > > >
> > > > It happens that most current radeon adapters cannot DMA there, they
> > have
> > > > a 40-bit DMA limit. I seem to be getting things to work fine using a
> > 39-
> > > > bit window, but I suppose that might collide with something else ?
> > > T4240 has 40bit physical address ability.
> > > "
> > > This chip's 40-bit, physical address map consists of local space and
> > external address
> > > space. For the local address map, 32 local access windows (LAWs) define
> > mapping
> > > within the local 40-bit (1 TB) address space. Inbound and outbound
> > translation windows
> > > can map the chip into a larger system address space such as the RapidIO
> > or PCIe 64-bit
> > > address environment. This functionality is included in the address
> > translation and
> > > mapping units (ATMUs).
> > >
> > > "
> > > That should be the reason to set the DMA window to 40-bit.
> > I see. However if the top half of that space isn't used by default with
> > whatever is our current setup, it makes sense to move down the 64-bit
> > DMA window to allow those adapters to function don't you think ?
> Good to me.
> 40 bit DMA will prevent your radeon video card from working. Right?
> Your P5020 DS system only support 36 bit physical address.

We should probably put the "64-bit DMA" address in the device-tree,
that way if somebody wish to do differently they can.
> > 
> > I'm trying to turn those FSL boxes into nice ppc64 dev. workstations :-)
> That is good. I'd like to see how long it will build a kernel ...

I'll tell you when you send me a 24 cores e6500 :-)

In the meantime I'll build them on my 16-cores (64 threads) P7+ :-)

I'm more thinking about how to seed general community developers with
machines they can use to ensure things work fine on ppc64 without having
to get them a rack in their basement...

Cheers,
Ben.

> thanks.
> Roy

Re: FSL 64-bit DMA window question

[Scott Wood]

On 06/07/2013 05:01:28 PM, Scott Wood wrote:
> On 06/07/2013 07:09:20 AM, Benjamin Herrenschmidt wrote:
>> On Fri, 2013-06-07 at 09:44 +0000, Zang Roy-R61911 wrote:
>> >
>> > > -----Original Message-----
>> > > From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
>> > >
>> > > On Fri, 2013-06-07 at 07:58 +0000, Zang Roy-R61911 wrote:
>> > > >
>> > > > > -----Original Message-----
>> > > > > From: Benjamin Herrenschmidt =20
>> [mailto:benh@kernel.crashing.org]
>> > > > >
>> > > > > Hi Folks !
>> > > > >
>> > > > > Is there any specific reason why you chose 1T (40 bit) as the
>> > > location of
>> > > > > the 64-bit DMA window ?
>> > > > >
>> > > > > It happens that most current radeon adapters cannot DMA =20
>> there, they
>> > > have
>> > > > > a 40-bit DMA limit. I seem to be getting things to work fine =20
>> using a
>> > > 39-
>> > > > > bit window, but I suppose that might collide with something =20
>> else ?
>> > > > T4240 has 40bit physical address ability.
>> > > > "
>> > > > This chip's 40-bit, physical address map consists of local =20
>> space and
>> > > external address
>> > > > space. For the local address map, 32 local access windows =20
>> (LAWs) define
>> > > mapping
>> > > > within the local 40-bit (1 TB) address space. Inbound and =20
>> outbound
>> > > translation windows
>> > > > can map the chip into a larger system address space such as =20
>> the RapidIO
>> > > or PCIe 64-bit
>> > > > address environment. This functionality is included in the =20
>> address
>> > > translation and
>> > > > mapping units (ATMUs).
>> > > >
>> > > > "
>> > > > That should be the reason to set the DMA window to 40-bit.
>> > > I see. However if the top half of that space isn't used by =20
>> default with
>> > > whatever is our current setup, it makes sense to move down the =20
>> 64-bit
>> > > DMA window to allow those adapters to function don't you think ?
>> > Good to me.
>> > 40 bit DMA will prevent your radeon video card from working. Right?
>> > Your P5020 DS system only support 36 bit physical address.
>>=20
>> We should probably put the "64-bit DMA" address in the device-tree,
>> that way if somebody wish to do differently they can.
>=20
> I thought the device tree was for describing the hardware, rather =20
> than configuration? :-)
> A kernel command line option might be more appropriate, unless you =20
> just mean describing the difference between e6500 (which supports 40 =20
> bit addresses) and previous chips (which support 36 bits), rather =20
> than an ability to move it earlier even on e6500.
>=20
> That said, the current code looks broken -- it checks whether a card =20
> can do 40-bit DMA, and if it can, it sets the DMA offset to (1ULL << =20
> 40), thus requiring 41-bit DMA.  It should be > instead of >=3D in =20
> fsl_pci_dma_set_mask.
>=20
> Maybe we could by default use the size of actual RAM, rather than the =20
> physical address space.  Then only odd scenarios such as DMA to =20
> non-kernel-owned RAM would need manual adjustment (MSIs would still =20
> go through the special window below 4G).
>=20
> -Scott
=

Re: FSL 64-bit DMA window question

[Benjamin Herrenschmidt]

On Fri, 2013-06-07 at 17:02 -0500, Scott Wood wrote:
> O
> > I thought the device tree was for describing the hardware, rather  
> > than configuration? :-)

A bit of both really. See things like /chosen etc...

Also to what extent a MAC address is HW vs. configuration ? :-)

The HW configuration for a given boards (ie, internal address map,
location of the various bridge windows etc...) is a fairly common thing
to put in a device-tree.

If the PCI outbound windows are there (and they are), why not the
inbound ones ? IE, it's not far fetched. 

> > A kernel command line option might be more appropriate, unless you  
> > just mean describing the difference between e6500 (which supports 40  
> > bit addresses) and previous chips (which support 36 bits), rather  
> > than an ability to move it earlier even on e6500.

Well, so we could indeed locate it at 36 on e5500 and that would clear
the current use case and break again on e6500... or we can make it
depend on the overall address map of the board, which is described
in the device-tree. IE, if you don't "locate" anything above 39-bit
in our address map, then using 39 for the window is ok. IE. It's a
choice. A server board setup that doesn't need gfx but want address
space for some other things wouldn't care.

A board wanting to use gfx (either desktop style, or some of the
military applications I've seen using FSL chips and radeons) would chose
the address map differently to allow the radeons to work.

> > That said, the current code looks broken -- it checks whether a card  
> > can do 40-bit DMA, and if it can, it sets the DMA offset to (1ULL <<  
> > 40), thus requiring 41-bit DMA.  It should be > instead of >= in  
> > fsl_pci_dma_set_mask.

Yes, this was broken for a while, I remember mentioning it a while back
but never actually sending a patch to fix it ... oops ;-)

> > Maybe we could by default use the size of actual RAM, rather than the  
> > physical address space.  Then only odd scenarios such as DMA to  
> > non-kernel-owned RAM would need manual adjustment (MSIs would still  
> > go through the special window below 4G).

You also need to account for other on-chip MMIOs no ? Or do you never
intend to let PCI devices hit them ?

If not, then top of RAM aligned to the next power of two sounds like a
great plan.

Also, those radeons are *also* broken for 64-bit MSIs (they advertize
support but are limited to 40-bit of address). We have added hacks to
deal with that in pseries that I was thinking of generalizing.

Cheers,
Ben.

Re: FSL 64-bit DMA window question

[Scott Wood]

On 06/07/2013 05:09:54 PM, Benjamin Herrenschmidt wrote:
> On Fri, 2013-06-07 at 17:02 -0500, Scott Wood wrote:
> > O
> > > I thought the device tree was for describing the hardware, rather
> > > than configuration? :-)
>=20
> A bit of both really. See things like /chosen etc...
>=20
> Also to what extent a MAC address is HW vs. configuration ? :-)

Normally I'd consider that hardware, unless you're overriding it for =20
some reason.

> The HW configuration for a given boards (ie, internal address map,
> location of the various bridge windows etc...) is a fairly common =20
> thing
> to put in a device-tree.

Sure, there's some stuff that is technically software config, but which =20
is easier to treat as a fixed property of the hardware once U-Boot is =20
done setting it up.  But U-Boot doesn't have anything to do with this =20
DMA window...

> If the PCI outbound windows are there (and they are), why not the
> inbound ones ? IE, it's not far fetched.

PCI outbound windows (and the LAWs that back them up) are set up by =20
U-Boot.  With the current FSL kernel code, if you set it to something =20
that isn't covered by a PCIe LAW from U-Boot, it won't work.

> > > A kernel command line option might be more appropriate, unless you
> > > just mean describing the difference between e6500 (which supports =20
> 40
> > > bit addresses) and previous chips (which support 36 bits), rather
> > > than an ability to move it earlier even on e6500.
>=20
> Well, so we could indeed locate it at 36 on e5500 and that would clear
> the current use case and break again on e6500... or we can make it
> depend on the overall address map of the board, which is described
> in the device-tree. IE, if you don't "locate" anything above 39-bit
> in our address map, then using 39 for the window is ok. IE. It's a
> choice. A server board setup that doesn't need gfx but want address
> space for some other things wouldn't care.

I suppose we could put in the device tree the highest address that has =20
been configured for anything...  though for that to be useful we'd need =20
to get out of the habit of putting CCSR near the top of the physical =20
address space.

> > > Maybe we could by default use the size of actual RAM, rather than =20
> the
> > > physical address space.  Then only odd scenarios such as DMA to
> > > non-kernel-owned RAM would need manual adjustment (MSIs would =20
> still
> > > go through the special window below 4G).
>=20
> You also need to account for other on-chip MMIOs no ? Or do you never
> intend to let PCI devices hit them ?

I don't think we normally need that (other than MSIs, which have a =20
special window under 4G)...  The question is whether it's better to let =20
odd use cases work without having to manually move the DMA window, at =20
the cost of decreased out-of-the-box performance with common PCIe cards.

-Scott=

Re: FSL 64-bit DMA window question

[Benjamin Herrenschmidt]

On Fri, 2013-06-07 at 17:34 -0500, Scott Wood wrote:
> > You also need to account for other on-chip MMIOs no ? Or do you never
> > intend to let PCI devices hit them ?
> 
> I don't think we normally need that (other than MSIs, which have a  
> special window under 4G)...  The question is whether it's better to let  
> odd use cases work without having to manually move the DMA window, at  
> the cost of decreased out-of-the-box performance with common PCIe cards.

Sorry, I didn't parse what the tradeoff is here...

Putting the inbound window above memory seems like a reasonable option then
(at least as a default that the board can override).

I sincerely hope those radeons are the only remaining things with that sort of
limitation but you never know ... it's all x86 fault of course for never having
used high DMA windows :-)

Cheers,
Ben.

Re: FSL 64-bit DMA window question

[Scott Wood]

On 06/07/2013 05:39:53 PM, Benjamin Herrenschmidt wrote:
> On Fri, 2013-06-07 at 17:34 -0500, Scott Wood wrote:
> > > You also need to account for other on-chip MMIOs no ? Or do you =20
> never
> > > intend to let PCI devices hit them ?
> >
> > I don't think we normally need that (other than MSIs, which have a
> > special window under 4G)...  The question is whether it's better to =20
> let
> > odd use cases work without having to manually move the DMA window, =20
> at
> > the cost of decreased out-of-the-box performance with common PCIe =20
> cards.
>=20
> Sorry, I didn't parse what the tradeoff is here...

I just meant that a PCIe device targeting something other than RAM, =20
CCSR (it's not just MSIs that are mapped through the special window), =20
or another PCIe is a rather unusual case -- not something that you'd =20
see by just plugging in an ordinary PCIe card.  The tradeoff is that if =20
we accommodate this strange use case, boards like the radeon would need =20
to use swiotlb (once we fix the > versus >=3D bug) unless the user tweaks =20
the DMA window.

It may be best to stick with the default that makes everything work, =20
even if a broken PCIe card ends up being a bit slower out of the box, =20
even if the PCIe-to-MMIO use case is weird and would require custom =20
setup anyway.  OTOH, did we ever care about 32-bit DMA being able to =20
access MMIO?

> Putting the inbound window above memory seems like a reasonable =20
> option then
> (at least as a default that the board can override).
>=20
> I sincerely hope those radeons are the only remaining things with =20
> that sort of
> limitation but you never know ... it's all x86 fault of course for =20
> never having
> used high DMA windows :-)

Hmm... Why are we using this special window at all?  Can't we just have =20
one large identity mapping starting at zero, with the MSI window =20
presumably taking precedence?  The manual is a bit vague on whether =20
inbound windows can overlap with priority... in EP mode it says it =20
does, and the RC section is silent.  Do we currently ever overlap =20
PCICSRBAR with a real window?

-Scott=

Re: FSL 64-bit DMA window question

[Benjamin Herrenschmidt]

On Fri, 2013-06-07 at 18:29 -0500, Scott Wood wrote:

> I just meant that a PCIe device targeting something other than RAM,  
> CCSR (it's not just MSIs that are mapped through the special window),  
> or another PCIe is a rather unusual case -- not something that you'd  
> see by just plugging in an ordinary PCIe card.  The tradeoff is that if  
> we accommodate this strange use case, boards like the radeon would need  
> to use swiotlb (once we fix the > versus >= bug) unless the user tweaks  
> the DMA window.

Yeah, well, swiotlb won't work for radeon anyway. It has its own
"mmu" (a GART really) and will constantly want to pin pages in it,
swiotlb will be at best a mess and at worst will just not work.

> It may be best to stick with the default that makes everything work,  
> even if a broken PCIe card ends up being a bit slower out of the box,  
> even if the PCIe-to-MMIO use case is weird and would require custom  
> setup anyway.  OTOH, did we ever care about 32-bit DMA being able to  
> access MMIO?

Not that I know of.

> Hmm... Why are we using this special window at all?  Can't we just have  
> one large identity mapping starting at zero, with the MSI window  
> presumably taking precedence? 

Then you'd have to reserve the RAM covered by the MSI window, not
necessarily a big deal. It would also still allow swiotlb to work, so it
actually doesn't seem like a bad idea if you don't have an actual /
usable iommu.

So if it works, I like that idea even better.

>  The manual is a bit vague on whether  
> inbound windows can overlap with priority... in EP mode it says it  
> does, and the RC section is silent.  Do we currently ever overlap  
> PCICSRBAR with a real window?

Cheers,
Ben.

Re: SATA FSL and upstreaming

[Timur Tabi]

Benjamin Herrenschmidt wrote:
> PHY reset timed out
> PHY reset timed out
> PHY reset timed out
> PHY reset timed out

This usually means that your RCW does not match your dip switch settings.

-- 
Timur Tabi

RE: SATA FSL and upstreaming

[Zang Roy-R61911]

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

Re: SATA FSL and upstreaming

[Benjamin Herrenschmidt]

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

RE: SATA FSL and upstreaming

[Bhushan Bharat-R65777]

VHJ5Og0KDQpGcm9tIGJhbmsgMA0KLS0tLS0tLS0tLS0tDQoNCnRmdHAgMHgxMDAwMDAwICByY3df
MnNnbWlpXzE1MDBtaHouYmluDQpwcm90ZWN0IG9mZiAweGVjMDAwMDAwICskZmlsZXNpemU7IGVy
YXNlIDB4ZWMwMDAwMDAgKyRmaWxlc2l6ZTsgY3AuYiAweDEwMDAwMDAgMHhlYzAwMDAwMCAkZmls
ZXNpemUNCg0KDQpUaGFua3MNCi1CaGFyYXQNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LQ0KPiBGcm9tOiBCZW5qYW1pbiBIZXJyZW5zY2htaWR0IFttYWlsdG86YmVuaEBrZXJuZWwuY3Jh
c2hpbmcub3JnXQ0KPiBTZW50OiBUaHVyc2RheSwgTWF5IDE2LCAyMDEzIDExOjU0IEFNDQo+IFRv
OiBaYW5nIFJveS1SNjE5MTENCj4gQ2M6IEJodXNoYW4gQmhhcmF0LVI2NTc3NzsgTGl1IFFpYW5n
LUIzMjYxNjsgRmxlbWluZyBBbmR5LUFGTEVNSU5HOyBsaW51eHBwYy0NCj4gZGV2QGxpc3RzLm96
bGFicy5vcmc7IFhpZSBTaGFvaHVpLUIyMTk4OQ0KPiBTdWJqZWN0OiBSZTogU0FUQSBGU0wgYW5k
IHVwc3RyZWFtaW5nDQo+IA0KPiBPbiBUaHUsIDIwMTMtMDUtMTYgYXQgMDY6MTcgKzAwMDAsIFph
bmcgUm95LVI2MTkxMSB3cm90ZToNCj4gPiBEbyB5b3UgdHJ5IHNsb3Q3Pw0KPiA+IFBDSWUxIGNv
bm5lY3RzIHRvIHNsb3Q3IGRpcmVjdGx5Lg0KPiANCj4gSSB0cmllZCBhbGwgc2xvdHMuIE5vbmUg
b2YgdGhlbSBzZWVzIGFueSBjYXJkLiBUaGUgY2FyZCBhbHNvIGRvZXNuJ3Qgc2VlbSB0byBiZQ0K
PiBwb3dlcmVkIHVwIChub25lIG9mIHRoZSBMRURzIGJsaW5rLCBpdCdzIGFuIGUxMDAwIHNpbmNl
IEkgZG9uJ3QgaGF2ZSBuZXR3b3JraW5nDQo+IHdpdGggdXBzdHJlYW0pLg0KPiANCj4gSSBhbHNv
IHRyaWVkIGEgZGlmZmVyZW50IGNhcmQgYW5kIHVib290IGlzIHByZXR0eSBhZGFtYW50IGF0IHNh
eWluZyAibm8gbGluayIgOi0NCj4gKQ0KPiANCj4gSSdsbCB0cnkgdG8gdXBkYXRlIHRoZSBSQ1cg
d2hlbiBJIGtub3cgaG93IHRvIGRvIGl0IDotKQ0KPiANCj4gQ2hlZXJzLA0KPiBCZW4uDQo+IA0K
PiA+IFJveQ0KPiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJv
bTogQmVuamFtaW4gSGVycmVuc2NobWlkdCBbbWFpbHRvOmJlbmhAa2VybmVsLmNyYXNoaW5nLm9y
Z10NCj4gPiA+IFNlbnQ6IFRodXJzZGF5LCBNYXkgMTYsIDIwMTMgMjowOSBQTQ0KPiA+ID4gVG86
IFphbmcgUm95LVI2MTkxMQ0KPiA+ID4gQ2M6IEJodXNoYW4gQmhhcmF0LVI2NTc3NzsgTGl1IFFp
YW5nLUIzMjYxNjsgRmxlbWluZyBBbmR5LUFGTEVNSU5HOw0KPiA+ID4gbGludXhwcGMtZGV2QGxp
c3RzLm96bGFicy5vcmc7IFhpZSBTaGFvaHVpLUIyMTk4OQ0KPiA+ID4gU3ViamVjdDogUmU6IFNB
VEEgRlNMIGFuZCB1cHN0cmVhbWluZw0KPiA+ID4NCj4gPiA+IE9uIFRodSwgMjAxMy0wNS0xNiBh
dCAwNjowNSArMDAwMCwgWmFuZyBSb3ktUjYxOTExIHdyb3RlOg0KPiA+ID4gPiBJIGRvIG5vdCBz
dWdnZXN0IGNoYW5naW5nIHRoZSBSQ1cuIElmIHRoZSBSQ1cgaXMgYnJva2VuIG9uIEJlbidzDQo+
ID4gPiA+IHNpZGUsIGl0IGlzIG5vdCBlYXN5IHRvIHJlY292ZXIgZm9yIGhpbS4NCj4gPiA+ID4g
TGV0J3MgY2hlY2sgdGhlIFUtYm9vdCBvdXRwdXQgZmlyc3QuDQo+ID4gPg0KPiA+ID4gVS1Cb290
IDIwMTMuMDEtMDAwMDktZzdiY2Q3ZjQgKE1hciAxNCAyMDEzIC0gMTQ6MjM6MTYpDQo+ID4gPg0K
PiA+ID4gQ1BVMDogIFA1MDIwRSwgVmVyc2lvbjogMS4wLCAoMHg4MjI4MDAxMCkNCj4gPiA+IENv
cmU6ICBFNTUwMCwgVmVyc2lvbjogMS4wLCAoMHg4MDI0MDAxMCkgQ2xvY2sgQ29uZmlndXJhdGlv
bjoNCj4gPiA+ICAgICAgICBDUFUwOjIwMDAgTUh6LCBDUFUxOjIwMDAgTUh6LA0KPiA+ID4gICAg
ICAgIENDQjo4MDAgIE1IeiwNCj4gPiA+ICAgICAgICBERFI6NjY2LjY2NyBNSHogKDEzMzMuMzMz
IE1UL3MgZGF0YSByYXRlKSAoQXN5bmNocm9ub3VzKSwNCj4gPiA+IExCQzoxMDAgTUh6DQo+ID4g
PiAgICAgICAgRk1BTjE6IDYwMCBNSHoNCj4gPiA+ICAgICAgICBRTUFOOiAgNDAwIE1Ieg0KPiA+
ID4gICAgICAgIFBNRTogICA0MDAgTUh6DQo+ID4gPiBMMTogICAgRC1jYWNoZSAzMiBrQiBlbmFi
bGVkDQo+ID4gPiAgICAgICAgSS1jYWNoZSAzMiBrQiBlbmFibGVkDQo+ID4gPiBCb2FyZDogUDUw
MjBEUywgU3lzIElEOiAweDFjLCBTeXMgVmVyOiAweDEyLCBGUEdBIFZlcjogMHgwNSwgdkJhbms6
DQo+ID4gPiAwIFJlc2V0IENvbmZpZ3VyYXRpb24gV29yZCAoUkNXKToNCj4gPiA+ICAgICAgICAw
MDAwMDAwMDogMGM1NDAwMDAgMDAwMDAwMDAgMWUxMjAwMDAgMDAwMDAwMDANCj4gPiA+ICAgICAg
ICAwMDAwMDAxMDogZDg5ODRhMDEgMDMwMDIwMDAgZGU4MDAwMDAgNDEwMDAwMDANCj4gPiA+ICAg
ICAgICAwMDAwMDAyMDogMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAgMTAwNzAwMDANCj4gPiA+
ICAgICAgICAwMDAwMDAzMDogMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAgU0VS
REVTDQo+ID4gPiBSZWZlcmVuY2UgQ2xvY2tzOiBCYW5rMT0xMDBNaHogQmFuazI9MTI1TWh6IEJh
bmszPTEyNU1oeg0KPiA+ID4gSTJDOiAgIHJlYWR5DQo+ID4gPiBTUEk6ICAgcmVhZHkNCj4gPiA+
IERSQU06ICBJbml0aWFsaXppbmcuLi4udXNpbmcgU1BEDQo+ID4gPiBEZXRlY3RlZCBVRElNTSBp
LURJTU0NCj4gPiA+IERldGVjdGVkIFVESU1NIGktRElNTQ0KPiA+ID4gMiBHaUIgbGVmdCB1bm1h
cHBlZA0KPiA+ID4gNCBHaUIgKEREUjMsIDY0LWJpdCwgQ0w9OSwgRUNDIG9uKQ0KPiA+ID4gICAg
ICAgIEREUiBDb250cm9sbGVyIEludGVybGVhdmluZyBNb2RlOiBjYWNoZSBsaW5lDQo+ID4gPiAg
ICAgICAgRERSIENoaXAtU2VsZWN0IEludGVybGVhdmluZyBNb2RlOiBDUzArQ1MxIFRlc3Rpbmcg
MHgwMDAwMDAwMA0KPiA+ID4gLSAweDdmZmZmZmZmIFRlc3RpbmcgMHg4MDAwMDAwMCAtIDB4ZmZm
ZmZmZmYgUmVtYXAgRERSIDIgR2lCIGxlZnQNCj4gPiA+IHVubWFwcGVkDQo+ID4gPg0KPiA+ID4g
UE9TVCBtZW1vcnkgUEFTU0VEDQo+ID4gPiBGbGFzaDogMTI4IE1pQg0KPiA+ID4gTDI6ICAgIDUx
MiBLQiBlbmFibGVkDQo+ID4gPiBDb3JlbmV0IFBsYXRmb3JtIENhY2hlOiAyMDQ4IEtCIGVuYWJs
ZWQNCj4gPiA+IFNSSU8xOiBkaXNhYmxlZA0KPiA+ID4gU1JJTzI6IGRpc2FibGVkDQo+ID4gPiBO
QU5EOiAgMTAyNCBNaUINCj4gPiA+IE1NQzogIEZTTF9TREhDOiAwDQo+ID4gPiBFRVBST006IE5Y
SUQgdjENCj4gPiA+IFBDSWUxOiBSb290IENvbXBsZXgsIG5vIGxpbmssIHJlZ3MgQCAweGZlMjAw
MDAwDQo+ID4gPiBQQ0llMTogQnVzIDAwIC0gMDANCj4gPiA+IFBDSWUyOiBkaXNhYmxlZA0KPiA+
ID4gUENJZTM6IFJvb3QgQ29tcGxleCwgbm8gbGluaywgcmVncyBAIDB4ZmUyMDIwMDANCj4gPiA+
IFBDSWUzOiBCdXMgMDEgLSAwMQ0KPiA+ID4gUENJZTQ6IGRpc2FibGVkDQo+ID4gPiBJbjogICAg
c2VyaWFsDQo+ID4gPiBPdXQ6ICAgc2VyaWFsDQo+ID4gPiBFcnI6ICAgc2VyaWFsDQo+ID4gPiBO
ZXQ6ICAgSW5pdGlhbGl6aW5nIEZtYW4NCj4gPiA+IEZtYW4xOiBVcGxvYWRpbmcgbWljcm9jb2Rl
IHZlcnNpb24gMTA2LjEuNyBQSFkgcmVzZXQgdGltZWQgb3V0IFBIWQ0KPiA+ID4gcmVzZXQgdGlt
ZWQgb3V0IFBIWSByZXNldCB0aW1lZCBvdXQgUEhZIHJlc2V0IHRpbWVkIG91dCBGTTFARFRTRUMx
LA0KPiA+ID4gRk0xQERUU0VDMiwgRk0xQERUU0VDMywgRk0xQERUU0VDNCwgRk0xQERUU0VDNSwg
Rk0xQFRHRUMxIEhpdCBhbnkNCj4gPiA+IGtleSB0byBzdG9wIGF1dG9ib290OiAgMCA9Pg0KPiA+
ID4NCj4gPiA+IENoZWVycywNCj4gPiA+IEJlbi4NCj4gPiA+DQo+ID4gPg0KPiA+DQo+IA0KPiAN
Cg0K

Re: SATA FSL and upstreaming

[Benjamin Herrenschmidt]

On Thu, 2013-05-16 at 06:33 +0000, Bhushan Bharat-R65777 wrote:
> From bank 0
> ------------
> 
> tftp 0x1000000  rcw_2sgmii_1500mhz.bin
> protect off 0xec000000 +$filesize; erase 0xec000000 +$filesize; cp.b
> 0x1000000 0xec000000 $filesize

Before I do something irreparable, what do you specifically mean by
"from bank 0" ? :-)

Cheers,
Ben.

RE: SATA FSL and upstreaming

[Zang Roy-R61911]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmh1c2hhbiBCaGFyYXQt
UjY1Nzc3DQo+IFNlbnQ6IFRodXJzZGF5LCBNYXkgMTYsIDIwMTMgMjozMyBQTQ0KPiBUbzogQmVu
amFtaW4gSGVycmVuc2NobWlkdDsgWmFuZyBSb3ktUjYxOTExDQo+IENjOiBMaXUgUWlhbmctQjMy
NjE2OyBGbGVtaW5nIEFuZHktQUZMRU1JTkc7IGxpbnV4cHBjLQ0KPiBkZXZAbGlzdHMub3psYWJz
Lm9yZzsgWGllIFNoYW9odWktQjIxOTg5DQo+IFN1YmplY3Q6IFJFOiBTQVRBIEZTTCBhbmQgdXBz
dHJlYW1pbmcNCj4gDQo+IFRyeToNCj4gDQo+IEZyb20gYmFuayAwDQo+IC0tLS0tLS0tLS0tLQ0K
PiANCj4gdGZ0cCAweDEwMDAwMDAgIHJjd18yc2dtaWlfMTUwMG1oei5iaW4NCj4gcHJvdGVjdCBv
ZmYgMHhlYzAwMDAwMCArJGZpbGVzaXplOyBlcmFzZSAweGVjMDAwMDAwICskZmlsZXNpemU7IGNw
LmINCj4gMHgxMDAwMDAwIDB4ZWMwMDAwMDAgJGZpbGVzaXplDQpZb3UgbmVlZCB0byB0ZWxsIEJl
biAgdGhhdCB0aGlzIGlzIGZvciBiYW5rIDQgcmN3Lg0KQW5kIGhvdyB0byBzd2l0Y2ggdG8gYmFu
azQuDQpSb3kNCg==

Re: SATA FSL and upstreaming

[Benjamin Herrenschmidt]

On Thu, 2013-05-16 at 06:33 +0000, Bhushan Bharat-R65777 wrote:
> protect off 0xec000000 +$filesize; erase 0xec000000 +$filesize; cp.b
> 0x1000000 0xec000000 $filesize

BTW, is it normal that the network in uboot is *extremely* unreliable ?
It takes dozens of tries if not more for it to "kick in", then it
eventually works.

I've given on dhcp and using fixed IPs but that doesn't help, tftp fails
several times until it eventually work ... if I'm in a lucky day.

Cheers,
Ben.

Re: SATA FSL and upstreaming

[tiejun.chen]

On 05/16/2013 02:37 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2013-05-16 at 06:33 +0000, Bhushan Bharat-R65777 wrote:
>> protect off 0xec000000 +$filesize; erase 0xec000000 +$filesize; cp.b
>> 0x1000000 0xec000000 $filesize
>
> BTW, is it normal that the network in uboot is *extremely* unreliable ?

We can use serial port:

loadb   - load binary file over serial line (kermit mode)
loads   - load S-Record file over serial line
loady   - load binary file over serial line (ymodem mode)

Then please send the RCW with appropriate mode above in your terminal client.

Tiejun

RE: SATA FSL and upstreaming

[Zang Roy-R61911]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmh1c2hhbiBCaGFyYXQt
UjY1Nzc3DQo+IFNlbnQ6IFRodXJzZGF5LCBNYXkgMTYsIDIwMTMgMjozMyBQTQ0KPiBUbzogQmVu
amFtaW4gSGVycmVuc2NobWlkdDsgWmFuZyBSb3ktUjYxOTExDQo+IENjOiBMaXUgUWlhbmctQjMy
NjE2OyBGbGVtaW5nIEFuZHktQUZMRU1JTkc7IGxpbnV4cHBjLQ0KPiBkZXZAbGlzdHMub3psYWJz
Lm9yZzsgWGllIFNoYW9odWktQjIxOTg5DQo+IFN1YmplY3Q6IFJFOiBTQVRBIEZTTCBhbmQgdXBz
dHJlYW1pbmcNCj4gDQo+IFRyeToNCj4gDQo+IEZyb20gYmFuayAwDQo+IC0tLS0tLS0tLS0tLQ0K
PiANCj4gdGZ0cCAweDEwMDAwMDAgIHJjd18yc2dtaWlfMTUwMG1oei5iaW4NCj4gcHJvdGVjdCBv
ZmYgMHhlYzAwMDAwMCArJGZpbGVzaXplOyBlcmFzZSAweGVjMDAwMDAwICskZmlsZXNpemU7IGNw
LmINCj4gMHgxMDAwMDAwIDB4ZWMwMDAwMDAgJGZpbGVzaXplDQpQbGVhc2UgYWxzbyBiZSBhd2Fy
ZSB0aGF0IHlvdXIgYXR0YWNobWVudCBpcyBub3QgYmluYXJ5Lg0KeW91IG1heSBuZWVkIHRvIGJ1
aWxkIGEgYmluYXJ5IFJDVyBmb3IgQmVuLg0KQWR2aWNlIEJlbiB0byB1c2UgQmFuazQgdG8gYXZv
aWQgYnJlYWtpbmcgYmFuazAuDQpUaGFua3MuDQpSb3kNCg==

RE: SATA FSL and upstreaming

[Xie Shaohui-B21989]

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

Re: SATA FSL and upstreaming

[Benjamin Herrenschmidt]

On Thu, 2013-05-16 at 06:24 +0000, Xie Shaohui-B21989 wrote:
> Hi, Ben,
> 
> Since the p5020ds you tested is a rev1 chip, I think the most possibility that SATA not work
> is due to a SATA erratum, which is fixed in rev1.1, we have a policy that patches for errata that 
> are present only on early silicon revisions, typically only rev1 silicon will not send upstream.
> You can find the patch at below link:
> http://git.freescale.com/git/cgit.cgi/ppc/sdk/linux.git/commit/?id=b79a8a0528b8a0008cb76f339806b1200b5d8f63

Well, the chip I have is rev1... since I'm the maintainer I might pull a
"Linus" and just apply the damn patch to make it work for me :-) Though
I'm being told that a rev2 chip is on its way to me ... I'll wait a few
more days see if that arrives.

Cheers,
Ben.

> Since it is not sent to upstream, it may need to be rebased if apply it to latest tree.
> 
> Also there might be another issue(SATA & USB) if you test 64 bit kernel on p5020ds with DRR > 4G, we have a patch
> Sent to upstream, but not accepted yet. Link as below:
> http://patchwork.ozlabs.org/patch/179828/
> 
> There are online documents of SDK, for the p5020ds hardware please see the link:
> http://www.freescale.com/infocenter/index.jsp?topic=%2FQORIQSDK%2F2989554.html
> 
> 
> Best Regards, 
> Shaohui Xie
> > -----Original Message-----
> > From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
> > Sent: Thursday, May 16, 2013 12:48 PM
> > To: Liu Qiang-B32616; Xie Shaohui-B21989; Fleming Andy-AFLEMING
> > Cc: linuxppc-dev@lists.ozlabs.org; Kumar Gala
> > Subject: SATA FSL and upstreaming
> > 
> > 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.
> > 
> > 
>