Jmicron Firmware Update Tool
Sandrine Willert
If you have ever tried to use a USB3.0 hard drive enclosure based on a JMicron chipset with TrueNAS (formerly FreeNAS); you may have come across multipath errors or serial numbers that make no sense. Or simply SMART and TRIM not functioning.
Additionally, you may have run into the stupid way these units power down the drives after 10 minutes of inactivity forcefully. Completely ignoring OS or HDD settings. This is infuriating if you want the drives to do what you tell them.
I have found that using a very specific build of the firmware for these enclosures, and then not programming the configuration area results in the enclosure passing through both the correct drive information and allows smart/trim to work!
The firmware version that I found the most reliable for me is the one that was posted to gbatemp by Wanderson Boy Rodrigues. This was also one of the few downloads that include the required windows software.
This is an incredibly safe as the JMicron devices have a burned in bootloader that lets you recover if you ever flash the wrong thing.Additionally, these devices use an external SPI flash for the firmware + config. This means that recovery is very simple worst case.
I have re-hosted the required files to flash the firmware here for convenience in case they are ever lost to time.You will need to use a Windows machine to use the JMicron software or you can probably use the Odroid tool on an arm64 sbc (untested).
The way that this works is that we want to reset all of the configuration memory to be blank (so that the device runs on defaults), and we also want to run a firmware that defaults to sane values and has auto-sleep defaulting to being turned off (some default to 10 minutes).
You will need to open your enclosure to get to the PCB. Near the main interface IC, there will be a small 8 pin SOIC that is storing the device firmware. Lookup the part number of the top of the chip to confirm its a flash IC.
You may need to try this a few times, testing longer or shorter times of holding the pin to ground, not 1000% on this, but I have had it work every time for me eventually. I use thin-tipped tweezers to make this easier to perform.
Just bought the EC DFLT drive sled. Tried both the JMicron Firmware update tool and the DS-UBLK-EC-DFLTFirmwareUpdateWINDOWS. JMicron Firmware update says "Cannot find any supported Sabrent devices" and DS-UBLK-EC-DFLTFirmwareUpdateWINDOWS ays "No avaiable device!!!". What is wrong?
@samueltong Only update the firmware if you have issues. The EC-DFLT can have one of multiple chipsets, certain ones require contacting support for the appropriate firmware update if it's not the JMicron. USB Device Tree Viewer may assist in verifying which chipset is being used.
@david123443212000 The FW updater only applies to EC-DFLTs that use the JMicron chipset. For ones using an ASMedia chipset instead, the firmware is either up-to-date or can be acquired through the website's technical support channel. The USB Device Tree Viewer shows USB devices and may state this with the hardware ID, such as 0x0578 for JMS578. The device will show up as Sabrent which is intentional so it works with the Acronis software.
@Sabrent hi. i have a SERIOUS problem. the drive works perfectly with 2TB disks, but when i use a 4TB disk it does not detect it. when i try to update the firmware, it detects the reader as SABRENT SCSI Disk Device and does not run the update program. any idea how to fix this?
If the device is updated from internal code, the tool does not backup the old firmware and a CAUTION statement is displayed.
There's no way updated from internal code in this case.
Note: This step needs root permission.
I have been testing lately a lot of external enclosures to use an used nvme drive that i had laying around, I tested 3 or 4 and all had the same problems: they didn't report any trim support or smart data report.
My latest enclosure is the Sabrent EC-TFNE, it does report the smart and trim support in Windows (tested attaching the disk to a VM). This enclosure uses a JMicron JMS583 a chip whose firmware and flashing tool is available to mod it. (Reddit & Anandtech)
In the trim support thread , someone talks about the chip not enabling "magics bits" being the reason why Linux does not report the support. As we can modify the firmware, is there anyone that know what exactly has to be modify to enable Linux support? Or is any other method to get the smart and trim data to show up?
SInce that gets rewritten back to 1 at some point (probably at boot), I also tried to make the change permanent by creating a custom .config file in /etc/modprobe.d/ and writing options usb_storage delay_use=10 in it.
From my diagnostics, the entire problem is caused by the fact that the unit has its own standby mode and goes to sleep after 10 min of inactivity, also putting the hard-disks to sleep. That happens irrespective of the APM settings of the hard drives themselves or hdparm. The 10 min interval seems to be flashed into the JMicron controller either by the Orico people or by JMicron themselves.
After being put to sleep in this way, when disk access is required by the OS, the unit spins the disks up but somehow in a quirky way so that they appear missing or broken to the OS (see the attached dmesg_log.txt).
Possibly as a result of that, the OS tries to reset them. Not succeeding that, the OS either disconnects them or "thinks" they are disconnected and subsequently unmounts the drives mapped to them. Interestingly enough, they still show up just fine in OMV's Storage -> Disks page, but when accessing the OMV Storage > File Systems page, that fails and a bunch of messages are thrown in the dmesg log.
P.S. A similar issue seems to exist with JMicron's JMS578 chipset - see this Odroid topic. According to that topic, the Odroid folks managed to get JMicron to issue a patch for that chipset that fixed the issue. I could not find a similar patch for JMS567.
Update: I checked the firmware version on my unit using the JMS578FwUpdate tool given by the Odroid folks here (step called "Example 6") and it turns out mine runs Bridge Firmware Version: v0.3.2.4. I have no idea whether it's the latest or not, but I can see that on the Orico downloads page there is an older version available for download (v0.3.2.3) here.
After completing to built the Neo2 and the 2.5 HDD inside the case (and using the 12V PowerSupply I had) armbian did start up and I could normally SSH into my Neo2 - BUT I cant see the HDD or the HDD-controller (which should be connected via USB).
USB on headers not active by default is due to kernel maintainers wanting it that way. On our OMV images this gets changed by default: -image.sh.template#L159 (see there also for a few other performance tweaks that might be suitable for performant NAS operation, especially the smb.conf tweaks, I would strongly recommend to use latest softy script to install Samba or if you're using a Debian flavour maybe even OMV)
Thanks for the SAMBA-Installation suggestion via the softy-script.
I had read that you seem to like OMV - but I did try installtions on Banana Pi and Raspberry Pi and often get error-messages and did read from othe users getting these messages on other computers....
So I decided to use the console for installing and configuring such things - and lern some commands
Honestly I really don't trust that much into those internal readouts anyway. But back on topic, you're talking about a case responsible for lower temperatures now. But isn't the main difference now that your NEO2 is wearing FriendlyELEC's heatsink while it had no heatsink before?
I just worked on providing clean and performant OMV images for ARM boards relying on Armbian's Debian Jessie flavour [1] since almost all available OMV images I found were more or less horrible (using shitty kernels and crappy settings). Settings matter a lot on those slow ARM boards, if you choose the wrong ones (or rely on distros that 'optimize'/'tune' only irrelevant stuff like DietPi for example) NAS performance might drop drastically. And I posted the links above for a reason: since it's easy to get which settings are important by studying the respective install scripts.
[1] since when trying to install OMV on Ubuntu it can't work due to dependency mismatches -- that's why you find so many reports on the net of 'OMV does not work on Armbian' since people don't understand that it's either Debian or Ubuntu what they run.
But back on topic, you're talking about a case responsible for lower temperatures now.
But isn't the main difference now that your NEO2 is wearing FriendlyELEC's heatsink while it had no heatsink before?
Before I had a small cermic heat-sink at the H5 CPU - but the Neo2 was in the lower part of 3D-printed case from FriendlyARM.
Sure - now the heat-sink is much bigger and from the case the ambient temperature around the heat-sink is lower the last rainy days
I did try the Banana Pi and RPi OMV Images from the official OMV-Webpage:
armhf images/
Most probably the heatsink wasn't that efficient and almost all those SBC enclosures are such an bizarre fail if it's about heat dissipation. I tested this years ago with a DHT22 sensor inside such a 'standard enclosure' and internal temperature was +20C above ambient temperature around. Metal enclosures with direct contact to heat emitting sources like the SoC would be way more efficient than those 'traditional' approaches attaching a heatsink of any size and then cramping everything in a tiny enclosure without direct contact to the outside (for a good implementation see ODROID HC1 for example, but with all those NanoPi it also works excellent, a customer is attaching them directly to 'huge heatsinks' (screwed to the inside of rack cabinets with a thin thermal pad between SoC and the metal)
If you chose those provided within the last 2 months... they work flawlessly (personally tested over ten times each). But I should really stop to care about reports that affect crappy hardware (Micro USB for DC-IN)
b1e95dc632