tkaiser

Because I won't call it "acceleration" but "hardware support" (AFAIK Kodi doesn't run on software OpenGL ES (Mesa) at all) or "offloading", and if I really wanted good software support I would look i.e. in the direction of i.MX6 with Vivante GPUs that have Etnaviv open-source drivers.

IMO instead of deleting it's better to post a correction or clarification, or in the worst case edit your own message striking out the incorrect information like this.

For anyone interested I have pushed the sources to github here: https://github.com/avafinger/ffmpeg-3.3.4_cedrus264
 
Feel free to try. It has been tested on A64, R40 and possibly will work on H5 too.  Cross compiling and re-writing the package in a compliant way would speedup things.
 

TL;DR: The small H2+/H3 boards unlike their bigger siblings are all prone to overheating due to smaller PCB size (on the larger boards the PCB's groundplane acts somewhat as a large heatsink dissipating heat away from the SoC). Due to mainline kernel settings not being optimized currently all these boards are slower under constant load compared to legacy kernel. This should change but won't unless someone is looking into it and spends some time on this.
 
Two areas that deal with this overheating tendency or are somewhat related are
 
thermal protection / throttling: use the thermal sensor(s) inside the SoC to downclock various engines if specific tresholds are exceeded DVFS (dynamic voltage frequency scaling). All the small boards have either no voltage regulation (NanoPi NEO2) or a primitive one only switching between 1.1V and 1.3V  
With sun8i legacy kernel Armbian and linux-sunxi community members spent a lot of time and efforts on improving thermal/throttling performance. Read through the following as a reference please: https://github.com/armbian/build/issues/298
 
The result of our optimizations was a lot of better performance compared to Allwinner's defaults (that targeted only Android and preferred higher single thread performance over overall better performance, with Allwinner settings on an overheating system you could end up with just one or two active CPU cores pretty easily). Now with mainline kernel situation for the larger H3 boards is ok-ish (those boards have an I2C adjustable voltage regulator, voltage switching works fine grained, overheating isn't much of an issue anyway and performance is almost as good as with legacy kernel). But situation with the smaller boards needs some attention.
 
If we run the cheapest boards currently with mainline kernel then we're talking about these settings:
 
max cpufreq 1008 MHz (at 1.3V), next lower cpufreq 816 MHz at 1.1V, then 624/480/312/240/120 MHz defined 4 thermal trip points defined starting at 65"C with throttling, then using 75° and 90°C and shutting board down when 105°C are reached.  
With Armbian and using legacy kernel it's the following instead:
 
max cpufreq is 1200 MHz, then 1008 MHz still at 1.3V, at 912 MHz we switch to 1.1V and below are a few other cpufreqs available between 816 MHz and 1344 MHz Armbian's legacy kernel provides cpufreq steps every 48 MHz (allowing for fine grained throttling) On the small boards we use twice as much thermal trip points as mainline settings and our strategy is to switch to 912MHz@1.1V pretty early once throttling occurs  
These differences result in both lower 'normal' performance (since mainline kernel limits also single threaded tasks to 1GHz instead of 1.2GHz) and also 'full load' performance since DVFS/THS/throttling settings are not optimal and once the board reaches the first thermal trip point throttling is not that efficient compared to legacy.
 
It's easy to test: grab an OPi Zero, NanoPi Duo or any of the other H2+/H3 boards with primitive voltage regulation, then grab an Armbian OS image with legacy kernel (3.4.113 using fex settings) and one with mainline kernel. Execute on both
 
