Support status of SATA port multipliers connected to A20

21 20861
Edited by tkaiser at Mon Feb 2, 2015 02:04

Just wanted to collect information/confirmation of interaction between A20 and SATA port multipliers

There are two things to do prior to recompiling the kernel:

1) exchange in "<kernel source>/drivers/ata/sw_ahci_platform.c" the following line
Copy the Code
Copy the Code
2) set "CONFIG_SATA_PMP=y" in kernel config

According to this thread at least port multipliers using Silicon Image's Sil3726 (look for "0x1095:0x3726" PCI vendor/device ID in dmesg output), SIL5744 (dmesg will show "0x1095:0x5744") and JMB321 (dmesg will show "0x197b:0x0325") are confirmed to work.

Caveats and known limitations:

The A20 only supports slow CBS based switching and not FIS based switching. But since the A20's SATA implementation is limited by itself (max. 45/200 MByte/sec write/read) it's perfectly ok to go with cheap multipliers utilizing JMB321 (you won't find them directly on aliexpress so you have to crawl through the port multiplier listing and check prices and product photos.)

According to the same thread the Sil3726 gets quite hot and consumes approx. 6W for himself alone (quite understandably since it's a highend multiplier supporting FIS based switching like it's successor 3826. But FIS won't help with A20).

EDIT: Cheap JMB321 based PMs do also have thermal issues under constantly high load. Please read the conclusion/fix at the end of this thread.

If you patched and recompiled the kernel as outlined above you won't be able to access SATA disks without a port multiplier in between.

Add post (Tue Jun 9, 2015 08:14):
The informations above only apply to kernels prior to 3.19. Go to the end of the thread to see what's to be done with 3.19 or above to use disks behind a PMP on A20's SATA port.
Edited by dupont-y at Wed Nov 12, 2014 07:11

Hi, I can confirm JMB321 ([    4.817353] ata1.15: Port Multiplier 1.2, 0x197b:0x0325 r0, 5 ports, feat 0x5/0xf) is working here

Edited by tkaiser at Tue Nov 18, 2014 09:21

Some progress on this topic: Seems like it will be possible with 3.18 to switch between port multiplier and direct attached SATA disks using a module so that one can switch between both modes on demand without patching first: ... ovember/302540.html

Edited by tkaiser at Fri Nov 21, 2014 04:58

I tried it with a cheap 2 drive external enclosure (Raidsonic Icy Box IB-RD4320StUS2) using a JMB352 port multiplier (0x197b:0x2352 r0, 2 ports, feat 0x0/0x0).

After applying the patch and recompiling the kernel it simply does not work and no disks show up:

I tried it with the same enclosure without the patch in the same setup a year ago with Cubietruck. Back then only one disk was accessible and I had frequent errors so I would suspect that it's not a good idea to try out such cheap setups at all.

Edited by f4exb at Sat Nov 22, 2014 18:37


the patch seems to work with the latest 3.18 kernel from Torvalds' git (3.18.0.-rc5) possibly with some earlier versions.
The configuration of drivers seems to have changed a bit. You will need to patch drivers/ata/ahci_sunxi.c instead but in the same way : find AHCI_HFLAG_NO_PMP flag and remove it

Boots up SATA and does not remove PMP capability:
  1. [    1.165938] ahci-sunxi 1c18000.sata: SSS flag set, parallel bus scan disabled
  2. [    1.173100] ahci-sunxi 1c18000.sata: AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl platform mode
  3. [    1.182083] ahci-sunxi 1c18000.sata: flags: ncq sntf stag pm led clo only pmp pio slum part ccc
  4. [    1.191820] scsi host0: ahci_platform
  5. [    1.195894] ata1: SATA max UDMA/133 mmio [mem 0x01c18000-0x01c18fff] port 0x100 irq 88
Copy the Code
Then later it sees the port multiplier:
  1. [    1.735879] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
  2. [    1.742372] ata1.15: Port Multiplier 1.2, 0x197b:0x0325 r0, 5 ports, feat 0x5/0xf
Copy the Code
Then eventually it sees both drives:
  1. [    6.098277] ata1.00: ATA-8: WDC WD1600BEVT-11A23T0, 01.01A01, max UDMA/133
  2. [    6.105146] ata1.00: 312581808 sectors, multi 0: LBA48 NCQ (depth 31/32)
  3. [    6.113295] ata1.00: configured for UDMA/133
  4. [    8.753832] ata1.01: ATA-8: WDC WD1600BEVT-22A23T0, 01.01A01, max UDMA/133
  5. [    8.760722] ata1.01: 312581808 sectors, multi 0: LBA48 NCQ (depth 31/32)
  6. [    8.792062] ata1.01: configured for UDMA/133
Copy the Code
My two drives are indeed seen in the system:
  1. ls /dev/sd*
  2. /dev/sda  /dev/sda1  /dev/sdb  /dev/sdb1
Copy the Code
I just mounted a RAID1 array with mdadm but unfortunately this is very very slow...

Edited by tkaiser at Sun Nov 23, 2014 05:11
f4exb replied at Sat Nov 22, 2014 17:59
I just mounted a RAID1 array with mdadm but unfortunately this is very very slow...

Fortunately it's way too slow since otherwise people would start implementing such insane approaches like RAID on the Banana Pi. The whole setup (using an unreliable port multiplier in between host and disks that will put your data at high risks) is crap. RAID (especially RAID-1) is only about availability (business continuity) which is impossible exchanging one single point of failure with another even more error prone like a cheap PM

Anyway thanks for the information regarding mainline kernel. Will be useful for my setup (a NAS using 3 or more 3.5" HDDs that can be used in a round robin fashion as backup target). Maybe Hans de Goede will finish his module approach for port multipliers on Allwinner boards so that patching won't be necessary any longer in the future.

Edited by f4exb at Sun Nov 23, 2014 08:24

Ok maybe it is pushing the unique SATA port of the BPi too far. Clearly the RAID-1 on the BPi with PM does not work. After about 5% sync completion of just 160GB volumes it gets locked up. The system cannot even be halted properly  and the only option is a hard reset. I have removed mdadm and the PM hack in the kernel completely since.

However I am still investigating redundant NAS using BPis and I just came across DBRD:

Basically this is RAID-1 over network. With the Gb ethernet ports a configuration with two relatively cheap BPis controlling the two redundant volumes is maybe a viable configuration?

f4exb replied at Sun Nov 23, 2014 08:24
Ok maybe it is pushing the unique SATA port of the BPi too far. Clearly the RAID-1 on the BPi with P ...

What you experienced while rebuilding your mirror is exactly what's expected when combining unreliable hardware to serve the wrong purpose. There's another thread/project where some folks want to build a RAID-5 (always crappy when dealing with TBytes on consumer hard drives) on top of this hardware. Which is just insane because when rebuilding a RAID-5 the port multiplier will both serve as bottleneck and as a single point of failure that will most likely fail in such a situation and then all the data is gone.

Regarding DrBd: It's just mirroring and I don't see a need for this. Because all you achieve is high(er) availability but who needs this at home? I would never ever store valuable data on a Banana Pi or any other system that lacks ECC RAM and I would use a modern filesystem that is able to fight 'bit rotting' (yeah, I'm a ZFS fanboi).

So when talking about Banana Pi as NAS my aim is to use it mainly for backup purposes (as a TimeMachine backup target utilizing different disks connected to the port multiplier that will be used and switched on/off automatically in a round robin fashion). And when I would use a BanaNAS for unique data that is not so important then I would never think about mirroring but instead use a second system with larger HDD and use a real backup approach able to keep older versions of documents at the second NAS. Can be done using rsync with hardlinks easily: (prior to that one has to setup keyless SSH authentication and it might be a good idea to use a weak SSH cipher eg. "-e 'ssh -c arcfour'" with rsync due to limited CPU power)

We achieve an average retention time of 90-120 days at a customer with 150% backup storage compared to the productive storage. But this depends on the size of changes made at the productive storage from day to day...

Thanks for all the useful info. I also browsed the related topics you developed in this forum. So to summarize there are 2 kinds of NAS: NAS and toy-NAS The BPi based stuff belonging to the latter. Among toy-NASes you still have the option to choose among the most breakable ones and the less breakable ones.

The PM stuff broke even before making it to a toy-NAS. After 5% of slow syncing it almost halted so I gave up and uninstalled mdadm and other stuff completely.

Basically anything RAID-1 is just useless with consumer level hardware including I suppose the cheap ready made NASes like the D-Link ReadyNAS I own and I would like to get rid of. Chances are that in case of problem you will not be able to recover any data at all. With the proper hardware ZFS is a very interesting option indeed.

So for the time being to set up a toy-NAS with a pair of BPis the best option is the "rsync + cp -al" trick as described in the link you mention. At least one can hope that some data will be recoverable.

Edited by tkaiser at Tue Nov 25, 2014 05:39

Well, the problem is that data integrity, availability and safety are different beasts that have to be tamed in different ways. And some design goals can not be achieved with inappropriate hardware like the Banana Pi combined with the cheapest possible and most unrealiable hardware you can find. Some features do still have a specific price tag.

Regarding data integrity the situation is somewhat problematic since blindly trusting in the DRAM's contents is wrong due to the lack of ECC RAM that is the simple requirement to get a clue whether you're affected by DRAM errors or not. The former happens more often than we all would expect (and no ECC RAM --> no checksum based file systems --> no end-to-end data integrity --> no periodical scrubbing --> limited data integrity).

Regarding data safety you have to ensure that you can access older versions of your documents otherwise you're lost when data gets deleted or damaged (and this is the main reason we do snapshots, backups and syncs implementing versioning. Not hardware failures but accidents like this). RAID/mirrors do not help here because every deletion/damage is instantly also mirrored or has added redundancy. Pointless.

Regarding data availability I don't care at all in Banana Pi setups since I don't run a business with this kind of hardware and therefore need no features addressing 'business continuity'. If I would care I would go with something like HP's N54L or one of the Avoton setups referenced in the other thread above (or the FreeNAS Mini). Because when I start thinking about data availability I would also care about data integrity and then ECC RAM and something like btrfs/ZFS is mandatory, regular scrubbing and the performance of RAID rebuilds or ZFS resilvering gets really important and so on...

You have to log in before you can reply Login | Sign Up

Points Rules