SATA

An integrated Serial ATA interface is available on Allwinner A10 and A20 SoCs.

Specifications
From A10 EVB Manual :


 * Supports SATA 1.5Gb/s, and SATA 3.0Gb/s
 * Compliant with SATA Spec. 2.6, and AHCI Revision 1.3 Specifications
 * Supports industry-standard AMBA High-Performance Bus (AHB) and it is fully compliant with the AMBA Specification, Revision 2.0.
 * Supports 32-bit Little Endian
 * OOB signaling detection and generation
 * SATA 1.5Gb/s and SATA 3.0Gb/s speed negotiation when Tx OON signaling is selected
 * Supports device hot-plugging
 * Support power management features including automatic Partial to Slumber transition
 * Internal DMA Engine for Command and Data Transactions
 * Supports hardware-assisted Native Command Queuing (NCQ) for up to 32-entries
 * Support external SATA (eSATA)

The A20 user manual lists identical SATA/AHCI interface features.

Performance
It has been tested to work up to 60MB/s.

SATA throughput is unbalanced for unknown reasons: With appropriate cpufreq settings it's possible to get sequential read speeds of +200 MB/s while write speeds retain at approx. 45 MB/s. This might be caused by buggy silicone or driver problems.

Unlike other platforms sequential SATA transfer rates on A10/A20 scale somewhat linearly with both cpufreq settings and DRAM clock. In case you use the wrong cpufreq settings it's impossible to achieve maximum SATA performance (eg. using the ondemand governor without io_is_busy setting).

On the dual-core A20 setting both CONFIG_SCHED_MC=y and CONFIG_SCHED_SMT=y at kernel compile time seems to increase SATA throughput (sequential reads +10 MB/s).

Also worth a look are Linux' I/O schedulers. If your SATA disk is available as /dev/sda you can query /sys/block/sda/queue/scheduler to get the list of available I/O schedulers (the active printed in brackets) and change the scheduler either globally by supplying elevator=deadline to bootargs environment or on a per device basis using echo deadline >/sys/block/sdN/queue/scheduler (deadline seems to be the most performant scheduler on A10/A20)

Since irqbalancing isn't working on sunxi/ARM one way to get better SATA throughput on A20 devices is to assign all AHCI/SATA IRQs to the second CPU core using echo 2 >/proc/irq/$(awk -F":" '/ahci/ {print $1}' </proc/interrupts)/smp_affinity

Port multipliers
A port multiplier allows to connect multiple SATA devices to a single SATA host port. Since sunxi devices with SATA are restricted to only one port, support for the port multiplier protocol (PMP) is a desirable feature. However, this requires suitable hardware (SATA controller) and software (AHCI driver).

PMP support - using SATA port multipliers with sunxi devices

 * A10 is frequently said not to support PMP due to hardware limitations and/or older SATA specification. But some documents (A10 EVB manual) indicate capabilities identical to the A20 (see above), and a patch submission from Hans de Goede suggests he tested PMP with both A10- and A20-based devices.
 * The A20's SATA controller is confirmed to support PMP from a variety of sources.

Originally the sunxi_ahci driver derived from Allwinner sources deliberately disabled PMP by always indicating. The reason probably was that while the A20 can do PMP, enabling it breaks compatibility with single drive (non-PMP) mode - so the two are mutually exclusive. (The patch mentioned above states this is due to an inability to issue a proper soft reset to a single drive after port multiplier mode gets enabled.)

A workaround is to compile the driver as a module, and use the  option as desired at load time (/etc/modprobe.d/ahci-sunxi.conf in most distros).

Caveats
If you rely exclusively on a port multiplier to access multiple drives, you're introducing a single point of failure (SPoF). Using this technology in an attempt to increase reliability (e.g. by constructing a RAID array) therefore is questionable.

Cheap port multipliers like JMB321/JMB393 are prone to overheating under load and then start to corrupt data or stop working at all. This adds significantly to the SPoF problem since if you build a RAID on top of such a port multiplier setup, the likelihood that you lose your whole array when you would need it will increase dramatically - as running a rebuild (after replacing a failed disk) will put significant stress on the system. Combining cheapest/unreliable components to increase reliability might work in some cases, but definitely not with PM based RAID.