sata_sx4 vs. Promise SX4060

sata_sx4 vs. Promise SX4060

[Lasse Makholm]

Hi,

I know it's been brought up here before, at least a few years ago
(http://search.gmane.org/?query=sx4060&group=gmane.linux.ide) but here
goes anyway...

I'm one of those semi-happy owners of a Promise SX4060 PATA RAID
controller which is apparently only supported for some 2.4-something
kernels...

Obviously I would a lot more happy with a 2.6 driver... :-)

So I've been googling high and low without much result, except finding
out that the SX4060 is based on the same chip (the PDC20621) as the SATA
150 SX4, leading me to believe that the sata_sx4 driver is probably the
best bet for getting the SX4060 working under 2.6 kernels...

Also, this comment in sata_sx4.c seems to support this suspicion:

	The SX4 behaves like a PATA chip, with no SATA controls or
	knowledge whatsoever, leading to the presumption that
	PATA<->SATA bridges exist on SX4 boards, external to the
	PDC20621 chip itself.

All documentation I've been able to find on the devices indicate that 
they are very similar...

I tried hacking the driver to recognize the SX4060 board number,
essentially the same thing as described here:
http://article.gmane.org/gmane.linux.ide/5435

...with similar results. The controller is recognized and it also
recognizes the attached drives, but it seems to have trouble 
initializing the DIMM and with the ATA_SET_FEATURES command...

With ATA_DEBUG and ATA_DEBUG_VERBOSE, I get something like this (I have 
the full log if someone wants to see it):

[  271.122187] pdc20621_dimm_init: Time Counter Register (0x44): 0xf0a6fb86
[  271.122250] pdc20621_dimm_init: Num counters 0xf590479 (257492089)
[  271.122309] pdc20621_dimm_init: 10 * Internal clk = 0x35a (858)
[  271.122369] pdc20621_dimm_init: 10 * Internal clk * 33 = 0x6e9a (28314)
[  271.122428] pdc20621_dimm_init: PLL F Param: 0x2f (47)
[  271.122486] pdc20621_dimm_init: pci_status: 0x8a2f1824
[  271.122721] pdc20621_dimm_init: Local DIMM Speed = 100
[  271.124883] pdc20621_dimm_init: Local DIMM Size = 64MB
[  271.125118] Local DIMM ECC Enabled
[  271.226153] 0, 0,
[  271.226220] 55, aa, Promise Not Yet Defined 1.1098
[  271.226291] 55, aa, Promise Not Yet Defined 1.1098
[  271.226524] pdc20621_dimm_init: Start ECC initialization
[  281.972847] BUG: soft lockup - CPU#0 stuck for 11s! [modprobe:6153]
Register and stack dump here...
[  293.775043] BUG: soft lockup - CPU#0 stuck for 11s! [modprobe:6153]
Register and stack dump here...
[  305.581239] BUG: soft lockup - CPU#0 stuck for 11s! [modprobe:6153]
Register and stack dump here...
[  312.567607] pdc20621_dimm_init: Finish ECC initialization
Lots of noise follows...
[  312.768567] ata5: PATA max UDMA/44 mmio m1048576@0xfe900000 dimm 
m32768@0xfe800000 port 0xfe900200 irq 17
[  312.768571] ata6: PATA max UDMA/44 mmio m1048576@0xfe900000 dimm 
m32768@0xfe800000 port 0xfe900280 irq 17
[  312.768574] ata7: PATA max UDMA/44 mmio m1048576@0xfe900000 dimm 
m32768@0xfe800000 port 0xfe900300 irq 17
[  312.768577] ata8: PATA max UDMA/44 mmio m1048576@0xfe900000 dimm 
m32768@0xfe800000 port 0xfe900380 irq 17
More noise follows...
[  342.918886] ata_port_flush_task: ENTER
[  342.918947] ata5: ata_port_flush_task: EXIT
[  342.918959] ata5.00: qc timeout (cmd 0xef)
[  342.918962] ata_dev_set_xfermode: EXIT, err_mask=4
[  342.919021] ata5.00: failed to set xfermode (err_mask=0x4)

