From mboxrd@z Thu Jan  1 00:00:00 1970
From: Alex Ivanov <gnidorah@p0n4ik.tk>
Content-Type: text/plain; charset=windows-1251
Content-Transfer-Encoding: quoted-printable
Date: Sun,  9 Mar 2014 12:34:38 +0400
Message-Id: <009CEB4D-869E-49D3-AD6F-9D78772CB270@p0n4ik.tk>
To: Erik Quanstrom <quanstro@quanstro.net>
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
Cc: 9fans@9fans.net
Subject: [9fans] sdkw - SATA drive detection broken (was ARM and u-boot)
Topicbox-Message-UUID: c63daa2a-ead8-11e9-9d60-3106f5b1d025

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

> - erik=20

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

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

I=92ve did an initial debug and found that SATA device detection never =
works. To compare this with NetBSD, i=92ve added a code with identical =
meaning to an early stages (prior of doing of anything else; i=92ve =
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=92m 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] =3D 3*Aipm | 0*Aspd | Adet; (I=92m 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] =3D 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=85 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=92ve 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=92t help, though i =
doubt it=92s a sync issue;
3) If i fool sdkw to make it think it found the device, i=92m getting an =
error from upper the stack, like it can=92t speak with device or so=85 =
So i twice doubt it=92s a sync issue, and it=92s more likely SATA =
controller doesn=92t work by some reason.

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

Thanks for any help!=