Tido

@dimraz you only do:
 
armbianmonitor -u
 
 

I concur, and I have a feeling the editable nature of the wiki may be... impermanent, let's say.

IMO it's their employee's job to ensure the provided information are correct. Community members may help them correct typo, grammar, etc., but not basic specs. (e.g. Does a mPCIe slot support PCIe+USB or USB only) They would only feel themselves being cheated when incorrect specs were provided, unless the board is provided for free.

**UPDATE August 9 2018**
After some messing around I determined I had some sort of contaminant on my Tinker Board GPIO pins interfering with their conductivity.  I have rerun my GPIO powering test and added the results below, there is no additional drop ( @tkaiser, @Frank Wu  I apologize for the bad information)  Other small updates include a possible reason for the small voltage reporting measurement error.
 
After having received an official Tinker Board Power supply, I submit my findings:
 
Test load hardware:  Tinker Board S with internal voltage monitoring
Condition:  No peripherals save mouse/keyboard/small cooling fan to prevent throttling
Load:  minerd --benchmark
Measurement:  For this I diverged from my typical labor-intensive periodic check with a meter and instead allowed the Tinker S to do the work.  It for sure added noise to the measurement, and so some uncertainty, however I think for the purpose here it is sufficient.
The Tinker S reads low when you get to the 5.0V area.  I measured the system voltage at 5.11V using the chassis supply, Tinker reported 5.02, however the values converged as they approached 4.7 Volts.  This is possibly due to the reference voltage for the ADC drifting ever so slightly with or without load.  With the new GPIO information, my meter and the Tinker Board were registering almost exactly the same voltage (within 0.02 volts) during the test, at 5 volts under load.  
As to the supply itself:
      
Laser marked info is a nice touch, molded strain reliefs at the adapter and the plug, rocker switch for power, and 18 AWG wire.
 
Electrical:
5.0 V 3.0 A.  This will be operating near the bottom end of the spec for USB peripherals on the Tinker due to voltage drop. The wire is heavy gauge and is in a "lamp cord" format, the jacket is flexible so I don't foresee too many internal strain breaks in anyone's future while using this supply. Data:

Analysis/Commentary (very loose format):
 
Using a 5.25 V chassis supply with my standard issue 1.5 meter 20 AWG cable that has seen a few hundred mate/unmate cycles for comparison, you can see that the system really needs to see more than 5V at the microUSB connector, and that cable age and wire gauge matter (my cable showed significantly more than 200 mV of drop, the new Tinker Board supply is showing a good bit less (the 4.9+ V spike is an anomaly I am attributing to the sudden release of electrical load)
 
Keeping an eye on the dmesg for indications of my USB peripherals resetting yielded no complaints.  It is experiencing excursions just below the acceptable minimum, so that will be something to look out for.  There is also the simple reality that the Tinker Board is not adequately cooled to pull this sort of current continuously, it goes into thermal throttling within seconds under full CPU load.
 
Recommendations for consumers: 
 
This supply will work, and is at least on par with the other similar units on the market.  The large conductors reduce one of the most common causes of voltage drop, and connector, I assume, is validated to exceed the 1.8 Amp minimum spec requirement for micro USB as per @Frank Wu.  Such a validation provides some insight into the voltage loss, as increased voltage loss results in increased power dissipation at the connector, the thing being actively minimized by such design/test work.
 
Recommendation to ASUS: 
 
If it is at all possible request the supplier increase the output voltage of this supply by 250 mV.  At that point it could be considered the "go-to" supply for anyone wanting to maintain the micro-USB RPi form-factor compatibility. 
 

Hi,

We've noticed this concerns at the beginning. 
As a matter of fact, believe that we are more worried about any safety design than our guests if out of the power current spec.
So that connector on the Tinker Board & Tinker Board S. We all requires our vendor need to qualified the pressure & safety stress test with 5V/3A.
They can all be relieved to used and can withstand 5v/3a.
(as I knew, the 1.8A is more like a reference standard, so also have lots connectors are required more than 1.8A.)
 
 
Since we have no intention of changing too much layout design and let it can have the highest possibility to fit RPI form-factor's 3rd party case, components, etc.
 
BTW glad to know you like our colorful design on GPIO, that is my favorite part too.
And we would be noted, also survey the DC jack design for If there are any new products in the future.

@HANAX please tell me which is your kernel version. If it is based on mainline, there is no need to specify anything. However, just few days ago issue has been found which causes that some resolution don't work. I already prepared some patches to fix that issue.

That's the question we're working on.  I think we can handle all from one codebase, at least as long as there aren't too many Tinker Reboot workarounds on other boards (I have that "contained" so it doesn't break anything)
 
From kernel to kernel the MAli drivers need tweaking, and while @Myy does excellent work with this, I thought it easier to keep Next on an an LTS kernel, then if people want bleeding edge they can compile a Dev image.
 
