Search the Community

I'm second to that - could anyone recommend good 12V+5V power adapter to that for reasonable price? So far I've been successfully running (for over a year or two 24h/7) Banana Pro on 5V 2A MicroUSB power with two HDDs together (320GB 2,5" connected via USB 2.0 adapter & 500GB 2,5" connected to SATA, powered from Banana Pro board SATA power connector), but recently I've got undervoltage problem (not sure if it's the board or the power cable adapter) - just connecting the 320GB USB disk shuts off the board on disk spin up (even nothing else connected) and 500GB disk on SATA gets SATA reset many times on disk spin up (also no other devices connected). Disks do not have such issues being connected to laptop (with the same USB-SATA adapter), but still probably reaching EOL (7y of work, mostly 24h/7 and SMART is not so happy). I'm currently thinking about single bigger disk (2TB-4TB) rather 3,5" connected to SATA with 12V+5V external power supply (which one?) or connecting to USB 2.0 port with USB 3.0 actively powered disk case (with 12V power adapter). I know that USB 2.0 will be performance bottleneck, but I think that somewhere next year (in half year or later) I'll buy something more powerful than Banana Pro (ROCK64 or something on Allwinner H6 with USB 3.0) and need to find some solution for now where I can re-use the disk later with new board. PS. Sorry for HW questions here, but discussion is already ongoing and @tkaiser you'll covering here very important topics and it seems we can't get better support on other forums.

Got some nice feedback from JMicron explaining firmware versions. 0.1.x is for self-powered SATA HDD/SSD device 0.2.x is for bus-powered SATA HDD/SSD device 0.4.x is for self-powered SATA HDD/SSD/ODD device application (ODD --> optical disk) $higher-number.x means custom firmware (enclosure maker) I only asked for the firmware revisions of a couple of devices I've access to so not all possible variations are listed above (eg. 0.3.x or 0.5.x could mean 'bus-powered HDD/SSD/ODD device). But at least this explains a lot already. When comparing 0.1.0.5 on ODROID HC1 and 0.4.0.5 with ROCK64 SATA cable the firmware revision (x.x.0.5) is the same while the ROCK64 cable firmware should also deal with optical drives. And the 0.2.x firmware being meant for bus-powered vs. self-powered suddenly explains the different behaviour I observed wrt JMS chip being present on the USB bus or not depending on whether there's a SATA drive connected or not (different consumption in different modes). Anyway that needs some more understanding and testing but at least we don't need to be concerned about one JMS578 device (ODROID HC1) having a horribly outdated firmware 0.1.0.5 while ROCK64 SATA cable has a way higher (0.4.0.5) since FW revision is actually the same. JMicron is still busy testing with a newer firmware revision solving the HDD spindown issues, once I get news or something to test I'll update this thread.

Huh? JMS567 is not JMS576. According to your debug output the one you're using is JMS578 (152d:0578 -- JMS567 would show up as 152d:0561 instead) so in case you're talking about an JMS576 then this chip would share same Product ID with JMS578. Can you please use your magnifier glass and check? Wrt versions: Xunlong's NAS Expansion bay with JMS578 uses 0.4.0.4 ROCK64 SATA cable with JMS578 uses 0.4.0.5 Hardkernel's HC1 with JMS578 uses 0.1.0.5 FriendlyELEC's NAS bay with JMS5xx uses 0.2.2.7 Two older JMS567 lying here around use 46.3.0.2 For now I would assume JMicron is implementing a special numbering scheme where the 3rd value is not a version number but only the last. Will ask them later.

It's in the first post in this thread. https://github.com/ayufan-rock64/linux-build/releases/download/0.4.0/xenial-mate-rock64-0.4.0-63-armhf.img.xz I also tried the DietPi image for ROCK64 and that worked well too. I loaded a Libreelec image and it booted but there was no sound. Probably needs the correct device tree.

