Search the Community

A 4.13 DTS patch just popped up on patchwork for Rock64, in case anyone is interested. https://patchwork.kernel.org/patch/9892325/ There was a small mountain of patches stuffed in there yesterday, should go through them

I am not much of a developer as my skills are more rust. As an end user the two products that are of most interest to me are the Rock64 & Helios4. Rock64 with the 4GB is sort of an allrounder with the Mali & USB 3.0 with the possibility of just hooking it up to OEM 4bay USB Jbod/Raid box, NAS with maybe KODI on top. Helios4 really interested in that NAS specific design, but got a feeling the Rock64 will garner more interest as a building block rather than a specific solution. I just purchased a Rock64 and hopefully can glean some wisdom from you guys. [Edit] http://espressobin.net/ looks pretty interesting and again opens up router / nas solutions. Still think the Rock64 offers a bit less but may be more general purpose that sort of fits its budget.

Benchmarks test software not hardware Here you go: Debian Jessie armhf: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 44271.21k 52204.07k 55156.22k 56023.72k 56142.51k aes-256 cbc 34693.89k 39353.94k 41079.04k 41499.31k 41645.40k bf-cbc 29864.52k 37308.12k 39764.57k 40467.80k 40667.82k Debian Stretch armhf: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128 cbc 42906.97k 51552.64k 54543.45k 55381.67k 55536.30k 55437.99k aes-256 cbc 29686.84k 37227.41k 39764.91k 40532.99k 40719.70k 40654.17k bf-cbc 28744.72k 39247.51k 43142.74k 44282.20k 44583.59k 44569.94k Debian Stretch arm64: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128 cbc 41623.29k 44895.06k 46213.89k 46552.41k 46620.67k 46574.25k aes-256 cbc 33123.65k 35228.65k 36029.53k 36235.26k 36268.71k 36235.95k bf-cbc 29389.00k 39838.93k 43663.10k 44790.10k 45118.81k 45105.15k Ubuntu Xenial armhf: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 44997.09k 51821.85k 54241.71k 54892.20k 55025.66k aes-256 cbc 34964.21k 38755.18k 40066.39k 40408.06k 40501.25k bf-cbc 32691.63k 38896.87k 40785.58k 41335.13k 41487.02k Ubuntu Xenial arm64: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 40718.71k 44137.43k 45305.69k 45607.59k 45662.21k aes-256 cbc 32820.84k 34230.12k 34952.36k 35160.41k 35687.08k bf-cbc 33233.00k 39495.68k 41386.75k 41935.19k 42087.77k In case any moderator cares about readability please add spoiler tags for the following (I will never use this functionality again with this interactive forum mess here): RK3328 allowed to clock at 1296 MHz max. Numbers below for Debian Jessie armhf userland running on 2GB and 4GB ROCK64 (same single bank DRAM config using same slower 1600 MHz DRAM settings on all boards BTW):

I got the same issue when I tried serial-debug on Rock64, output on TX is Ok, but no RX. Probably something in DT.

