How to upgrade F/W with jms561 under Raspberry Pi

#45

As I read your dmesg, I had a similar problem, see here: USB SATA device disconnect randomly

After two months I decided to reinstall the whole Raspbian, and the problem is gone!
It was a very hard decision, because of I had a fully configured server (Apache + PHP, Nextcloud, RAID1, FTP, Smaba, Plex, qBittorrent, etc.).

Make a backup from your SD card (or get / buy a new one), reinstall the OS, install the rockpi-sata driver, and wait a few hours/1-2 days.

If the problem not encounters, you have to reconfigure everything on the freshly installed OS, but your problem is solved.

#46

Maybe this is a dump comment, but one has to install the sata-hat software (as mentioned on the wiki) before updating the firmware. Maybe it is obvious to every buddy else but it took a minute for me to realize this.
After the installation (ATTENTION update python setuptools manually before the installation!) I have succesfully updated the firmware.

system
raspberry pi 8 GB
rasberry os 64 bit
sata hat Q(D) v1.3

#47

A quick test for speeds and connector can be done with “lsusb -t”. This will show you the connections and whether they are USB2 (480M) or USB3 (5000M). I had it showing up as 480 and when the system was powered down and the connector firmly seated, on reboot I showed as 5000M.

Should look rather similar to the following (lsusb;lsusb -t).

Bus 002 Device 002: ID 152d:0561 JMicron Technology Corp. / JMicron USA Technology Corp. JMS551 - Sharkoon SATA QuickPort Duo
Bus 002 Device 003: ID 152d:0561 JMicron Technology Corp. / JMicron USA Technology Corp. JMS551 - Sharkoon SATA QuickPort Duo
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
|__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=uas, 5000M
|__ Port 2: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M

#48

Hey guys,
I can confirm that this firmware update on a clean install with 4 connected Seagate Ironwolf NAS Drives has worked for me on Ubuntu Server 20.04 LTS.
Greetings,
Fox

#49

Is it possible to install this curl -sL https://rock.sh/get-rockpi-sata | sudo -E bash -
on OSMC raspberry pi 4B? There is no distro support it says. But it’s the same debian base on this OS. So i dont understand what the problem is?

cat /etc/os-release
PRETTY_NAME=“Open Source Media Center”
NAME=“OSMC”
VERSION=“March 2022”
VERSION_ID=“2022.03-1”
ID=osmc
ID_LIKE=debian

ANSI_COLOR=“1;31”
HOME_URL=“https://www.osmc.tv”
SUPPORT_URL=“https://www.osmc.tv”
BUG_REPORT_URL=“https://www.osmc.tv”

#50

@Anders_Eriksson

Hello. The install script will check the name of /etc/os-release and if the name is not in the known list, it will say not supported. I first heard about OSMC and have not tested it, so it is not on the list. You can download this file (raspbian.sh) manually and install it.

#51

It requires these packages which I cannot find.
What repository needs to be added?

Package(s) python3-spidev pigpio is required.

Why is this not handled automatically with an program manager?

#52

Please, can you bring the OS recognition into the current age and handle current LTS releases of Ubuntu because right now its on an aged out version.

We shouldn’t have to hack around this. Filesystem is about as close to a vital service as it gets: if I can’t rely on you, I will have to look to other SATA controllers.

And, jmicron say you’re old firmware too.

2 Likes
#53

Yeah i guess this is a dead project. :frowning:

#54

I’m sorry. We update it.

We have also contacted the agent, whether there is new firmware.

1 Like
#55

@setq any news on new firmware?

#56

Is there any firmware update?

#57

The supplier replied that there was no new firmware.

1 Like
#58

Thanks for clarification,
is JMS551 same as JMS561? I’m just not sure that I’m trying right thing, wiki link points here, but lsusb reports:

Bus 002 Device 004: ID 152d:0561 JMicron Technology Corp. / JMicron USA Technology Corp. JMS551 - Sharkoon SATA QuickPort Duo
Bus 002 Device 003: ID 152d:0561 JMicron Technology Corp. / JMicron USA Technology Corp. JMS551 - Sharkoon SATA QuickPort Duo

