Search the Community

BPi Zero means: Allwinner H2+ with 16-bit memory interface. So results should be almost the same as with NanoPi NEO (Allwinner H3 which is the same as H2+ and also 16-bit memory interface): https://forum.armbian.com/topic/7776-benchmarking-cpus-not-yet-a-research-article/?do=findComment&comment=58554 (what also matters is DRAM clockspeed and kernel version). Your BPi Zero scores 2109 while my NEO limited to 1.1 GHz scores 2088 --> same numbers. So most probably your Zero started to throttle down (quite common with small boards if they don't wear huge heatsinks) There's a reason I asked for the output of '7zr b ; 7zr b' above (executing the benchmark at least 2 times -- 'fire and forget' benchmarking is bad). Since users obviously hate monitoring (so only generating numbers without meaning) the 2nd 7z execution would show actual clockspeeds. The new 7-zip versions contain a clockspeed measuring algorithm producing something like this at the start of the benchmark: CPU Freq: 765 1192 1193 1193 1191 1193 1193 1193 1193 This confirms that the CPU cores were running at 1.2 GHz when starting the benchmark. The 2nd 7z call would run this again so if the RPi firmware in the meantime started to throttle it would be obvious by looking at these numbers. Also 2nd benchmark run would produce lower numbers so 'throttling had happened' can not be overlooked. Your RPi 3 scored 3277, my Rock64 scored 3594. Both times 4 Cortex-A53 cores. RPi 3 set to 1.2 GHz, Rock64 set to 1.4 GHz. Results more or less as expected. The RPi 3+ when really clocking with 1.4 GHz will perform also better. But as explained above RPi Trading guys rolled out a new ThreadX release (AKA 'firmware') that cripples all RPi 3+ around to throttle down to 1200 MHz even with medium loads. BTW: I'm asking here for 7-zip numbers not since I'm interested in 'RPi 3+ performance' (this is predictable since it's just a boring quad-core A53) but to demonstrate that MONITORING is important when benchmarking and that passive benchmarking always only generates numbers without meaning

yes i've heard about the rock64 gbe problem, don't know if it was finally solved (pcb tracks timings), but i don't know about a global rk3328 GMAC interface problem. So far i can't fault my z28pro Gbe, it has been running a torrent through vpn with continuous upload of 30-50Mbps and i haven't noticed any problem, nor any dubious log output.. i've done a short 6 min iperf test : i also transfered approx 750GB of real data to an attached USB drive and about 80MB/s and it didn't fail. If it's not a physical hardware issue, and yes the ethernet pcb design on that device is quite insane ( massive gap under the transformer, although strictly following the datasheet recommendation), i must say that all my traffic is going through quality shielded cat6 cables with proper earth. well the z28pro 2G/16G (Gbe, Wifi AC+BT) being often available at or below 40e, i don't think you'll find a Usb3/Gbe device at a lower price. I'll leave the dev boards aside although i don't think they are much cheaper and you should at least add the cost of a case and power adapter.

yes, on Rock64. CardReader is USB2. I reproduced the same error with NetworkManager generated file inserted into that poor package list file. after typing several times apt-get with different commands (purge, clean, autoclean, install, update) and dpkg --configure -a, package list file got corrupted again with exactly the same NM stuff... every debian package system utility (apt-get, debconf-*) complained about syntax errors in Perl files. Mostly in File.pm. looking there showed something like this: nless(XXX){} } } } } 1; ^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@;^@; with "nless" and mismatched curly braces. XXX - some C-macro looking thing, I forgot exact name of it. Could this kind of damage be a result of a FS corruption? Are these perl library files generated dynamically somehow, or are they just unpacked from zipped archives during the installation? Since it got quite psychedeIic, I just reinstalled Armbian on the same card and it worked well so far. And by the way the proper file File.pm even doesn't have "unless" keyword in it.

Just to be clear: this was on Rock64 and you fiddled around with SD cards in an external USB card reader? Is the card reader SuperSpeed capable ('USB 3.0')?