I just booted a mainline kernel on my Rock64 (4.12-rc7 with defconfig, rest was from ayufan's minimal xenial image) and that seems to work ok. Currently investigating a problem with the GMAC0 not finding the PHY, so no network at the moment, but USB2 seems to work, USB3, video and audio drivers are not there yet... Boot log: http://pastebin.ubuntu.com/25206030/ I guess I will try 4.12.4, 4.13-rc2 and rockchip-next as well...

I am sorry, that I can´t help on this Topic. I am just a User and not someone who can deal with Driver Issues. Looking at Rockchip, i think that they have massive Problems with Sound-Drivers besides BSP Kernels. On my z28 (RK3328) I have only Sound on Android. I don´t think that there will be changes in near future, that is why I cancelled my Order on Rock64.

This sounds like a familiar issue I have with my Rock64 sample too, there seems something wrong with the sampling clock for the analog audio codec...

Thanks Igor. Pointing me to search for AP6212 led to other posts and post topics and I ended up at this post: https://forum.armbian.com/index.php?/topic/4578-example-support-proposal-for-rock64/& Although this is kind of off topic, I started this post explaining having tried the ESP32, CHIP, CHIP PRO and now the Orange Pi Zero+2 H5. I now have 5 x ESP32, 3 x CHIP, 7 x CHIP PRO (+ development kit) and 3 x OPI Z+2 H5. I found @TKaiser Board Support Proposal particularly interesting. Obviously I'm a newbie here and knew nothing about Armbian until purchasing the OPI boards just a few days ago, I wish I had known about Armbian sooner then perhaps I would not have such a large graveyard of latest tech SBC's. To the point of @TKaiser's post, as a "user" and "newbie" the information Armbian can provide PRIOR to a user purchasing a new, latest and greatest board based on Google searches and technical specs, is invaluable IMO. On each of the above boards I hit a brick wall and cannot continue development due to support issues. I read that it would have been a smarter choice to purchase the OPI Z+2 H3 version rather than the H5 version. My project specifically requires Linux OS, WIFI, BLE, GPIO and Camera. It also needs to be very inexpensive. You guys are so knowledgeable about the intricacies of each board you support (whether good or bad) that as a user I could make a far more informed decision based on your board recommendations which in turn are based on my board functionality requirements. At this point, referring to the specific board requirements above, should I add the OPI Z+2 H5 to the graveyard and go for the OPI Z+2 H3 board? If so, do you know if the H3 board definitely supports Bluetooth Low Energy? I presume the H3 board uses the older and inferior performing AP6212 chip rather than the AP6212A chip? FYI: The CHIP was the only board that provided all required functions albeit camera operation via USB which is just too slow FPS. Later to find out the CHIP uses low quality components, is not recommended for commercial use and is not warranted (after all, it's only $9)!! They recommended the CHIP PRO. Unfortunately, on the CHIP PRO the CSI camera interface seems completely unsupported and the CSI hardware connection looks a little weird when compared to other CSI boards and cameras. Thanks yet again for all your help.

And this is with latest official Armbian nightly without mPCIe card and SATA disk connected after mounting rootfs and doing root@rock64:/mnt/sda1/boot# ln -s /boot/dtb-4.4.73-mvebu64/marvell/armada-3720-community.dtb armada-3720-community.dtb https://pastebin.com/YGtgAYZz

Hmm... I tried it now with my older 4.4.52 based OMV build and it looks like this then: https://pastebin.com/cF9eHnKf So after mounting the rootfs and doing a root@rock64:/mnt/sda1/boot# cp dtb/marvell/armada-3720-community.dtb armada-3720-community.dtb it looks like this: https://pastebin.com/RWJi6YuU I have read-only serial console access (can't type anything) and this thing overheats really badly within a minute.

Since I would believe this eMMC connector isn't made for much matings I prefer to leave the eMMC where it is. Then there are three opportunities: Use a male-to-male USB cable, get the device into MaskRom mode (google --> 'maskrom site:armbian.com') and flash the eMMC directly from a host device Burn an image to SD card, boot ROCK64 from SD card and then use whatever mechanism to either overwrite the eMMC with a complete OS image or use later Armbian's nand-sata-install to transfer the installation from SD card to eMMC When community+RK got an universal bootloader working and Pine Inc starts to flash this to the SPI NOR flash on the board a guided installation routine will eventually be possible that fetches an OS of choice from the Internet or locally and then overwrites the eMMC with this (device specific bootloader remaining on the SPI NOR flash, OS image being device agnostic). Not yet ready and I doubt we're talking here about 2017 too With my testings so far I had a hard time getting ROCK64 to throttle with normal workloads and the currently implemented DVFS OPP table (maxing out at 1296 MHz). This might look differently when we add more DVFS OPP to reach the advertised 1.5GHz (since then Vcore voltage has also to be increased and then throttling is more likely to occur). You should also keep in mind that ODROID-C2 has a better GPU than ROCK64 and Hardkernel folks in the beginning thought they would deal with a 2.0GHz SoC here (just to discover later that Amlogic's blobs simply reported wrong cpufreq and limited max cpufreq to 1.5GHz anyway). So the heatsink on C2 is both slight overkill but also sufficient to not run into throttling situations there unless you use really stupid small enclosures. On ROCK64 I tested with my usual el cheapo $0.5 heatsink and this was responsible for maybe ~5°C less and throttling jumping in later (I used cpuburn-a53 which is the most heavy CPU load I currently know of for A53 cores). Putting ROCK64 in an upright position allowing the PCB bottom to receive some airflow instead of placing it on a pillow had a similar effect. I would believe most of the heat gets dissipated into the PCB below the SoC already.