Little update on the NAS Expansion board: the first time I had this thing in my hands and gave it a try with mainline kernel I was surprised why the JMS578 chips on the board did not allow to use UAS. It looked always like this (lsusb -t): /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M With no other JMS578 device around I experienced this and since I'm currently testing with Orange Pi Zero Plus (still no UAS) and In the meantime JMicron provided us with a firmware update tool.... I thought I take the slightly higher JMS578 firmware revision from ROCK64 SATA cable (0.4.0.5) and update the NAS Expansion board (0.4.0.4) with: root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sda -v Bridge Firmware Version: v0.4.0.4 root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sdb -v Bridge Firmware Version: v0.4.0.5 root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sdb -b ./JMSv0.4.0.5.bin Backup Firmware file name: ./JMSv0.4.0.5.bin Backup the ROM code sucessfully. Open File Error!! root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sda -f ./JMSv0.4.0.5.bin -b ./JMSv0.4.0.4.bin Update Firmware file name: ./JMSv0.4.0.5.bin Backup Firmware file name: ./JMSv0.4.0.4.bin Backup the ROM code sucessfully. Programming & Compare Success!! Success! /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 480M Please keep in mind that you need to update both JMS578 of course. I won't upload the newer firmware yet since thanks to Pine's TL Lim I'm in direct contact to JMicron now and it's about fixing another JMS578 firmware issue.

Say man, I have SCISHION V88 mini II RK3229 TV Box. I loaded the ROCK64 Ubuntu Mate image on a mcroSD card and it booted up without doing anything. No toothpick, no standing on my head, no nothing. Ethernet worked until I upgraded the kernel. Or maybe it was because of the reboot. Not sure. The MAC address of the NIC changes with every reboot. So I plugged a USB ethernet adapter into the USB 3.0 port and I had network connectivity again. I was able to run Subsonic and Samba/NFS on it to make it a media and file server with decent throughput due to the USB 3.0 port. For under $30, not a bad little box and things will only get better when/if a proper device tree is available for the box. Well now that I think of it, the box was $30 but if you add another $10 for a USB NIC and another $10 for a USB 3.0 hub, it loses it's appeal as a cheap NAS.

Hmm... http://linux-sunxi.org/index.php?search=RTL8211E-VB-CG&title=Special%3ASearch suggest that's copy&paste from http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO2 -- so if FriendlyELEC would've written just 8211E, then this would also be listed that way in the wiki. In fact I'm thinking about editing it there Edited it and linked to normal RTL8211E entry. Seriously: please always test from bottom to top first. In networking such 'link down, link up' problems happen most of the times at layer 1 so please check this first (also testing between your two NEO2). Few months ago the PSU of my old lab switch died (a dumb ALLNET Gbit switch) and in the meantime I had to send two cables to the trash already since with the replacement switches ('smart' ones from HP and Netgear) strange problems occured sometimes but in some combinations always (eg. ROCK64 not negotiating an GbE link at boot).

Got the basic idea and the whole picture now. Really helps! Just ordered a ROCK64 as my ARM SBC and I salute to all members here providing the optimized ARM images!!

Yes. That's what the benchmarks are telling. I'll generate them only for ROCK64 since I tried this many times already in the past and sysbench's cpu test scales linearly with both count of CPU cores and clockspeed (in other words: it's a 'benchmark' that can not be used to model any real-world task out there since just calculating prime numbers inside the CPU cores/caches): 408: execution time (avg/stddev): 91.3720/0.00 600: execution time (avg/stddev): 61.7398/0.00 816: execution time (avg/stddev): 45.2492/0.00 1008: execution time (avg/stddev): 36.5560/0.00 1200: execution time (avg/stddev): 30.6810/0.00 1296: execution time (avg/stddev): 28.3843/0.00 I would suggest contacting Amlogic pretty soon since their next 'Amlogic is cheating on us!!1!!' drama is just around the corner (like last year when Willy Tarreau discovered that all reported S905 CPU clockspeeds above 1500 MHz were bogus)

