Search the Community

pine64 products have sloppy DC connectors. This connector simply detaches from the motherboard. I use in production pine64 pine64-lts pineH64 and rock64. As a result of switching on and off the dc connector, in each case it has peeled off and does not hold power. I've attached the DC connector with glue but that's not what the factory mount. The low price now goes sideways. workmanship worse than nonopi.

I tried compiling Debian 9 Full OS Image with Desktop using BRANCH=next and default kernel configs for * NanoPi K1 * Rock64 * OrangePi Plus 2E And all failed at the end: Errors were encountered while processing /tmp/apt-dpkg-install-LTKPXl/621-numix-icon-theme_0.3+922~201711061547~ubuntu16.04.1_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) [ error ] ERROR in function create_rootfs_cache [ debootstrap-ng.sh:213 ] [ error ] Installation of Armbian packages failed [ o.k. ] Process terminated [ error ] ERROR in function unmount_on_exit [ image-helpers.sh:59 ] [ error ] debootstrap-ng was interrupted I am using the 18.04 minimal image in a virtual box. It worked a month ago. It works today for Ubuntu Full OS image with Desktop and BRANCH=next. Thanks.

Good evening, I have a Rock64/4G board and just downloaded and installed the Armbian_5.42_Rock64_Debian_stretch_default_4.4.124_desktop.7z to the SD card. After the reboot I saw X11 login interface and everything was great. After that I installed the latest packages with an apt update and then apt upgrade and restarted. Now I only see "rock64 login:" on the screen. The Xorg.0.log I have attached looks actually quite good. Xorg.0.log

I am a beginner so be carefull to my opinion I see Scishion V88 Piano and V88 Mini III TV boxes work on Kernel 4.4.132 Ubuntu 18.04.1 LTS with https://github.com/ayufan-rock64 ( we boot on sd and after we delete partion 6 and 7 boot on usb stick , because since version 0.5.15-136 it use SPL/TPL instead of Rockchip's loader, big thank's to segv ) This is RK3328 is low price ( begin at 35$ ) and looks like S905 ( same MALI-450MP2 and 4 Cortex-A53) BUT rockchip make mpp dev ... For other the RK3229 ( very low cost begin at 25 $ ) i don't see any linux booting well, does not support 10-bit HEVC, Mali-400 MP2 and 4 ARM Cortex-A7 ) The rk3399 the cost is more tahn 100$ and we have 6 core : 2 Cortex-A72 4 Cortex-A53 and Mali-T860 MP4. Better than the S912 but the cost is important. and the old RK3368, 8 cœurs ARM Cortex-A53 64 Bits, PowerVR SGX6110 but i don't see linux drivers on linux ... So my choice is for all RK3328 for start ... And if you want i can send you one.

so test : Software transcoding /home/rock64/bin/ffmpeg -vcodec h264 -i http://192.168.1.50:8001/+1:0:19:401:4:20FA:EEEE0000:0:0:0 -s 320x240 /tmp/test.avi resut = frame= 507 fps= 16 q=8.6 Lsize= 1058kB time=00:00:22.40 bitrate= 386.8kbits/s dup=0 drop=6 speed=0.703x Hardware Transcoding (only decode ) /home/rock64/bin/ffmpeg -vcodec h264_rkmpp -i http://192.168.1.50:8001/+1:0:19:401:4:20FA:EEEE0000:0:0:0 -s 320x240 /tmp/test.avi error = 0 Impossible to convert between the formats supported by the filter 'Parsed_null_0' and the filter 'auto_scaler_0' Error reinitializing filters! Failed to inject frame into filter network: Function not implemented tested with some otehr file with ame result OK, i must find ...

For install with etcher write sd card with xenial-minimal-rock64-0.5.15-136-arm64.img.xz (not other ) with etcher write usb stick bionic-minimal-rock64-0.7.9-1067-arm64.img.xz (or better ) boot on sd witout usb stick delete partition 6 and 7 , reboot with usb stick, activate eth1 ( all explain in the post off segv ) i continue ...

