[9fans] sdkw - SATA drive detection broken (was ARM and u-boot)

[Alex Ivanov <gnidorah@p0n4ik.tk>]

> well, good luck.  there's a sata driver in 9atom. 

> - erik 

Hi, Eric et al.

Thanks for the driver! :) I however have problem using it.

My device is a HP t5325 which is almost the same as any other 88F6281 *plug:

"Plan 9 from Bell Labs

l1 D: 16384 bytes, 4 ways 128 sets 32 bytes/line; write-through only
l1 I: 16384 bytes, 4 ways 128 sets 32 bytes/line; write-back type `reg 7 ops, format C' (016) possible
l2 cache: 256K or 512K: 4 ways, 32-byte lines, write-back, sdram only
cpu0: 1200MHz ARM Marvell 88F6281 A1; arm926ej-s arch v5te rev 2.1 part 131
#S/sd0: sata ii 2 ports
#l0: 88e1116: 100Mbps port 0xf1072000 irq 11: f4ce4623eb6a
#l1: ether1116: init mii failure
#u/uspurious irqbridge interrupt: 00000010
sb/ep1.0: ehci: port 0XF1050100 irq 19
504M memory: 52M kernel data, 452M user, 1959M swap
root is from (tcp)[tcp]: filesystem IP address[no default]:"

There is an internal SATA flash drive connected to a 1st port of Marvell SATAHC and while NetBSD, for example, is able to recognize it:

"mvsata0 at mvsoc0 unit 0 offset 0x80000-0x87fff irq 21: Marvell Serial-ATA Host Controller (SATAHC)
mvsata0: GenIIe, 1hc, 2port/hc
atabus0 at mvsata0 channel 0
atabus1 at mvsata0 channel 1
mvsata0 port 0: device present, speed: 3.0Gb/s
wd0 at atabus0 drive 0
wd0: <SM224>
wd0: 463 MB, 942 cyl, 16 head, 63 sec, 512 bytes/sect x 949536 sectors»

Plan 9 isn’t (as you see from it's kmesg).

I’ve did an initial debug and found that SATA device detection never works. To compare this with NetBSD, i’ve added a code with identical meaning to an early stages (prior of doing of anything else; i’ve snarf pasted even register bits for sure) of both Plan 9 and NetBSD drivers (sdkw.c and mvsata_mv.c accordingly) and here are the results. I’m including info about port 1 only, as port 2 has no devices.

Busaddrs going the same on both systems:
Port_addr 0xf1082000
SStatus_addr 0xf1082300
SErr_addr 0xf1082304
Sctl_addr 0xf1082308

As well as initial state of registers:
1)
Sctl 0x00000004
SErr: 0x04000000

SStatus: 0x00000004
det: PHY offline
ipm: no device connected

Next doing hard reset:
d->reg[Sctl] = 3*Aipm | 0*Aspd | Adet; (I’m omitting | 3*Aspm as it done in NetBSD, though the results are bad even with it).

2)
Sctl: 0x00000301
SErr: 0x04000000

SStatus: 0x00000000
det: no device present
ipm: no device connected

Device detection should work after this:
d->reg[Sctl] = 3*Aipm | 0*Aspd | 0*Adet;

And here is the wreck:

3)
Sctl: 0x00000300

NetBSD:
SErr: 0x14010000

SStatus: 0x00000123
det: device present, speed: 3.0Gb/s
ipm: ACTIVE state

Plan 9:
SErr: 0x04000000

SStatus: 0x00000000
det: no device present
ipm: no device connected

Not changed at all… WTF?

Another case where IPM is active (occurs from time to time) is even stranger:
1)
Sctl 0x00000004
SErr: 0x04000000

SStatus: 0x00000104
det: PHY offline
ipm: ACTIVE state

2)
Sctl: 0x00000301

NetBSD:
Err: 0x14000000

SStatus: 0x00000100
det: no device present
ipm: ACTIVE state

Plan 9:
SErr: 0x04000000

SStatus: 0x00000101
det: device connected, but communication not established
ipm: ACTIVE state

3)
Sctl: 0x00000300

NetBSD:
SErr: 0x14010000

SStatus: 0x00000123
det: device present, speed: 3.0Gb/s
ipm: ACTIVE state

Plan 9:
SErr: 0x04000000

SStatus: 0x00000101
det: device connected, but communication not established
ipm: ACTIVE state

So, any ideas?
What i’ve already tried:
1) Put the code in another place of Plan 9, like USB driver. Results are the same;
2) Put delays and coherence() here and there. Doesn’t help, though i doubt it’s a sync issue;
3) If i fool sdkw to make it think it found the device, i’m getting an error from upper the stack, like it can’t speak with device or so… So i twice doubt it’s a sync issue, and it’s more likely SATA controller doesn’t work by some reason.

Sigh :(
Maybe NetBSD SoC driver code does some init, which Plan 9 doesn’t?

Thanks for any help!