Search the Community

Let me test this later with the 16GB eMMC on my Pinebook -- if it's sufficient we might provide a small u-boot package to fix this. Related: the 'performance' numbers you provided for your 64 GB eMMC are better at small block sizes than the 16 GB eMMC I tested but seem to be limited to the 'usual' 23 MB/s sequential barrier we see with SD cards on Pinebook and other Allwinner devices (due to using the slowest SDIO mode there). Can you please provide output from 'armbianmonitor -u' now and also re-test the 64 GB module after switching to performance cpufreq governor ('cpufreq-set -g performance' )?

It should work unless broken. I am running my Pinebook from eMMC and install went smoothly.

I must admit that I didn't tried it on Pinebook, since I'm still running ayufan image ont it. But nand-sata-install should work the same way as for other boards ... Do you have an USB-TTL to Audio Jack to figure out where it is choking ?

The u-boot is taken from this similar path : /usr/lib/linux-u-boot-dev-pinebook-a64_5.xx_arm64/u-boot-sunxi-with-spl.bin

Small steps - with Zador's help I got the armbian build system working with Docker and managed to force in my changes. The new kernel now runs better than my previous attempt which couldn't load any modules for some reason, which prevented wifi from working amongst other things. I also found that the uboot version of mmc.c has the same test for csd.rev which seems like a reasonable explanation for the boot failure from eMMC, so I've removed the test and rebuilt uboot. I installed the resulting .deb onto the armbian running from sd card, rebooted and have now started a fresh run of nand-sata-install. The only problem is that I have no idea where nand-sata-install gets the copy of uboot to write to the eMMC, so I hope it picks up my modified version and not a copy of the original from somwhere! Ah, looks like the installer gets uboot from /usr/lib/linux-u-boot-pinebook-a64_5.32_arm64/ and that's been updated today, so presumably contains my new build: /usr/lib/linux-u-boot-pinebook-a64_5.32_arm64$ ls -l total 960 -rw-rw-r-- 1 root root 983040 Sep 4 11:46 u-boot-with-dtb.bin Fingers crossed!

Hmm, the install to eMMC seemed to work ok in that if I boot from SD I can mount the eMMC and see the files, but it won't boot from the eMMC. Unfortunately I don't have a serial line hooked up to the pinebook so I can't see what's going on. Visually, the backlight of the screen turns on, but nothing appears on the display. The LED for caps lock is not responsive. When I mount the filesystem on the eMMC it is reported as 62G, so I assume that resizefs must have been run. /boot/Image on the eMMC is sym-linked to my kernel with the modified mmc driver, so that seems good. I compiled the kernel by cloning longsleep's linux-pine64 kernel directly (I've been having problems building armbian), so maybe I'm missing some patches? It feels like it must be close to working, I'll see if I can dig into it some more.

oh, there's an armbian image for the pinebook! i installed it last night and i'm delighted to see that a recent version of mpv is the default media player!!! Unfortunately it sometimes crashes (*), leaving me with the last image plastered all over the screen (all screens, even when i switch to another vt) - forcing me to reboot, or is there a way to tell the framebuffer (i suppose) to drop that? (*) it seems to crash with larger resolutions/throughput. Tested with a x264 encoded 1920x800@3000kb/s movie, the issue is reproducible. HEVC otoh works beautifully now, yay!

My pinebook just arrived. I have to say it's excellent value, with both the keyboard and screen being very usable. I'm sure I'll run into a few problems soon enough, but so far I'm very pleased! Update: First major problem isn't with the laptop itself, but the 64G eMMC that I ordered to go with it. Sadly it's dead-on-arrival. I've emailed them to let them know, so now I'll get to see what their customer support is like! More minor issues, there is some instability with the trackpad that sometimes jumps the cursor to the bottom left corner. Overall, still very impressed Update Aug 28th: the flashing of the screen backlight at low brightness has gone away. I'm not sure why, but it's working just fine now. I had a prompt reply to my email about the 64G eMMC saying they would forward the message to support, but haven't heard anything since. But it's been the weekend so that's not unreasonable. I opened a support ticket today in case the original email didn't make it to the right place, so we'll see how that turns out. Sep 2: It looks like the problem with the 64G eMMC is that it is reporting an EXT_CSD revision of 8, and the mmc driver checks for a max value of 7. I'm hoping I can patch the kernel to accept 8 and get things going, but I'm wondering if uboot will need to be updated as well.