Pinebook (A64) and ROCK64 (RK3328) also with Ubuntu Xenial arm64 sysbench distro package (that's important! Otherwise just numbers without meaning since sysbench is a compiler settings benchmark and not able to meausre hardware performance) echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor for i in $(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies) ; do echo $i >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq echo -e "$(( $i / 1000)): \c" sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=4 2>&1 | grep 'execution time' done Pinebook (no throttling happening -- just compare time_in_state before/after every run). CPU clockspeed above 1152 MHz are disabled by Allwinner's budget cooling settings that's why 1200 and 1344 results are the same as for the 1152, since that's the real clockspeed: 480: execution time (avg/stddev): 19.1398/0.01 600: execution time (avg/stddev): 15.2882/0.01 720: execution time (avg/stddev): 12.7485/0.01 816: execution time (avg/stddev): 11.2629/0.01 912: execution time (avg/stddev): 10.1254/0.01 960: execution time (avg/stddev): 9.5806/0.00 1008: execution time (avg/stddev): 9.0986/0.01 1056: execution time (avg/stddev): 8.6765/0.01 1104: execution time (avg/stddev): 8.3067/0.01 1152: execution time (avg/stddev): 7.9538/0.00 1200: execution time (avg/stddev): 7.9521/0.00 1344: execution time (avg/stddev): 7.9843/0.01 ROCK64 (no throttling happened): 408: execution time (avg/stddev): 23.4966/0.01 600: execution time (avg/stddev): 15.4553/0.00 816: execution time (avg/stddev): 11.3848/0.01 1008: execution time (avg/stddev): 9.1798/0.01 1200: execution time (avg/stddev): 7.6882/0.00 1296: execution time (avg/stddev): 7.1025/0.00 ROCK64 is slightly slower which most probably is related to L1 cache latencies or something like that. You'll find a lot of additional information here: https://forum.armbian.com/topic/1748-sbc-consumptionperformance-comparisons/ (see there especially that how the sysbench binary has been built is the most important factor and that sysbench numbers of devices with totally different DRAM configuration/performance show identical sysbench scores)

well i've studied the dts and datasheet a bit, quite interesting things to learn in there and much closer to my microcotroler knowledge than i thought it would be, hardware is hardware i guess.. i'll start by saying that if of course that dtb (from the "resource" emmc block) is not the one actually used at boot, the comments below will not be very or at all useful. i will also mention that the hardware reference pdf shows 3 ETH+Wifi+BT configuration examples, none use sdmmc0, only a mix of sdmmc1 / sdmmc0ext (not the same pins and address as sdmmc0) / usb, and that the only sdcard example uses sdmmc0. then from the z28 pro dts file you get the following sdmmc bus defined : quick recap of the datasheet address mappings : FF50_0000 SDMMC (probably both for SDMMC0 & SDMMC1 ?) FF51_0000 SDIO FF52_0000 EMMC FF5F_0000 SDMMC_EXT (datasheet only mentions SDMMC0_EXT, i still don't understand what's with the EXT, alternate SDMMC0 pins ?) pinctrl-0 = <0xc5 0xc6 0xc7 0xc8>; ( sdmmc0-clk / sdmmc0-cmd / sdmmc0-bus4 / sdmmc0m1-pwren?? ) pinctrl-1 = <0xc9>; ( sdmmc0-gpio) those phandles point to the following pins in the dts : this is slightly different from the rock64 dts which is as follows : sdmmc0_dectn (card present pin) is not included in the phandles and is "replaced" by sdmmc0m1-pwren. the very weird thing is that for sdmmc0m1-pwren : rockchip,pins = <0x0 0x1e 0x3 0xe8>; seems completely bogus as there are no GPIO0_1E (or any 1E pin in the datasheets). then again i don't quite understand how the hex value of pins is set in that dts, so 1E may be a shift from the datasheet value.. you can also see in the dts that sdmmc0ext is "status = okay" (enabled) and has all the correct phandles, so is the "sdmmc0_ext" used instead of sdmmc0 ? Seeing that UHS_SDR104 is only defined for sdmmc0 i would assume it's the real sd card slot bus.. also that "broken-cd" (no card detection) is set for sdmmc0ext seems weird for a sd slot.. The thing i have not yet figured out is how to identify which external device (sdcard slot, wifi) is actually connected to that hardware bus configuration.. i would assume you can't or only guess by the bus configuration. I'll stop for now by mentioning that ayufan's rock64 dts is slightly different form the current mainline rock64 dts but i may be wrong it's getting confusing.

XU4 and HC1 are fully software compatible (check the readme) and heat dissipation on HC1 is WAY BETTER than with XU4. But you're limited to 2.5" disks here and should keep in mind that Hardkernel already announced a HC2 without that much details (so maybe using the same JMS561 as on Cloudshell 2 minus the interconnection problems -- better ask in their forum). Wrt new boards being interesting for NAS use cases: Pine folks want to provide something called 'Cloudmedia Transformer' (same idea as XU4 vs. HC1, the Transformer is a 100% software compatible ROCK64 + JMS578 on the PCB in an heat emitting metal enclosure that fits a 2.5" HDD, they also thought about a 3.5" variant) Similar to 'Le Potato' a so called 'Le Fly' also with RK3328 might appear (the bottom one here) A bunch of RK3399 devices will be available (all with PCIe 2.x x4 and USB3), I expect software support next year on par with RK3328 EspressoBin might have stable software support next year (you can use the native SATA port there and add mPCIe SATA cards with 2 or even 4 additional real SATA ports) Allwinner H6 boards with both PCIe (single lane, PCIe 2.x) and USB3 will appear (see here and keep in mind that Banana Pi people also have an H6 board in the works) Banana Pi R2 might be ready next year (MTK software support looks promising so maybe next year when mainline kernel support matured we'll support the board) The GnuBees are not listed by intention.