Thanks @Xaliusand @TonyMac32 @Xalius Speaking about the odroid Adaptor. I read that the rock64 eMMC may be compatible to Odroids eMMC, but cannot find any definitive proof. Now you mention it as well, so may I ask which odroid you refer to? There are, as far as I know, at least two different Odroid eMMCs specifications: one line-up works only with the odroid Cy models (info mentioned on product page). And the other only with Odroid Xy and Uy models. May I ask which odroid you own?

I either use the eMMC adapter that came with one of my ODROIDs or write to the eMMC from a sdcard image. There is also a flash tool from RK that uses USB-OTG via USB A-to-A cable... As for heatsinks, I mounted a small 14x14x14mm sink since I build a lot on my Rock64 and that keeps it from throttling with all four cores running at 1.3Ghz. The RK3328 is implemented with 28nm node, not sure what S905 uses? http://www.fischerelektronik.de/web_fischer/en_GB/heatsinks/B01/Heatsinks for PGA/PR/ICKPGA14x14x14_/index.xhtml

I wonder how you guys write to eMMC. Is it shipped with an eMMC-to-MicrsoSD adaptor, like the Hardkernel eMMCs? Also I'd like to know whether the board has a heatsink mounted? SOC wise it is comparable to Odroid C2, but all the pictures of ROCK64 are without heatsink, although the SOC is apparently running at 1.5GHz, just like the Odroid C2. Is it perhaps a shrunk process node, thus dissipating less heat (than Odroid C2)?

mmm very interesting, maybe in the future can be the replacement to my Beelink X2 Please note: 'The high-end version ( 2G RAM + 16G ROM ) has gigabit interfaces, with dual-band 2.4G + 5.8G WiFi and Bluetooth 4.0' Gigabit Ethernet and SDIO Wi-Fi/BT are mutually exclusive with RK3328 so wireless capabilities are provided via USB here. The box design will follow closely RK's reference design so we can take a look at ROCK64 schematics (page 4, lower left corner --> 'Config 2') but of course no one knows yet whether we need there adjusted Gigabit Ethernet TX/RX delay settings...

It depends on your specific needs. Usually, it's never just about pure calculating power. A theoretical comparison is usually bad way since you (can) have bad kernel/support on those big numbers and the board can still not be used for nothing but (Android) media player ... where top stability is not needed. There is usually no schematics for media players and therefore it's much harder to fix anything. And ... there will not be many people having this player since it's costly. But. It can be better than this and you might get lucky. Sometimes some player works well I put my luck on Alfawise Z28 Pro since it matches chip on Rock64 where we are putting our efforts to. Not that powerful but with more chances of success.

@r1kaomsk, the 4.4.x BSP kernel tried to store MACs in the GPT vendor partition on the eMMC. ayufan changed that for Rock64 images to the SPI flash since eMMC are removable here...

Just for the Record, i have Ayufan´s Xenial-Mate-Rock64-Armhf Image running on a Z28 TVBox 1GbRam/8Gb Emmc....