Ummm?... because Q4OS only supports Pinebook, Pine64 and Raspberry Pi as per their downloads page. Unless I'm missing something. Even if I am, that would mean their "ARM port" download is trying to do something similar to Armbian by being compatible with multiple devices. Aside from chromebooks, tablets, etc... I think you'd be hard pressed to find an argument for using Q4OS over Armbian especially for OPiZero. Maybe that's just me though. https://q4os.org/downloads1.html So what's your reasoning as to why you opt for Q4OS over Armbian?

Yes. Mali is a memory-to-memory 3D rendering engine that provides OpenGL ES acceleration, and Mali400 is a rather old and relatively slow core anyway, so it is useful mostly in Android on with applications that can utilize OpenGL ES 2.0, assuming there are properly configured kernel and userspace drivers. It depends on how do you define "video" and "playback". There is limited hardware video decoding support. On Linux images it is provided via a VDPAU backend and you can check the "libvdpau-sunxi" column in the status matrix for the currently supported formats and A64 column to note that H265 10bit video is not supported by hardware. Unsing the VDPAU backend means that it easily integrates with video players like mpv, mplayer2 and VLC but you can forget about video in web browsers. Because mainline is a Work-In-Progress, especially for the Pinebook, and Allwinner (A64 SoC vendor) currently provides kernel 3.10 for 64-bit SoCs. And even with experimental video output support on the mainline kernel you can forget about hardware video decoding. Everything depends on the kernel (well, and hardware capabilities and limitations). You will need to replace at least u-boot and Device Tree (if it is loaded separately) for the Pinebook, but "any Pine64 OS" most likely won't give you any improvements over releases optimized for the Pinebook. Xenial is an LTS release, so it will be supported by Ubuntu for a longer period of time. Usually we provide both Debian and Ubuntu based server images but only Ubuntu based desktop images. To summarize - currently most of the ARM based devices will be far from perfect for multimedia use cases on Linux, best case scenario - you'll need custom patched FFmpeg/gstreamer that hopefully could be integrated into a selected OS release without breaking anything. And the Pinebook for its price is a very good lightweight desktop replacement, but don't expect it to be capable in all multimedia tasks that can be done on an x86/x64 desktop.