Also, welcome back!

Actually it's nice. It simply suffers from what almost all other tools trying to display 'CPU utilization' in some way or the other also suffer from: ignoring reality.
 
With cpufreq scaling 'CPU utilization' alone doesn't tell that much any more especially on systems where all this stuff happens very dynamically (e.g. TurboBoost on x86 where CPU cores clock from 1.2 GHz to 2.2 GHz when just one core is busy, but as soon as a second core processes stuff immediately downclock to 1.8 GHz and stuff like that. Same situation with ARM especially with big.LITTLE and/or on boards where a cheating firmware controls what's happening and the kernel not even has any clue at which clockspeeds the CPU cores are running --> fortunately only applies to Raspberry Pi and Amlogic SBC)
 
I thought several times about an utility both being correct and providing nice looking output. But apart from enhancing RPi-Monitor with templates for some ARM SoC families our armbianmonitor approach is all we came up with. Ugly but at least providing real information and not illusions:
 
root@rock64:~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 10:25:43: 1392MHz 0.39 9% 2% 3% 0% 2% 0% 41.4°C 0/6 10:25:49: 600MHz 0.36 0% 0% 0% 0% 0% 0% 40.9°C 0/6 10:25:54: 1392MHz 0.41 2% 0% 1% 0% 0% 0% 45.5°C 0/6 10:25:59: 1392MHz 0.46 37% 9% 16% 0% 10% 0% 48.2°C 0/6 10:26:04: 1392MHz 0.50 29% 8% 10% 0% 11% 0% 48.2°C 0/6 10:26:09: 1392MHz 0.70 36% 8% 18% 0% 9% 0% 45.0°C 0/6 10:26:14: 1392MHz 1.37 40% 1% 0% 0% 38% 0% 44.1°C 0/6 10:26:19: 1392MHz 1.34 27% 3% 17% 0% 6% 0% 50.0°C 0/6 10:26:24: 1392MHz 1.31 25% 0% 24% 0% 0% 0% 51.7°C 0/6 10:26:29: 1392MHz 1.28 25% 0% 25% 0% 0% 0% 51.7°C 0/6 10:26:34: 1392MHz 1.26 26% 3% 22% 0% 0% 0% 51.2°C 0/6 10:26:39: 1392MHz 1.64 25% 6% 19% 0% 0% 0% 49.5°C 0/6 10:26:44: 600MHz 2.07 2% 2% 0% 0% 0% 0% 42.7°C 0/6 10:26:49: 1392MHz 1.98 24% 0% 0% 0% 22% 0% 47.7°C 0/6 Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 10:26:55: 1392MHz 1.91 24% 0% 0% 0% 24% 0% 46.4°C 0/6 10:27:00: 1392MHz 1.83 22% 1% 10% 0% 10% 0% 46.4°C 0/6 10:27:05: 600MHz 1.69 0% 0% 0% 0% 0% 0% 44.1°C 0/6 10:27:10: 600MHz 1.55 2% 0% 1% 0% 0% 0% 44.1°C 0/6^C  
This is a Rock64 running off a really crappy 4GB SD card (I got a bunch of them recently when replacing them with SanDisk Ultra A1 at a customer) doing an 'apt update'. We see cpufreq increasing, average load increasing and even overall %cpu utilization increasing. But by looking at %io we see that the whole system is often stuck in IO simply because the SD card performs horribly low when it's about random IO. See the '10:26:14' entry: 40% CPU that are in reality only waiting for the crappy SD card finishing its work.
 
That's the problem with 'CPU monitoring' on Linux in general and especially on SBC where 'crappy storage' is more rule than exception. When looking at load or CPU utilization it's all the time misleading as soon as slow performing storage is involved. Since 'Linux waiting for IO' counts as 'CPU busy / increased load'.
 
That's why I unfortunately can only recommend our ugly armbianmonitor to really get a clue what's going on...

Possible addition for stock Armbian builds...adds quite a bit to the terminal based graphical status
 
https://github.com/cjbassi/gotop
 
 

@guidol, today arrived my Transcend RDF5 (unfortunately not available in white here). Veryfing the image is lovely 50MB/sec. I think my old USB2.0 is way slower, I have to check that.

I did an initial boot without changes to see if the image it works...
Warning: a reboot is needed to finish resizing the filesystem. Please reboot the system as soon as possible root@bananapim2plus:~# h3disp -m 1280x1024 -d Now trying to patch script.bin with your settings. Successfully finished. Please reboot for changes to take effect reboot ...  brilliant, it booted to the desktop with 1280x1024 @60Hz. Resizing completed.
 
I did all that. Unfortunately, the Display stays now black, I can only access it via SSH.
armbianmonitor -u   http://ix.io/1h7i
 