Find solution : write in usb stick: bionic-minimal-rock64-0.7.9-1067-arm64.img.xz boot on sd with partion 6 and 7 deleted And ... Boot ok in 18.04.1 LTS

i make the list boot sd ok : xenial-minimal-rock64-0.5.7-101-arm64.img.xz xenial-minimal-rock64-0.5.15-136-arm64.img.xz and after it's stop, so i understand it's : 0.6.0: Use SPL/TPL instead of Rockchip's loaders (supports flashing and booting from SPI), Ok , so i try to find if i cand write it with a spi device

Escuse me (i have V88 mini 3 , 2G ram 8 emc ) , i don't want to use usb stick , only sd. i try Download xenial-minimal-rock64-0.5.15-136-arm64.img.xz and it's booting well on sd. I try lot of other img without sucess We need absolutly an usb stick for newer img ?

Hi, Just wanted to chime in here as I had a similar issue with a wifi adapter bought from Pine64. My issue began with the fact that the aforementioned adapter would just randomly lose connection to my wifi router and at that point I could not even see the device in the USB tree using the 'lsusb -t' command. In my case, I believe there was a hardware issue with the adapter I received so I decided on buying a new one, which used the same Realtek RTL8188EU chipset, namely a COMFAST CF-WU810N which works out of the box with the Rock64 in case anyone needs a compatible wifi adapter not sold by Pine64. More to the point of this thread, the configuration of the wireless interface on Armbian Xenial can also be done without the use of the "NetworkManager" service. Optional Step: I did not want to keep the horrid predictable/unique wireless interface name generated based on the device's MAC address so I added the below line in this file to assign it the name "wlan0". * Please note, you need to change the 'ATTR(address)' field with your device's MAC address and REBOOT your machine so the kernel assigns the new interface name. This change is reboot persistent and may be taken out by removing the "70-persistent-net.rules" file. $ cat /etc/udev/rules.d/70-persistent-net.rules SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="40:a4:3f:98:a1:xt", ATTR{dev_id}=="0x0", ATTR{type}=="1", NAME="wlan0" $ Mandatory Steps: Configure the wireless interface with a static IP address as below: $ cat /etc/network/interfaces.d/wlan0 auto wlan0 allow-hotplug wlan0 iface wlan0 inet static address 192.168.1.10 netmask 255.255.255.0 #gateway 192.168.1.1 dns-nameservers 192.168.1.1 wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf $ Next, you need to create the "wpa_supplicant.conf" file, where the details of your SSID (wIreless network name) are stored like below. * Please note, you must change the 2 letter "country" code to your specific country, and the "ssid" & "psk" parameters to your network's name and password. $ sudo cat /etc/wpa_supplicant/wpa_supplicant.conf ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev update_config=1 country=<YourCountryCode> network={ ssid="YourWirelessNetworkName" key_mgmt=WPA-PSK psk="YourSecretPassword" } $ The last step implies performing a link down/up of the interface. ip link set interface_name down && ip link set interface_name up

Thanks @tkaiser. You're right, the use would be the same (gitlab-runner), except that it would build 64bits binaries. I also thought of using a S912 based TV Box, but I know nothing about its eMMC performances and it looks like it's a pain to install Armbian on these boxes. I will have a closer look to Rock64, thanks ($35.44 is a nice price tag to start). I will try to find a 2.5' SDD.

Rock64 (but their eMMC is neither super fast nor would I trust too much into it). Based on your other post the obvious choice is still Rock64 + their SATA cable + a great SSD.