Regarding the Gb-Lan-problems I recognized a declining speed, which occurred quite frequently after some time. And because there were some similar reports for the Rock64 on other sites, I assumed it was a general problem of the RK3328. But this might be wrong, because another aspect is, that the LAN-Port on this box is as strong as the grip of the hand of Mr. Burns . This thing is the most sloppiest Port I've ever seen. You don't feel a click, when you plug the cable in. In the end it is possible, that I only face a mechanical problem here. Beside that, I think it is a nice little box and if the onboard devices are useable for your needs, it is relatively cheap.

With this commit I added 7-zip benchmark reporting to Armbian now. Will be available after next updates and with next batch of new images. Why not recommending to just do an 'apt install p7zip ; 7zr b'? Since 'fire and forget' benchmarking is always BS. You need some monitoring in parallel to know whether your system was really idle and at which clockspeeds the CPU cores were operating (throttling occuring or not?). Most recent 7-zip contains an own routine to 'pre-heat' the system prior to starting the benchmark (to let cpufreq scaling switch from low clockspeeds to highest ones and e.g. on Intel systems let the system enter TurboBoost modes). This 7-zip code runs single threaded so based on the kernel's scheduler sometimes ending up on the 'wrong' CPU core (e.g. a little core on big.LITTLE SoCs) On a NanoPC T4 with conservative settings (limiting big CPU cores to 1.8 GHz and little cores to 1.4 GHz) this looks like this: root@nanopct4:/home/tk# armbianmonitor -z Preparing benchmark. Be patient please... 7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,6 CPUs LE) LE CPU Freq: 1413 1414 1414 1411 1413 1414 1414 1414 1415 RAM size: 3878 MB, # CPU hardware threads: 6 RAM usage: 1323 MB, # Benchmark threads: 6 Compressing | Decompressing Dict Speed Usage R/U Rating | Speed Usage R/U Rating KiB/s % MIPS MIPS | KiB/s % MIPS MIPS 22: 3642 363 976 3543 | 98020 543 1540 8359 23: 3691 365 1030 3761 | 95217 541 1522 8239 24: 3606 354 1094 3878 | 92662 535 1520 8133 25: 4597 451 1164 5249 | 89079 529 1498 7928 ---------------------------------- | ------------------------------ Avr: 383 1066 4108 | 537 1520 8165 Tot: 460 1293 6136 Monitoring output recorded while running the benchmark: Time big.LITTLE load %cpu %sys %usr %nice %io %irq CPU C.St. 10:16:19: 1800/1416MHz 0.12 12% 1% 7% 2% 1% 0% 44.4°C 0/5 10:16:25: 408/ 600MHz 0.11 0% 0% 0% 0% 0% 0% 43.9°C 0/5 10:16:30: 600/1416MHz 0.10 1% 0% 0% 0% 0% 0% 45.0°C 0/5 10:16:35: 1800/1416MHz 0.17 40% 0% 39% 0% 0% 0% 49.4°C 0/5 10:16:40: 1800/1416MHz 0.32 77% 0% 77% 0% 0% 0% 55.0°C 0/5 10:16:45: 1800/1416MHz 0.94 73% 0% 72% 0% 0% 0% 51.1°C 0/5 10:16:50: 1800/1416MHz 0.94 65% 0% 65% 0% 0% 0% 53.3°C 0/5 10:16:55: 1800/1416MHz 1.19 68% 0% 67% 0% 0% 0% 56.1°C 0/5 10:17:00: 1800/1416MHz 1.49 79% 1% 78% 0% 0% 0% 53.9°C 0/5 10:17:06: 1800/1416MHz 1.45 31% 0% 31% 0% 0% 0% 57.8°C 0/5 10:17:11: 1800/1416MHz 2.07 68% 0% 67% 0% 0% 0% 57.2°C 0/5 10:17:17: 1800/1416MHz 2.30 78% 0% 77% 0% 0% 0% 58.9°C 0/5 10:17:22: 1800/1416MHz 2.52 90% 1% 89% 0% 0% 0% 57.8°C 0/5 10:17:27: 1800/1416MHz 2.72 81% 0% 80% 0% 0% 0% 57.2°C 0/5 Time big.LITTLE load %cpu %sys %usr %nice %io %irq CPU C.St. 10:17:32: 1800/1416MHz 2.66 61% 0% 60% 0% 0% 0% 60.6°C 0/5 We get an overall score of above 6100 and 7-zip's 'CPU Freq' line reports CPU0 (a little core) being clocked at 1.4 GHz. But since this is a big.LITTLE design we need the monitoring output that gets displayed below 7-zip benchmark numbers. By looking at the 2nd line we see that the system was totally idle prior to starting the benchmark (I implemented a 10 second sleep between starting monitoring and firing up the benchmark for this reason -- to control whether the system was already busy or not). As a comparison 7-zip numbers of another RK3399 board that allowed the CPU cores to clock slightly higher (2.0/1.5 GHz): ODROID-N1 scored 6500. As a reference some other boards. Rock64 with new 1.4 GHz settings: NanoPi NEO with cpufreq scaling limited to 816 MHz to keep the board always at lowest DVFS voltage (results irrelevant) Please keep in mind that benchmarks that run fully multi threaded are NOT representative for most workloads running on computers (they're single threaded). Also please keep in mind that while 7-zip is not that much affected by different compiler settings (like the infamous sysbench) of course it is somewhat. So when you see 7-zip benchmark numbers generated few years ago when the 7z binary has been built with a GCC 4.x most probably with today's software and a binary built by GCC 7.x you see higher scores. So take these comparison numbers with a grain of salt: https://s1.hoffart.de/7zip-bench/ To get new armbianmonitor with -z functionality today it's as easy as wget -O /usr/bin/armbianmonitor https://raw.githubusercontent.com/armbian/build/master/packages/bsp/common/usr/bin/armbianmonitor

apt.armbian.com is not up to date: root@rock64:~# apt-cache search headers | grep rk3328 linux-headers-dev-rk3328 - Linux kernel headers for 4.14.0-rc2-rk3328 on arm64 linux-headers-rk3328 - Linux kernel headers for 4.4.77-rk3328 on arm64 By switching to 'nightly' with armbian-config (and accepting that you're fine with a bricked system) which replaces apt.armbian.com with beta.armbian.com things change: root@rock64:~# uname -a Linux rock64 4.4.138-rk3328 #10 SMP Mon Jul 9 13:05:42 PDT 2018 aarch64 GNU/Linux root@rock64:~# apt-cache search headers | grep rk3328 linux-headers-dev-rk3328 - Linux kernel headers for 4.17.0-rc6-rk3328 on arm64 linux-headers-rk3328 - Linux kernel headers for 4.4.138-rk3328 on arm64 Of course this is not a solution.

My friend is trying to set up ZFS on his Rock64 and we've tried everything under the sun to get this thing working but we've hit a wall every single time We're running Armbian Xenial version 4.4.124 and downloaded the kernel header (4.4.0-124) because using armbian-config gave a kernel mismatch error, and it still reports that it can't find the kernel header. We couldn't find a 4.4.124 header, for some reason there are only 4.4.0-x available. The process fails with installing ZFS with the lines: Loading new spl-0.6.5.6 DKMS files... Building only for 4.4.124 rk3228 Module build for the currently running kernel was skipped since the kernel source for this kernel does not seem to be installed. The armbian-config doesn't seem to download the correct headers into /usr/src/linux-headers-4.4.x , we only have 4.4.77... The only option for the headers is to uninstall them. Any help would be greatly appreciated! We've not been able to get ZFS working because of kernel module issues on DietPi, OpenMediaVault, and now Armbian.

All the affected people in the referenced issue are using USB hubs. I never use USB hubs in between host and disk and just get the usual xhci error once I connect a SuperSpeed disk to Rock64 and besides that everything is fine. If I would want to connect two fast disks to an SBC I choose an appropriate SBC or maybe would test such a JMS561 thing (but in my personal opinion USB attached storage is a bit too unreliable so I try to avoid it where possible)

The script is here: https://github.com/ayufan-rock64/linux-build/blob/0-6-stable/package/root/usr/local/sbin/enable_dtoverlay

rock64 rk3328 orange pi one Can the rock64 rk3328 run several programs simultaneously? Browse internet with little latency? When I tested orange pi one youtube would stutter. Thank you.

web-server for what? For 100ds of users simultaneously or just some dash-board stuff for monitoring your IoT stuff? In case the first, I've no idea.. in case the second, well my IoT stuff with web-frontend runs on el cheapo OPi Zeros (with Arm A7 and 512mb ram which is mostly not half used). GbE is something you don't get with the RPi 3+... you get a bizarre mixture between GbE and fast Ethernet which seems to make more problems that it solves. Fresh and maintained with support is somehow... Well define support, some people need more some need less. If you think the RPi3 b+ is sufficient from 'horse power' I would go for the Rock64 (I don't have one but it's on my list). The support seems to be decent (mainline & bsp), the price is good (25$ for 1GB 35$ for 2GB ram) you get proper powering via barrel plug, you get an eMMC socket for reliable OS storage and in case you need more 'fast storage' USB3 with an attached SSD should perform ok-ish (no 'real SATA' but fast enough for most purposes IMO). And you get 'real GbE' not only 'GbE over USB2 shared with all available USBs'. RK3328 gets a decent mainline support, so chances are hight that those boards are supported for a longer time... For the OS, those 80MB/s don't matter.. It's all about randomIO. I suggest you read through @tkaisers various threads where he explains this in detail. The RPi had/has its use-cases but there aren't many anymore and for web-server like stuff there are IMO better boards in the same price-range. Worth to read: Some of the informations there are outdated, but to gain some background infos it's still worth a look.

The two RK3328 boards I mentioned have both an eMMC slot. Rock64 numbers, Renegade numbers. I think with both boards settings still aren't optimal (so access could be faster) but as you might know the more important number when looking at 'OS performance' is random IO (IOPS) and not sequential transfer speeds (MB/s). So if you choose a great performing A1 rated SD card like a SanDisk Extreme A1 even when the board is bottlenecked by DDR50 mode it will be way faster compared to using an average (AKA crappy) SD card since they all suffer from horribly low random write performance. See here for some details and especially follow the links there. Random IO (write) performance is more important than anything else. Sequential transfer speeds are close to irrelevant.

Combining all of this I would end up buying a RK3328 device like Rock64 or Renegade. No idea why you need fast SD card modes since in combination with a JMS578 USB-to-SATA adapter and a SSD you have pretty fast storage: https://forum.armbian.com/topic/1925-some-storage-benchmarks-on-sbcs/?do=findComment&comment=51350 (even if USB based storage access is a lot faster compared to Allwinner A20 SATA as on Banana Pi). More CPU horsepower and a bit more pricey? RK3399. But if it's only about serving some static or dynamic web pages I would also evaluate whether cheap Allwinner H5 based boards like NanoPi NEO2 or Orange Pi Zero Plus (with massive zram overcommitment) aren't worth a look.

With Rock64 and especially in such a scenario with an external USB hub only by measuring voltages at the drive's side. And please keep in mind what I've written above about USB3 controller limitations with ARM SoCs. I consider USB storage 'unreliable storage' by definition and as soon as an USB hub is in between host and drives as 'utterly unreliable storage'. The only thing I would put in between a Rock64's USB3 port and 2 disks is this JMS561 thing mentioned here: https://forum.openmediavault.org/index.php/Thread/19871-Which-energy-efficient-ARM-platform-to-choose/?postID=169303#post169303 (but exactly that. Hardkernel sells something called 'Cloudshell 2' for their ODROID-XU4 which is also based on JMS561 but their device suffers/sufferend from serious firmware issues)

Why do you think so? Most probably it's just a fake card with Kingston printed on the surface and copied flash metadata from a Toshiba card. Kingston was pretty popular amongst fraudsters some time ago: https://www.bunniestudios.com/blog/?page_id=1022 Also how should such an app help detecting fake flash that simply reads out some (faked) metadata, looks up in a database and then displays $something? Fake cards use faked metadata. It's pointless to trust in this metadata at all (see my above link). My personal take on avoiding faked flash: Only buy A1 rated cards any more (since for the 'SBC use case' buying anything else is just a mistake) Immediately after purchase check them with either F3 or h2testw. This test will not identify modern fakes who do not fake capacity any more but use real capacity but are made out of inferior components compared to genuine cards After flashing an Armbian image with Etcher the first thing to test is 'iozone -e -I -a -s 100M -r 4k -r 16384k -i 0 -i 1 -i 2' Why? Since fake cards suck wrt especially random IO performance. The result of such an iozone test might look like this: root@rock64:~# iozone -e -I -a -s 100M -r 4k -r 16384k -i 0 -i 1 -i 2 Iozone: Performance Test of File I/O Version $Revision: 3.429 $ Compiled for 64 bit mode. Build: linux Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins Al Slater, Scott Rhine, Mike Wisner, Ken Goss Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR, Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner, Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone, Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root, Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer, Vangel Bojaxhi, Ben England, Vikentsi Lapa. Run began: Thu Jul 19 12:36:21 2018 Include fsync in write timing O_DIRECT feature enabled Auto Mode File size set to 102400 kB Record Size 4 kB Record Size 16384 kB Command line used: iozone -e -I -a -s 100M -r 4k -r 16384k -i 0 -i 1 -i 2 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random kB reclen write rewrite read reread read write 102400 4 1272 1303 7799 7865 6380 140 102400 16384 9837 9640 15924 14124 15921 8077 The 4k number for random writes (here 140) must exceed 2000 since A1 specs require at least 500 IOPS with 4k block size, iozone reports KB/s and with 4K that means we need to multiply 500 IOPS with 4K to get at least 2000 KB/s displayed. So if iozone reports anything below 2000 here I immediately ask the seller for return/refund since the card sold is not compliant to A1 performance class. Of course it's important to buy SD cards only from sellers who have a 'no questions asked' return/refund policy.

I do have a setup: 2.5" disks connected to the powered USB 3.0 hub. The power adapter is 10A. If I do start rsync copy from one disk to another after a while I'm getting the error: rsync error: error in file IO (code 11) at receiver.c(393) [receiver=3.1.2] All disks disappired. There is no way to return them back, only reboot helps. In dmesg I could find that device jsut stopped and disappired: [ 2342.927583] usb 5-1.1: USB disconnect, device number 3 [ 2342.931057] usb 4-1: USB disconnect, device number 2 [ 2342.931975] usb 5-1: USB disconnect, device number 2 [ 2345.629932] usb 5-1.3: USB disconnect, device number 4 [ 2345.663838] usb 5-1.4: USB disconnect, device number 5 [ 2342.904003] xhci-hcd xhci-hcd.9.auto: xHCI host not responding to stop endpoint command. [ 2342.904016] xhci-hcd xhci-hcd.9.auto: Assuming host is dying, halting host. [ 2342.927380] xhci-hcd xhci-hcd.9.auto: Host not halted after 16000 microseconds. [ 2342.927400] xhci-hcd xhci-hcd.9.auto: Non-responsive xHCI host is not halting. [ 2342.927416] xhci-hcd xhci-hcd.9.auto: Completing active URBs anyway. [ 2342.927502] xhci-hcd xhci-hcd.9.auto: HC died; cleaning up [ 2342.927543] xhci-hcd xhci-hcd.9.auto: xHCI host not responding to stop endpoint command. [ 2342.927552] xhci-hcd xhci-hcd.9.auto: Assuming host is dying, halting host. [ 2342.930928] xhci-hcd xhci-hcd.9.auto: HC died; cleaning up Any ideas? How to find the reason of this crash?

Actually it's nice. It simply suffers from what almost all other tools trying to display 'CPU utilization' in some way or the other also suffer from: ignoring reality. With cpufreq scaling 'CPU utilization' alone doesn't tell that much any more especially on systems where all this stuff happens very dynamically (e.g. TurboBoost on x86 where CPU cores clock from 1.2 GHz to 2.2 GHz when just one core is busy, but as soon as a second core processes stuff immediately downclock to 1.8 GHz and stuff like that. Same situation with ARM especially with big.LITTLE and/or on boards where a cheating firmware controls what's happening and the kernel not even has any clue at which clockspeeds the CPU cores are running --> fortunately only applies to Raspberry Pi and Amlogic SBC) I thought several times about an utility both being correct and providing nice looking output. But apart from enhancing RPi-Monitor with templates for some ARM SoC families our armbianmonitor approach is all we came up with. Ugly but at least providing real information and not illusions: root@rock64:~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 10:25:43: 1392MHz 0.39 9% 2% 3% 0% 2% 0% 41.4°C 0/6 10:25:49: 600MHz 0.36 0% 0% 0% 0% 0% 0% 40.9°C 0/6 10:25:54: 1392MHz 0.41 2% 0% 1% 0% 0% 0% 45.5°C 0/6 10:25:59: 1392MHz 0.46 37% 9% 16% 0% 10% 0% 48.2°C 0/6 10:26:04: 1392MHz 0.50 29% 8% 10% 0% 11% 0% 48.2°C 0/6 10:26:09: 1392MHz 0.70 36% 8% 18% 0% 9% 0% 45.0°C 0/6 10:26:14: 1392MHz 1.37 40% 1% 0% 0% 38% 0% 44.1°C 0/6 10:26:19: 1392MHz 1.34 27% 3% 17% 0% 6% 0% 50.0°C 0/6 10:26:24: 1392MHz 1.31 25% 0% 24% 0% 0% 0% 51.7°C 0/6 10:26:29: 1392MHz 1.28 25% 0% 25% 0% 0% 0% 51.7°C 0/6 10:26:34: 1392MHz 1.26 26% 3% 22% 0% 0% 0% 51.2°C 0/6 10:26:39: 1392MHz 1.64 25% 6% 19% 0% 0% 0% 49.5°C 0/6 10:26:44: 600MHz 2.07 2% 2% 0% 0% 0% 0% 42.7°C 0/6 10:26:49: 1392MHz 1.98 24% 0% 0% 0% 22% 0% 47.7°C 0/6 Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 10:26:55: 1392MHz 1.91 24% 0% 0% 0% 24% 0% 46.4°C 0/6 10:27:00: 1392MHz 1.83 22% 1% 10% 0% 10% 0% 46.4°C 0/6 10:27:05: 600MHz 1.69 0% 0% 0% 0% 0% 0% 44.1°C 0/6 10:27:10: 600MHz 1.55 2% 0% 1% 0% 0% 0% 44.1°C 0/6^C This is a Rock64 running off a really crappy 4GB SD card (I got a bunch of them recently when replacing them with SanDisk Ultra A1 at a customer) doing an 'apt update'. We see cpufreq increasing, average load increasing and even overall %cpu utilization increasing. But by looking at %io we see that the whole system is often stuck in IO simply because the SD card performs horribly low when it's about random IO. See the '10:26:14' entry: 40% CPU that are in reality only waiting for the crappy SD card finishing its work. That's the problem with 'CPU monitoring' on Linux in general and especially on SBC where 'crappy storage' is more rule than exception. When looking at load or CPU utilization it's all the time misleading as soon as slow performing storage is involved. Since 'Linux waiting for IO' counts as 'CPU busy / increased load'. That's why I unfortunately can only recommend our ugly armbianmonitor to really get a clue what's going on...

I actively rebase my kernel on top of rockchip-linux to keep a list of patches somehow compact. My current workflow is not very good for community contribution, still: this is rebase of commit history, but I'm happy to change that. One thing that is probably unique about my kernel that I release a new kernel version after every: https://gitlab.com/ayufan-repos/rock64/linux-kernel/ and https://github.com/ayufan-rock64/linux-kernel and this is released as debian packages that you can put on any distro and apt-get install: http://deb.ayufan.eu/ayufan-rock64/linux-kernel. In my latest builds, I effectively moved from building kernel each time to installing kernel/u-boot package for simplicity and split of responsibility (single resp repository). Anyway. I don't want to be a bottleneck, so I would say that the best would be to start a new common repo branch and rebase all our work on this branch, give a few people review/merging capabilities and based the work on the good will of people. I know that being alone and reviewing/accepting is a job that can get boring, as you also need to ensure the quality, splitting the responsibility here is desirable. Now, I do all the stuff there myself, but also I only have to check rock64/rockpro64 which is to be fair not a lot of hurdle for me, but with more dependence on this work we simply need more people. I somehow like the rebase workflow that we always keep a small number of patches, but I'm fine with merge workflow too

Hi guys, I was wondering whether the image for, e.g., the Rock64 can be expected to work also on a TV-Box with RK3328 chipset, for example this one? Cheers, chessplayer

If the board is not broken ... one possible explanation is that filesystem gets corrupted due to not perfect SD card/driver combo. But even this is a very long shot. There has been a lot of upstream kernel changes so it is hard to be sure where is the source of your problem. Rock64 is nice, powerful but also a complex board. Software support is not on the same level as simple (and stupid) hardware design from 2009 (Videocore + ARM core(s), single USB2 line: RPi 1,2,3). Despite this, Rock64 works pretty well and I never experienced problems you have.

New user of a Rock64 board, I've tinkered with a RaspberryPi and BeagleBone before but wanted something to set up as a home media server. I flashed the SD card with an "Armbian_5.42_Rock64_Ubuntu_xenial_default_4.4.124" image and it worked perfectly fine at home, connecting to my network, etc. However, I took it to a new location and it straight up refuses to boot. I've tried it on several displays and with several HDMI cables. It hangs for a solid 30-45 seconds after initiating boot with a black HDMI screen, and then turns off and back on dumping a log citing either spinup shutdown errors or a temperature shutdown on Core 0. I've flashed a separate SD card with the same image as well as the stretch image off the main Armbian page and both of them work for a short while but then proceed to crash seemingly without change ~24 hours later. Is there a large chance my board is simply intermittently dead or is the Rock64 known for being extremely picky with HDMI cables/monitors at boot? Edit: Got it home to my original setup and I have no dice there. I'm at a loss - everything seems to work perfectly with the board after flashing but only for a day or so, then it gets stuck on boot. At this point I'm keen to put it down as a defective board, I'm not sure what else it would be after trying different images, SD cards, HDMI cables, and monitors.

From the schematics, it looks like 1.3V will be default. Well, we will see... That the board might not be that interesting.. normal for H3 boards. According to dl page, there are still some downloads. At least what I appreciate, they inform proactive that they changed something, and also what they changed. The OPi Zero raised 8.49$ for the 256mb and 10.49$ versions (+ shipping 5.50$ here in switzerland). Depending on your needs, those boards are still good. For most of my needs the OPi PC+ is sufficient (29$ including shipping) the BPi M2+ is around 40$ with shipping, but it has GbE. So it's up to the user to decide what's more important. For this price a rock64 gets more and more interesting. Powerful and cheap.

Guess which is the only Allwinner A64 board around where engineers 'forgot' to include charging capabilities? The one that is on sale of course All 64-bit SoCs that support ARMv8 Crypto Extensions (this is something different than SoC vendor proprietary 'crypto engines'). So every Cortex-A53 or A72 (except Raspberry Pi, ODROID-C2 and NanoPi K2): https://forum.armbian.com/topic/4583-rock64/?do=findComment&comment=37829

I have several rock64, rpi, and opi boards but only one ftdi232 serial adapter. Since not each board has hdmi output or in some cases it is buggy a serial connection is the only way for me to see what's going on. If I remove the adapter from a running board and plug it in immediately again I still get serial output, however, if I plug it in after a while I don't get any output. Any ideas what could be the reason and how to fix this?