h3disp -m 1280x1024 -d ... reboot... et voila desktop is up and running. Well done Sir
 

The question was a hint, because some did wrote that only etcher could do a verfify.
 
Sure, not all Win32 DiskImager installations on this planet get autoupdated, so I did wrote about the NEWEST version with links for Windows-download!
The verify doesnt start automatically, but its only one click after write without selecting drive or image
(auto-verify could be a request for the next version).
 
I often do search informations via google an do help many people here in the forum - so I am not only do write questions, I also try to give answers.

Hi,
 
Thank you for your interest, you won't be disappointed. You have probably read that the developer want to do some changes - and some of this changes are now ready to get tested in the BETA's of armbian.
 
Do not test with your 'production' SDcard unless you have done a backup ;-)
 
Once done that, please go to 'armbian-config' System  switch to BETA (Nightly), do an update/upgrade, reboot, check if your system still performs as before.
If it does work like before - please let us know and post your 'armbianmonitor -u' link If it doesn't work, please try a reboot, check if the problem is reproduceable and if so  explain the steps to reproduce it and post your 'armbianmonitor -u' link  
If you like to know what has changed or is changing:
Kernel upgrade for Allwinner boards. NEXT is 4.17.y and it's getting daily updates. (LIB_TAG="sunxi-4.18" in our build system)
https://forum.armbian.com/topic/7398-bsp-scripts-rfc/
https://forum.armbian.com/topic/5565-zram-vs-swap/
https://forum.armbian.com/topic/6444-varlog-file-fills-up-to-100-using-pihole/
 
This is not all, see details on GitHub look at the shell code - which makes this happen - more eyes less errors
 
And if you want to try a fresh install, look for the nightly created 17. June https://dl.armbian.com/
 
Thank you in advance for your support
 

censorship in the Name of a Kaiser is okay.
I see!!

Does this tool always verify burning results?
 
 
Does this tool always verify burning results?
 
 
Does this tool always verify burning results?
 
We had an awful lot of absolutely unnecessary support requests 2 years ago with users failing to burn images correctly (since SD cards were broken or card readers or whatever). When starting to only recommend Etcher this amount of absolutely unnecessary support requests declined drastically.
 
A burning tool that does no verify is a nightmare from a support point of view since unfortunately the average user doesn't get it that a lot of stuff can go wrong when burning SD cards. This problem is the whole reason why resin.io folks developed Etcher in the first place.
 
Recommending any burning tool that does NOT a verify the result by default is a really bad idea.

Sure, 'the Allwinner syndrome'. Once the SoC is EOL and can not be purchased any more the brave souls over at linux-sunxi finished mainline kernel support. Situation 3-4 years ago was different but today I really have no clue why to waste a single second on anything Allwinner that is not also cheap as hell (talking about the small OPi and NanoPi boards) or makes good use of Allwinner's battery support (PineBook, Olimex' Teres, Olimex Lime/Lime2 boards that use the battery to provide full 'UPS functionality' since also powering USB and SATA devices via step up converters)
 
Banana Pi M3 with its outdated 32-bit Cortex-A7 little cores and the totally unsupported PowerVR GPU is even more expensive than faster little.LITTLE designs like NanoPi Fire3 or even true big.LITTLE designs like ODROID XU4/HC1/HC2 (the latter also with an USB-to-SATA bridge but USB3 based and more than 25 times faster than the crappy GL830 on the M3).

1. Turning the slots (if left) is useful for the option if you put the Board vertically. The Board orientation option is vertically limited by the placement of the connectors on the short sides -> to put vertically (with support on one of the short sides) is unlikely.
2. In Odroid, the position of the fins is designed for the forced air flow (fan) option regardless of the position H1. Put H1 vertically (something to support the table was on the short side with connectors) with the movement of air along the ribs and the second option vertically, with support on the long side (vertical movement of heated air across the ribs). I don't know (it's hard to estimate the real size on the photo) how big these edges are, but according to the laws of physics, the higher the height of the edges, the more effect. By the way, I advise you to look at the cooling radiators for powerful sound amplifiers of good manufacturers, how they have ribs and what size they are on the back side of the amplifier.

This radiator will be inefficient. The main location of the Board \ radiator is horizontal and without a fan, with natural air circulation. Therefore, grooves, such depth and shape, along the long side, on the surface of the radiator is not needed. Such grooves will work only in the vertical position of the radiator (that the air would move along the grooves). But then it will be difficult to connect the cables to the connectors. If you make the radiator half the thickness (reduced by the height of the grooves) and with a smooth surface it will work better than this option and the cost will be half (less metal consumption and do not need to make slots in production). Or change the direction of the slots to 90 degrees (parallel to the short side). And do not varnish or paint the radiator surface.