i'm still looking at my original z28 pro before testing linux images i have extracted the dtb from the resource partition (didn't know it was there with rockchip) and converted it to dts. It's not easy to read as "aliases or defines" are not there anymore and everything is in hex. but it should be intesresting to compare it to rock64 dts to see hardware configuration variations. One thing i'm still not sure about is if that dtb (from the "resource" block) is actually used by the box at boot or if there's another dtb somewhere.. here's the boot serial output : rk-kernel.dts.zip

Well, for the +100 MB/s you need a good OS image taking care of settings (those images that don't care about settings/versions perform really low as NAS) and I really hope Hardkernel now ships with a better USB cable to interconnect both devices. If you can solve the USB3 connection hassles then XU4 is not the worst choice to be combined with 2 USB3/UAS capable disk enclosures (the internal USB3 hub doesn't matter when you connect HDDs, that's only a performance drop noticable with SSDs). Besides XU4 you've currently not that many options if it's about really fast storage and 2 HDDs at the same time. ROCK64 would need an external USB3 hub, those mPCIe equipped boards combined with an ASM 106x or Marvell 88SE9215 are an option or Helios4. Next year will get more interesting since a few more boards with good storage capabilities will be available.

.... so much info in so little link. Thanks for that....For me as a beginner the XU4 Cloudshell 2 combination seemed perfect + on their website they advertise copy speeds via network of ~ 100 mb/s and nothing about loose connections etc.. Well, now I'm exactly where I started off.... Btw. thx also for the insight about sd,hdd and emmc performance. This all confirmes my decision to stay with armbian as os. But now I again don't know which hardware I should use. Pardon me to get off topic but since it seems to me that you're the "diy nas" expert here I want to ask for your advice I have too much devices lying around (probably you have more lying around ) and plan to replace them with...well..idealy one SBC and an enclosure: -) WD My Cloud 6TB, single bay NAS (I'm unhappy with the os, I just needed a new HDD and it was a good offer) -) "old" 3TB HDD in external USB 3.0 enclosure hooked up to NAS via USB port -) Hummingboard i2eX (you're probably familiar to that board) working as my home server -) dirt cheap S905X china box running libreelec working as my media center I think I will stay with the S905X box, it works really good with libreelec. All other devices should be replaced. I would like to take my two hdd's, put them in a case along with a SBC and use this as a NAS/homesever combo. File transfer of ~ 100-110 mb/s via gigabit lan would be really nice. The homeserver is running dl/torrent servers like transmission, nzbget, jdownloader2 | managers like sickrage,radarr,htpcmanager and also unrar at a decent decompressing speed would be nice. All of that + NAS functionallity...... Do you think it's doable or am I dreaming of an "egg-laying wool-milk-sow"? The Rock64 seems promising, but do you think it will be able to handle the homeserver jobs?

According to this - always some issues - https://github.com/ayufan-rock64/linux-u-boot/commit/73faad8aeba3fc5a416c86a003cdb627fb24b624

Undervoltage, it seems you forgot that the Tinkerboard is a pile of crap you can switch off even with light loads. Wrt the S905X benchmark results unfortunately I miss distro and clockspeed info. Based on the information I assume it's Ubuntu Xenial y la patata is running at slightly above 1.4 GHz These are your results: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 172077.88k 476222.74k 796116.22k 989857.79k 1065203.03k aes-192-cbc 166314.77k 410735.66k 636071.94k 756757.16k 800991.91k aes-256-cbc 159311.97k 370863.64k 544318.12k 630333.78k 660720.30k And this is ROCK64 at stable 1.3 GHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 163161.40k 436259.80k 729289.90k 906723.33k 975929.34k aes-192-cbc 152362.85k 375675.22k 582690.99k 693259.95k 733563.56k aes-256-cbc 145928.50k 337163.26k 498586.20k 577371.48k 605145.77k Smells like 1.3 GHz vs. 1.42 GHz (and not 1.5GHz). Would be great if someone could provide tinymembench results too. 7-zip numbers are not that great since even an RPi 3 at 1200 MHz performs at this level. Strange.

Equation for board with SDIO wlan and bluetooth, no gmac: the SDIO module is wired with a full uart RTS CTS (UART0 | UART1) for Bluetooth and a sdmmc (SDMMC0 | SDMMC1 | SDMMC0_EXT). UART1 is multiplexed with SDMMC0_EXT. UART2 has a pin switch (UART2-0 | UART2-1). UART2-1 isn't multiplexed with SDMMC0. SDMMC0 available. UART2-0 is multiplexed with SDMMC0. SPI2 is multiplexed with SDMMC0_EXT. I see four possibilities : - The console is UART2-0 (multiplexed with SDMMC0). SDMMC0_EXT and SDMMC1 are dedicated to the SDIO module. Boot possible with an SDMMC0 sdcard but loss of the UART2 console. => (maybe an idea about bug boot with uart connected) - The console is UART2-1 (not multiplexed with SDMMC0). UART1 (disable SDMMC0_EXT) for serial bluetooth, SDMMC1 and SDMMC0 are dedicated to the SDIO module and SD socket. Boot possible with an SDMMC0 sdcard. - The console is UART2-1 (not multiplexed with SDMMC0). UART0 for serial bluetooth, SDMMC1, SDMMC0 and SDMMC0_EXT can be dedicated to the SDIO module and SD socket. Boot possible with an sdcard if SDMMC0 is available on sd socket. Boot possible with an spi nor flash if SDMMC0_EXT is available on sd socket. - The console is UART1 (multiplexed with SDMMC0_EXT). UART0 for Bluetooth, SDMMC1|SDMMC0 for sdio wlan. SDMMC1|SDMMC0 for sd socket. Boot possible with an SDMMC0. - The console is UART0. UART1 (multiplexed with SDMMC0_EXT) for Bluetooth, SDMMC1|SDMMC0 for sdio wlan and SD port. SDMMC1|SDMMC0 for sd socket. Boot possible with an SDMMC0. As information ROCK64 use UART2-1 for serial console. Sorry for brainstorming but it's needed to make the right uboot with output on right serial console

This can only happen if /var/log/armhwinfo.log is either missing or empty. Did you also start to delete log files? Since it just works? This thread now has 23 posts and all that would've been needed is Booting Armbian image Insert wireless dongle (2 seconds waiting) nmtui-connect If driver is contained in the kernel and if firmware is contained in armbian-firmware package (as in your case) Wi-Fi is up and running after this (and if not 'armbianmonitor -u' output is needed). No need to fiddle around in config files and with interface names people seem to hate (and not understand). If you love to configure Linux networking the anachronistic way (you call this 'standard' for reasons unknown to me) you can always do so. Just waste some hours of your live to get an idea how to get back primitive interface names (wlan0), how/why some wireless network adapters appear as more than 1 device by default (RealTek's p2p0 you see above for example), how/why network manager and Debian's/Ubuntu's 'classical' interfaces stuff interfere and how to deal properly with link status changes. As with every task you can spend hours on stuff that could be done within seconds --> nmtui/nmtui-connect. BTW: the driver contained for the dongle spits out an awful lot of messages. Might be worth to open an issue at https://github.com/ayufan-rock64/linux-kernel to lower verbosity for drivers below drivers/net/wireless/rockchip_wlan/