Even more noise follows...

[  373.068199] ata5.00: failed to set xfermode (err_mask=0x4)
[  373.068260] ata5.00: limiting speed to UDMA/44:PIO3
[  373.068263] pdc_20621_phy_reset: ENTER
[  373.068320] ata_bus_reset: ENTER, host 5, port 0
[  373.068388] ata_bus_softreset: ata5: bus reset via SRST
[  373.224003] ata_dev_classify: found ATA device by sig
[  373.224068] ata_bus_reset: EXIT
[  373.224125] ata5.00: ata_dev_read_id: ENTER
[  373.224127] ata5: ata_dev_select: ENTER, device 0, wait 1
[  373.224157] ata5: ata_dev_select: ENTER, device 0, wait 1
[  373.224195] ata_tf_load: feat 0x0 nsect 0x0 lba 0x0 0x0 0x0
[  373.224253] ata_tf_load: device 0xA0
[  373.224321] ata_exec_command: ata5: cmd 0xEC
[  373.231994] ata_hsm_move: ata5: protocol 2 task_state 2 (dev_stat 0x58)
[  373.232057] ata_pio_sector: data read
[  373.232419] ata_hsm_move: ata5: protocol 2 task_state 3 (dev_stat 0x50)
[  373.232479] ata_hsm_move: ata5: dev 0 command complete, drv_stat 0x50
[  373.232562] ata_port_flush_task: ENTER
[  373.232618] ata5: ata_port_flush_task: EXIT
[  373.232622] ata5.00: ata_dev_configure: ENTER
[  373.232634] pdc20621_nodata_prep: ata5: ENTER
[  373.232692] pdc20621_ata_pkt: ENTER, dimm_sg == 0x200180, 2097536
[  373.232760] pdc20621_nodata_prep: ata pkt buf ofs 282, mmio copied
[  373.232819] pdc20621_packet_start: ata5: ENTER
[  373.232879] pdc20621_packet_start: submitted ofs 0x200100 (2097408), 
seq 1
[  373.232987] pdc20621_interrupt: ENTER
[  373.233045] pdc20621_interrupt: mask == 0x2
[  373.233103] pdc20621_interrupt: seq 1, port_no 0, ap de81c000, tmp 2
[  373.233162] pdc20621_host_intr: ENTER
[  373.233230] pdc20621_host_intr: BUS_NODATA (drv_stat 0x50)
[  373.233297] pdc20621_interrupt: seq 2, port_no 1, ap de820000, tmp 0
[  373.233357] pdc20621_interrupt: seq 3, port_no 2, ap de824000, tmp 0
[  373.233416] pdc20621_interrupt: seq 4, port_no 3, ap de828000, tmp 0
[  373.233475] pdc20621_interrupt: seq 5, port_no 0, ap de81c000, tmp 0
[  373.233535] pdc20621_interrupt: seq 6, port_no 1, ap de820000, tmp 0
[  373.233594] pdc20621_interrupt: seq 7, port_no 2, ap de824000, tmp 0
[  373.233654] pdc20621_interrupt: seq 8, port_no 3, ap de828000, tmp 0
[  373.233713] pdc20621_interrupt: mask == 0x2
[  373.233769] pdc20621_interrupt: EXIT
[  373.233828] ata_port_flush_task: ENTER
[  373.233886] ata5: ata_port_flush_task: EXIT
[  373.233890] ata5.00: ata_dev_configure: cfg 49:2f00 82:7c6b 83:7b09 
84:4003 85:7c69 86:3a01 87:4003 88:087f
[  373.233894] ata_dump_id: 49==0x2f00  53==0x0007  63==0x0007 
64==0x0003  75==0x0000
[  373.233964] ata_dump_id: 80==0x00fe  81==0x001e  82==0x7c6b 
83==0x7b09  84==0x4003
[  373.234033] ata_dump_id: 88==0x087f  93==0x600b
[  373.234092] ata5.00: ATA-7: Maxtor 6Y080P0, YAR41BW0, max UDMA/133
[  373.234095] ata5.00: 160086528 sectors, multi 0: LBA
[  373.234105] ata5.00: ata_dev_configure: EXIT, drv_stat = 0x50
[  373.234110] ata_dev_set_xfermode: set features - xfer mode
[  373.234168] pdc20621_nodata_prep: ata5: ENTER
[  373.234226] pdc20621_ata_pkt: ENTER, dimm_sg == 0x200180, 2097536
[  373.234292] pdc20621_nodata_prep: ata pkt buf ofs 282, mmio copied
[  373.234351] pdc20621_packet_start: ata5: ENTER
[  373.234411] pdc20621_packet_start: submitted ofs 0x200100 (2097408), 
seq 1
[  373.234520] pdc20621_interrupt: ENTER
[  373.234577] pdc20621_interrupt: mask == 0x2
[  373.234634] pdc20621_interrupt: seq 1, port_no 0, ap de81c000, tmp 2
[  373.234694] pdc20621_interrupt: seq 2, port_no 1, ap de820000, tmp 0
[  373.234754] pdc20621_interrupt: seq 3, port_no 2, ap de824000, tmp 0
[  373.234813] pdc20621_interrupt: seq 4, port_no 3, ap de828000, tmp 0
[  373.234872] pdc20621_interrupt: seq 5, port_no 0, ap de81c000, tmp 0
[  373.234932] pdc20621_interrupt: seq 6, port_no 1, ap de820000, tmp 0
[  373.234991] pdc20621_interrupt: seq 7, port_no 2, ap de824000, tmp 0
[  373.235051] pdc20621_interrupt: seq 8, port_no 3, ap de828000, tmp 0
[  373.235110] pdc20621_interrupt: mask == 0x2
[  373.235166] pdc20621_interrupt: EXIT
Above stuff seems to happen a couple of times...
[  403.217240] ata_port_flush_task: ENTER
[  403.217301] ata5: ata_port_flush_task: EXIT
[  403.217313] ata5.00: qc timeout (cmd 0xef)
[  403.217316] ata_dev_set_xfermode: EXIT, err_mask=4
[  403.217375] ata5.00: failed to set xfermode (err_mask=0x4)
[  403.217434] ata5.00: disabled
It finally bombs... Same thing happens for all 4 ports...