sudo rpimonitor -r (installs RPi-Monitor so you can enjoy nice graphs when connecting with a web browser to port 8888 of your machine) sudo rpimonitor -p (installs cpuminer which is a great tool to heatup your board and also to measure 'thermal performance' since spitting out khash/s values in benchmark mode minerd --benchmark (this is the actual benchmark running)  
With mainline kernel performance is lower. Expected result: same performance. What to do? Improve mainline settings.
 
BTW: Mainline settings currently are as they are since these were the values megi started with last year. Once numbers exist they're only dealt with copy&paste any more.

Just for the record: These 65°C are just a number set here: https://github.com/friendlyarm/linux/blob/sunxi-4.11.y/arch/arm/boot/dts/sun8i-h3-nanopi.dtsi#L158
 
Ondrej used this and the other numbers when he started to code DVFS/THS stuff last year, AFAIK no one so far has looked into H3 thermal/throttling stuff from a user perspective ('Are these settings sufficient') and the only time I looked into it it was pretty obvious that the way throttling currently works with mainline kernel on those boards with primitive voltage regulation (switching only between 1.1V and 1.3V) is worse compared to BSP/legacy kernel.

Well, I'm surprised why people expect $anything from TV boxes. These things aren't for Linux enthusiasts but for clueless people that only buy numbers (8 CPU cores vs. 4 cores --> 8! 2 GB DRAM vs. 3 GB DRAM --> 3! $30 vs. $28 --> 28!). They have to look performant by specs while they have to be as cheap as possible for their target audience to buy them. Why does someone think both can work at the same time?
 
This means manufacturers don't have to take care about performance but only about cluelessness (use 8 cores even if it's totally useless since the competitors also use 8 cores now so you are not able to sell faster boxes with less CPU cores anymore in the markets where they make money, put recycled DRAM on the PCB and combine it with an u-boot that dynamically tunes DRAM clockspeed down until the box doesn't immediately crash so you as manufaturer can afford putting 3 GB crappy/slow DRAM on board since customers would never buy your box with 2 GB faster DRAM)
 
And then this kind of 'cheating' also happens everywhere. Don't know exactly how it works with Amlogic (since I consider all their SoCs not worth a look, might change if a dev board relying on Amlogic A113D appears) but I know how it's done with Allwinner and there it's easy: the 'board support packages' (BSP) TV box vendors get contains a kernel with a list of cpufreq operation points (that's the entire 'up to x.x GHz' thing) that does not need to have any relationship with reality (Allwinner sets 1536 MHz here for A64 as an example). Then there are other settings defining how voltage and clockspeed relates (DVFS) and then there's another settings defining thermal behaviour. The result is that the TV box will be marketed as 'up to 1.5GHz', the real settings already prevent everything above 1152 MHz and due to shitty thermal design of most boxes the SoC won't even see those 1.1GHz when running under constant load since already throttled down to less than 1 GHz. And their target audience is happy since in Android's CPU-Z and stupid benchmarks like Geekbench '4 cores @ 1536 MHz' is listed and that's all they care about,
 
IMO interesting read: https://www.cnx-software.com/2017/09/12/factory-price-of-some-tv-boxes-and-accessories/#comments

Well, it seemed like a nice theory, but it didn't work. I've tried a few other things as well, such as switching the order of steps before attempting the speed switch, but nothing has helped so far. I took a look at the mmc driver in mainline, and it has changed a lot. A very quick attempt at dropping the new driver into the legacy build failed about as quickly as you'd probably expect. I think I'll try and boot a 4.x kernel and see if it can get the card into hs200/hs400. If it does then I can compare the speed change sequence in the new and old drivers, and hopefully either fix the old to match or put the effort into back porting the new. If the new driver can't get the card into hs200 either, then I'll clean up the existing HS/ddr50 hack and stick with that.

mmc-utils is already present in Stretch, and we could probably build it for older releases too, but can't give any ETA due to some HW related issues.

OK, I have a theory for being unable to switch to hs200 based on the following output from the mmc-utils:
 
Power class for 52MHz, DDR at 1.95V [PWR_CL_DDR_52_195: 0xdd]
Power class for 200MHz at 3.6V [PWR_CL_200_360: 0xdd]
 
It looks to me like operation above 52MHz requires the module to be supplied with 3.6V and switched into the appropriate power class (in this case power class 13). This will mean an increase in power consumption from around 400mA to 700mA, so it will be interesting to see if it solves the problem and is worth the power in terms of actual performance gains.
 
I wrote the code to switch the supply to 3.6V last night, but didn't realise at the time that I also need to configure the power class, so still failed the switch to HS200. Can't wait to get back and try the next step!

You can actually squeeze a NanoPi Duo, RJ45 MagJack (LED,GND pins off), a USB port, and tiny buck converter on a half-size breadboard.


 
Seems to be working fine with a user built stretch image for the Orange Pi Zero target, at least initially.
Max current @12vDC I saw was under 400mA with sysbench and WiFi running but more tests are needed.

To disable all serial output u-boot recompilation is required, it's easier to use other UART ports and leave ttyS0 as is.

What do we know now? Not much  -- most importantly that some details will change and 'board available soon'.
 
