How to select a good board, processor?

Recommended Posts

Title changed by moderator from "Performance and support ... how to select a good board, processor? Problem about different installation procedures by variety of platforms  ex rpi-monitor ..."

pine64:~$ uname -a
Linux pine64 3.10.102-2-pine64-longsleep #66 SMP PREEMPT Sat Jul 16 10:53:13 CEST 2016 aarch64 GNU/Linux

After reading the post here about your thoughts concerning AllWinners processor seems not the best choice qua performance and support.

What kind of boards, processor is this community recommending? Thanks, I didn't found yet some kind of stars, recommendations here about boards.

To be honest I'm little bit misguided, because of the supported CPUs, boards.

On the other hand the post : “Need help on Pine A64, 64bit Quad Core 1.2GHz Single board computer” was for me as newcomer an eye opener.
Just as this document of Tido

I have a lot of respect for you all, your time and effort.

But what is the big difference between ARMbian and a debian installation?

I'm little bit confused in a way … 
TKaiser, just like a lot of others in this community, did so much effort and coding, but I've the impression that every platform has it's own installation procedure for rpi-monitor.
By accident I found this guide one for board PINE A64, which is quite different to the one for the Banana A20 Pi.


wget -q -O - | /bin/bash

(I was not able to find your original post back, here???… in the hope to learn a little bit more.
Except a small post here about the performance  – tkaiser reference    )

for banana pi (router) A20, is for me not all clear but the post explains quite a lot.

On the other hand …
I have already  few questions about the set-up
for PINE A64, I don't see on the rpi-monitor that there is no PMU [Power Management Unit] available.
Is it difficult to implement ...   [  ] ... 
I have read now about regular expressions ... but how do you go from command line to ... 


config files.
[ ] But still makes no sense ... 

In meanwhile I found this information in paragraph : "Add other graphs from additional sources: other mount point"  - REF :

COMMAND | perl -ne '/REGEXP/' and print "$1\n"'

And despite I use a32Gb SD-card mounted, I just see 6Gb (also in command line).
(a SD one like recommend at : SD-card )

PICTURE on-line : (annex)

command line

pine64:~$ sudo fdisk -l
[sudo] password for debian: 
Disk /dev/mmcblk0: 29.7 GiB, 31914983424 bytes, 62333952 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x88dd9856
Device         Boot  Start      End  Sectors Size Id Type
/dev/mmcblk0p1       40960   143359   102400  50M  e W95 FAT16 (LBA)
/dev/mmcblk0p2      143360 12787711 12644352   6G 83 Linux

[ /etc/rpimonitor/template/sdcard.conf ]
static.7.source=df /
static.8.source=df /boot
dynamic.6.source=df /

about SWAP: 
I have 0 as indications; NaN [Not A Number] indication  for percentage ... on first thought, I think it's a regular expression problem???

command line :

pine64:~$ cat /proc/meminfo 
MemTotal:        1003820 kB
MemFree:          211060 kB
Buffers:           19060 kB
Cached:           623204 kB
SwapCached:            0 kB

[ /etc/rpimonitor/template/swap.conf ]

dynamic.8.postprocess=$this->{'static'}->{'swap_total'} - ($1/1024)

Maybe I look it too simple, because the variety of platforms ...
Is it not possible to install all config files (one installation guide) and then just use the correct one, depending platform and number of bits 32/64.

Screen Shot 2017-06-02 at 07.55.49.png

Link to post
Share on other sites
Armbian is a community driven open source project. Do you like to contribute your code?

On 2. 6. 2017 at 9:14 AM, Kris said:

Linux pine64 3.10.102-2-pine64-longsleep

- this is not Armbian, which means scripts done for Armbian might not work there

- we don't support something, we don't know how it's put together, it's a work from somebody else

- information, which you are referring to is very old and possible outdated.

Link to post
Share on other sites
On 2.6.2017 at 9:14 AM, Kris said:

I was not able to find your original post back, here???

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: (it's bundled in most recent ayufan builds for Pine64 and Pinebook).


All currently available RPi-Monitor templates here: (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':


Link to post
Share on other sites

Only adding this as I did look at it and 'fixed' the problem, which was indeed simply wrong pattern match, due to how ubuntu's free formats things different of recent times. However, I do agree with tkaiser, it isn't really needed, as linux is supposed to use 'free' memory for caching... unused memory isn't wasted! I just didn't like the broken stats! ;)


in /etc/rpimonitor/template


Modified swap.conf is like this.


Modified memory.conf is like this.


I also added more stuff to my Allwinner_A64.conf file, which may or may not be the right filename, I might have renamed that in the process of cleaning stuff up.  I added the GPU temps since the health monitor was doing that. Still need to go back and pull the PMIC temp and battery stuff in, and then update my script. It'll happen sometime soon.





Link to post
Share on other sites
10 minutes ago, pfeerick said:

I added the GPU temps since the health monitor was doing that. (but useless anyway, this Mali400 bullshit is of no interest since there's no use case for Mali400 on this platform! But I guess it will take until 2018 until everyone over in Pine64 land will be cured from the stupid Mali hype so many are still suffering from)

Link to post
Share on other sites

You forgot to mention that fact that the GPU won't be that far off the CPU temperature anyway, since they're on the same die. :P It may be interesting though if you do hardware assisted encode/decode stuff, whoever is daft enough to use the pine64 for that :-/

Link to post
Share on other sites
11 minutes ago, pfeerick said:

You forgot to mention that fact that the GPU won't be that far off the CPU temperature anyway, since they're on the same die


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: (A64 is more or less a H3 with exchanged CPU cores and crippled USB)


19 minutes ago, pfeerick said:

It may be interesting though if you do hardware assisted encode/decode stuff, whoever is daft enough to use the pine64 for that



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: (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)


Link to post
Share on other sites

My apologies on that last point... I fully deserved that... I keep thinking that the misleadingly named GPU is actually the GPU, instead of just the 3D accelerator.  I'll stop there though, as this is getting away from the OT.  I just wanted to bite that bullet publicly! :o

Link to post
Share on other sites
This topic is now closed to further replies.