While I do know my way around Linux, C and a debugger, I'm still pretty 
blank when it comes ATA stuff... So any tips on where to go from here 
would highly appreciated...

Some questions:

* I guess the soft lockups during DIMM init are suspicious... Is it
   possible that the driver got the memory map wrong? The detected
   64 MB is correct... The SX4060 BIOS lists this information:

	Installed Memory Address: FE800000 Size: 64M
	Controller IRQ: 11
	ATA IO Address: E000
	XOR and HDMA IO Address: ED00
	Sequence Control IO Address: EC00
	Flash and SRAM Memory Address: FE900000

    But I don't know how to relate this to what's in the driver
    source...

*  Is it a reasonable assumption that SX4060 support could be achieved
    with fairly small changes to the sata_sx4 driver? (I realize that
    knowing exactly /what/ changes are needed is an entirely different
    matter...)

  * Is there any point in contacting Promise about information on this
    device? Or would I just be wasting my time?

  * Is it a correct assumption that the sata_sx4 driver knows nothing the
    various array configurations and that it will always just see 4
    independent drives, regardless of what arrays have been configured in
    the BIOS?

  * Also, is there any (easy) way to choke debug output from some ATA
    devices, while keeping it for others? Apart from grep... :-)

  * Would there be any useful information to gather from running the card
    with the Promise drivers under Windows or a 2.4 kernel?

I'd be happy to put in some time and effort in moving this forward but I 
probably won't make much progress need some pointers from some ATA-gurus...

/Lasse

Re: sata_sx4 vs. Promise SX4060

[Jeff Garzik]