That was just doing the math given that I knew A64 was clocked with 1152 MHz and then calculating clockspeed based on values for Pinebook and OPi PC 2 --> 815. So I assumed PC2 is running with 816 MHz. In the meantime I tested with my only H5 board (OPi Zero Plus 2 H5): openssl speed -elapsed -evp aes-256-cbc --> 26782.38k (Huh? What's going on here? Debug output). I again did some math (running sysbench on OPi PC2 and ROCK64, took both execution times, naively assuming PC2 running at 816 MHz again and then 'echo '11.2318 / 7.1657 * 816' | bc -l' --> 1279.03049248503286489152 (1296 MHz ROCK64 was running at). Why are my AES scores that low? Edit: Found a bug in armhwinfo. New armbianmonitor -u output here: http://sprunge.us/MdKL Since I found a spare SD card I couldn't resist to test with ROCK64 again (my first board with 2GB and an el cheapo heatsink applied). Debian Stretch, 'OpenSSL 1.1.0f 25 May 2017', same numbers as with Jessie when running single threaded. When testing AES256 with 4 threads it starts at almost 2,400,000k and after some time throttles down to 2,100,000k (it was even even below 2,050,000 but that was due to 'rock64_health.sh -w' running in parallel which is way too resource hungry in this mode updating every 0.5s): https://pastebin.com/Ck15UQv4

It is indeed. So to get a more realistic idea about the AES encryption potential when more than one CPU core is involved I would suggest running: tk@pinebook:~$ cat check-ssl-speed.sh #!/bin/bash while true; do for i in 0 1 2 3 ; do openssl speed -elapsed -evp aes-256-cbc 2>/dev/null & done wait done tk@pinebook:~$ ./check-ssl-speed.sh | grep "^aes-256-cbc" With Pinebook I'm throttled 'down' to 1056 MHz after a few minutes and the total AES-256 score remains below 2,000,000k: https://pastebin.com/hYDvaRdH On ODROID-HC1 I prefixed with 'taskset -c 4-7' to let the stuff run on the big cores only. They throttled down to 1.5 GHz after some times and overall performance is slightly above 220,000k: https://pastebin.com/HbZVnp87 Now back on-topic (ROCK64, RK3328, 28nm vs. 40nm with H5/A64): I would believe ROCK64 when making use of the ARM crypto extensions can remain on 1.3GHz all the time while calculating the stuff with 4 threads in parallel. @zador.blood.stained will you give it a try?

I added them above already (for HC1 which shows better heat dissipation than XU4 but that doesn't matter since 'while true ; do openssl speed -elapsed -evp aes-256-cbc 2>&1 | grep "^aes-256-cbc" ; done' doesn't exceed 70"C reported SoC temperature after 15 minutes). The summary above might not be 'benchmarking gone wrong' any more but still 'numbers without meaning' Since without reported cpufreq the numbers don't tell much (assuming all the A53 perform identical at the same clockspeed I calculated based on Pinebook cpufreq the one for ROCK64: 605 / 537 *1152 --> 1297 and the one for OPi PC 2: 380 / 537 *1152 --> 815). In other words: with an Armbian image on PC2 that currently does not implement cpufreq scaling we're running the benchmark here with just 816 MHz (set by u-boot) so once cpufreq scaling is working numbers of RK3328, H5 and A64 devices depend solely on cpufreq) Now the important question: At which clockspeed did Amlogic's S905 run? And how do numbers look like after we allowed the C2 to try some throttling: timeout 1200 bash -c 'while true ; do openssl speed -elapsed -evp aes-256-cbc 2>&1 | grep "^aes-256-cbc" ; done'

Hmm... to summarize the 'OpenSSL 1.0.2g 1 Mar 2016' results for the 3 boards/SoC tested above with some more numbers added (on all A53 cores with crypto extensions enabled performance is directly proportional to CPU clockspeeds -- nice): ODROID N1 / RK3399 A72 @ 2.0GHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 377879.56k 864100.25k 1267985.24k 1412154.03k 1489756.16k aes-192-cbc 325844.85k 793977.30k 1063641.34k 1242280.28k 1312189.10k aes-256-cbc 270982.47k 721167.51k 992207.02k 1079193.94k 1122691.75k ODROID N1 / RK3399 A53 @ 1.5GHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 103350.94k 326209.49k 683714.13k 979303.08k 1118808.75k aes-192-cbc 98758.18k 291794.65k 565252.01k 759266.99k 843298.13k aes-256-cbc 96390.77k 273654.98k 495746.99k 638750.04k 696857.94k MacchiatoBin / ARMADA 8040 @ 1.3GHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 360791.31k 684250.01k 885927.34k 943325.18k 977362.94k aes-192-cbc 133711.13k 382607.98k 685033.56k 786573.31k 854780.59k aes-256-cbc 314631.74k 553833.58k 683859.97k 719003.99k 738915.67k Orange Pi One Plus / H6 @ 1800 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 226657.97k 606014.83k 1013054.98k 1259576.66k 1355773.27k aes-192-cbc 211655.34k 517779.82k 809443.75k 963041.96k 1019251.37k aes-256-cbc 202708.41k 470698.97k 692581.21k 802039.13k 840761.34k NanoPi Fire3 / Nexell S5P6818 @ 1400 MHz (4.14.40 64-bit kernel): type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 96454.85k 303549.92k 637307.56k 909027.59k 1041484.46k aes-192-cbc 91930.59k 274220.78k 527673.43k 705704.40k 785708.37k aes-256-cbc 89652.23k 254797.65k 460436.75k 594723.84k 648388.61k ROCK64 / Rockchip RK3328 @ 1296 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 163161.40k 436259.80k 729289.90k 906723.33k 975929.34k aes-192-cbc 152362.85k 375675.22k 582690.99k 693259.95k 733563.56k aes-256-cbc 145928.50k 337163.26k 498586.20k 577371.48k 605145.77k PineBook / Allwinner A64 @ 1152 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 144995.37k 387488.51k 648090.20k 805775.36k 867464.53k aes-192-cbc 135053.95k 332235.56k 516605.95k 609853.78k 650671.45k aes-256-cbc 129690.99k 300415.98k 443108.44k 513158.49k 537903.10k Espressobin / Marvell Armada 3720 @ 1000 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 68509.24k 216097.11k 453277.35k 649243.99k 741862.06k aes-192-cbc 65462.17k 194529.30k 375030.70k 503817.22k 559303.34k aes-256-cbc 63905.67k 181436.03k 328664.06k 423431.51k 462012.42k OPi PC2 / Allwinner H5 @ 816 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 102568.41k 274205.76k 458456.23k 569923.58k 613422.42k aes-192-cbc 95781.66k 235775.72k 366295.72k 435745.79k 461294.25k aes-256-cbc 91725.44k 211677.08k 313433.77k 362907.31k 380482.90k Banana Pi R2 / MediaTek MT7623 @ 1040 MHz and MTK Crypto Engine active type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 519.15k 1784.13k 6315.78k 25199.27k 124499.22k aes-192-cbc 512.39k 1794.01k 6375.59k 25382.23k 118693.89k aes-256-cbc 508.30k 1795.05k 6339.93k 25042.60k 112943.10k MiQi / RK3288 @ 2000 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 87295.72k 94739.03k 98363.39k 99325.95k 99562.84k ODROID-HC1 / Samsung Exynos 5244 @ (A15 core @ 2000 MHz): type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 78690.05k 89287.85k 94056.79k 95104.34k 95638.87k aes-192-cbc 69102.10k 77545.47k 81156.61k 81964.71k 82351.45k aes-256-cbc 61715.85k 68172.80k 71120.73k 71710.72k 72040.45k ODROID-C2 / Amlogic S905 @ 1752 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 51748.63k 59348.22k 62051.33k 62763.35k 62963.71k aes-192-cbc 46511.57k 52507.95k 54599.08k 55151.27k 55312.38k aes-256-cbc 42094.22k 46302.95k 47941.46k 48372.74k 48513.02k NanoPi M3 / Nexell S5P6818 @ 1400 MHz (3.4.39 32-bit kernel): type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 44264.22k 54627.49k 58849.88k 59756.35k 60257.62k aes-192-cbc 39559.11k 47999.32k 51095.30k 51736.15k 52158.46k aes-256-cbc 35803.41k 42665.24k 44926.47k 45733.21k 45883.39k Clearfog Pro / Marvell Armada 38x @ 1600 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 47352.87k 54746.43k 57855.57k 58686.12k 58938.71k aes-192-cbc 41516.52k 47126.91k 49317.55k 49932.63k 50151.42k aes-256-cbc 36960.26k 41269.63k 43042.65k 43512.15k 43649.71k Raspberry Pi 3 / BCM2837 @ 1200 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 31186.04k 47189.70k 52744.87k 54331.73k 54799.02k aes-192-cbc 30170.93k 40512.11k 44541.35k 45672.11k 45992.62k aes-256-cbc 27073.50k 35401.37k 38504.70k 39369.39k 39616.51k Banana Pi M3 / Allwinner A83T @ 1800 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 36122.38k 43447.94k 45895.34k 46459.56k 46713.51k aes-192-cbc 32000.05k 37428.74k 39234.30k 39661.91k 39718.95k aes-256-cbc 28803.39k 33167.72k 34550.53k 34877.10k 35042.65k Banana Pi R2 / MediaTek MT7623 @ 1040 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 22082.67k 25522.92k 26626.22k 26912.77k 26995.37k aes-192-cbc 19340.79k 21932.39k 22739.54k 22932.82k 23008.60k aes-256-cbc 17379.62k 19425.11k 20058.03k 20223.66k 20267.01k Edit: Added results for Pinebook and ODROID-HC1 ensuring both were running at max cpufreq Edit 2: Added cpufreq settings for each tested device. Please note throttling dependencies and multi-threaded results below Edit 3: Added Banana Pi M3 single thread performance above. Performance with 8 threads sucks since A83T throttles down to 1.2GHz within 10 minutes and overall AES253 score is below 190000k. Edit 4: Added EspressoBin numbers from here. Another nice example for the efficiency of ARMv8 crypto extensions. Edit 5: Added NanoPi M3 numbers from there. Edit 6: Added Clearfog Pro numbers (Cortex-A9 -- unfortunately OpenSSL currently doesn't make use of CESA crypto engine otherwise numbers would be 3 to 4 times higher) Edit 7: Added Banana Pi R2 numbers from here (Cortex-A7, cpufreq scaling broken since ever so SoC only running with 1040 MHz, numbers might slightly improve once MTK manages to fix cpufreq scaling) Edit 8: Added numbers for ARMADA8040 (A72) from CNX comment thread. Edit 9: Added RK3288 (Cortex A17) numbers from here. Edit 10: Added RPI 3 (BCM2837) numbers. Please be aware that these are not Raspbian numbers but made with 64-bit kernel and Debian arm64 userland. When using Raspbian you get lower numbers! Edit 11: Added Allwinner H6 numers from here. Edit 12: Added RK3399 numbers from here. Edit 13: Added new S5P6818 numbers since now with mainline 64-bit kernel ARMv8 crypto extensions are available

I tested it by myself while making a Rock64 configuration for Armbian. I'm still not sure why cryptsetup shows much higher numbers than openssl (and so I decided to not post them right away without making some real world tests with cryptsetup on a real storage, but even if I had a spare SSD to make a benchmark, I broke the USB3 port while desoldering the protection diodes) Yes, and a relatively fast DRAM. So just by numbers Rock64 (4.4 kernel, performance governor) is more or less twice as fast as the Pinebook (3.10 kernel, performance governor, A64 has AES instructions too) and more or less 4 times as fast as Armada A388 with CESA. AFAIK A53 cores in H5 don't have AES support? Can you post contents of /proc/cpuinfo ?

Thank you for the test. Wrt Ethernet I was thinking about adding the USB Ethernet dongle that came with the Pinebook (RTL8152) since this works out of the box with the network config we use on the OPi Zero image (zero contents and therefore interfaces under NM control). So most probably an own download page pointing to OPi Zero images and mentioning sed -i 's/xradio_wlan\ g_serial\ xradio_wlan/8189es g_serial/' /etc/modules && reboot is enough. Dealing with up to 4 interfaces here (USB Ethernet gadget, Wi-Fi and two times Fast Ethernet) would also be a nice opportunity to write up an article dealing with OPi R1 but more generally explaining how to configure networking here (and focus on common mistakes like connecting more than one interface to the same network and then wondering why eg Wi-Fi stops working after the Ethernet cable is disconnected )

(IMO) There is no point on switching to 4.12 since Icenowy just made a first 4.13 branch: https://github.com/Icenowy/linux/tree/sunxi64-4.13-rc5 While it doesn't have some features that could be added (I can already hear "there is no DVFS! let's use Megous' branch instead") it's still a good candidate for a development branch since it has a WIP DRM display driver, support for the Pinebook, and the SoPine. if/when she posts a 4.13.y branch (for a stable kernel version, not a release candidate) we can try switching sun50i-dev to that branch, but we still need to update the u-boot (ideally to v2017.09).

Well, from a technical point of view it's just an OPi Zero with an USB-Ethernet dongle attached to the USB port in a much nicer form factor. Software development efforts needed: close to zero since the only two things that are interesting is whether the used Ethernet chip is supported by legacy kernel and runs stable (testing efforts hardware vendors usually skip) and same for Wi-Fi (since it's RTL8189ETV an /etc/modules modification should do the trick). If Armbian wants to support this board IMO we should focus on providing a single OS image for both H2+ OPi Zero variants. But let's wait until schematics are released or at least real information is available (especiall type of Ethernet chip -- if it's RTL8152 then we could at least test a bit with legacy kernel since Pinebook shipped with such a dongle) Well, it can always grow to one side without affecting mechanical compatibility to add-on boards.

While it's far from "supported", HDMI output should work via simplefb enabled by u-boot, but I don't think that anybody tried to enable the DSI output in mainline (though Icenowy was able to use the RGB output on the Pinebook which should use pretty much the same display pipeline if I understand it correctly). By "mostly useless" I mean mostly useless for an average user that wants to use a desktop environment (X11 or Wayland). Without a matching binary userspace driver (and by "matching" I mean architecture (armhf vs arm64), API (Wayland, X11, framebuffer) and hardware (Mali400 and matching revision)) you won't be able to use it, and it's not like ARM or Allwinner are willing to provide a full set of these blobs. Well, if you call r3p0 UMP version "support", then maybe. AFAIK r5p0 was tested on mainline H3 and H5 too, but again it is limited by the availability of a matching userspace binary and a proper DRM display driver.

Update. Pinebook was my Beachbook for some time. I used it for email, browsing, IRC and terminal. It proved to be sufficient while once it didn't start charging (from 5%) even plugged to charger - unplug / plug back solved that - and "heavy" Chromium usage ate all resources. I think we need to check Chromium caching - when using let's say about 10 tabs for some time - RAM is going down, swap is not getting used and system just become extremely slow / unresponsive. My environment did not provide enough motives for exploring the problem deeper

What about to provide a separate pinebook-hdmi dtb file? I already searched to understand how to enable hdmi but not found. OK, will RFC. Loaction of this file https://github.com/armbian/build/blob/master/config/50-pine64-pinebook-touchpad.conf is also not very logical. Where should we collect such things?

Release candidate latest fixes + this regarding audio on resume, touch pad and kernel upgraded with upstream patches. Download: (touch pad fix not included) https://dl.armbian.com/pinebook-a64/Ubuntu_xenial_default_desktop.7z What about HDMI out - how to use it?

All those listed long ago for a reason in the very same thread: https://forum.armbian.com/index.php?/topic/4133-quick-pinebook-preview-review/&do=findComment&comment=31463

I was using Pinebook for a week and it's performing ... good as a light browsing and remote terminal console work - any objections to move it from WIP section? Any idea why audio stopped to work? IIRC we fixed that.

[Disclaimer on] This is the try to play through some sort of an approval process contuining discussion from here and there -- maybe move @hmartin's last post to the latter thread? IMO we need a transparent process to decide whether to support new devices or not weighing pros/cons for both developers and users and estimate efforts especially if it's a new platform. Even if hardware vendors send out free dev samples we should not automatically start with new boards but discuss and evaluate first since we already deal with way too much boards with a crew just too small. I would believe @Igorhas now every new Olimex device and TL Lim said he sent out 3 ROCK64 boards to various Armbian devs me being amongst... I think that's an opportunity to start to establish such a process now? Since I've thought about this issue for a few days and came to no conclusion (Github issue or not or discussion in forum and so on) I'm now just naively start with a new thread regarding this RK3328 device and maybe we find out collectively how to define a process based on this? [Disclaimer off] Let me introduce ROCK64: RK3328 SoC: feature list ROCK64 schematic (preliminary since vendor promised to accept last minute changes/suggestions within the 2 next weeks) Board layout picture (same form factor as Raspberries, pre-production samples do not fit exactly in RPi enclosures, final design should fit) 1GB, 2GB or 4GB PC-18666 LPDDR3 eMMC has higher boot priority than SD card (but eMMC can be disabled via jumper) socketed eMMC modules are the same as on Pinebook and SoPine (and compatible to older ODROIDs and their SD card adapter) 128Mb SPI NOR flash (16MB) on future board revisions (to directly boot from USB[3] storage, network or whatever) RK3328 should be interesting for media center purposes (4K support, video codedcs, somewhat decent GPU, high memory bandwidth) Due to USB3, GbE and additional Fast Ethernet also interesting for NAS/server use cases (TBC, both USB3 and GbE performance needs to be checked) I2S exposed and compatible to some early RPi DACs, a lot more GPIOs exposed as usual (see picture above and this) Pricing will be competitive (can't share details yet but it's based on amount of DRAM and tries to match Pine64 costs but since DRAM prices increased a lot the last months it might be slightly more. Prices will be announced publicly within the next 2 weeks) Pros: board vendor actively participates (listens to community, provides information including schematic and cares about correctness, tries to bridge developer community and chip vendor) board vendor provides dev samples and documents problems devs might run into (see below) chip vendor actively supports mainline Linux and u-boot chip vendor is said to focus on ROCK64 as currently best supported RK3328 device to spread market adoption (TBC) SDK/BSP not horribly outdated (RK relies currently on 4.4) almost all Armbian target audiences might benefit from RK3328 support (desktop replacement, NAS/server, audiophiles + IoT use cases due to exposed GPIOs/interfaces) No unreliable shitty Micro USB for DC-IN but sane 3.5/1.35mm barrel plug to be combined with 5V/3A PSU Pine Inc already sells together with Pinebook Icenowy already received a dev sample Cons: new platform (Rockchip 64-bit) needing more initial work Did anyone of you received shipping confirmation with tracking number already? @jernej? Unfortunately I get a dev sample with unusable USB3 (some components need to be desoldered which is a pity since I'm not good in soldering at all) My next steps planned: Boot the board with what's provided within one week (TL Lim mentioned a 'Debian based 4.4 BSP, later Yocto' and said RK would be ready with a mainline variant within the next weeks) Test GbE speeds, memory throughput and the usual Armbian tunables (IRQ distribution) ask @Xaliusfor USB3 numbers (his dev sample was shipped out later and doesn't need soldering) Present results to continue discussion