Search the Community

ROCK64 @ 1.488GHz type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 179760.41k 500823.06k 837207.72k 1040921.94k 1120367.96k aes-192-cbc 166930.03k 430311.10k 668937.47k 795866.79k 842443.43k aes-256-cbc 160133.98k 390004.61k 572388.78k 662836.57k 694777.17k The little board that could has broken 1GB/s Edit: According to this it should go all the way up to 1.5GHz without too much extra in the way of Vcore

I tried to generate a debian stretch image and I had the same issue. Apparently there's people using this image and it works https://github.com/ayufan-rock64 Hopefully we can get an Armbian image soon!

I found this thread very interesting. I am experimenting myself with several different NAS options. Today I connected a Cubie HDD RAID sub-board to a Rock64 and two HGST travelstar 7.2k 1TB each. I copied over some 100GB using the samba server that just comes along with Rocks Linux rock64 4.4.77-rockchip-ayufan-118 For large files peeks were at 112MB/s when I copied over from a Win PC through 1GE, but kept a constant rate over 100MB/s. The Cubie sub board uses RAID 1 per default. I tried the copy process again and disconnected one of the disks. Just took it off. Active copy process died. I had the RAID volume mounted as /dev/sda1, but /dev/sda disappeared. That was not expected behavior. I rebooted the Rock64 and was able to mount my volume now only supported by one disk. I started my 100GB copy job again. At first it kept the rate of at least 100MB/s. Then I reconnected the second disk. The rate went down to about 60MB/s. I would think the decrease is due to re-syncing of the volume. I think it's ok to still have 60MB/s while it's doing that. I like this sub board, but I didn't like it disliked removing one disk at run time. I like it gives through USB3 enough IO to max out the 1GE of the Rock64. I don't like I need to solder in order to change the RAID mode. I would rather just have two targets e.g. /dev/sda & /dev/sdb Any other tests I should be doing?

Hi all. I have a Rock64 board with 1GB RAM. I downloaded this image https://dl.armbian.com/rock64/Ubuntu_xenial_default_nightly.7z and I wrote it on the SD card (Samsung EVO 16GB) using both Etcher and dd command. But when I power the board, all 3 leds light up and remains on, nothing else happens. I have the same behaviour with the 0.6.0 stretch-minimal image downloaded here https://github.com/ayufan-rock64/linux-build/releases The only images that works are the 0.5.10 downloaded here https://github.com/ayufan-rock64/linux-build/releases/tag/0.5.10 What's wrong? I can exclude problems with power supply (I bought the one they suggested on their site, 5V 3A) and with SD card because I have no problem with 0.5.10 image. I tested both xenial-mate and stretch-minimal (with the XFCE4 desktop environment installed later) images without problems. Thanks in advance. Matteo

Nope, they sort it by popularity or whatever (Pine64 at the top and ROCK64 at the bottom for example) and try to group by board names (eg. putting LeMaker's Banana Pro and SinoVoip's BPi M2+ in one section while both are totally incompatible -- same problem also with NanoPis). Doing so is HIGHLY MISLEADING since not brands are important but the technical base. A NanoPi NEO 2 and a NanoPi M3 are from two different worlds while a NEO 2 and an Orange Pi Zero Plus are almost the same (especially when Armbian is running on them it will be very hard to spot any difference in usage and performance!) If people search on the download page they search for features. If they're absolutely clueless we can't help them anyway. If we want to guide people a little bit we have to stop what we're doing now (focused on technical details) and start to get into the heads of our users (what are they interested in? And are these the correct reasons? Again 'SATA': Not the existence of a small port with 7 pins to connect a SATA cable to is relevant but what users associate with this. And on boards we list as what they consider the label for 'fast storage' they get just insanely slow and broken GL830 USB-SATA crap). Seriously: people looking for the NAS use case click on GbE, click on SATA, check the boards, think 'the more DRAM the better', think 'the more CPU cores the better', weigh some features and end up buying an Orange Pi Plus 2 instead of an ODROID-XU4 (which is magnitudes faster as NAS but is not even considered since users think 'SATA is better than USB3'). What we do here is highly misleading and must stop.

Yep, I agree that it actually might make no noticable difference. Though I'd like to maximize the chances to have a good setup. Found this blog here: http://salutepc.altervista.org/ssd-on-usb-3-0-3-1-with-trim-support-windows-linux.html He has almost the same setup as I have (or would like to have): - Samsung 850 EVO - StarTech.com USB312SAT3CB - Windows and probably Ubuntu based Rock64 System He also confirms working Trim and the numbers seem quite solid. So I think that startech thingy looks like a solid choice