Lasse Makholm wrote:
> 
> Hi,
> 
> I know it's been brought up here before, at least a few years ago
> (http://search.gmane.org/?query=sx4060&group=gmane.linux.ide) but here
> goes anyway...
> 
> I'm one of those semi-happy owners of a Promise SX4060 PATA RAID
> controller which is apparently only supported for some 2.4-something
> kernels...
> 
> Obviously I would a lot more happy with a 2.6 driver... :-)
> 
> So I've been googling high and low without much result, except finding
> out that the SX4060 is based on the same chip (the PDC20621) as the SATA
> 150 SX4, leading me to believe that the sata_sx4 driver is probably the
> best bet for getting the SX4060 working under 2.6 kernels...
> 
> Also, this comment in sata_sx4.c seems to support this suspicion:
> 
>     The SX4 behaves like a PATA chip, with no SATA controls or
>     knowledge whatsoever, leading to the presumption that
>     PATA<->SATA bridges exist on SX4 boards, external to the
>     PDC20621 chip itself.
> 
> All documentation I've been able to find on the devices indicate that 
> they are very similar...
> 
> I tried hacking the driver to recognize the SX4060 board number,
> essentially the same thing as described here:
> http://article.gmane.org/gmane.linux.ide/5435
> 
> ...with similar results. The controller is recognized and it also
> recognizes the attached drives, but it seems to have trouble 
> initializing the DIMM and with the ATA_SET_FEATURES command...
> 
> With ATA_DEBUG and ATA_DEBUG_VERBOSE, I get something like this (I have 
> the full log if someone wants to see it):
> 
> [  271.122187] pdc20621_dimm_init: Time Counter Register (0x44): 0xf0a6fb86
> [  271.122250] pdc20621_dimm_init: Num counters 0xf590479 (257492089)
> [  271.122309] pdc20621_dimm_init: 10 * Internal clk = 0x35a (858)
> [  271.122369] pdc20621_dimm_init: 10 * Internal clk * 33 = 0x6e9a (28314)
> [  271.122428] pdc20621_dimm_init: PLL F Param: 0x2f (47)
> [  271.122486] pdc20621_dimm_init: pci_status: 0x8a2f1824
> [  271.122721] pdc20621_dimm_init: Local DIMM Speed = 100
> [  271.124883] pdc20621_dimm_init: Local DIMM Size = 64MB
> [  271.125118] Local DIMM ECC Enabled
> [  271.226153] 0, 0,
> [  271.226220] 55, aa, Promise Not Yet Defined 1.1098
> [  271.226291] 55, aa, Promise Not Yet Defined 1.1098
> [  271.226524] pdc20621_dimm_init: Start ECC initialization
> [  281.972847] BUG: soft lockup - CPU#0 stuck for 11s! [modprobe:6153]
> Register and stack dump here...
> [  293.775043] BUG: soft lockup - CPU#0 stuck for 11s! [modprobe:6153]
> Register and stack dump here...
> [  305.581239] BUG: soft lockup - CPU#0 stuck for 11s! [modprobe:6153]
> Register and stack dump here...
> [  312.567607] pdc20621_dimm_init: Finish ECC initialization
> Lots of noise follows...
> [  312.768567] ata5: PATA max UDMA/44 mmio m1048576@0xfe900000 dimm 
> m32768@0xfe800000 port 0xfe900200 irq 17
> [  312.768571] ata6: PATA max UDMA/44 mmio m1048576@0xfe900000 dimm 
> m32768@0xfe800000 port 0xfe900280 irq 17
> [  312.768574] ata7: PATA max UDMA/44 mmio m1048576@0xfe900000 dimm 
> m32768@0xfe800000 port 0xfe900300 irq 17
> [  312.768577] ata8: PATA max UDMA/44 mmio m1048576@0xfe900000 dimm 
> m32768@0xfe800000 port 0xfe900380 irq 17
> More noise follows...
> [  342.918886] ata_port_flush_task: ENTER
> [  342.918947] ata5: ata_port_flush_task: EXIT
> [  342.918959] ata5.00: qc timeout (cmd 0xef)
> [  342.918962] ata_dev_set_xfermode: EXIT, err_mask=4
> [  342.919021] ata5.00: failed to set xfermode (err_mask=0x4)
> 
> Even more noise follows...
> 
> [  373.068199] ata5.00: failed to set xfermode (err_mask=0x4)
> [  373.068260] ata5.00: limiting speed to UDMA/44:PIO3
> [  373.068263] pdc_20621_phy_reset: ENTER
> [  373.068320] ata_bus_reset: ENTER, host 5, port 0
> [  373.068388] ata_bus_softreset: ata5: bus reset via SRST
> [  373.224003] ata_dev_classify: found ATA device by sig
> [  373.224068] ata_bus_reset: EXIT
> [  373.224125] ata5.00: ata_dev_read_id: ENTER
> [  373.224127] ata5: ata_dev_select: ENTER, device 0, wait 1
> [  373.224157] ata5: ata_dev_select: ENTER, device 0, wait 1
> [  373.224195] ata_tf_load: feat 0x0 nsect 0x0 lba 0x0 0x0 0x0
> [  373.224253] ata_tf_load: device 0xA0
> [  373.224321] ata_exec_command: ata5: cmd 0xEC
> [  373.231994] ata_hsm_move: ata5: protocol 2 task_state 2 (dev_stat 0x58)
> [  373.232057] ata_pio_sector: data read
> [  373.232419] ata_hsm_move: ata5: protocol 2 task_state 3 (dev_stat 0x50)
> [  373.232479] ata_hsm_move: ata5: dev 0 command complete, drv_stat 0x50
> [  373.232562] ata_port_flush_task: ENTER
> [  373.232618] ata5: ata_port_flush_task: EXIT
> [  373.232622] ata5.00: ata_dev_configure: ENTER
> [  373.232634] pdc20621_nodata_prep: ata5: ENTER
> [  373.232692] pdc20621_ata_pkt: ENTER, dimm_sg == 0x200180, 2097536
> [  373.232760] pdc20621_nodata_prep: ata pkt buf ofs 282, mmio copied
> [  373.232819] pdc20621_packet_start: ata5: ENTER
> [  373.232879] pdc20621_packet_start: submitted ofs 0x200100 (2097408), 
> seq 1
> [  373.232987] pdc20621_interrupt: ENTER
> [  373.233045] pdc20621_interrupt: mask == 0x2
> [  373.233103] pdc20621_interrupt: seq 1, port_no 0, ap de81c000, tmp 2
> [  373.233162] pdc20621_host_intr: ENTER
> [  373.233230] pdc20621_host_intr: BUS_NODATA (drv_stat 0x50)
> [  373.233297] pdc20621_interrupt: seq 2, port_no 1, ap de820000, tmp 0
> [  373.233357] pdc20621_interrupt: seq 3, port_no 2, ap de824000, tmp 0
> [  373.233416] pdc20621_interrupt: seq 4, port_no 3, ap de828000, tmp 0
> [  373.233475] pdc20621_interrupt: seq 5, port_no 0, ap de81c000, tmp 0
> [  373.233535] pdc20621_interrupt: seq 6, port_no 1, ap de820000, tmp 0
> [  373.233594] pdc20621_interrupt: seq 7, port_no 2, ap de824000, tmp 0
> [  373.233654] pdc20621_interrupt: seq 8, port_no 3, ap de828000, tmp 0
> [  373.233713] pdc20621_interrupt: mask == 0x2
> [  373.233769] pdc20621_interrupt: EXIT
> [  373.233828] ata_port_flush_task: ENTER
> [  373.233886] ata5: ata_port_flush_task: EXIT
> [  373.233890] ata5.00: ata_dev_configure: cfg 49:2f00 82:7c6b 83:7b09 
> 84:4003 85:7c69 86:3a01 87:4003 88:087f
> [  373.233894] ata_dump_id: 49==0x2f00  53==0x0007  63==0x0007 
> 64==0x0003  75==0x0000
> [  373.233964] ata_dump_id: 80==0x00fe  81==0x001e  82==0x7c6b 
> 83==0x7b09  84==0x4003
> [  373.234033] ata_dump_id: 88==0x087f  93==0x600b
> [  373.234092] ata5.00: ATA-7: Maxtor 6Y080P0, YAR41BW0, max UDMA/133
> [  373.234095] ata5.00: 160086528 sectors, multi 0: LBA
> [  373.234105] ata5.00: ata_dev_configure: EXIT, drv_stat = 0x50
> [  373.234110] ata_dev_set_xfermode: set features - xfer mode
> [  373.234168] pdc20621_nodata_prep: ata5: ENTER
> [  373.234226] pdc20621_ata_pkt: ENTER, dimm_sg == 0x200180, 2097536
> [  373.234292] pdc20621_nodata_prep: ata pkt buf ofs 282, mmio copied
> [  373.234351] pdc20621_packet_start: ata5: ENTER
> [  373.234411] pdc20621_packet_start: submitted ofs 0x200100 (2097408), 
> seq 1
> [  373.234520] pdc20621_interrupt: ENTER
> [  373.234577] pdc20621_interrupt: mask == 0x2
> [  373.234634] pdc20621_interrupt: seq 1, port_no 0, ap de81c000, tmp 2
> [  373.234694] pdc20621_interrupt: seq 2, port_no 1, ap de820000, tmp 0
> [  373.234754] pdc20621_interrupt: seq 3, port_no 2, ap de824000, tmp 0
> [  373.234813] pdc20621_interrupt: seq 4, port_no 3, ap de828000, tmp 0
> [  373.234872] pdc20621_interrupt: seq 5, port_no 0, ap de81c000, tmp 0
> [  373.234932] pdc20621_interrupt: seq 6, port_no 1, ap de820000, tmp 0
> [  373.234991] pdc20621_interrupt: seq 7, port_no 2, ap de824000, tmp 0
> [  373.235051] pdc20621_interrupt: seq 8, port_no 3, ap de828000, tmp 0
> [  373.235110] pdc20621_interrupt: mask == 0x2
> [  373.235166] pdc20621_interrupt: EXIT
> Above stuff seems to happen a couple of times...
> [  403.217240] ata_port_flush_task: ENTER
> [  403.217301] ata5: ata_port_flush_task: EXIT
> [  403.217313] ata5.00: qc timeout (cmd 0xef)
> [  403.217316] ata_dev_set_xfermode: EXIT, err_mask=4
> [  403.217375] ata5.00: failed to set xfermode (err_mask=0x4)
> [  403.217434] ata5.00: disabled
> It finally bombs... Same thing happens for all 4 ports...
> 
> While I do know my way around Linux, C and a debugger, I'm still pretty 
> blank when it comes ATA stuff... So any tips on where to go from here 
> would highly appreciated...