I just found that somebody earlier mentioned JMS551, today I reassembled whole sata HAT and found out that chip is labelled as JMS561, but lsusb reports JMS551. Is it something to worry about or are they the same?

#59

I nevered managed to run the quad sata hat stably until today:

I installed the updated firmware from here (v158.001.000.004):

https://wiki.odroid.com/accessory/add-on_boards/xu4_cloudshell2/firmware_upgrade

Every since then, the hat reports no problems and I could finally copy more than 100GB in one session.
I suspect it was the UAS fix that did the trick.
Maybe the firmware fixes your problems too.
Also make sure to disable S.M.A.R.T. due to incompatibility with UAS.

Edit: After a couple of hours, the disks have again disconnected. Only fix might be disabling UAS alltogether.

#60

At that point I was just not sure if radxa version has still some old firmware or there is something just in linux kernel that has some kind of bug, but as @setq indicated - there is no firmware update for this chip. Odroid guys made this excellent wiki page with clear information about issues on all versions. On my tests I found out that each version has some issues and in fact they are not that harmful for usb drives connected for some short time for PC, but it’s makes impossible to use any software RAID because it will just rebuild all the time.

My solution was to use hardware RAID, I could not use RAID5 but two RAID1 in one volume is good enough. So far it’s the only one stable combination I could find, this will cover Your existing setup, has good transfer as well as working SMART. It also does not need to use main SoC power just to maintain such array.

#61

I agree. I think the hardware ist just plain broken / not working.

I have been experimenting with the SATA hat for a couple of years now, trying different configurations / SSDs / HDDs but I always end up with random disconnects:

device descriptor read/8, error -110

Maybe hardware raid indeed is the only solution, I was hoping for something more modern like ZFS to work.

#62

I’ve tried two ZFS zpool setups on my quad sata nas. I’ve not updated the jmicron firmware since I’ve not read anything about positive changes after the firmware update.

  1. raidz on all 4 disks. When doing a rsync to that zpool the disks would disconnect and I would have to reboot: zfs does not want to restore the zpool even when the disks come back online.
    When I limited the rsync throughput to 30MB/s the disks were fine and would not disconnect.

  2. Now I’m testing a second setup. 2 mirror vdevs in one zpool. And I’ve already rsynced 200GB and the disks are just fine. I’ll update when something goes wrong.

edit: and the disks disconnected again after 302GB. It looked so good. I even upgraded debian while running the rsync and all went fine for a while.
Now updated jmicron fw to v8.1.3.6. Lets see how it holds up

edit2: disk gone again. @dominik how did you set up the hardware raid? If that is still stable I’d like to try it

edit3: found it: Setting up HARDWARE RAID with QUAD SATA-HAT (jms561 controller)

#63

Ok.
think I found a pretty solid solution. I’ve thought that before so I might update when something goes wrong again…

I’m using the hardware raid feature of the quad sata board’s jmicron controllers. See link in above post on how to do this.
Together with zfs.

My first setup failed:
Two disks on controller 1 in RAID1
Two disks on controller 2 in RAID1
zpool create -f tank /dev/sda1 /dev/sdb1 (no mirror)
This way I dont write to the two controllers at the same time all the time.
But this failed after ~45min (disk disconnects)

My second setup seems to hold up:
Two disks on controller 1 in JBOD
Two disks on controller 2 in JBOD
zpool create tank mirror /dev/sda1 /dev/sdb1
So now I’m letting zfs do the mirroring. And the controllers dont have to write to two disks per controller at the same time. My thinking is. This makes it as easy as possible for the jmicron controllers (and their problems)
I have now rsynced 500G to that zpool over the course of a few hours. No disconnects yet.

edit: 8hours later and 1,4TB later. Still all good. No disconnects. This could be a winning setup

#64

Mine is working stable for about year now. I’m using ext4 + RAID 1 on both controllers. It also worked fine with UAS disabled and with no particular SMART queries, but this was very problematic on OMV when each update needed to fix code. Also hardware RAID don’t use CPU that much.