Search the Community

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.

Hello, recently got a pinebook. I have a strong Linux-on-PC-user background (running ArchLinux on my desktop & older netbook, and debian oldstable on my home server laptop), but not really a developer background and no experience with single board computers at all! Ubuntu Mate is happily chugging along right now, but video playback (h264 packed in .mkv) is abysmal to non-existent. I have tried these releases; the stable 0.6.2 first: AFAICS, it uses a frambuffer driver (fbturbo) under Xorg. video playback was more than choppy, and the UX drops to zero because the video window can't be resized and sticks to the screen, always on top across all desktops. I upgraded to 0.7.8 and ran the scripts according to the rather sparse instructions (and I haven't found better instructions): Now video playback is non-existent! But according to the glmark2-es2 benchmarking utility i get 100points. hm. i think i read on pine64 forums that the drivers responsible provide only a subset of opengl v2.0, and that subset has nothing to do with video playback. True? Some additional info in this post. My questions: Is video playback possible at all? The answers i see on pine64 forums range from "With these mplayer settings it works" or "It is OK; not perfect but usable." to "It is what it is because the driver is closed source and nothing to do" ... I get the impression there's some self-delusion in this (who'd want to admit that getting a pinebook was a mistake)... About the pinebook Linux releases: Why a (the same?) 3.10 kernel in all pine64 releases? Is an alternative OS available and will it bring improvement? Can I install any pine64 OS, or does it have to be a binebook release (I am quite capable of setting up my own desktop, but I'm not sure how deep the differences between pine64 and pinebook run)? About armbian for pine64: A Xenial stable release is on offer. why xenial? the name "armbian" suggests debian, not ubuntu? Thanks for reading. PS: I am aware that there's 2 stickies that relate to my questions; if the information I'm asking for is buried in them, I apologize and will accept any pointers given.

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.

What is way more important is to understand how the physical environment affects thermal readouts especially in the Pinebook. There PMIC and SoC are both attached with thermal pads to a metal plate. When the Pinebook charges, the PMIC gets very hot and transfers this heat over to the SoC, so SoC temperatures seem to increase for no reason and people are scared. In general it's the old story about data vs information. People love numbers (since easy to compare), love graphs (since nice looking) but don't like information (need to switch on the brain). So what does monitoring provides? Data but no information. You need to have some knowledge to make use of it, in this case about PMIC+SoC placement. This RPi-Monitor stuff is great for developing good settings (as we did last year for H3 and A64 devices, this year it was just a quick check if we can throw Allwinner's Pinebook settings away and replace with the way better Pine64 settings community developed last year) but once this is done it's not that useful anymore unless you want to experiement yourself (testing out different heatsinks or cooling solutions for an enclosure for example) BTW: position of the CPU cores matters wrt temperature sensor: https://forum.armbian.com/index.php?/topic/1614-running-h3-boards-with-minimal-consumption/&do=findComment&comment=12525 (A64 is more or less a H3 with exchanged CPU cores and crippled USB) This is not related to GPU/Mali400 (this Mali crap is useless with A64 anyway). Allwinner's video engine is doing this stuff, we can use HW accelerated video decoding on A64 since March 2016 (even if over in Pine64 land still some believe they need 'the Mali' for that), we were able to use hardware accelerated video encoding a few months later. Temperatures increase just by a few degree: https://forum.armbian.com/index.php?/topic/789-breaking-news-choosing-armbian-speeds-up-your-orange-pi-multiple-times/&do=findComment&comment=6005 (video engine in H3 and A64 is exactly the same, at the top of that thread you also find a nice example why Allwinner's defaults are so shitty and why it matters to replace them with community settings)

There was none since with Armbian it's just a simple 'armbianmonitor -r' to get RPi-Monitor installed. But currently only for one single platform the templates will be adjusted so you end up with default templates on all other platforms and have to exchange them yourself. On A64 platforms using legacy kernel (that applies to you) the most simply thing is to use this script: https://github.com/ayufan-pine64/linux-build/blob/master/package/root/usr/local/sbin/install_rpi_monitor.sh (it's bundled in most recent ayufan builds for Pine64 and Pinebook). All currently available RPi-Monitor templates here: https://github.com/armbian/build/tree/master/scripts/armbianmonitor/templates (even for shitty devices like Banana Pi M3 Armbian hopefully never will support). I never touched or even looked at those templates for memory or swap since useless anyway (it's fine having no 'free memory': http://www.linuxatemyram.com)

On the Pinebook or SOPine having the eMMC installed changes the device numbering and needs handling in boot.cmd, not sure how the RK u-boot config handles that atm...