Wow, thanks for both hints! Real crap, that they advertise it wrongly as JMS578 based. After doing some research I think I will give the Startech USB312SAT3CB a shot. It is based on a ASM1351 USB3.1 Gen2 controller, which (as some other little reviews show) apparently performs better than JMS578 and it has firmware support as well as Trim support added by a Startech firmware. It's a bit more expensive, but I think I can give it a try and see whether it is okay or not. Perhaps I'll make another order of the ROCK64, then I can directly add their JMS578 based USB3toSATA converter to have it as well.

I bought two of them just to realize that they're based on crappy Norelsys chips (the reason why Armbian in the meantime does UAS blacklisting on its own -- the same happens on ayufan OS images for ROCK64 though there it's done differently). The JMS578 ORICO thingie looks different: http://www.orico.cc/goods.php?id=6355 Please read through this carefully again. The guy has one JMS567 and there's something wrong with it (queue size limited to 14 for whatever reasons). When comparing ASM1153 and JMS567/JMS578 they perform both pretty identical (JMS578 should be able to support TRIM but AFAIK there's still software support missing in Linux)

Thank you very much once again @tkaiser! I'm a bit disappointed by the high consumption and simply hoped that there are alternatives. Sure the additional SATA 3.0 PHY is present and need its power to function, thogh usually an SSD does consume less than 50mW in idle, where I expect an SATA PHY to be present as well on the SSD motherboard. Anyway, your hint about the possibility to upgrade firmware etc. is a real advantage in favour of JMS chips. Any pros and cons for JMS567 vs JMS578 ? I assume I would do nothing wrong bying one like this: ORICO Adapter USB 3.0 zu SATA, USB 3.0 Konverter Kabel für SATA III 2.5 Zoll Festplatte HDD und SSD (claiming to be JMS578 based) By the way: Found this mini review, where the ASMedia chips seem to be way better performance wise: https://superuser.com/questions/1059492/usb3-to-sata-adapter-performance EDIT Apparently ASM1351 does a huge leap in random write performance compared to the others. Perhaps I should go for it and look how it is. I assume UASP is supported by recent/relevant Linux kernels for ASM1351? Would be interesting to see how it performs on a ROCK64 with current 4.4.77 ARMBian nightly.