Well, the hardware programming guide for SX4 is available at
http://gkernel.sourceforge.net/specs/promise/

Can you post "lspci -vvv" entry for this device?  I'm betting that the 
SX4060 BIOS information is merely echoing what is in the PCI BARs for 
the PCI device.


> Some questions:
> 
> * I guess the soft lockups during DIMM init are suspicious... Is it
>   possible that the driver got the memory map wrong? The detected
>   64 MB is correct... The SX4060 BIOS lists this information:
> 
>     Installed Memory Address: FE800000 Size: 64M
>     Controller IRQ: 11
>     ATA IO Address: E000
>     XOR and HDMA IO Address: ED00
>     Sequence Control IO Address: EC00
>     Flash and SRAM Memory Address: FE900000
> 
>    But I don't know how to relate this to what's in the driver
>    source...

Anything is possible when two pieces of h/w are different :)

You could try commenting out the DIMM init stuff in the driver 
completely, on the hope that BIOS configured it properly.


> *  Is it a reasonable assumption that SX4060 support could be achieved
>    with fairly small changes to the sata_sx4 driver? (I realize that
>    knowing exactly /what/ changes are needed is an entirely different
>    matter...)

Dunno.  Your progress so far is a really good sign, and Promise 
certainly re-uses designs, so it is a reasonable theory, at least...