There is no difference what kind of burn you get, from a solid surface or from a "striped".
If the calculations can surface temperature (of any size) more than 50-60 Degrees, in such cases, use a simple protection device - a grid (fence) with a large cell (by analogy, as using protection on the fans from falling on the blades).

Still being designed but photos attached. Big enough for you? @tkaiser 

I just discover one strange issue regarding video driver. My primary test monitor is 1280x1024 ... where desktop works fine, while 1080p or 4K desktop doesn't come up, text mode only. @jernej Is this a known problem?

This is exactly why there are people like us who dissect products and push them to their limits so that end users don't have to rely on marketing nor salesmen but on real numbers reliably measured by third party who don't have any interest in cheating.
 
Regarding your point about Tj and lifetime, you're totally right, and in general it's not a problem for people who overclock because if they want to get a bit more speed they won't keep the device for too long once it's obsolete.
Look at my build farm made out of MiQi boards (RK3288). The Rockchip kernel by default limits the frequency to 1.6 GHz (thus the Tinker board is likely limited to this as well). But the CPU is designed for 1.8. In the end, with a large enough heat sink and with throttling limits pushed further, it runs perfectly well at 2.0 GHz. For a build farm, this 25% frequency increase directly results in 25% lower build time. Do I care about the shortened lifetime ? Not at all. Even if a board dies, the remaining ones are faster together than all of them at stock frequency. And these boards will be rendered obsolete long before they die.
 
I remember a friend, when I was a kid, telling me about an Intel article explaining that their CPU's lifetime are halved for every 10 degrees Celsius above 80 or so, and based on this I shouldn't overclock my Cyrix 133 MHz CPU to 150. I replied "because you imagine that I expect to keep using that power-hungry Cyrix for 50 years? For me it's more important that my audio processing experimentation can run in real time than protecting my CPU and having to perform them offline".
 
However it's important that we are very clear about the fact that this has to be a choice. You definitely don't want companies to build products that will end up in sensitive domains and expected to run for over a decade using these unsafe limits. On the other hand, the experiments run by a few of us help figuring available margins and optimal heat dissipation, both of which play an important role in long term stability designs.

@Exellent Finally I had the time to do some tests with the eMMC and it looks like everything works pretty fine.
I changed the boot order of U-boot, so the priority is always the external sd card, then the USB stick and finally the eMMC, so even if the image is installed in embedded memory, it should be always possible to run newer images using an external sdcard. Still there is no rockusb nor fastboot, so it is wise to experiment only if you have access to the serial console.
I added a new image to the first post with "eMMC friendly" tag, if you want to give it a try. Just burn the image on a sdcard and then use armbian-config to install the system into the eMMC

The wakeup from power-off is indeed managed by the Cortex-M processor with some code loaded in the boot time.
This code can be modifier and is present in amlogic's u-boot source :
https://github.com/BayLibre/u-boot/blob/n-amlogic-openlinux-20170606/board/amlogic/gxl_p212_v1/firmware/scp_task/pwr_ctrl.c#L184
 
But, it's linked to the Amlogic kernel implementation, and supporting it with mainline linux will need some work.

Hi,
 
Thank you for your interest, you won't be disappointed. You have probably read that the developer want to do some changes - and some of this changes are now ready to get tested in the BETA's of armbian.
 
Do not test with your 'production' SDcard unless you have done a backup ;-)
 
Once done that, please go to 'armbian-config' System  switch to BETA (Nightly), do an update/upgrade, reboot, check if your system still performs as before.
If it does work like before - please let us know and post your 'armbianmonitor -u' link If it doesn't work, please try a reboot, check if the problem is reproduceable and if so  explain the steps to reproduce it and post your 'armbianmonitor -u' link  
If you like to know what has changed or is changing:
Kernel upgrade for Allwinner boards. NEXT is 4.17.y and it's getting daily updates. (LIB_TAG="sunxi-4.18" in our build system)
https://forum.armbian.com/topic/7398-bsp-scripts-rfc/
https://forum.armbian.com/topic/5565-zram-vs-swap/
https://forum.armbian.com/topic/6444-varlog-file-fills-up-to-100-using-pihole/
 
This is not all, see details on GitHub look at the shell code - which makes this happen - more eyes less errors
 
And if you want to try a fresh install, look for the nightly created 17. June https://dl.armbian.com/
 
Thank you in advance for your support
 

Thanks.
 
O.K. I will do few more tests with your changes and then merge in. It was tested well, but we all know how this goes.
 
Let's point out for more profound testing when changes reach beta repository. We need to make sure upgrading won't break, while for new images I am not worried that much.

One a bit radical idea, which crossed on my mind - do we actually need a swap file enabled by default?
 
In general, features of the old armhwinfo scripts weren't changed much while the change logic was hopefully met discussion above.