Well, we have to keep in mind that this is just a TV box SoC and not designed for serious storage tasks. Especially the choice of protocols/connectors is not comparable. Please look at the dmesg output starting from 15.730777. That was me testing with a JMS567 enclosure and running in all sorts of errors. I shut the board down, reinserted the cable --> problem gone. When testing with the cable not properly inserted it looked like this (please notice the orange triangles which show minimum and maximum values since bus resets happened and other stuff -- surprisingly no filesystem corruption): In other words: Cabling/connector issues are quite common with USB3. USB3 cables/receptacles have 5 more contacts than USB2 gear and those are f*cking small compared to the 2 contacts used for Hi-Speed/USB2 data lines. Only if cables really fit exactly and are inserted fully you won't run in troubles: USB3 is cheap consumer electronics crap and you need to pay a lot of attention to such stuff! For the USB2 data lines it doesn't matter much whether the cable is completely inserted or not but those small USB3 contacts need 'full contact' and since the SuperSpeed data lines are on the outer contacts small movements of the cable can negatively impact connectivity (you touch the cable, it's now inserted with 3° instead of 0° and problems start). In case I'll ever build a small NAS with a ROCK64 there are 3D printed parts needed to properly fix the cable since everything else is just plain stupid. Even HDD vibrations can lead to contact problems over time if the cable is not properly fixated! And now have a look how 'Mini SAS' or SATA look like. The contact surface is much MUCH larger, some cable bending is exactly no problem and there are metal latches by design to fixate cable/connector: And then all serious storage protocols know mechanisms to deal with cable/connector problems. With SATA for example we have SMART attribute 199. If this value increases this indicates a cable/connector problem since SATA uses some checksumming to ensure data integrity. SMART counter 199 should increase if this happens so you know exactly where to look at. With USB3/UAS the error messages read like 'uas_eh_abort_handler 0 uas-tag 7 inflight: CMD OUT' and people get crazy yelling 'UAS is evil!' while they would run in exactly the same problems without UAS but then the error messages read differently.

@tkaiser Damn, thats really impressive! This thingy looks like it is going to bring load of fun for little NAS and server applications. Obviosly not comparable to Synology or similar, but it's also not meant to compete with such devices. Great great, thanks for these tests! It's a shame that pine64 is the only distributor, hence it won't push into the market like Rapsberry and Odroid C2 (in case that LibreELEC support vor ROCK64 will ever come to a usable stage). On the other hand... ROCK64 board seems to initiate software development as a pioneer, so many other manufacturers may come with RK3328 boards then. Just like Odroid C2 started the S905/S905x/S912 boom.

And another small ROCK64/RK3328 update. We're still struggling with some USB problems (RK engineers are aware of and I hope we'll see a fix soon) but since ayufan in the meantime also creates OMV images for ROCK64 automagically I thought let's give it a try again. The settings we came up with the last 3 months here and over in OMV forum are almost all adopted but I ran into some minor glitches with ayufan's build. I had trouble with running rrdcached keeping all cores busy at 100% (had to deactivate it manually), then it seems /usr/local/sbin/rock64_fix_irqs.sh doesn't get executed at boot (this script does the usual tuning Armbian does in /etc/init.d/armhwinfo on all platforms -- a lot of time/efforts went into this over the years) and then also /var/lib/netatalk/CNID isn't handled by folder2ram which negatively affects some of the Netatalk performance numbers below (everything dealing with small files/requests). Also /etc/cron.d/make_nas_processes_faster doesn't work, also manually trying to set I/O scheduling class and priority has no effect (maybe a missing kernel config?). Anyway: executing the /usr/local/sbin/rock64_fix_irqs.sh script increases NAS throughput numbers by 15-20 MB/s and even if not all tunables work right now and we will get 1 or even 2 USB3/UAS fixes it now looks like this (first test made with JMS567, 2nd with ASM1153 powered by ROCK64): Identical performance (every variation below 5% is identical!) and since CNID database currently lives on the rootfs which is on a SD card the numbers for 'create' and 'lock/unlock' will automagically decrease once folder2ram will take care of the CNID databases. With Windows Explorer or macOS Finder sequential transfer speeds exceeding 100 MB/s should already work (see here why/how LanTest test results differ)