>  * Is there any point in contacting Promise about information on this
>    device? Or would I just be wasting my time?

I've been the one getting Promise to release docs, but it's a slow 
process that (literally) has taken years.

However, that said, they _do_ respond and _are_ interested.  You might 
try promise_linux@promise.com and point out that the existing SX4 docs 
are publicly released at http://gkernel.sourceforge.net/specs/promise/ 
with the blessing of Chi and Sam @ Promise.


>  * Is it a correct assumption that the sata_sx4 driver knows nothing the
>    various array configurations and that it will always just see 4
>    independent drives, regardless of what arrays have been configured in
>    the BIOS?

Correct.


>  * Also, is there any (easy) way to choke debug output from some ATA
>    devices, while keeping it for others? Apart from grep... :-)

Alas, not at present.

There is a half-finished infrastructure in libata, but messages need to 
be moved over to it (ap->msg_enable).


>  * Would there be any useful information to gather from running the card
>    with the Promise drivers under Windows or a 2.4 kernel?

<shrug>  Those are all useful tools for the toolbox, certainly.  Nothing 
pops into my head immediately, but those are definitely tools to keep 
around for this type of endeavor.


> I'd be happy to put in some time and effort in moving this forward but I 
> probably won't make much progress need some pointers from some ATA-gurus...