Hardkernel/Jmicron released a firmware update tool here https://wiki.odroid.com/odroid-xu4/software/jms578_fw_update (archived and contents mirrored at http://kaiser-edv.de/tmp/tAm6om/jms578fwupdater.tgz) It seems this firmware update does NOT solve the real problem (the bridge not behaving SAT -- SCSI / ATA translation -- compliant but doing its own thing). I checked firmware versions of the onboard JMS578 on my HC1 (/dev/sdb) and on ROCK64 SATA cable (/dev/sda): root@odroidxu4:~/JMS578FwUpdater# for i in /dev/sd? ; do echo -e "$i: \c" ;./JMS578FwUpdate -d $i -v; done /dev/sda: Bridge Firmware Version: v0.4.0.5 /dev/sdb: Bridge Firmware Version: v0.1.0.5 So JMS578 firmware version on the ROCK64 thingie is way higher than HC1's internal but firmware update does only provide a new 'JMS578-v0.1.0.5.bin' version. Now updating firmware on HC1 with newer 0.1.0.5 firmware, setting 5 min spindown timeout and backing up old firmware: root@odroidxu4:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sdb -f JMS578-v0.1.0.5.bin -b ./backup.bin -t 5 Update Firmware file name: JMS578-v0.1.0.5.bin Backup Firmware file name: ./backup.bin Auto spin-down timer: 5 min. Backup the ROM code sucessfully. Programming & Compare Success!! Backing up the ROCK64 SATA cable firmware seems to work too: root@odroidxu4:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sda -b ./backup_0405.bin Backup Firmware file name: ./backup_0405.bin Backup the ROM code sucessfully. Open File Error!! root@odroidxu4:~/JMS578FwUpdater# ls -la backup* -rw-r--r-- 1 root root 50688 Nov 1 19:34 backup_0405.bin -rw-r--r-- 1 root root 50688 Nov 1 19:31 backup.bin I think I'll wait for the next firmware update that contains a real fix (JMS578 becoming SAT compliant) since with this firmware the chip is still broken: root@odroidxu4:~/JMS578FwUpdater# hdparm -C /dev/sdb /dev/sdb: SG_IO: bad/missing sense data, sb[]: 70 00 01 00 00 00 00 0a 00 00 00 00 00 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 drive state is: unknown