I just checked also against RK3399 with A72 cores killed. Below 7-zip MIPS and cpuminer kH/s (all binaries built with GCC 6.3): RK3328: Renegade @ 1380 MHz: 3710, 3.92 kH/s (faster memory than Rock64) Rock64 @ 1380 MHz: 3610, 3.85 kH/s RK3399 (with A72 cores killed): NanoPC T4 @ 1415 MHz: 3920, 4.54 kH/s (way faster memory than the other boards) S905: NanoPi K2 @ 1480 MHz: 3850, 4.61 kH/s (slightly higher cpufreq) ODROID-C2 @ 1530 MHz: 3870, 4.63 kH/s (slightly higher cpufreq) S905X: Le Potato @ 1410 MHz: 3780, 3.92 kH/s (faster memory than Rock64) Unfortunately testing on NanoPi Fire3 with just 4 CPU cores is not possible since when trying to kill CPU cores the system deadlocks. Might need changed kernel config? root@nanopifire3:~# zgrep -i hotplug /proc/config.gz CONFIG_HOTPLUG_CPU=y # CONFIG_ARM_DYNAMIC_CLUSTER_HOTPLUG is not set # CONFIG_CPU_HOTPLUG_STATE_CONTROL is not set cpuminer allows to set CPU affinity but this doesn't work since still firing up 8 threads and then results are lower as expected (3.24kH/s): taskset -c 0-3 ./cpuminer --benchmark --cpu-priority=2 --cpu-affinity=0x15

Someone mentioned that the label "media" in the download image[link] is new. Is this script still required for GPU support? What is the equivalent of lspci for these things [arm sbcs - specifically rock64]. Is there anything like, in pi3, you can adjust the memory dedicated to gpu?

On https://www.aliexpress.com/store/product/Free-shipping-7-Inch-Android-4-4-Fashion-notebook-HDMI-Laptop-inch-Dual-Core-VIA-HDMI/4362013_32893471150.html you can buy a 7 inch display notebook. There is also a 10 inch display version. I am trying to determine which mainboard I would have the notebook to have. If main priorities are free software cf free software foundation's requirements and performance adequate for common debian utilization. To me it is at the same time having a running browser. 5 open tabs. One showing a youtube video. File manager running. Email client running. Running libre office or a media player or photo editor. It seems rk cpus are the ones to select among. If choosing between the rk3288 and rk3328 the rk3328 is the better choice? Can you answer if the free vpu software will work on the rock64 rk3328? the best choice for a notebook?

Just seen that your Rock64 results are with a 2GB. I'll do the same with my 4GB. Just interested if there's a difference with 7zip multicore. It's only 4-cores tho. Now doing Blender bench between Xenial default and nightly. Again just out of curiosity. I red it's now clocked to 1.39Ghz. I'll give you the sbc-bench results later if they're interesting. I don't think they will be. It's already 100%... Eidit : Blender just crashed on 1.39Ghz after 30minutes. At 1.3Ghz no problem : 1h17m55s I'll try again. Maybe it's not stable enough. 2nd try did it. So could be a fluke the crash. Xenial Rock64 4GB results : http://ix.io/1j7d Again very different than other distro's. I'm also wondering if zram would make a big difference with the 8-core 2gb devices? Cheers

Has the rk3328 and rock64 got free vpu software now cf tkaiser's link? What about the rk3399 and rk3288?

Yep, my code gets confused by those overclock OPPs but the detailed results show clearly that execution happened all the time at the '1800 MHz' OPP that is 1730 MHz in reality (how I love all this firmware cheating ) Wrt NanoPi K2 vs. Le Potato: It's S905 (no ARMv8 Crypto Extensions) vs. S905X (there Amlogic licensed the stuff). So numbers as expected, simply compare with ODROID-C2. But it's obvious that only Hardkernel got a BS free BLOB from Amlogic whereas FriendlyELEC has to use the cheating BLOB faking cpufreqs above 1480) The cpuminer numbers for Le Potato are in sync with another A53 running at 1400 MHz (see Rock64 and Renegade based on RK3328 -- we can only compare numbers that were generated with exactly identical GCC/distro version: Stretch arm64). What's surprising is that S905 outperforms S905X and RK3328 here (maybe related to L1/L2 cache sizes or something like this) I added the new numbers to https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md -- thank you!