We have a H6 Product Brief available and a few selected developers already had a look into user manual (NDA situation right now, so not possible to get any answers from them  )
 
So all we know is really just:
H6 is limited wrt DRAM (2GB DDR4/DDR3/DDR3L max), I know the DRAM manufacturer from the modules in my Beelink X2 but have forgotten the name The Ampak module might be an AP6356S providing dual-band/dual-antenna Wi-Fi + BT 4.1 Gigabit Ethernet (H6 is said to have a 2nd Fast Ethernet MAC/PHY but no idea how/whether exposed here -- maybe available on pin headers to be combined with an external MagJack like it's possible on ROCK64 or NanoPi Duo)  One HDMI is a v2.0a output for sure, the other can be another HDMI output (LCD to HDMI converter) or maybe also a HDMI to TS input (depends on the type of chip behind the left HDMI port) eMMC on board One of the USB receptacles is blue (USB3 SuperSpeed), the other is USB2 and I would believe the remaining USB2 port is available on pins 36/38 of the mPCIe connector allowing to attach 'miniPCIe WWAN modems' (to be combined with the SIM card slot -- AFAIK these modems use USB at a 3.3V logic level) the mPCIe slot also exposes H6's single PCIe 2.x lane there's AV, optical audio out and an IR receiver (positioned IMO somewhat strangely since if rotated 90° on the PCB side next to its actual location OPi 3 Plus combined with a little enclosure would already make up for a complete TV box)

What do we know now? Not much  -- most importantly that some details will change and 'board available soon'.
 
We have a H6 Product Brief available and a few selected developers already had a look into user manual (NDA situation right now, so not possible to get any answers from them  )
 
So all we know is really just:
H6 is limited wrt DRAM (2GB DDR4/DDR3/DDR3L max), I know the DRAM manufacturer from the modules in my Beelink X2 but have forgotten the name The Ampak module might be an AP6356S providing dual-band/dual-antenna Wi-Fi + BT 4.1 Gigabit Ethernet (H6 is said to have a 2nd Fast Ethernet MAC/PHY but no idea how/whether exposed here -- maybe available on pin headers to be combined with an external MagJack like it's possible on ROCK64 or NanoPi Duo)  One HDMI is a v2.0a output for sure, the other can be another HDMI output (LCD to HDMI converter) or maybe also a HDMI to TS input (depends on the type of chip behind the left HDMI port) eMMC on board One of the USB receptacles is blue (USB3 SuperSpeed), the other is USB2 and I would believe the remaining USB2 port is available on pins 36/38 of the mPCIe connector allowing to attach 'miniPCIe WWAN modems' (to be combined with the SIM card slot -- AFAIK these modems use USB at a 3.3V logic level) the mPCIe slot also exposes H6's single PCIe 2.x lane there's AV, optical audio out and an IR receiver (positioned IMO somewhat strangely since if rotated 90° on the PCB side next to its actual location OPi 3 Plus combined with a little enclosure would already make up for a complete TV box)

What do we know now? Not much  -- most importantly that some details will change and 'board available soon'.
 
We have a H6 Product Brief available and a few selected developers already had a look into user manual (NDA situation right now, so not possible to get any answers from them  )
 
So all we know is really just:
H6 is limited wrt DRAM (2GB DDR4/DDR3/DDR3L max), I know the DRAM manufacturer from the modules in my Beelink X2 but have forgotten the name The Ampak module might be an AP6356S providing dual-band/dual-antenna Wi-Fi + BT 4.1 Gigabit Ethernet (H6 is said to have a 2nd Fast Ethernet MAC/PHY but no idea how/whether exposed here -- maybe available on pin headers to be combined with an external MagJack like it's possible on ROCK64 or NanoPi Duo)  One HDMI is a v2.0a output for sure, the other can be another HDMI output (LCD to HDMI converter) or maybe also a HDMI to TS input (depends on the type of chip behind the left HDMI port) eMMC on board One of the USB receptacles is blue (USB3 SuperSpeed), the other is USB2 and I would believe the remaining USB2 port is available on pins 36/38 of the mPCIe connector allowing to attach 'miniPCIe WWAN modems' (to be combined with the SIM card slot -- AFAIK these modems use USB at a 3.3V logic level) the mPCIe slot also exposes H6's single PCIe 2.x lane there's AV, optical audio out and an IR receiver (positioned IMO somewhat strangely since if rotated 90° on the PCB side next to its actual location OPi 3 Plus combined with a little enclosure would already make up for a complete TV box)

Just pushed re-organized thermals to repo, cpu_thermal is zone0, gpu_thermal is zone1.  This is for dev, next, and default.  All I did was move the "reserve_thermal" entry to the end of the list of three.
@tkaiser

The above thing is a $10 accessory that can be ordered together with ROCK64 (and maybe other Pine Inc. devices like Pine64 or Pinebook?). It's an USB-to-SATA bridge (JMicron JMS578 based) to be used together with 2.5" SSD/HDD or 3.5" HDD. For the latter purpose it's equipped with a separate power jack suitable for the usual 12V 5.5/2.1mm power barrels (centre positive) you find PSUs with literally everywhere.
 
TL;DR: If you want to add storage to your ROCK64 order this cable too. It works great with both 2.5" and 3.5" disks and it's somewhat sad it's not available separately since it's a great storage companion for many other devices too.
 
Basics first:
Mechanical quality of USB jack is excellent, Pine folks took care that the jack fits really tightly in USB receptacles so USB3 contact issues should not be an issue here (tested on ODROID-XU4 which is my worst device in this regard. The Pine adapter worked great and these pretty nice XU4 USB3 storage performance numbers were produced with Pine's adapter) The device is not really black but it's just a very dark but translucent plastic. If it's connected to an USB port and thereby powered a solid blue led is shining through. Disk activity is shown with a blinking red led in parallel. If you hate blinking leds like me turning the device 180° over is sufficient JMS578 as USB-to-SATA bridge is an excellent choice since amazingly fast, 'USB Attached SCSI' capable, same with 'SCSI / ATA translation' and even TRIM (though software support for this still missing in Linux) When combined with 2.5" disks the whole power consumption happens through the USB cable. Keep in mind that USB2 ports are rated for 500mA and USB3 ports for 900mA max. ROCK64 AFAIK allows 650mA on the USB2 ports and 950 mA on the USB3 ports. In other words: chances are great to run in underpowering problems when you connect 2.5" disks to the USB2 ports and run heavy loads on it (see below). 3.5" HDDs need not only 5V but also 12V. Usually the motor spinning the platters is on the 12V rail while internal electronics and the stepper motors to move around the head(s) are on the 5V rail. Please always keep in mind that Pine's SATA cable unlike any 'real' 3.5" HDD disk enclosure uses the separately provided 12V only to feed pins 13-15 on the SATA power connector. 5V consumption for the JMS578 and the disk's 5V rail has still to be provided by the device the SATA cable is connected to since coming from the USB power lines. On 'real' disk enclosures the 12V are internally also used to generate the 5V so an external disk is NOT powered in any way by the connected host. With this cable it's different!  
Below is the standard SATA power connector pinout. 3.3V are usually not used, 12V are needed for 3.5" HDDs and 5V are always required. The JMS578 bridge chip needs some 5V juice too which is also taken from the connected host/board via USB power lines.
 

 
We already have a lot of performance numbers with fast SSDs connected to JMS578 (see https://forum.armbian.com/index.php?/topic/1925-some-storage-benchmarks-on-sbcs/&do=findComment&comment=34192 or there for example) so let's focus on real-world use cases this time: A large 3.5" HDD connected to a ROCK64 serving as a NAS or backup disk.
 
Let's start with some consumption numbers with an idle ROCK64. In the meantime I've 3 different ROCK64 generations on my desk (1st dev sample with 2GB and unusable USB3, 2nd gen dev sample with 4 GB and now a production board with 1 GB DRAM and a different Gigabit Ethernet PHY). Measurements done without PSU taken into account:
 
Pre-production board, 4GB, RTL8211E PHY:
Idle, Fast Ethernet active, nothing connected: 1100mW Idle, GbE active, nothing connected: 1430mW   
Production board, 1GB, RTL8211F PHY:
Idle, Fast Ethernet active, nothing connected: 1180mW Idle, GbE active, nothing connected: 1300mW Idle, GbE active, JMS578 connected: 1720mW Idle, GbE active, JMS578 with sleeping disk: 2850mW With RTL8211E PHY the difference between GbE and Fast Ethernet was 330mW (on most GbE boards with 8211E it's exactly like this: ~350mW) and now with RTL8211F the difference is just 120mW (difference on ODROID-C2 which also uses 8211F is 230mW). When adding the JMS578 cable w/o connected disk consumption increases by 400mW. In this (rather useless) mode the JMS578 hides itself on the USB bus (lsusb output shows nothing -- interestingly on ODROID HC1 which also relies on JMS578 this is different) and obviously JMS578's USB and SATA PHYs are powered off. As soon as a disk is connected but sent to sleep JMS578 now consumes +1.5W and appears on the USB bus (now JMS578 has to power 2 highspeed PHYs: USB3 and SATA 3.0).
 
So with production ROCK64 boards minimal idle consumption is 1.2W (PSU's own consumption excluded). But as soon as we connect this cable with a disk behind idle consumption more than doubles (+1550mW) even if we send the disk to sleep. That's bad news for use cases that require a connected disk only running from time to time since now the JMS578 consumes more energy than the board itself.
 
Edit: I discovered recently that the HDD I was testing with has a rather high standby/sleep consumption so the +1550mW are not JMS578 alone but maybe even largely the Seagate Barracuda. See here for details but keep in mind that while on ODROID HC2 also a JMS578 is used it runs a different firmware which influences idle consumption behaviour a lot. More details on JMS578 firmwares: https://forum.armbian.com/topic/3317-orange-pi-zero-nas-expansion-board-with-sata-msata/?do=findComment&comment=43735
 
What are the options? With ROCK64 production boards we're fortunately able to toggle power provided to USB ports: https://forum.pine64.org/showthread.php?tid=5001
 
So the SATA cable connected to an USB2 port would allow to regain lowest idle consumption since we could unmount the disk when not needed, then send the disk to sleep using 'hdparm -y' (JMS578 fully supports 'SCSI / ATA translation so you can access every disk feature with hdparm or other low level tools!) and finally switch JMS578 off by cutting power on  the USB2 port. My personal use case is a ROCK64 with a huge 3.5" HDD to backup various macOS devices in the household. Backup performance is close to irrelevant and the only events needing top 'NAS performance' would be large restores or 'desaster recovery'. In other words: for normal backup operation once a day it would be sufficient to connect the disk to an USB2 port.  Nope, doesn't work any more, see below for details.
 
How does performance look like with a 7.2k 3.5" HDD (Seagate Barracuda from a few years ago):
 
The Barracuda is totally empty so able to achieve nice maximum sequential performance scores since testing only on the outer tracks (~170 MB/s):
USB3 / UAS (7.9W vs. 3.3W) random random kB reclen write rewrite read reread read write 102400 4 11738 23147 25131 25087 1091 948 102400 16 62218 77830 84257 84768 4246 4136 102400 512 150052 148303 154342 163817 58563 97809 102400 1024 148290 148324 156772 164963 85125 113412 102400 16384 149840 149248 144297 151440 153146 133806 1024000 16384 167750 169544 172970 174205 160859 151406 When connected to an USB2 port performance drops a lot (maxing out at ~37MB/s):
USB2 / UAS (6.4W vs. 3.3W) random random kB reclen write rewrite read reread read write 102400 4 7735 7849 6821 7925 998 916 102400 16 17687 19040 20793 19430 3624 4096 102400 512 33472 33662 33738 34329 26020 33683 102400 1024 33836 34030 34855 35505 29941 28791 102400 16384 34294 34373 35599 36694 36174 33714 1024000 16384 33600 34516 36576 36902 36372 34111  
I tested backing up the same MacBook Air twice with ~70 GB data using Gigabit Ethernet (the usual Thunderbolt Ethernet adapter) and time difference was negligible comparing HDD connected to USB2 or USB3. When backing up through Wi-Fi there is no difference any more since Wi-Fi is the bottleneck. In other words: from a performance point of view for this use case connecting the SATA cable to an USB2 port and being able to totally cut power to both cable/JMS578 (+1.5W consumption) and a sleeping 3.5" disk (less than 0.1W consumption with almost all disks) is worth the efforts.
 
Once your MacBook gets stolen you simply disconnect the backup HDD from the USB2 and reattach it to an USB3 port and start the restore on your new device with +80 MB/s (Gigabit Ethernet now being the bottleneck) 
 
What about power requirements? ROCK64 only provides up to 650 mA on the USB2 ports! I tried to test this precisely with my usual 'monitoring PSU' approach. All I was getting were some nice kernel panics due to UNDERPOWERING. The Banana Pro I used to provide power (and measure consumption) simply does not provide enough current so Linux on ROCK64 started to fail in many funny ways once USB accesses happened.
 
So I had to revert on measuring with PSU included with a cheap powermeter (more realistic but not that precise).
 
When measuring only the 12V rail of my 3.5" Barracuda the disk consumed up to 18W when spinning up. In normal operation (either idle or with any workload) 12V consumption varied between 6W and 8W (12V only needed to spin the platters).
 
The 5V power requirements for JMS578 + 3.5" HDD disk were as follows:
USB2: 6.4W vs. 3.3W (full load vs. idle). Numbers with 5V PSU included so we're talking about needed power provided on an USB2 port of approximately ~3W which fits perfectly in the power budget of ROCK64's USB2: 650mA * 5V == 3250mW USB3: 7.9W vs. 3.3W (full load vs. idle). Numbers again with 5V PSU included so we're talking about needed power provided on an USB3 port of approximately ~4W which fits perfectly in the power budget of ROCK64's USB3: 950mA * 5V == 4750mW  
At least with my 3.5" HDD it worked pretty well to let it operate on both USB2 and USB3 ports when board powering was appropriate (with insufficient powering all weird sorts of issues popped up. My favourite was a kernel panic when issueing 'lsusb' after 30 seconds. Once I powered ROCK64 reliably all these 'software issues' were gone immediately -- again and again: insufficient powering is one of the most severe problem sources)

And please ask them to consider being compatible to the rest of the (Linux) world using thermal_zone0. Most probably still using thermal_zone1 is for backwards compatiblity since they had it that way on their 4.4 kernel already (a tribute to badly written software expecting things at hardcoded locations). But since every software/script out there naively expects CPU temp available as thermal_zone0 it would be better to become compatible to this (even more a tribute to badly written software expecting things at hardcoded locations )

I can boot a 4.12 momentarily, I was debugging 4.13.  I found what *I think* is the culprit, the gpu node was changed and somehow omitted the cooling-cells property.
 
 
[edit]  zone1 is cpu_thermal, zone2 is gpu_thermal 
 
The device tree has the tsadc channel 0 as a "reserve_thermal", with 1 and 2 cpu and gpu. 
 

Maybe this has something to do with it
Processing file /home/zador/armbian/patch/u-boot/u-boot-odroidxu4-next/cfgload-support-ext4.patch 1 out of 2 hunks FAILED -- saving rejects to file cmd/cfgload.c.rej I'll update the patch and push the fixes a bit later.

That's great, so we won't have to ban @TonyMac32right now! Nice feedback from your side. Maybe creating a tutorial 'how to help the right way?' or something like that?  
 
I really wonder how the average forum joe today would react when being confronted with http://www.catb.org/esr/faqs/smart-questions.html

You're absolutely right. The few hundred people a day downloading these broken and totally untested images (check statistics yourself: https://dl.armbian.com/_download-stats/) are all fooled since these images can't work (broken, untested, 'armbian style'). And only you are brave enough to publicly inform those lazy Armbians about this severe problem. Last image has been released back in June so those lazy Armbians already fooled thousands of poor users with providing broken and untested images. It's almost a miracle that you're the first to tell the truth! Keep on rocking!

You're absolutely right. The few hundred people a day downloading these broken and totally untested images (check statistics yourself: https://dl.armbian.com/_download-stats/) are all fooled since these images can't work (broken, untested, 'armbian style'). And only you are brave enough to publicly inform those lazy Armbians about this severe problem. Last image has been released back in June so those lazy Armbians already fooled thousands of poor users with providing broken and untested images. It's almost a miracle that you're the first to tell the truth! Keep on rocking!

You're absolutely right. The few hundred people a day downloading these broken and totally untested images (check statistics yourself: https://dl.armbian.com/_download-stats/) are all fooled since these images can't work (broken, untested, 'armbian style'). And only you are brave enough to publicly inform those lazy Armbians about this severe problem. Last image has been released back in June so those lazy Armbians already fooled thousands of poor users with providing broken and untested images. It's almost a miracle that you're the first to tell the truth! Keep on rocking!

Bingo ! You got a good idea !
Without the mSATA inserted, there is no more issue for using the USB receptable for any devices.
This means the JMS stay quiet on the D+/D- line and no more conflicts.