If you buy it now, the firmware is updated already. Just plug in and it works with 3A.
"Penta SATA HAT" supported for "Rock 3a"?
2 Likes
Addenum: Just gave the install another try as there seemed to be an update but…
#######################
2023-06-13T22:00:00Z
Anyone else experiancing transfer becomming bumpy above approx 1.8 GB in short sequence (2 Min or so) and stopping/freezing completey till reboot above ~2 GB
##########################
current install looks fine now . see below… Any comments
*root@rock3a:/home/rock#curl -sL https://rock.sh/get-rockpi-penta 1 | sudo -E bash -
*** Penta SATA Hat Install for ROCK Pi 4 / ROCK 3
*** Tested distributions:
*** - ROCK Pi 4
*** Armbian 20.05.4 focal
*** Armbian 20.05.3 buster
*** Debian 9 Desktop (radxa official image)
*** Ubuntu Server 18.04 (radxa official image)
*** - ROCK 3
*** Debian 10 Desktop (radxa official image)
*** Ubuntu Server 20.04 (radxa official image)
*** Please report problems to setq@radxa.com and we will try to fix.
deb http://apt.radxa.com/focal-testing/ focal main
OK
Hit:1 http://ports.ubuntu.com/ubuntu-ports focal InRelease
Get:2 http://ports.ubuntu.com/ubuntu-ports focal-security InRelease [114 kB]
Get:3 http://ports.ubuntu.com/ubuntu-ports focal-updates InRelease [114 kB]
Get:4 http://ports.ubuntu.com/ubuntu-ports focal-backports InRelease [108 kB]
Get:5 http://apt.radxa.com/focal-testing focal InRelease [2338 B]
Get:6 http://ports.ubuntu.com/ubuntu-ports focal-security/main arm64 Packages [1621 kB]
Get:7 http://ports.ubuntu.com/ubuntu-ports focal-security/main Translation-en [358 kB]
Get:8 http://ports.ubuntu.com/ubuntu-ports focal-security/restricted Translation-en [257 kB]
Get:9 https://repo.45drives.com/debian focal InRelease [6858 B]
Get:10 http://ports.ubuntu.com/ubuntu-ports focal-security/universe arm64 Packages [764 kB]
Get:11 http://ports.ubuntu.com/ubuntu-ports focal-security/universe Translation-en [174 kB]
Get:12 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 Packages [1929 kB]
Get:13 http://ports.ubuntu.com/ubuntu-ports focal-updates/main Translation-en [440 kB]
Get:14 http://ports.ubuntu.com/ubuntu-ports focal-updates/restricted Translation-en [272 kB]
Get:15 http://ports.ubuntu.com/ubuntu-ports focal-updates/universe arm64 Packages [993 kB]
Get:16 http://ports.ubuntu.com/ubuntu-ports focal-updates/universe Translation-en [255 kB]
Get:17 https://repo.45drives.com/debian focal/main amd64 Packages [51.3 kB]
Fetched 7460 kB in 5s (1556 kB/s)
Reading package lists… Done
running install
running bdist_egg
running egg_info
creating Adafruit_SSD1306.egg-info
writing Adafruit_SSD1306.egg-info/PKG-INFO
writing dependency_links to Adafruit_SSD1306.egg-info/dependency_links.txt
writing requirements to Adafruit_SSD1306.egg-info/requires.txt
writing top-level names to Adafruit_SSD1306.egg-info/top_level.txt
writing manifest file ‘Adafruit_SSD1306.egg-info/SOURCES.txt’
reading manifest file ‘Adafruit_SSD1306.egg-info/SOURCES.txt’
writing manifest file ‘Adafruit_SSD1306.egg-info/SOURCES.txt’
installing library code to build/bdist.linux-aarch64/egg
running install_lib
running build_py
creating build
creating build/lib
creating build/lib/Adafruit_SSD1306
copying Adafruit_SSD1306/init.py -> build/lib/Adafruit_SSD1306
copying Adafruit_SSD1306/SSD1306.py -> build/lib/Adafruit_SSD1306
creating build/bdist.linux-aarch64
creating build/bdist.linux-aarch64/egg
creating build/bdist.linux-aarch64/egg/Adafruit_SSD1306
copying build/lib/Adafruit_SSD1306/init.py -> build/bdist.linux-aarch64/egg/Adafruit_SSD1306
copying build/lib/Adafruit_SSD1306/SSD1306.py -> build/bdist.linux-aarch64/egg/Adafruit_SSD1306
byte-compiling build/bdist.linux-aarch64/egg/Adafruit_SSD1306/init.py to init.cpython-38.pyc
byte-compiling build/bdist.linux-aarch64/egg/Adafruit_SSD1306/SSD1306.py to SSD1306.cpython-38.pyc
creating build/bdist.linux-aarch64/egg/EGG-INFO
copying Adafruit_SSD1306.egg-info/PKG-INFO -> build/bdist.linux-aarch64/egg/EGG-INFO
copying Adafruit_SSD1306.egg-info/SOURCES.txt -> build/bdist.linux-aarch64/egg/EGG-INFO
copying Adafruit_SSD1306.egg-info/dependency_links.txt -> build/bdist.linux-aarch64/egg/EGG-INFO
copying Adafruit_SSD1306.egg-info/requires.txt -> build/bdist.linux-aarch64/egg/EGG-INFO
copying Adafruit_SSD1306.egg-info/top_level.txt -> build/bdist.linux-aarch64/egg/EGG-INFO
zip_safe flag not set; analyzing archive contents…
creating dist
creating ‘dist/Adafruit_SSD1306-1.6.2-py3.8.egg’ and adding ‘build/bdist.linux-aarch64/egg’ to it
removing ‘build/bdist.linux-aarch64/egg’ (and everything under it)
Processing Adafruit_SSD1306-1.6.2-py3.8.egg
Removing /usr/local/lib/python3.8/dist-packages/Adafruit_SSD1306-1.6.2-py3.8.egg
Copying Adafruit_SSD1306-1.6.2-py3.8.egg to /usr/local/lib/python3.8/dist-packages
Adafruit-SSD1306 1.6.2 is already the active version in easy-install.pth
Installed /usr/local/lib/python3.8/dist-packages/Adafruit_SSD1306-1.6.2-py3.8.egg
Processing dependencies for Adafruit-SSD1306==1.6.2
Searching for Adafruit-GPIO==1.0.6
Best match: Adafruit-GPIO 1.0.6
Processing Adafruit_GPIO-1.0.6-py3.8.egg
Adafruit-GPIO 1.0.6 is already the active version in easy-install.pth
Using /usr/local/lib/python3.8/dist-packages/Adafruit_GPIO-1.0.6-py3.8.egg
Searching for spidev==3.5
Best match: spidev 3.5
Processing spidev-3.5-py3.8-linux-aarch64.egg
spidev 3.5 is already the active version in easy-install.pth
Using /usr/local/lib/python3.8/dist-packages/spidev-3.5-py3.8-linux-aarch64.egg
Searching for Adafruit-PureIO==1.1.5
Best match: Adafruit-PureIO 1.1.5
Processing Adafruit_PureIO-1.1.5-py3.8.egg
Adafruit-PureIO 1.1.5 is already the active version in easy-install.pth
Using /usr/local/lib/python3.8/dist-packages/Adafruit_PureIO-1.1.5-py3.8.egg
Finished processing dependencies for Adafruit-SSD1306==1.6.2
/home/karl
(Reading database … 166168 files and directories currently installed.)
Preparing to unpack /tmp/tmp.Qw6FBu5K89 …
Removed /etc/systemd/system/multi-user.target.wants/rockpi-penta.service.
Unpacking rockpi-penta (0.10) over (0.10) …
Setting up rockpi-penta (0.10) …
Created symlink /etc/systemd/system/multi-user.target.wants/rockpi-penta.service → /lib/systemd/system/rockpi-penta.service.
Try to create a new topic
setq@radxa.com
NO FIX AVAILABLE YET?
Sorry but I bought this crab, because I had confidence in the 3rd release of a rock3a plus YOUR PENTA SATA HAT, that it would be somehow less buggy. IT IS purely to maintain, as when you want to experiment with it you always have to rip the whole thing apart just to install a new version of software.
With the HAT mounted safely on top there is no access to the eMMC and even changing the SD is a tricky thing to do!
This very much reduces the fun factor to experiment with such a nitty Potential of SBC Power plus that cabability for a somehow reliable datamanagement.
** 'til now I’m just disappointed :-(**
What a waste of time and energy to have this stuff being sent around half of the world, just to see that it is a bunch of mybe somehow WORKÍNG things, thrown together just to feed the market that seems to have money to feed your “copy and paste” culture.
Shame on you. YOU can do better, I know! Soo! get up and act! … at least start communicating in a trustworthy way!
CAN YOU PLEASE GIVE US A STATUS REPORT PLEASE
I just bought this same hardware and will try this solution as well. I hope I can get a stable solution, although this is a test, as I built a OMV NAS solution in late 2022 based on x86-64 Intel µATX board.
Indeed , support from Radxa is low, very low, I will post my results hoping I will have a better experience.
If the test ends up as a stable alternative with decent performance, I may switch to it and convert the x86-64 solution as a low power workstation, only if…
Rock 3A + Penta Sata HAT?
I also considered that, but it seems that rock3a has 2x pcie 3.0 lanes and rock4 has 4x pcie 2.1 lanes, and don’t know what is supported by hat so what speed whole set is capable of
good luck, post results.
I received the Penta SATA board yesterday and tried to assemble it on a new Rock 3a with 8 GB RAM. I got some strange behavior with an unexpected reboot loop, so today I removed the SATA board, first reinstalled Debian to get rid of the problems, assembled it again and tonight, aside HDMI problems preventing to use the screen, it is correctly running in test mode with a temporary 2"5 WD Black drive on top of the Penta hat: yes, it is recognized and usable! I am still using a 65W PD connected to the USB-C of the rock SBC for the moment (it powers the hat through the GPIO interface).
A quick test proves it basically works: I have created an ext4 partition and was able to read/write data to the disk.
I will have to wait for a few days since I have the drives for RAID 5, but not the case for the final setup and the Flex ATX power supply cannot be used directly. The next steps will be final assembly, power supply setup, removal of GUI packages and installation of OpenMediaVault before the interesting part: performance test…
I started to carefully note the different steps/problems/fixes to hopefully propose a detailed experience.
Thanks for report. With 4 drives You will need much more power. Also stability is some issue, I just replaced power adapter with the one with 12v and 5A to check if this was core of my problems on quad sata hat.
Im waiting for speed test as well as link.information. ROCK 4 should have 4 x 2.0 pcie lanes, and ROCK 3 has 2 x 3.0 so overall bandwith of m.2 is same on those two, but link may be limited to 2 x 2.0. Looking forward for Your results 
I think the SATA hat is correctly recognized, but I was unable to check the PCIe link, I might dig on that side later.
Well, I received all hardware last Tuesday, but had to buy additional specific SATA male cables for 3"5 drives (Amazon saved me time on this). Unfortunately, after a simple temporary hardware setup and a long RAID 5 volume initialization (20h), I noticed that one of the SATA drives disconnected when writing to it, destroying my first performance tests.
The SMART status, green at the very beginning, turned yellow: one of the new drive is faulty. I changed the port and then the cable, but the drive disconnects and this heavily degrades data transfers.
I do not have spare drives as these three drives are already spare disks for my active NAS (I had one spare and I bought two new identical drives), so I will ask for replacement…
In the meantime, I planned to try simpler tests with direct disk accesses and then RAID 0 and RAID1, but another quick test on the USB 3 port with an external pocket drive highlights a bottleneck on the ROCK board itself that do not seem CPU bounded… maybe I should analyze the system installation first… So I think the road will be long, very long, before I can really finalize this little NAS project 
1 Like
@tkaiser excellent tool sbc-bench with one of switch show link speeds. This gives comfortable view for attached devices and information about degraded links
I also plan to use this device as backup for bigger nas, so on it’s not reliable to put any data there 
there is also some new firmware available for jms chips and I hope this will fix some errors
Some progress in my preliminary test on a RAID NAS server based on the Penta SATA on Rock 3A. The system is a Debian release adapted to OMV 6 by removal of the GUI packages and booting from eMMC. The hardware in still is test mode, running in an open environement but power is supplied by a Flex ATX PSU only from the molex plug on the SATA hat and HDDs are housed in a hot-swap enclosure.
Unfortunately, the status is currently a failure, as explained below.
Aside a defect on one of the three SATA disks, I was able to test the performance on the degraded RAID 5 array (running on 2 disks) with a tranfer rate in read and write of about 100~110 MB/s for a large archive (12 GB), apparently CPU bounded (cp and mdo_raid5 processes entirely filling one A55 core), but at least it ran flawlessly. Test is similar from/to eMMc module and a modern USB 3 external drive. My conclusion so far is that read and write speeds are almost identical and using either a fast USB device on the onboard eMMc module as source (for write) or target (for read) does not matter.
I then turned the array to striping (RAID 0) to check if a hight transfer was possible, hoping this mode is less CPU bounded. This is where trouble quickly occured: the copy is blocked with recurrent kernel errors:
[ 313.679532] ata3.00: exception Emask 0x0 SAct 0xffffffff SErr 0x0 action 0x6 frozen
[ 313.679643] ata3.00: failed command: WRITE FPDMA QUEUED
[ 313.679696] ata3.00: cmd 61/00:00:00:18:30/08:00:00:00:00/40 tag 0 ncq dma 1048576 ou
res 40/00:01:04:03:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[ 313.679763] ata3.00: status: { DRDY }
and it happens on both SATA ports in use. I changed the plugged ports, checked the cables and replaced one of them, but it does not help, the same errors occur. I also replugged the FPC cable provided with the Penta SATA hat, no change.
Finally, I plugged a single 2"5 direclty in one of the SATA ports to avoid the intermediate cables as I used for my very first and short test, but the same error also occurs after less than a minute… it seems my first test was too short (smaller files).
Testing the USB 3.0 port only, between eMMc and the external drive, so independently of the SATA hat, seems very stable: I was able to transfer a dozen GB of files several times in both directions without any error.
Performance is here also bounded, with read and write speeds of repectively about 90 and 60 MB/s (the USB drive max speed is 100~110 MB/s), so again probably CPU bounded.
Since I checked the cables (they are not tightly plugged, but it seems safe enough), tested several of the SATA ports and with a single drive directly plugged, without any cable except the provided FPC cable, I think the problem can only come from one of these potential explanations:
- the FPC cable or its connection to the Rock3 is not reliable
- the SATA hat firmware/driver is buggy or my OS install is not correct
- the SATA hat has a hardware problem
Any advice?
I don’t think that the problem lays in sata or fpc cable, they are rather ok, but this have to be something about system (kernel) and JMB chipset/firmware. On JMB561 (quad sata hat) You can’t get everything to work - either smart or UAS will cause problems and drives disconnects. I’ve seen different problems on different kernels and firmwares so I think You always have to double check all of them.
JMB chipsets have their own utility to do hardware RAID, maybe it’s worth to check that. I would look for speed parameters - maybe there is something like UAS on USB that can be disabled for tests? You may get different results with different kernels - if You have good test then try older 4.x as well as 5.x and maybe some mainline attempts.
Of course still there is some firmware inside JMB585 - take a look at that, maybe there is newer version that includes fixes, even if You have latest version perform upgrade (with backup option, then compare bin). Also there are some upgrades to disk firmwares and that sometimes help, always worth to check that too.
As I mentioned earlier I’m looking for upgrade from quad to penta sata kit hoping that JMB585 is way better than pair of JMB561 connected via usb. Hopefully You will manage to get that to work and that should be same as some m.2 cards with same jmb chip. I think I have ASM card but I need to verify that, if it’s JMB then all issues will be the same as Your.
Yes, cables are probably ok. The problem obviously comes from a stress on the transfer and is most probably linked to drivers/firmwares. This JMB585 chip has no hardware RAID support and is reported by JMicron to use PCIe 3.0 x 2 (https://www.jmicron.com/file/download/945/JMB585.pdf), which is exactly what the Rock 3A offers, so theoretically, its is just fine…
Unfortunately, my knowledge in kernel/drivers/firmwares is quite limited, all I can say is I have installed the Radxa Debian 11 release and used the script provided by Radxa to setup the SATA hat. The kernel version is 4.19 and I guess I would have to compile a 5.x flavor from the config file used for the 4.19 if I want to test an alternate kernel without having to play with too many options.
I also will have to dig a little to get all details on how the Penta SATA hat is identified and what drivers exactly are in use (AHCI, but I don’t know how this stuff works…). Any help on that is welcome 
As I have received the replacement hard drive, the RAID 5 set of 3 drives is now rebuilt and, surprise, as when running in degraded mode (2 disks), not a single error anymore in kernel! it is quite slow but seemingly stable and steady, with transfer speeds a little above 100MB/s in both read/write modes between the RAID array and the onboard eMMc. Again, clearly CPU bounded.
As You, I am testing the solution as a spare time project and there is not need foe a perfect answer since I already have a good working solution based on Intel x86 12th gen. If possible, I plan to test RAID 0 and 5 and try to get the best stable performance. Child playground only so far
So yes, there is some room for investigation on kernel/driver/firmware and I will have a few hours next week to do dig the subject. If You have another contact channel for more direct exchanges on the topic, please let me know.
Thanks again
@ydeletrain, try kernel 5.*
I bought an SSD drive in June 2022 and I had problems with the drive.
After switching to the 5.* kernel, the problems disappeared.
SMART ssd showed problems with CRC. Like it’s a sata cable issue or something.
Immediately put the kernel 5.*
Recently tested Armbian flavor 23.02.2 based on Debian Bullseye (required for OMV packages) and latest 6.10 kernel.
Behavior and performance are very similar, although the kernel starts in a cleaner way (less error messages), however I still receive the same kind of ‘failed command: WRITE FPDMA QUEUED’ message, just a bit less often and not with RAID5.
All I can maybe do now is check what exact drivers/firmwares are in use.This is the next step.
Also, I am about to receive a second Penta SATA hat I ordered a few months ago, before the current one. It was delayed because out-of-stock at that time and I thought the item would have been refunded, but it is apparently and finally on its way to my home. So,I will also test this second hat and might have a free sample to give…
What does mean ‘firmware’ upgrade? Is it a microcode to upgrade on the SATA board or simply the drivers for the Linux kernel (ahci)?
Probably it’a about JMS chip on penta sata hat, but I could not find anything more - what is recent version and how to update (or from where to get such firmware). Some of firmwares are slightly changed for particular boards, and they are distributed directly to companies.
Hardware RAID saved my quad sata kit, earlier I tried several other options but they were just problematic. Now I have two groups of raids, one for each controller. Also UASP seems to work with this setup. The only question is SMART info passed from real drives, that is so far only available on custom command. Bad news that penta sata hat has no hardware RAID
Sorry for late answer, I missed it. Just use forum PM if needed.
Did that RAID rebuilt and working correctly now? Software raid always gets some resources, on pi4b it takes about 20% and that is much.
1 Like
Thank You for your reply,
SBC world is on tight edge, reliability and support have become critical and the price range between low end x86-64 and ARM/RISK V is lower and lower.
In short, this attempt on my side is close to a clear failure, too bad. Again, this is a free time project, but it costed more than expected, especially for the case / power supply and cables. Good news is I am not in bankrupt situation, but expectations are not met.
- hardware RAID unavailable - critical for RAID5 on Rock 3A and Rock 4, and not officially supported on Rock 5B where the higher CPU power could help improve software RAID performance
- Availability of suitable and affordable cases for SBC NAS: none for 3"5 drives (I bought a mini ITX 4 drives NAS case for the purpose, with a refurbished 150W Flex-ATX power supply and specific SATA cables) - this costs a lot (more than150 EUR) in addition to the Radxa hardware (Rock3A 8GB + EMMC module + SATA hat, around 150 EUR)
- Support from Radxa (distros / forum): low
Facts, as a brief summary:
- RAID5 works, but with very poor performance, around 100 MB/s in both read/write operations on 3 drives. This is clearly CPU bounded and similar on all tested kernels. But the slow down lower the stress on the JMB chip, and this seems to make a difference!
- RAID0 fails with systematic resets of the SATA links, destroying performance tests, whatever the kernel version (kernels 4.x, 5.x and 6.x on Armbian Debian based, 4.x on Radxa provided Debian).
- Simple WD Black 2"5 7200 rpm drive fails with similar error as in case of RAID0
So, software RAID is not a good start for low end Rockchip and in striping mode (RAID0), there is an obvious problem, where Radxa team could help, but all kernels seem to suffer from the same symptoms: SATA link reset due to failing write command.
If You live in Europe, I have a spare Penta SATA hat for You, just drop me an email and I will try to send it to your home for test purposes. I may have missed something, a secondary viewpoint might be helpful…
1 Like
I was also bit confused about this product and probably went similar path with quad sata hat, it also took way more time than I expected to get it to work. Stable work 
Meanwhile I learned about many things about this particular technology and of course about SBCs and their system, kernels and configuration. You never know why to use or not RAID until You got problems with it and need to deal with them. And of course You will get an idea why big nas hardware just costs so much, beside hardware You will get software and support, those will be ready to use just out of box.
Others are also not perfect with their support. Biggest community - raspberry - has much more users, but most of them will produce useless replies suggesting You to turn off and on or just replace board with new one. I found few bugs in releases as well as still there are some issues with UAS and USB. Also I found many topics about JMB and x86 issues, some still not resolved. Realtec has its own problems (lack of sleep mode on selected nvme/sata adapters), so it’s not perfect here too
Yesterday one of my R4B+ become unstable and now it’s not turning on, this will delay my project for that board (still have second one). Earlier there were few problems with m.2 with that board, maybe something similar may be issue on Your side? I have few ROCK boards that are ok as well as pi and working quad sata hat. After vacation I will also build big NAS. And yes - I’m in middle of Europe.
Few days ago allnet mailed me about ROCK 5A board availability and I need to talk to them about my faulty 4B+, I was thinking about getting penta hat with that order. Your offer is interesting, we can try that to see what I can get from this hat, if it will work at least like quad I’ll just buy it from You in return for Your trust Of course it should be way better via it’s specs. I’ll write You e-mail tomorrow so we can plan some tests. Thanks again.
I forked rockpi-penta to adapt script for rock-3a armbian with latest kernel
repository
Read README.md for setup instructions
Wait for 0.12 release to more stable OLED (cause I merged new features from some of the forks)