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