Suptronics/Geekworm sells RPi add-ons for a long time. They started with an add-on using the crappy/slow GL830 USB-to-SATA bridge but switched to a good JMS578 after some public complaints (see there also for the issues with GL830) Now they offer a metal box with fan kit and for their X830 USB-to-SATA board for less than 30 bucks. Power input: 14 to 40V DC via 5.5/2.5mm power barrel jack, the SBC can then be powered through GPIO header pins. Boards that should fit inside the enclosure: Any RPi Libre Computer Tritium H2+/H3/H5 Libre Computer Le Potato MiQi NanoPi K1 Plus NanoPi K2 ODROID C1/C1+ ODROID C2 Tinkerboard Rock64 Libre Computer Renegade PineH64 B NanoPi M4 (sufficient cooling will require mounting the fan not on top but next to the board) Caveats: With the 4 last boards you can either limit connection between board and the SATA-bridge to USB2 (the small adapter only transports the Hi-Speed data lines) or you need a standards violating USB3-A to USB3-A cable (which is said to be included with X830 -- no idea if it's also part of the kit). I'm not sure how a 3.5" HDD is mounted inside the enclosure and expressed my concerns about this and potential firmware issues (as well as how to solve them) with the X830 only here: https://www.cnx-software.com/2018/06/12/add-a-3-5-hard-drive-raspberry-pi-suptronics-x830-add-on-board/#comment-554303 (there you also find some more information and link to a wiki). Disclaimer: never used any of their products and not able to 'review' anything. I just thought this would be a nice combination if a 3.5" HDD should be used together with one of the supported SBC since usually 3.5" HDDs needing 5V and 12V at the same time is somewhat challenging. Edit: Just realized that it's only the enclosure + fan and you need to buy the X830 board separately. Then we're talking about a pretty expensive gadget which will be kinda ugly too with USB3 equipped boards since it needs an 80cm USB cable to externally connect SBC and disk inside the enclosure. Too bad.

I believe it's the latter. And if I would fire up 2 iperf3 tasks at the same time most probably I would use 'taskset -c 4 ' and 'taskset -c 5 ' to pin them to different big cores. Since I don't believe little cores are fast enough IRQ colissions can ruin benchmark numbers (and real world performance too) iperf3 unlike iperf also shows dropped packages every 2 seconds -- you get a bit faster the idea that something's wrong IRQ affinitiy with such fast cards might be a big issue. Ayufan chose to use these settings for both Rock64 and RockPro64: https://github.com/ayufan-rock64/linux-package/blob/d31494d0b9afafa5a98ef0f4d94dcdad611d45e3/root/usr/local/sbin/rock64_fix_performance.sh#L30-L35 (PCIe ends up on a little core while onboard Ethernet and USB3 lands on a big core). With Armbian we're not entirely sure how to deal with IRQ affinity on RK3399 since user configurations differ. Quoting myself: 'most probably the best idea is to switch from static IRQ affinity set at boot by armbian-hardware-optimization to a daemon that analyzes IRQ situation every minute and adopts then dynamically the best strategy'. Anyway: playing with these fast cards is an interesting example for an Active Benchmarking attempt needed

Latest commit added @wtarreau's great mhz tool to the reports to spot strange things happening (especially on Raspberry Pi and with Amlogic SoCs): Example output from a Rock64: Checking cpufreq OPP: Cpufreq OPP: 408 Measured: 400.981/400.762/400.857 Cpufreq OPP: 600 Measured: 592.858/592.944/592.672 Cpufreq OPP: 816 Measured: 808.872/808.932/809.031 Cpufreq OPP: 1008 Measured: 1000.598/1000.816/1000.416 Cpufreq OPP: 1200 Measured: 1193.027/1192.765/1193.027 Cpufreq OPP: 1296 Measured: 1288.983/1285.487/1288.694 Cpufreq OPP: 1392 Measured: 1385.218/1384.623/1384.995 And from a RockPro64: Checking cpufreq OPP for cpu0-cpu3: Cpufreq OPP: 408 Measured: 406.192/406.314/406.319 Cpufreq OPP: 600 Measured: 598.053/598.195/598.344 Cpufreq OPP: 816 Measured: 814.302/814.292/814.001 Cpufreq OPP: 1008 Measured: 1006.214/1006.239/1006.214 Cpufreq OPP: 1200 Measured: 1197.827/1198.355/1198.369 Cpufreq OPP: 1416 Measured: 1414.209/1414.286/1414.023 Checking cpufreq OPP for cpu4-cpu5: Cpufreq OPP: 408 Measured: 406.563/406.592/406.636 Cpufreq OPP: 600 Measured: 598.649/598.310/598.581 Cpufreq OPP: 816 Measured: 814.583/815.065/814.663 Cpufreq OPP: 1008 Measured: 1006.509/1006.558/1006.570 Cpufreq OPP: 1200 Measured: 1198.494/1198.564/1198.591 Cpufreq OPP: 1416 Measured: 1414.612/1414.596/1414.534 Cpufreq OPP: 1608 Measured: 1606.477/1606.577/1606.677 Cpufreq OPP: 1800 Measured: 1798.487/1798.587/1798.627 These checks are done twice: At the start of the benchmark when the system is idle and again directly after the most demanding test has finished and the CPUs are heated up to the max (7-zip or cpuminer based on 'sbc-bench' vs. 'sbc-bench neon'). Results made with RPi 3, 3+ and Vim2 might look really funny then

In the meantime I improved the script in some areas (especially throttling/undervoltage warnings). To get rid of CRLF it's as easy as wget -O - https://pastebin.com/raw/CXtt28y1 | tr -d "\015" >/usr/local/bin/sbc-bench.sh chmod 755 /usr/local/bin/sbc-bench.sh sudo /usr/local/bin/sbc-bench.sh Tested already with a bunch of boards (all the time in situations with active cooling to test for stuff like kernel differences or architecture): Raspberry Pi 2, kernel 4.14, default RPi settings, not throttled: http://ix.io/1ivw NanoPC T4, kernel 4.17, preliminary settings, not throttled: http://ix.io/1ivB RockPro64, kernel 4.18, ayufan/arm64 settings, not throttled: http://ix.io/1iw5 RockPro64, kernel 4.4, ayufan/arm64 settings, not throttled: http://ix.io/1ivR NanoPi Fire3, kernel 4.14, Armbian settings, not throttled, zram swapping: http://ix.io/1ivC Clearfog Pro, kernel 4.14, Armbian settings, not throttled: http://ix.io/1ivE Rock64, kernel 4.4, Armbian settings, not throttled: http://ix.io/1ivG Rock64, kernel 4.4, ayufan/armhf settings, also 1392 MHz, not throttled: http://ix.io/1iwz The interesting stuff as follows: When comparing the RK3399 boards (NanoPC T4 and RockPro) kernel version makes a huge difference wrt memory bandwidth/latency which also results in different 7-zip scores arm64 vs. armhf (Rock64) is not that much of an issue. The armhf binary is slightly slower but on the other hand an armhf userland can cope with less available physical memory NanoPi Fire has 8 CPU cores but just 1 GB DRAM which results in a big problem with almost all workloads that would benefit from 'as much CPU cores as possible'. As a result swapping happens. With recent Armbian not that much of a problem since we switched from SD card based emergency swap to zram which works pretty well. But when running sbc-bench with a different distro relying on swap numbers might be much lower since storage becomes the bottleneck (TBC). I'll push the script plus explanations on Github over the weekend and create an own thread for the tool.

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&amp;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.