Now a second SSD (very slow Intel 540) in a second JMS567 connected to the VIA 812: root@rock64:/home/rock64# lsusb Bus 005 Device 005: ID 0bda:8153 Realtek Semiconductor Corp. Bus 005 Device 004: ID 152d:3562 JMicron Technology Corp. / JMicron USA Technology Corp. Bus 005 Device 003: ID 152d:3562 JMicron Technology Corp. / JMicron USA Technology Corp. Bus 005 Device 002: ID 2109:0813 Bus 005 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 004 Device 002: ID 2109:2813 Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub root@rock64:/home/rock64# lsusb -t /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M |__ Port 2: Dev 3, If 0, Class=Mass Storage, Driver=uas, 5000M |__ Port 3: Dev 4, If 0, Class=Mass Storage, Driver=uas, 5000M |__ Port 4: Dev 5, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M I created a btrfs raid-0 (mkfs.btrfs -f -m raid0 -d raid0 /dev/sda1 /dev/sdb2) and tried it again: Samsung EVO 840 and Intel 540 as RAID-0 with UAS behind VIA 812: random random kB reclen write rewrite read reread read write 102400 4 7760 6563 15659 15284 11590 4870 102400 16 21240 16059 49077 39481 39938 11588 102400 512 158914 128861 126339 127106 122961 134573 102400 1024 169372 173392 152526 128089 128313 167697 102400 16384 257307 1592 287695 284334 288541 241423 Shitty performance as expected and especially the 16M rewrite horribly low due to the yet missing fix for an USB3 PHY issue currently present on RK3328: https://pastebin.com/wkkdgV4J RAID at home is stupid anyway but once the USB3 issues are fixed upstream I would believe adding more than one disk to a ROCK64 and accessing them even at the same time won't be an issue since performance will still be way faster than the Gigabit Ethernet bottleneck here (if you look closely my USB hub also contains an RTL8153 Gigabit Ethernet USB chip -- the same that is used on ODROID-XU4 BTW -- so most probably later we see crazy folks doing crazy stuff like using a ROCK64 as iSCSI server utilizing Multipathing to serve clients with up to 220MB/s)

I am currently trying to patch some holes in the Rock64 dts. There seem to be some regulator properties missing and some GPIOs for card detect... I got this in the beginning: http://pastebin.ubuntu.com/25013127/ I got rid of the "rk808 1-0018: Looking up vccX-supply property in node ..." by defining the regulator inputs in the dts, and adding a fixed 5V regulator for DC input: https://github.com/ayufan-rock64/linux-kernel/pull/3/files But I have a problem now that the regulator driver can not connect the new inputs or rather created the symlinks in syfs (symptom?) [ 2.087955] rk808 1-0018: Pmic Chip id: 0x8050 [ 2.096971] rk808 1-0018: source: on=0x40, off=0x00 [ 2.108733] rk808 1-0018: Looking up vcc1-supply from device tree [ 2.108849] DCDC_REG1: supplied by vcc_sys [ 2.116743] vcc_sys: could not add device link regulator.4 err -2 [ 2.118643] vdd_logic: 712 <--> 1450 mV at 1100 mV [ 2.118947] reg-fixed-voltage sdmmc-regulator: Looking up vin-supply from device tree [ 2.118981] vcc_sd: unable to resolve supply [ 2.119009] rk808 1-0018: Looking up vcc2-supply from device tree [ 2.119100] DCDC_REG2: supplied by vcc_sys [ 2.126809] vcc_sys: could not add device link regulator.5 err -2 [ 2.128223] vdd_arm: 712 <--> 1450 mV at 1000 mV [ 2.128528] reg-fixed-voltage sdmmc-regulator: Looking up vin-supply from device tree [ 2.128559] vcc_sd: unable to resolve supply [ 2.128586] rk808 1-0018: Looking up vcc3-supply from device tree [ 2.128674] DCDC_REG3: supplied by vcc_sys [ 2.136256] vcc_sys: could not add device link regulator.6 err -2 [ 2.137517] vcc_ddr: at 5000 mV [ 2.137767] reg-fixed-voltage sdmmc-regulator: Looking up vin-supply from device tree [ 2.137797] vcc_sd: unable to resolve supply [ 2.137825] rk808 1-0018: Looking up vcc4-supply from device tree [ 2.137907] DCDC_REG4: supplied by vcc_sys [ 2.145348] vcc_sys: could not add device link regulator.7 err -2 [ 2.146250] vcc_io: 3300 mV [ 2.146552] reg-fixed-voltage sdmmc-regulator: Looking up vin-supply from device tree [ 2.146583] vcc_sd: supplied by vcc_io [ 2.154221] rk808 1-0018: Looking up vcc5-supply from device tree [ 2.154254] LDO_REG1: supplied by vcc_io [ 2.161514] vcc_io: could not add device link regulator.8 err -2 [ 2.163889] vdd_18: 1800 mV [ 2.164188] rk808 1-0018: Looking up vcc5-supply from device tree [ 2.164220] LDO_REG2: supplied by vcc_io [ 2.171394] vcc_io: could not add device link regulator.9 err -2 [ 2.173749] vcc_18emmc: 1800 mV [ 2.174041] rk808 1-0018: Looking up vcc6-supply from device tree [ 2.174072] LDO_REG3: supplied by vcc_io [ 2.181197] vcc_io: could not add device link regulator.10 err -2 [ 2.183588] vdd_10: 1000 mV