If you are looking for generic ATA programming information, 
http://ata.wiki.kernel.org/index.php/Developer_Resources tries to give 
the basics.  Even if there is a broken link, you can usually google for 
a filename to find a bazillion copies of the spec in question.

Regards,

	Jeff

Re: sata_sx4 vs. Promise SX4060

[Lasse Makholm]

Jeff Garzik wrote:
> Lasse Makholm wrote:
[SNIP]
>> While I do know my way around Linux, C and a debugger, I'm still 
>> pretty blank when it comes ATA stuff... So any tips on where to go 
>> from here would highly appreciated...
> 
> Well, the hardware programming guide for SX4 is available at
> http://gkernel.sourceforge.net/specs/promise/

Cool! I've been chewing through a lot of this stuff over the past few 
days and I'm least starting to get some idea of what I'm messing with... :-)

I also browsed through your documentation on libata but it's still hard 
for me to grasp the information without having more of an overview of 
how it all works... I'm hoping that Essential Linux Device Drivers can 
help me out there but my copy hasn't arrived yet... :-)

> Can you post "lspci -vvv" entry for this device?  I'm betting that the 
> SX4060 BIOS information is merely echoing what is in the PCI BARs for 
> the PCI device.

Certainly...

00:0d.0 RAID bus controller: Promise Technology, Inc. PDC20621 (FastTrak
S150 SX4/FastTrak SX4000 lite) (rev 01)
	Subsystem: Promise Technology, Inc. PDC20621 (FastTrak S150
SX4/FastTrak SX4000 lite)
	Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
	Interrupt: pin A routed to IRQ 17
	Region 0: I/O ports at e000 [size=256]
	Region 1: I/O ports at ed00 [size=256]
	Region 2: I/O ports at ec00 [size=256]
	Region 3: Memory at fe900000 (32-bit, non-prefetchable) [size=1M]
	Region 4: Memory at fe800000 (32-bit, non-prefetchable) [size=32K]
	Expansion ROM at fe700000 [disabled] [size=64K]
	Capabilities: [60] Power Management version 1
		Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

Looks like your assumption was correct...

As far as I understand it, the 64 MB on the DIMM is accessed one 32 KB 
page at a time through the area at fe800000. Is that correct?

> You could try commenting out the DIMM init stuff in the driver 
> completely, on the hope that BIOS configured it properly.

I tried adding an msleep_interruptible(10) for every MB written in the 
initialization loop and that seems to work pretty well... It still 
puzzles me a bit that the problem is there at all though... Is it 
reasonable that it takes so long to write those 64 MB?

By the way, is msleep_interruptible() always safe to call?

I was wondering why the init stuff is there at all... Is it to ensure 
that content of the SDRAM is aligned with the parity bits?

What exactly does this do:

	/* DIMM Initialization Select/Enable (bit 18/19) */
	data &= (~(1<<18));
	data |= (1<<19);
	writel(data, mmio + PDC_SDRAM_CONTROL);

