-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

NetBSD experiment from last week reveals the following behaviour
(a complete failure to init a sata drive):

/////////////////////////////////////////////////////////////////////////
mvsata0 port 0: device present, speed: 3.0Gb/s
wd0 at atabus0 drive 0 wd0:
<?M^??M^??M^??M^??M^??M^??M^??M^??M^??M^??M^??M^??M^??M^??M^??M^??M^??M^?
?M^??M^?> wd0: drive supports 255-sector PIO transfers, LBA48 addressing 
wd0: 16287 PB, 1310804 cyl, 16383 head, 16383 sec, 512 bytes/sect x 
4611474908973580287 sectors
[...snipped log...]
wd0: IDENTIFY failed
wd0: unable to open device, error = 5
/////////////////////////////////////////////////////////////////////////

So I decided to go back and see how the drive behaves in raw u-boot,
prior to os loading - and sure enough:

/////////////////////////////////////////////////////////////////////////
Pogov4> ide reset

Reset IDE: Bus 0: OK Bus 1: not available     Device 0: Model:
?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ Firm: ?ÿ?ÿ?ÿ?ÿ Ser#: 
?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ?ÿ             Type: Hard Disk             
Supports 48-bit addressing             Capacity: 524263.9 MB = 511.9 GB 
(1073692671 x 512) IDE read: device 0 not ready IDE read: device 0 not ready
/////////////////////////////////////////////////////////////////////////

So we get garbage during init.

At first assumed that mvsata.c
(http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/ic/mvsata.c,
Kiyohara Takashi, 
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x37207C581D932701)
is hopelessly broken. But then dug around and unearthed a variety of sata 
drives, and discovered that the behaviour appears to afflict only ones made
by SanDisk.

Here's a disk from a deceased Apple box:
Going back to u-boot console,

/////////////////////////////////////////////////////////////////////////
Pogov4> ide reset

Reset IDE: Bus 0: OK Bus 1: not available     
Device 0: Model: APPLE SSD TS128B Firm: AGAA0206 Ser#: 40AS10DTT61Z
             Type: Hard Disk             Supports 48-bit addressing
             Capacity: 115712.0 MB = 113.0 GB (236978176 x 512)
/////////////////////////////////////////////////////////////////////////

NetBSD:

/////////////////////////////////////////////////////////////////////////
mvsata0 port 0: device present, speed: 3.0Gb/s
wd0 at atabus0 drive 0 wd0: <APPLE SSD TS128B> 
wd0: 113 GB, 235097 cyl, 16 head, 63 sec, 512 bytes/sect x 236978176 sectors

# fdisk fdisk: Cannot determine the number of heads

Disk: /dev/rsd0c NetBSD disklabel disk geometry: 

cylinders: 959, heads: 255, sectors/track: 32 (8160 sectors/cylinder)
total sectors: 7831552

[...snip...]
/////////////////////////////////////////////////////////////////////////

Problem with SanDisk unit is -not- observed on ArchLinux/pogo
(built with github.com
/archlinuxarm/PKGBUILDs/blob/master/core/linux-kirkwood/archlinuxarm.patch

but it appears now that the issue is less urgent than it first appeared to be.
'Doctor, it hurts when I do that.' -- 'Don't do that.'

Manufacturer's data sheet re: pogo SOC,
http://www.marvell.com
/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf

provides no obvious clue re: the curiosity described here.

If anyone feels like trying their hand at this mystery, everything you need
(with the exception of a 'pogo' and a SandDisk drive...) is contained
in this document.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQEcBAEBCgAGBQJU7nsbAAoJELmCKKABq//H4JwH/1xnV+Cba3Xs3X+guFhgdDS3
S28mlSJV9lhMoG3TavMeScpAMNMteaUlzBZ3vn9I/v2B/oXhYFh+ygg/w6mQhEMC
GNSjdJ0LvXE3VfSaIbZ4rU/hmb7yENZb83qSqknK0H6WE6SB37URyRvz6kbFRIGz
SZc6YLWMiuROIgn1XIXZQRfYcdzGAx7o9KqyjH27/GYaijGQUtZUyYTsyzTtvb2Z
Y4dzpugD4ChQL5azua30tcb1AjyGditxzZ3GZs5r9CqH46NjmRka1TcKVs6Nepy6
blJHN61AodWqpqBwZDO6OdOQ40uiMnQ3cBQ9RUBU+AnT+NFtw8CVQjAzod0vo2s=
=MehM
-----END PGP SIGNATURE-----