"logging in" after you flashed a linux image on the emmc, right ? i'm still investigating the stock android features at the moment so i haven't flashed anything yet. i don't quite understand how sdmmc1 (not bootable sd port, according to the datasheet) would be used on this device, when those pins are shared with the gmac bus which is activated on the z28 pro with gigabit. Also seeing that the same routing exists on the rock64 schematics (gmac pins + rtl8111) and sdmmc1 is not routed on the board. there are also some sdmmc0_ext pins i don't quite understand the purpose in the datasheet. I will extract the android dts and compare it to the rock64 one or to a z28 (not pro) one if i can find any, but i still don't know how dts really works and if you specify which sd port is enabled, or only that "there's a sd card port on the device".. Anyways i can't interrupt uboot and even if i could there's always a chance you can't input anything, as seen on other devices. I was hoping for a extremely favorable uboot with pxe boot =)

I have built a rock64 stretch image and found in syslog: localhost cron[757]: (*system*armbian-updates) INSECURE MODE (group/other writable) (/etc/cron.d/armbian-updates) could be fixed with: sudo chmod 644 /etc/cron.d/armbian-updates

Driver and firmware are two different things. With ROCK64/RK3328 we currently use a 'vendor kernel' and Rockchip added a bunch of Wi-Fi drivers to their kernel sources. Part of Armbian images is an installed package 'armbian-firmware' which should at least address onboard adapters and most common dongles. So all that should be needed is nmtui-connect, done. No need to fiddle around with interfaces files and names. There's a reason we recommend using nmtui-connect (since usually 'just works') but I have no idea how to improve the current situation that users don't read/follow this documentation...

I jump into a hack try! Just bought an MXR10 same AX5 board but a better emmc chip 32GB 208mhz instead 16GB 103mhz. According to rock64 forum, it's possible to boot in spi mode and sdio can work with spi nor flash in spi mode 1Bit. So in theory it's possible to put spi flash in place of sdio wifi module. I will try to put openwrt on spi 16mbyte, to install linux, dump android image. I think this is why vendor put sdcard on the wrong sdio port, in order to block easy copying their android image. If it's work it's will be easy for someone to buy an spi flash, write it with an esp8266 (esptool can write 128mbit flash). The hard part is be able to boot an openwrt or an network boot from spi flash. On A5X or MX10 there is an usb hub, so i think it's possible to add an usb wifi to remplace the sdio wifi module removed

Rock64 doesn't have on-board wifi. Mine's got a Wifi USB dongle, working fine.