I couldn't find any details about it in the PDC20621 programming guides, 
so I assume it's some basic memory-related knowledge that I don't have...

I also tried writing some test patterns into the memory in the init 
loop, reading them back out and comparing to the original (using 
pdc20621_put_to_dimm() and pdc20621_get_from_dimm())

u32 patterns[10] = {
	0xffffffff, 0xff00ff00, 0x00ff00ff, 0xf0f0f0f0, 0x0f0f0f0f,
	0xcccccccc, 0x33333333, 0xaaaaaaaa, 0x55555555, 0x00000000,
};

for (j = 0; j < 10; j++) {
	tmp = patterns[j];
	pdc20621_put_to_dimm(host, (void *) &tmp, addr, sizeof(u32));
	pdc20621_get_from_dimm(host, (void *) &tmp, addr, sizeof(u32));
	if (tmp != patterns[j])
		VPRINTK("Ouch! Addr 0x%08x: 0x%08x != 0x%08x\n",
			addr, tmp, patterns[j]);
}

...but that miserably failed... I suspect I'm missing something here... 
Any hints?

Why is a writel() always(?) followed by readl() by the way? Google 
hasn't been able to tell me that so far...

All commands (as opposed to just block transfers) are always copied to 
the onboard DIMM before being sent to an ATA port, correct?

The ATA_CMD_SET_FEATURES command still seems to be the main problem though:

[ 1115.001429] ata5.00: qc timeout (cmd 0xef)
[ 1115.001434] ata5.00: failed to set xfermode (err_mask=0x4)
[ 1115.001437] ata5.00: disabled

The error mask is AC_ERR_ATA_BUS but I don't have much of a clue as to 
why that happens yet...

> I've been the one getting Promise to release docs, but it's a slow 
> process that (literally) has taken years.
> 
> However, that said, they _do_ respond and _are_ interested.  You might 
> try promise_linux@promise.com and point out that the existing SX4 docs 
> are publicly released at http://gkernel.sourceforge.net/specs/promise/ 
> with the blessing of Chi and Sam @ Promise.

That's really good news. I think I'll poke around some more and try to 
get a feel for what I'm doing before I start bothering the nice folks at 
Promise though. But I'll definitely get in touch with you if/when I 
decide to write them...

>>  * Is it a correct assumption that the sata_sx4 driver knows nothing the
>>    various array configurations and that it will always just see 4
>>    independent drives, regardless of what arrays have been configured in
>>    the BIOS?
> 
> Correct.

...and is it then also correct that said knowledge about array configs 
is/belongs in the dmraid stuff?

>>  * Also, is there any (easy) way to choke debug output from some ATA
>>    devices, while keeping it for others? Apart from grep... :-)
> 
> Alas, not at present.
> 
> There is a half-finished infrastructure in libata, but messages need to 
> be moved over to it (ap->msg_enable).

OK. I might look into that... Is it lightyears from usable or would it 
be worth looking into?

>> I'd be happy to put in some time and effort in moving this forward but 
>> I probably won't make much progress need some pointers from some 
>> ATA-gurus...
> 
> If you are looking for generic ATA programming information, 
> http://ata.wiki.kernel.org/index.php/Developer_Resources tries to give 
> the basics.  Even if there is a broken link, you can usually google for 
> a filename to find a bazillion copies of the spec in question.

Ah, thanks... Nice to meet you, 900+ page ATA spec! :-)

Anyway, I've (again) been googling high and low in search of basic 
"bootstrapping" knowledge about this stuff and now that I've found at 
least some of it (I now know what a PRD is - yay!), I'm thinking that it 
could be helpful to others...

Would be an idea maybe to create a page or two on ata.wiki.kernel.org 
with e.g. terminology and other basic stuff?

/Lasse

Re: sata_sx4 vs. Promise SX4060

[Nicolas Tuffier]

I'm higly interested in driver for this hardware.
I also have an SX4060 with 3 drives and need to use it with kernel 2.6.25.
I'm trying to get info from Promise Support and unsuccessfully tried to compile
partial source code found at http://www.lugh.de/promise/