tkaiser

To stop wasting my and other's time on this boring 'issue' here a final summary:
Close to unbelievable but after another 'evil tkaiser attacking us' event today the hardware vendor 'fixed' voltage regulation description. Just to remind you: this file has to be correct in the first place, there's no excuse for such wrong information there, it's simply the hardware vendor describing how the board works. So now that PL01 is used for voltage regulation (now in conflict with another active PL01 entry for s_rsb_sda -- good luck!) only all gmac* entries are still wrong and cooler_table not using the 912 MHz OPP is most probably a great recipe for poor performance when overheating occurs. So in case someone from SinoVoip wants to fix their pseudo Armbian build it would be wise to fix the fex first since afterwards Armbian's h3consumption tool can work without issues (today not due to still wrong fex file) On their Gitbook pages the size of M2 Zero increased by 5mm (now at least this most basic info is correct), most of the other 'information' is still sparse, wrong, missing, bogus. But fortunately the hardware is still too small on their product page and of course soon everywhere around the globe in advertisements and product listings since all resellers use the wrong dimensions they've been provided with back in July. So anyone interested in this board running with the outdated legacy kernel: chances are great that you get a working OS image over at bananapi.org (soon). As a reminder: Armbian follows the policy to not officially support Raspberry Pi boards which of course also applies to deliberately compatible looking but mostly incompatible RPi clones like this M2 Zero here (we don't want to see this forum/community dying when RPi users or fooled M2 Zero customers arrive) Armbian also tries to phase out legacy kernel support (3.4.113 which is not supported any longer since over half a year now). CSI/camera support with mainline kernel is still WiP so when switching from legacy to mainline camera functionality will also be missing. Again no reason to officially support such a device Third 'problem': dishonest advertising. Nowhere is mentioned by the vendor that M2 Zero is totally incompatible to RPi cameras (which is something average buyers expect) and RPi software (which is something clueless buyers expect from something that mimics the look of an RPi Zero and is said to run 'Raspberry Pi image'). There's really no reason for us here wasting our spare time with support efforts like this: https://forum.armbian.com/topic/5579-power-off-with-hdd-over-active-hub/?do=findComment&comment=43088  
Exactly. @Lion Wang's problem is that he wants to sell hardware and his company earned a very negative reputation over the last years (believing this would be caused only by evil people outside and not related to their internal and pretty real problems). That's something where some idiots here at Armbian could help working for him in their spare time and doing his software and support work.
 
@lvmc has the problem that he wants to use this BPi board with his own camera modules. Should work now so let's please stop babbling about community and so on.
 
We have the problem that even if we wanted to support SinoVoip products they don't allow us. They refuse to cooperate, do not provide correct hardware descriptions, do not listen to community, delete community knowledge, ignore(d) even patches they got for free just due to ignorance, ignorance, ignorance.
 
A few people here suggested to give SinoVoip a final chance. I support this. The problem is... I and others are dealing with Banana madness now in the 3rd year. We have heard that so often that it simply got too boring. So let's step back now, give them 6 months of time to show that they're willing to improve, deal with their internal ignorance/stupidity problems and then let's have a look again.
 
In the meantime it would be great if people would stop asking us for anything Banana related. Thank you.
 
 

OK, I started the Sunxi wiki page ... http://linux-sunxi.org/Sunvell_R69
Is a pice of crap, yes I know.
Hi @guidol may I use your board images in the wiki?
Anyone interested in sent me info to fill the info.
Thanks!!

Only on H2+/H3 boards (sun8i architecture) our RPi-Monitor installation routine will detect this and installs improved templates (should work with both legacy and mainline kernel, at least I added/tested this last year). No other platforms (PC2 --> H5 --> sun50i) are supported in this way, especially the background daemon collecting detailed CPU (and voltage) information isn't installed.
 
I do not plan to change anything here since the above 'OPi-Monitor mode' was mostly implemented to let users help us supporting new boards (especially needed for the overheating Banana Pi M2+ back then). The other reason why I will not touch this is since work on Armbian got so frustrating especially the last days.
 
My templates were uploaded to Github https://github.com/armbian/build/tree/master/packages/bsp/armbianmonitor/templates -- sun8i dev would be the best starting point.

Man, that's soooooooooo annoying. Do you know how much time it needs to support this M2 Zero IF SinoVoip would care about providing correct information? Less than an hour. It's just importing a CORRECT hardware description and then doing some MINOR adjustments. That's how it works
Get correct hardware description from board vendor adopt/improve settings test, test, test provide general support if Armbian supports the board Step 1 is the problem. We NEVER got correct information, usually we get bogus information for whatever reasons (you call it business strategy while I would call it stupidity/ignorance) and it's the same with Zero AGAIN. If I have to ask someone who personally called me an asshole already, refuses to update publicly available information and also ensures that's there's only BS instead of technical documentation available then:
why should a developer deal with this stuff? why should a community like Armbian think about step 4 above? If the vendor's business model is targeting only clueless consumers who do not even care about basic product descriptions being correct (even the PHYSICAL DIMENSIONS, still not fixed in their 'technical documentation') while at the same time being tricked into believing they would buy something compatible to Raspberry Pi Zero (SOFTWARE COMPATIBILITY) then why should a community like Armbian want to support these consumers and the vendor?
 
Even if this M2 Zero isn't useful for any of my own use cases (anyone ever thought about WHY we Armbians spend our SPARE TIME on which devices?) I would've long added https://github.com/armbian/build/blob/master/config/boards/bananapim2zero.csc and https://github.com/armbian/build/blob/master/config/fex/bananapim2zero.fex to the build system since it's easy and fun. But impossible with SinoVoip since they refuse to provide step 1 above and even actively hinder community to support their products.
 
Nothing will change until this company starts to realize that they need to replace their copy&paste monkey responsible for this gitbook mess with a technical writer and that they have to provide CORRECT hardware descriptions early and in an easily accessible way (push the stuff to github at one location, correct mistakes as soon as you're aware of it). And even then it's highly questionable why Armbian as community should start to officially support devices that are designed to trick consumers into believing full Raspberry Pi compatibility where there is none.
 
BTW: I really don't know why I have to repeat this now again (especially since you call this boring). It's so OBVIOUS what's wrong with the company's behaviour and it's also obvious that they don't want to change this. It's still just a waste of time (the board I lost most of my time with in the past was the Zero's bigger sibling M2+, everything related to SinoVoip providing INCORRECT hardware information/description -- whether on purpose or caused by stupidity/ignorance doesn't really matter any more).
 

Good news: @zador.blood.stained imported (cherry-picked) vendor provided software support for Helios4 into our build system recently, I let on my host build an OMV image and it seems it's working out of the box: https://github.com/armbian/build/pull/812#issuecomment-342006038 (though some minor issues present we can focus now on).

Running "systemctl --user enable ..." using su won't work according to my tests, so psd activation needs to be reworked into a separate login script.

Someone said my name?  Sorry it took me a while to run this, but they offer a 100MHz clock speed and that takes a very long time to run--especially with one thread.  I have a high degree of confidence that there is no throttling as IIRC, I tested this setup with cpuburn and got no throttling.  I can't imagine this being more demanding than that!
 
Here's the data:
num-threads=4
100: execution time (avg/stddev): 99.4764/0.02 250: execution time (avg/stddev): 37.7647/0.01 500: execution time (avg/stddev): 18.6581/0.00 1000: execution time (avg/stddev): 9.2395/0.00 1296: execution time (avg/stddev): 7.1300/0.00 1536: execution time (avg/stddev): 6.0117/0.00 1656: execution time (avg/stddev): 5.5794/0.01 1680: execution time (avg/stddev): 5.4853/0.00 1752: execution time (avg/stddev): 5.2694/0.01 num-threads=1
 
100: execution time (avg/stddev): 369.1851/0.00 250: execution time (avg/stddev): 146.8992/0.00 500: execution time (avg/stddev): 73.3360/0.00 1000: execution time (avg/stddev): 36.6221/0.00 1296: execution time (avg/stddev): 28.2551/0.00 1536: execution time (avg/stddev): 24.4123/0.00 1656: execution time (avg/stddev): 22.0989/0.00 1680: execution time (avg/stddev): 21.7828/0.00 1752: execution time (avg/stddev): 21.3559/0.00  

It doesn't. But it also doesn't work if I revert URL rewrite. Forum has to have at least one bug

ubuntu xenial
/usr/bin/sysbench: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=01b3ec2b7f6a203ed
 
This is just a boostrapped ubuntu image with the kernel on github.

I'm well aware of this and as already said IF SINOVOIP WOULD START TO PROVIDE CORRECT HARDWARE DESCRIPTIONS BPi M2 Zero would've been long added as .csc (community supported board variant) so it's at least ensured that hardware settings match so other projects relying on Armbian's build system or using same legacy kernel can easily add support for BPi M2 Zero to their projects (those others are for example H3Droid, RetrOrangePi, Lakka and @jernej's community OpenELEC distro).
 
It would have already happened if the company in question would start to provide correct and not all the time missing or even wrong information.
 
That was talking about most basic support, just describing the hardware so it's useable with legacy kernel (the 3.4 that is unsupported since more than half a year since EOL in April 2017) in a good way. Impossible with SinoVoip since they do not provide the needed information (voltage regulation, if this thing can't switch to 1.1V it will permanently overheat). As soon as this is fixed it's throwing in 2 files into the build system and perfectly working OS images can fall out of it, then @lvmc would already be happy since he doesn't need community, friendlyness and the other stuff but just working OS images for his commercial use cases. Fair enough but not related to 'Armbian support', he and we are missing vendor support.
 
'Full Armbian' support would mean we actively try to support this device. Armbian wants to move away from legacy kernel so all you have with mainline kernel is then a H2+ device lacking 3 USB ports with a problematic Wi-Fi implementation (AP6212A though referenced as AP6212 by the vendor -- do you start to understand why dealing with them sucks?), only one USB OTG port, no working camera and tinkerers encouraged to solder a MagJack wrongly then then flooding our forum about Ethernet problems.
 
Adding to this: false/misleading advertising. Buyers believe M2 Zero would be compatible to RPi cameras (not true at all) and to RPi software (not true at all). And these people will later end up here in the forum (since they'll realize pretty fast that SinoVoip doesn't support SinoVoip hardware) and complain about incompatibilities. That's the other reason official Armbian support is highly questionable.
 
And may I remind you that all the work done on Armbian is done by volunteers even if the liar who called me already an asshole constantly spreads I would be paid by Xunlong. Seriously: why dealing with this stuff?

Easy: Correct this mistake here: https://bananapi.gitbooks.io/bpi-m2-/content/en/bpi-m2-zero-hardware/bpi-m2-zero-hardware-spec.html (what to expect from a vendor who is not even able to specify the physical dimensions of his own products? It's now year 3 that we deal with this insane amount of stupidity/ignorance, these guys simply don't give a shit about 'information' they provide being correct or of any meaning).
 
As you can see in this thread as usual either schematics or their hardware description (provided fex file) are wrong, this simply sucks and prevents any development efforts. As you can also see above @Icenowy (member of linux-sunxi community) is the only person on this planet currently able to provide some real information (eg. voltage regulation different on her board compared to later board variants -- but you never know what they screw up with a new board revision).
 
As soon as SinoVoip starts to support their own hardware (and do not just spread BS) things might greatly improve though I've not the slightest idea why Armbian would want to support this board (just with BPi M2 Berry the M2 Zero only tries to attract clueless RPi users and I'm sure we really don't want these people here in the forum constantly asking why raspivid, omxplayer and adjusting display resolutions in /boot/config.txt doesn't work. Supporting boards that are designed as scam isn't that smart)

@tkaiser it works with both SinoVoip's OV5640 or own custom module.

It seems it is browser related -- sorry for the noise. Tested on 3 different platforms with 3 different browsers each and only the one I use for 'average web surfing' (Safari on macOS) shows the behaviour.

My OMV installation routine was at fault (cause/fix), it only affects installations with IPv6 propagated through DHCP (that's why I did not notice since my lab is IPv4 only) and is fixed at least on the XU4/HC1 image in the meantime. Most probably only C2 image affected any more (and maybe C1 image).
 
Still waiting for C2 being usable with btrfs and next kernel in general. Then I'll regenerate the image. In the meantime affected users should take care that IPv6 is temporarely disabled when they boot their OMV image the first time.

tkaiser OPi R1 Image:
Linux orangepi 3.4.113-sun8i #13 SMP PREEMPT Sat Nov 4 07:45:43 PDT 2017 armv7l armv7l armv7l GNU/Linux
 
After resize-boot armbianmonitor/iwconfig:
root@orangepi:~# armbianmonitor -u /var/log/armhwinfo.log has been uploaded to http://sprunge.us/EVRd root@orangepi:~# iwconfig lo no wireless extensions. enxc0742bffe8ff no wireless extensions. wlan0 unassociated Nickname:"<WIFI@REALTEK>" Mode:Managed Frequency=2.412 GHz Access Point: Not-Associated Sensitivity:0/0 Retry:off RTS thr:off Fragment thr:off Encryption key:off Power Management:off Link Quality:0 Signal level:0 Noise level:0 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 eth0 no wireless extensions. after configuring the interfaces via nmtui - without problems:
root@orangepi:~# armbianmonitor -u /var/log/armhwinfo.log has been uploaded to http://sprunge.us/HOVb root@orangepi:~# iwconfig lo no wireless extensions. enxc0742bffe8ff no wireless extensions. wlan0 IEEE 802.11bgn ESSID:"MySSID" Nickname:"<WIFI@REALTEK>" Mode:Managed Frequency:2.462 GHz Access Point: C0:25:E9:44:71:68 Bit Rate:72.2 Mb/s Sensitivity:0/0 Retry:off RTS thr:off Fragment thr:off Encryption key:****-****-****-****-****-****-****-**** Security mode:open Power Management:off Link Quality=100/100 Signal level=70/100 Noise level=0/100 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 eth0 no wireless extensions. root@orangepi:~# ifconfig enxc0742bffe8ff Link encap:Ethernet HWaddr c0:74:2b:ff:e8:ff inet addr:192.168.6.154 Bcast:192.168.6.255 Mask:255.255.255.0 inet6 addr: fe80::c274:2bff:feff:e8ff/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:10302 errors:0 dropped:0 overruns:0 frame:0 TX packets:1086 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1316838 (1.3 MB) TX bytes:349868 (349.8 KB) eth0 Link encap:Ethernet HWaddr e2:fc:56:2f:d5:dc inet addr:192.168.6.101 Bcast:192.168.6.101 Mask:255.255.255.255 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:3 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:238 (238.0 B) Interrupt:114 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:388 errors:0 dropped:0 overruns:0 frame:0 TX packets:388 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:95697 (95.6 KB) TX bytes:95697 (95.6 KB) wlan0 Link encap:Ethernet HWaddr 08:ea:40:7c:02:ad inet addr:192.168.6.152 Bcast:192.168.6.255 Mask:255.255.255.0 inet6 addr: fe80::aea:40ff:fe7c:2ad/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:8559 errors:0 dropped:0 overruns:0 frame:0 TX packets:24 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1553591 (1.5 MB) TX bytes:3347 (3.3 KB) root@orangepi:~# lsmod Module Size Used by 8189es 1075930 0 zram 8964 4 pcf8591 3363 0 bmp085 3487 0 cdc_ether 3679 0 usbnet 14096 1 cdc_ether g_serial 28549 0 btrfs 712409 0  

@tkaiser Dont be frustrated -  now that I got my R1 here is fex-file, lsmod, iwconfig and dmesg from their image for the R1: ubuntu_server_xenial_H2_R1_V0.1.img
ubuntu_server_xenial_H2_R1_V0.1.img: Linux OrangePizero 3.4.39 #2 SMP PREEMPT Fri Apr 14 14:05:55 CST 2017 armv7l armv7l armv7l GNU/Linux (running hot like the armbian legacy) root@OrangePizero:~# iwconfig gre0 no wireless extensions. lo no wireless extensions. tunl0 no wireless extensions. wlan1 unassociated Nickname:"<WIFI@REALTEK>" Mode:Managed Frequency=2.412 GHz Access Point: Not-Associated Sensitivity:0/0 Retry:off RTS thr:off Fragment thr:off Encryption key:off Power Management:off Link Quality=0/100 Signal level=0 dBm Noise level=0 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 eth1 no wireless extensions. wlan5 unassociated Nickname:"<WIFI@REALTEK>" Mode:Managed Frequency=2.412 GHz Access Point: Not-Associated Sensitivity:0/0 Retry:off RTS thr:off Fragment thr:off Encryption key:off Power Management:off Link Quality=0/100 Signal level=0 dBm Noise level=0 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 sit0 no wireless extensions. eth0 no wireless extensions. ip6tnl0 no wireless extensions. root@OrangePizero:~# lsmod Module Size Used by r8152 49914 0 cdc_ether 3187 0 usbnet 14152 1 cdc_ether sunxi_ir_rx 9150 0 gpio_sunxi 8265 0 8189es 996645 0 root@OrangePizero:~# ifconfig eth0 Link encap:Ethernet HWaddr 76:92:b2:d9:2d:6d inet6 addr: fe80::7492:b2ff:fed9:2d6d/64 Scope:Link UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:3 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:510 (510.0 B) Interrupt:114 eth1 Link encap:Ethernet HWaddr c0:74:2b:ff:e8:ff inet addr:192.168.6.153 Bcast:192.168.6.255 Mask:255.255.255.0 inet6 addr: fe80::c274:2bff:feff:e8ff/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1253 errors:0 dropped:0 overruns:0 frame:0 TX packets:994 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:122366 (122.3 KB) TX bytes:133846 (133.8 KB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:142 errors:0 dropped:0 overruns:0 frame:0 TX packets:142 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:11895 (11.8 KB) TX bytes:11895 (11.8 KB) wlan1 Link encap:Ethernet HWaddr 0e:ea:40:7c:02:ad UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) wlan5 Link encap:Ethernet HWaddr 08:ea:40:7c:02:ad UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) root@OrangePizero:~# find / -name script.bin /media/boot/script.bin root@OrangePizero:/media/boot# ls boot.scr script.bin System Volume Information uImage root@OrangePizero:/boot# ls boot0_OPI.fex script.bin.OPI-PC_1080p50 script.bin.OPI-PLUS_1080p60 uImage script.bin.OPI-2_1080p50 script.bin.OPI-PC_1080p60 script.bin.OPI-PLUS_720p50 uImage_OPI-2 script.bin.OPI-2_1080p60 script.bin.OPI-PC_720p50 script.bin.OPI-PLUS_720p60 uImage_OPI-2_NO_BUDGET_COOLING script.bin.OPI-2_720p50 script.bin.OPI-PC_720p60 u-boot_OPI-emmc.fex uImage_OPI-PLUS script.bin.OPI-2_720p60 script.bin.OPI-PLUS_1080p50 u-boot_OPI.fex uImage_OPI-PLUS_NO_BUDGET_COOLING  
dmesg_Opi_R1.txt
script.bin
script.fex

What about an universal lib which is  totally decoupled from HW platform, and with functions (SPI, I2C, UART, GPIO) separated?
  - It should be not only able to run on Allwinner SoCs, but also other
  - No kernel driver hacking or physical register access, only based on Linux userspace interface
 
I did port the wiringPi last year. Both C and Python (Cython based) are supported.
The only customizing needed is to fill in the GPIO number map (standard Linux GPIO number) and device number (SPI1, ttyS2 etc.)
 
https://github.com/nightseas/nightWiring
https://github.com/nightseas/python-nightWiring/

May I put another dime in the pocket?
 
http://wiringx.org/
 
It is a very modular GPIO library, both C and Python.
I added versions for the Orange Pi one and the Olimex OLinuXino(not yet committed to the GitHub ) I didn't write the library though, but am using/contributing to it.
You can write one program and it is binary compatible with all boards. The Blink example works on all supported boards by giving the argument which board it should run on.
So, if I may say so, it has it's functions totally decoupled from the HW platform.
Adding a platform is about half an hour work, adding another SoC might take a little longer, but the H3 is already added, so adding more boards based on that SOC is pretty easy.
 
regards

Hm. According to schematics Opi Zero+2 H5 doesn't wire USB port 1 anywhere, and Opi PC2 and Prime have USB1 enabled by default.
And since I also don't see anything that would resemble an amrbianmonitor -u support link and a serial console log from u-boot I don't think I have anything I can look into.
 
It is possible to check that overlays are applied correctly in /proc/device-tree and probably somewhere in /sys too.

Just like on any Z28 (Pro) box. My personal opinion on 'working' on TV boxes: It's stupid from a developer's perspective for more than one reason (read here and below). That being said obviously you missed that Igor ordered the biggest Z28 Pro TV box variant (with GbE onboard) so if it's about choosing a RK3328 TV box that might maybe get supported status then it's clearly Z28 Pro and none of the other Z28 boxes that are all more or less the same hardware since following closely one of 4 Rockchip reference designs (check ROCK64 schematics there you find all 4 variants).

IMO we should consider shipping with
overlays=usbhost2 added to /boot/armbianEnv.txt by default for this board since zero disadvantages but only avoiding support efforts and 'reviews' ('With Armbian mSATA does not work'). Users don't read the fineprint, so let's fix this now and not later.
 
On a related note: I did some tests with zram and vm.swappiness=100 and this really looks promising. Could be a real improvement on those boards with low memory where we can ensure that no legacy kernels will be used.
 
Edit: Or maybe it's better to add ohci2/ehci2 nodes to the DT patch since referencing sun8i-h3-nanopi.dtsi there and activating usb3 by default can already be considered 'wrong' from a kernel dev's perspective (for reasons unknown to me these guys want to reduce 'user experience')

-
 

Better use ddrescue for this (apt install gddrescue). Then to get an idea how much to shrink the partition one could mount /dev/loop0p1 (in case it's a single partition image -- better check /proc/partitions) and look at the output from 'df -k' then und umount the partition. And in case it's not about to create an image that gets burned directly after but to archive an image (compressed) then it's a good idea to mount the shrinked partition and zero out all empty space:
dd if=/dev/zero of=/mnt/loop0p1/zeroes bs=1M || (sync ; rm /mnt/loop0p1/zeroes ; umount /mnt/loop0p1)  
 
Why re-inventing the wheel? The way better alternative is /etc/init.d/resize2fs start. And cloning already existing installations is dangerous for a variety of reasons since you end up with same SSH keys on all devices and on some boards MAC addresses of Ethernet or Wi-Fi are stored in files below /etc (so you end up with duplicate MAC addresses in your network causing all sorts of 'funny' troubles).
 
If anyone starts to think about cloning Armbian installations that were already booted (and ran /etc/init.d/firstrun therefore), it's strongly recommended to read and understand this script (except the useless do_firstrun_automated_user_configuration function). Since the best idea is to prepare the installation to clone in a way that on new boards both /etc/init.d/firstrun and /etc/init.d/resize2fs get started again (even if a full expand is not wanted, better shrink the partition before to an absolute minimum and use the documented tweaks to control resizing later)

Most probably the heatsink wasn't that efficient and almost all those SBC enclosures are such an bizarre fail if it's about heat dissipation. I tested this years ago with a DHT22 sensor inside such a 'standard enclosure' and internal temperature was +20°C above ambient temperature around. Metal enclosures with direct contact to heat emitting sources like the SoC would be way more efficient than those 'traditional' approaches attaching a heatsink of any size and then cramping everything in a tiny enclosure without direct contact to the outside (for a good implementation see ODROID HC1 for example, but with all those NanoPi it also works excellent, a customer is attaching them directly to 'huge heatsinks' (screwed to the inside of rack cabinets with a thin thermal pad between SoC and the metal)
 
 
If you chose those provided within the last 2 months... they work flawlessly (personally tested over ten times each). But I should really stop to care about reports that affect crappy hardware (Micro USB for DC-IN)

Check your SD card and dmesg for 'read-only' messages. Man, this gets so booooooooring.