Fire219 just got his board and ran a GbE test using ayufan's latest image (only tx-offloading enabled by default) with performance governor. Rock64 (client) --> Thinkcentre (server) [ 4] local 192.168.0.120 port 49148 connected to 192.168.0.85 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 104 MBytes 868 Mbits/sec 0 2.39 MBytes [ 4] 1.00-2.00 sec 108 MBytes 904 Mbits/sec 0 2.39 MBytes [ 4] 2.00-3.00 sec 108 MBytes 902 Mbits/sec 0 2.67 MBytes [ 4] 3.00-4.00 sec 108 MBytes 902 Mbits/sec 0 2.67 MBytes [ 4] 4.00-5.00 sec 105 MBytes 880 Mbits/sec 0 3.63 MBytes [ 4] 5.00-6.00 sec 110 MBytes 921 Mbits/sec 0 3.63 MBytes [ 4] 6.00-7.00 sec 105 MBytes 883 Mbits/sec 0 3.63 MBytes [ 4] 7.00-8.00 sec 110 MBytes 923 Mbits/sec 0 3.63 MBytes [ 4] 8.00-9.00 sec 106 MBytes 891 Mbits/sec 0 5.45 MBytes [ 4] 9.00-10.00 sec 106 MBytes 891 Mbits/sec 0 5.45 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 1.04 GBytes 896 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 1.04 GBytes 894 Mbits/sec receiver iperf Done. Thinkcentre (client) --> Rock64 (server) [ 4] local 192.168.0.85 port 54468 connected to 192.168.0.120 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 111 MBytes 931 Mbits/sec 0 450 KBytes [ 4] 1.00-2.00 sec 112 MBytes 941 Mbits/sec 0 474 KBytes [ 4] 2.00-3.00 sec 112 MBytes 937 Mbits/sec 0 474 KBytes [ 4] 3.00-4.00 sec 111 MBytes 929 Mbits/sec 0 474 KBytes [ 4] 4.00-5.00 sec 112 MBytes 940 Mbits/sec 0 474 KBytes [ 4] 5.00-6.00 sec 111 MBytes 933 Mbits/sec 0 474 KBytes [ 4] 6.00-7.00 sec 112 MBytes 938 Mbits/sec 0 474 KBytes [ 4] 7.00-8.00 sec 112 MBytes 942 Mbits/sec 0 474 KBytes [ 4] 8.00-9.00 sec 112 MBytes 936 Mbits/sec 0 474 KBytes [ 4] 9.00-10.00 sec 112 MBytes 936 Mbits/sec 0 474 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 1.09 GBytes 936 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 1.09 GBytes 934 Mbits/sec receiver iperf Done.

@TonyMac32 I have to find out, but iirc it is the same. I did some more test and basic writing/reading with mtd-utils seems to work now, just read back a block after power cycling: root@rock64:/home/rock64# nanddump -l500 -f test.bin /dev/mtd0 ECC failed: 0 ECC corrected: 0 Number of bad blocks: 0 Number of bbt blocks: 0 Block size 4096, page size 1, OOB size 0 Dumping data starting at 0x00000000 and ending at 0x000001f4... root@rock64:/home/rock64# cat test.bin Hello World! I am a SPI Flash! This is a test! root@rock64:/home/rock64#