09 марта 2014 г., в 18:11, erik quanstrom <quans...@quanstro.net> написал(а):
Erik, thanks for the quick answer! > this is fun. i wrote this driver a long time ago. but all the little > quirks (even of the documentation) come back quickly. i put > the kernel i'm running up on 9atom you can download them > @ > http://ftp.9atom.org/other/9plug > http://ftp.9atom.org/other/s9plug > or > 9fs atom; fcp /n/atom/ftp/*9plug /some/where > > please try that kernel and let me know. since the driver > does hotplugging, it might be after you've connected to the file > server that you get a connection. Are these ones differ from those built from source after unrolling of 9atom.iso.bz2? Sry, but i’m a total Plan 9 noob and can’t set a working file+auth server. Any guides i was followed were either misleading or wrong at some step. Anyway, since i’m never getting Spresent bit in Sstatus (no matter how much time passed after the boot), status change will not ever come. > > also try unplugging the usb devices. Have them unplugged all the time. BTW, anyone plans to work on USB flash storage support, so we can just use some USB drives to boot from? > the host bridge error is > omnious. often a host bridge error will screw up multiple devices. So it may be a culprit? > > here's the results i get > > kw# cat /dev/kmesg > 127 holes free > 009a9000 03be5000 52674560 > 52674560 bytes free > 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 A0; arm926ej-s arch v5te rev 2.1 part > 131 > #S/sd0: sata ii 2 ports > #F0: kwnand: Hy27UF084G2M 536,870,912 bytes pagesize 2048 erasesize > 131,072 spares per page 64 > #l0: 88e1116: 1000Mbps port 0xf1072000 irq 11 tu 1514: 00504301db37 > #l1: 88e1116: 1000Mbps port 0xf1076000 irq 15 tu 1514: 00504301db38 > #u/usb/ep1.0: ehci: port 0xf1050100 irq 19 > preallocate 16384 x 4096 KB 0x03be5000-0x07be5000 > 504M memory: 52M kernel data, 452M user, 0M swap > usb/hub... version...time... > > init: starting /bin/rc > kw# sd01: status: 000 -> 123: new > sd01: llba 78,165,360 sectors > INTEL SSDSA2M040G2GC 2CV102HD CVGB03800093040NGN [newdrive] > > > kw# cat /dev/sd00/ctl > inquiry > state null > sig 00000000 > link down > sstatus 00000000 > serror 00000000 > sctl 00000300 > isr 00804000 > icfg 009b7095 > ifccr 00000000 > geometry 0 0 > > > kw# cat /dev/sd01/ctl > inquiry INTEL SSDSA2M040G2GC > state ready > sig 01010101 > model INTEL SSDSA2M040G2GC > serial CVGB03800093040NGN > firm 2CV102HD > wwn 50015179593f82f0 > tler 5000 > link up > sstatus 00000123 > serror 14010000 > sctl 00000300 > isr 00404034 > icfg 009b7095 > ifccr 00000000 > geometry 78165360 512 > part data 0 78165360 > > you mention that the first thing you do is this > > 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). > > this doesn't jive with the sata spec (the ahci spec, which for the S registers > mirrors it, is more accessible). it may be beneficial to read the spec. > the actions that need to be done are > 1. clear the Serror register (sdkw:1228) > 2. set the Icfg register (sdkw:1229) > (the setting of emphasis was a guess and could be wrong for > your device. it may also vary by device.) > 3. reset the phy. this is a 3 step process in linkrst() > a) turn on device detection > b) wait 1ms (unsure of this timing, it could be longer) > c) turn off device detection > > 3*Aspm requests transition to active state. if you get bad results > by turning the device on, then something else is wrong. :-) > > in fact you mention that Sctl = 300, which means that the device > is asleep. (Iactive|Isleepy if you follow pc/ahci.h) > >> Not changed at all… WTF? > > you must clear the error register first. You’re absolutely right, but i’m in the same situation (status = 0) even with the whole init routine, which your driver does. > (the setting of emphasis was a guess and could be wrong for > your device. it may also vary by device.) I will check it. > b) wait 1ms (unsure of this timing, it could be longer) Not my case. Already tried to bump this delay. Ok… I will trace everything when using proper initialization, but i doubt it will clear anything, since i was not followed SATA spec, and did just a device probe, and while this didn’t work on Plan 9, it worked on NetBSD. Maybe it that host bridge issue? > >> Maybe NetBSD SoC driver code does some init, which Plan 9 doesn’t? > > i don't think that's it. > > - erik > Alex
