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

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

[Alex Ivanov]

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

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

[Steve Simon]

I am in no position to help, sorry, however I would love to
have access to a plan9 port to the HP t5325.

-Steve

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

[Alex Ivanov]

Steve Simon <steve <at> quintile.net> writes:

>
> I am in no position to help, sorry, however I would love to
> have access to a plan9 port to the HP t5325.
>
> -Steve
>
>

Steve,

There is no special port to this single device. There is a port to the
Marvell Kirkwood SoCs in Plan 9 main code tree:
http://plan9.bell-labs.com/sources/plan9/sys/src/9/kw/ which
covers 88f6281 used in this hardware.
I've just followed Guruplug guide to run Plan 9 on that HP device:
http://plan9.bell-labs.com/wiki/plan9/guruplug/index.html

P.S.: There is also a port of Inferno:
https://code.google.com/p/inferno-kirkwood/

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

[Steve Simon]

I suspose I was thinking of audio, video, and SATA drivers rather than a new kernel.

Does the SoC include the video device?

I suspose what I am really asking is "what doesn't work"

-Steve

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

[Alex Ivanov]

Steve Simon <steve <at> quintile.net> writes:

> I suspose I was thinking of audio, video, and SATA drivers
> rather than a new kernel.
> Does the SoC include the video device?

I would like to have full support for this device too, but it's
an unpopular one, so there is a little chance that it will have
a full port of anything besides the Linux anytime. It's better
to go with Plan 9 @ Raspberry Pi now and in near future.

There is no audio driver for Kirkwook, but it shall be written
universal for all devices. t5325 doesn't need any special
handling, except the audio ports layout and an alc5621
codec driver.

SoC doesn't include the video device. Instead, a rare PC card
XGI VOLARI Z11 is plugged into PCI-E port. The platform
knows nothing about it, so it must be POSTed by a driver,
which is an odd hassle.

There are SATA drivers in 9atom (sdkw) and Inferno (devsata).
Though, none of them work on my device, but this only
because something blocks SATAHC from proper functioning.

>
>
> I suspose what I am really asking is "what doesn't work"

Well, the kmesg i've posted should give you an initial info.
I have no possibility to test the stuff until i get local boot
or will set a network/auth server for proper network boot.
Ethernet works. USB controller got recognized. That's all.

>
> -Steve
>
>

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

[Steve Simon]

thanks for the info, i have a pi and audio for that is further up my list,
but i have just bought a t5325 on ebay so i will have a go at that
some time in the future - just one more for the todo list...


> On 13 Mar 2014, at 05:36, Alex Ivanov <gnidorah@p0n4ik.tk> wrote:
>
> Steve Simon <steve <at> quintile.net> writes:
>
>> I suspose I was thinking of audio, video, and SATA drivers
>> rather than a new kernel.
>> Does the SoC include the video device?
>
> I would like to have full support for this device too, but it's
> an unpopular one, so there is a little chance that it will have
> a full port of anything besides the Linux anytime. It's better
> to go with Plan 9 @ Raspberry Pi now and in near future.
>
> There is no audio driver for Kirkwook, but it shall be written
> universal for all devices. t5325 doesn't need any special
> handling, except the audio ports layout and an alc5621
> codec driver.
>
> SoC doesn't include the video device. Instead, a rare PC card
> XGI VOLARI Z11 is plugged into PCI-E port. The platform
> knows nothing about it, so it must be POSTed by a driver,
> which is an odd hassle.
>
> There are SATA drivers in 9atom (sdkw) and Inferno (devsata).
> Though, none of them work on my device, but this only
> because something blocks SATAHC from proper functioning.
>
>>
>>
>> I suspose what I am really asking is "what doesn't work"
>
> Well, the kmesg i've posted should give you an initial info.
> I have no possibility to test the stuff until i get local boot
> or will set a network/auth server for proper network boot.
> Ethernet works. USB controller got recognized. That's all.
>
>>
>> -Steve
>
>
>
>

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

[erik quanstrom]

> > I suspose what I am really asking is "what doesn't work"
>
> Well, the kmesg i've posted should give you an initial info.
> I have no possibility to test the stuff until i get local boot
> or will set a network/auth server for proper network boot.
> Ethernet works. USB controller got recognized. That's all.

you can't take root from the net, or usb?

- erik

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

[Alex Ivanov]

erik quanstrom <quanstro <at> quanstro.net> writes:

>
> > > I suspose what I am really asking is "what doesn't work"
> >
> > Well, the kmesg i've posted should give you an initial info.
> > I have no possibility to test the stuff until i get local boot
> > or will set a network/auth server for proper network boot.
> > Ethernet works. USB controller got recognized. That's all.
>
> you can't take root from the net, or usb?

Erik,

I can't take root from the net, but that's my fault.
How can i do USB boot? I thought that USB mass storage
devices aren't supported:
> BTW, anyone plans to work on USB flash storage support,
> so we can just use some USB drives to boot from?

>
> - erik
>
>

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

[erik quanstrom]

> I can't take root from the net, but that's my fault.  How can i do USB
> boot?  I thought that USB mass storage devices aren't supported:

i've set up several machines to boot from usb, and the installer
that i've been working on boots from usb.  i can't tell you how
to set up u-boot, but if you'll be using partitions, usbd and either
partfs or sdloop needs to be built into the kernel.  since i use
sdloop, i don't think i can give you good directions.  but basically,
you want to set up nobootprompt=path-to-usb-storage in plan9.ini.

- erik

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

[Alex Ivanov]

erik quanstrom <quanstro <at> quanstro.net> writes:

>
> > I can't take root from the net, but that's my fault.  How can i do USB
> > boot?  I thought that USB mass storage devices aren't supported:
>
> i've set up several machines to boot from usb, and the installer
> that i've been working on boots from usb.

Please make an announce on it, when you'll finish :)

Sorry, but as i've already said, i'm a Plan 9 newbie.
All the Plan 9 @ Kirkwood tutorials i've found assist only on
netboot methods. Maybe someone could add USB boot part?
Here for example:
http://plan9.bell-labs.com/wiki/plan9/guruplug/index.html

> i can't tell you how to set up u-boot

No need, thanks, i know how.

> but if you'll be using partitions, usbd and either
> partfs or sdloop needs to be built into the kernel.

Usbd and partfs are enabled in standard Plan 9 "plug" kernel, so
should be no problem there.
I have a USB flash drive with written Plan 9 "rpi" image over there,
thought an OS doesn't show any signs that it was recognized.

> since i use
> sdloop, i don't think i can give you good directions.  but basically,
> you want to set up nobootprompt=path-to-usb-storage in plan9.ini.
>
> - erik

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

[erik quanstrom]

> Please make an announce on it, when you'll finish :)
>
> Sorry, but as i've already said, i'm a Plan 9 newbie.
> All the Plan 9 @ Kirkwood tutorials i've found assist only on
> netboot methods. Maybe someone could add USB boot part?
> Here for example:
> http://plan9.bell-labs.com/wiki/plan9/guruplug/index.html

i don't have a spare machine to experiment on, or enough time.
sorry.  i think the options that make most sense involve getting
something --- a pc or pi to netboot from.

- erik

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

[Alex Ivanov]

09 марта 2014 г., в 18:11, erik quanstrom <quanstro@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

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

[erik quanstrom]

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.

also try unplugging the usb devices.  the host bridge error is
omnious.  often a host bridge error will screw up multiple devices.

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.

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

i don't think that's it.

- erik