Hello everyone First congratulations for this project. I just started playing with it recently and I am very impressed. Good job! I am the developer of NextCloudPi, which basically consists on providing Nextcloud images for the Raspberry Pi, but has evolved to other flavours such as docker x86 and docker ARM. It also features many scripts for managing the instance that can be run from a classic whiptail like TUI or a simple web interface. The initial goal of the project is to drive as many people away from dropbox into selfhosting, so there's also a Wizard and I try to ease the process of DDNS, certificates and so on. I am after porting it to more powerful boards, so I adapted my build scripts for Armbian and I would like to share them here. I generated a first version of the SD armbian based image for the odroid HC1/X4, that you can find here. If anyone would be interested on trying this and even better help me adapt it further for performance and polish that would be fantastic The build code that I use to produce it is git clone https://github.com/armbian/build ncpbian cd ncpbian wget https://raw.githubusercontent.com/nextcloud/nextcloudpi/master/armbian.sh -O userpatches/customize-image.sh ./compile.sh docker BOARD=odroidxu4 BRANCH=next KERNEL_ONLY=no KERNEL_CONFIGURE=no RELEASE=stretch BUILD_DESKTOP=no NextCloudPi can be installer on any Debian Stretch system with curl -sSL https://raw.githubusercontent.com/nextcloud/nextcloudpi/master/install.sh | bash That script has been tested on Debian x86 servers and also a rock64 (@inos tested it) and an odroid HC1 (and rpi too). Now what I do for the SD images is basically that with a couple adjustments inside customize-image.sh Some issues that I found, maybe you have suggestions the most annoying one: there's about four places where the build process clones from git. There is around a 50% chance that the process will get just stuck there and I have to start over. This means that I sometimes have to try up to five times for the build to finish. Running top inside the container gives 1 root 20 0 21620 5104 2920 S 0.0 0.1 0:00.45 /bin/bash /root/armbian/compile.sh docker-guest BOARD=odroidxu4 BRANCH=next KERNEL_ONLY=no KERNEL_CONFIGURE=no RELEASE=stretch BUILD_DESKTOP=no CLEAN_LEVEL= NO_APT_CACHE+ 9945 root 20 0 4116468 9368 4364 S 0.0 0.1 0:00.16 /usr/bin/qemu-arm-static /bin/bash /tmp/customize-image.sh stretch odroidxu4 odroidxu4 no 9958 root 20 0 4116468 9500 4356 S 0.0 0.1 0:00.28 /usr/bin/qemu-arm-static /bin/bash 10356 109 20 0 4659004 106464 14556 S 0.0 1.3 0:01.66 /usr/bin/qemu-arm-static /usr/sbin/mysqld 13408 root 20 0 4116468 8408 3096 S 0.0 0.1 0:00.10 /usr/bin/qemu-arm-static /bin/bash 14636 root 20 0 4116468 11312 4452 S 0.0 0.1 0:00.12 /usr/bin/qemu-arm-static /bin/bash /usr/local/bin/ncp-update 14668 root 20 0 4116468 9488 4368 S 0.0 0.1 0:00.25 /usr/bin/qemu-arm-static /bin/bash ./update.sh 18087 root 20 0 4116468 8004 2788 S 0.0 0.1 0:00.03 /usr/bin/qemu-arm-static /bin/bash ./update.sh 18929 root 20 0 4116468 9928 4776 S 0.0 0.1 0:00.17 /usr/bin/qemu-arm-static /usr/bin/git clone https://github.com/letsencrypt/letsencrypt 18932 root 20 0 4182572 35188 8016 S 0.0 0.4 0:02.04 /usr/bin/qemu-arm-static /usr/lib/git-core/git-remote-https origin https://github.com/letsencrypt/letsencrypt 18936 root 20 0 4182544 12032 4596 S 0.0 0.2 0:00.24 /usr/bin/qemu-arm-static /usr/lib/git-core/git fetch-pack --stateless-rpc --stdin --lock-pack --thin --check-self-contained-and-connected --cloning https://github.com/le+ 18940 root 20 0 4182544 8980 1416 S 0.0 0.1 0:00.00 /usr/bin/qemu-arm-static /usr/lib/git-core/git fetch-pack --stateless-rpc --stdin --lock-pack --thin --check-self-contained-and-connected --cloning https://github.com/le+ 18942 root 20 0 19948 3652 3128 S 0.0 0.0 0:00.04 bash 18957 root 20 0 38328 3344 2904 R 0.0 0.0 0:00.01 top Also, I had to re-set the root password for installing some packages that use `sudo -u`, such as mariadb, or I get Setting up mariadb-common (10.1.26-0+deb9u1) ... update-alternatives: using /etc/mysql/mariadb.cnf to provide /etc/mysql/my.cnf (my.cnf) in auto mode Selecting previously unselected package mariadb-server-10.1. (Reading database ... 33975 files and directories currently installed.) Preparing to unpack .../mariadb-server-10.1_10.1.26-0+deb9u1_armhf.deb ... You are required to change your password immediately (root enforced) chfn: PAM: Authentication token is no longer valid; new one required adduser: `/usr/bin/chfn -f MySQL Server mysql' returned error code 1. Exiting. dpkg: error processing archive /var/cache/apt/archives/mariadb-server-10.1_10.1.26-0+deb9u1_armhf.deb (--unpack): subprocess new pre-installation script returned error exit status 1 Finally, postfix postinstallation script fails here /usr/sbin/postconf: fatal: inet_addr_local[getifaddrs]: getifaddrs: Address family not supported by protocol So it gets marked as not successfully installed until we run some apt action on the board. Not a big deal really but it would be nice to fix it without ugly hacks. It seems like a qemu-user-static issue https://lists.gnu.org/archive/html/qemu-devel/2016-05/msg02382.html I tested this with my odroid HC1 and I also own a rock64 like this one. Next, I want to try it on the rock64, so what target should I use to build for this board? Thanks, and I hope this is helpful! Feedback is welcome!

Ok, so that's bad news and good news. Bad news about the aggressive spin down, and good news that JMicron is at least listening to you and working on it. It's a shame I didn't read your message before ordering two HC1s today, but then it sounds like my other choice (rock64 plus it's sata adapter) has the same problem. Let's hope that JMicron come through with that fix!

My Z28 PRO is running Armbian using this method and our Rock Nightly image https://dl.armbian.com/rock64/Ubuntu_xenial_default_nightly.7z ... of course, fine-tuning is needed since I don't see ethernet nor Wifi, but luckily there is a screen and USB. http://sprunge.us/UeGE Serial console login works. How to get properly into MASK ROM mode, which is needed to flash to eMMC on Alfawise Z28 PRO? Short a resistor marked on a picture and attach male A-A USB cable to USB otg port - on the other end as USB3.

Hello, I was able to overclock the CPU to 1.488Ghz by editing rk3328-rock64.dtb file. But I can not figure out how to set the RAM-clock-speed. Is there any chance to ramp up the RAM clock?

another Fast Ethernet (100M) box. I haven't figured out if that sdmmc0 fuck up on the z28 pro is global to all Gbe versions of rk3328 boards, probably not.. I'll have more time to play with my z28 pro over the weekend, test linux and so on.. those log entries got me a little worried (ayufan rock64 git) :

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.