Tido

Just for the record:
the noise is actually a result of the mainline kernel powering down the audio subsystem when not in use. Disabling this as described in the below quoted post works also with my Banana Pi. With using a cable (as described above) the noise is gone, but still there is quite a loud "plop" when the audio-subsystem changes its power-state. Disabling the powering down of the audio subsystem removes also the "plop" - so I removed my cable.... and the "plop" :-)
Cheers, Bernie_O

Where did you spot those (at least here I don't find anything with 'hardware acceleration': https://dl.armbian.com/lamobo-r1/archive/)?
 
BTW: Aren't underpowering issues caused by a crappy board design and video stuff with an outdated legacy kernel (and the whole idea to run a graphics stack on a device used as a firewall or router!) really on topic in a thread dealing with mainline kernel and DSA?

Than let's find out how many useful feedback do we actually get? If usually made an image and test - almost don't use them, but I use repository.
 
Phase out process. Supported from me and S500 is the first on the list. I would only remove them from download section, where some note / link should be added - "deprecated / unsupported / .. or smth like that.
 
3rd point. Agree.

IMO this needs to be discussed separately, not in this (Banana Pi M2 Ultra) thread.

It's in the RK808 datasheet
You can set shutdown to 140c or 170C
You can set hot die to 85, 95, 105 or 115C
 
The RK808 driver can then read the shutdown status or the hot die status
http://rockchip.fr/RK808 datasheet V0.8.pdf

Scary update: BPi M2 Berry is on it's way: https://bananapi.gitbooks.io/bpi-m2-ultra-open-source-single-board-computer/content/bpi-m2-berry-hardware/bpi-m2-berry-hardware-spec.html
 
Most if not all support threads in their forum regarding Banana PI M2 Ultra are related to 'this just sucks': http://forum.banana-pi.org/c/Banana-pi-BPI-M2-Ultra
 
And instead of improving the software support situation or even answering to those many support questions or complaints those crazy 'engineers' decided to add to this mess shitty Micro USB for DC-IN to ensure that users will run into even more basic stability problems from now on: "BPI-M2 Berry power with Micro USB port (default)"
 
So they sell now a new board with RPi 3 dimensions using R40 and still SATA but no eMMC, IR and battery support any more. 4 USB receptacles means an internal USB hub (already curious whether they do it in the most stupid way as usual and as we can see on Banana Pi M3 already: not exposing one of the SoC's USB host ports and then connecting all USB receptacles through an internal hub to the remaining SoC's host port) and switching back to 'great' Micro USB will ensure that majority of users suffers from under-voltage and the usual symptoms (instability under load, maybe even boot/crash cycles. Amazing!).
 
Can we please stop adding such support nightmares like this to Armbian's build system?

And, if you are looking for a good power supply you go to IKEA - as usually

By accident I came across this brilliant review, if you start from the begin he explains about the short comings of PSU and if you start at 4min it is just about the IKEA PSU. At the very end you find his conclusion

Hi,
 
And welcome to the forum.
Most of your question are answered in here: https://docs.armbian.com/

Armbian installs cpufrequtils and minimum cpufreq is set to 600 MHz with RK3288 boards. That's the only reason why it never goes below this value a few seconds after booting. Anyone is able to change that (/etc/defaults/cpufrequtils) but you should check your expectations or let's better say feelings first (why do you want to lower this value, what do you expect from it, how fast does the used cpufreq governor increases cpufreq based on load if necessary -- lower min cpufreq can lead to much lower overall performance if other settings don't fit -- and you should try to understand the meaning of a so called WFI instruction since there shouldn't be that much difference idling at 600 MHz or 126 MHz)
 
TL;DR: Most probably there's nothing wrong with 600 MHz
 
Edit: Forgot that we're talking about Cortex A17 here: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0464f/CACJFAJC.html -- anyway unless one sets up a sufficient monitoring environment providing thermal and consumption numbers for both 126 MHz and 600 MHz and performance numbers for real world workloads (NOT full load benchmarks) staying at 600 MHz seems reasonable to me. If someone will spend some time on this checking through all available cpufreq governors with all available kernels is required to propose a change to Armbian's defaults  

You can install directly using armbian-config.
sudo armbian-config Last entry on the first menu "Softy"

 
And inside this menu mark "Syncthing"
 

 
* Sorry but the snapshots are partly in Spanish.

Sorry, I don't use any of the devices Armbian supports as 'Desktop replacement', I do not even remotely think of doing the stuff I do on my macOS machines on cheap ARM devices for $30 or less and can't comment on anything Audio related anyway (since I don't do Audio stuff and the few times I dealt with that on Linux it felt brain-dead)
 
https://github.com/armbian/build/blob/master/config/fex/beelinkx2.fex#L1082
 
Beelink X2 implements no voltage regulation (prone to overheating) therefore it's useless to quote stuff that applies to other devices only.

I'm in favor of leaving everything as is for now. This Etcher implementation is still in beta, we have enough issues and migrations to deal with, so jumping from one compression format to another IMO is not something urgent.

Unless it is confirmed by vendor that DVFS table can be safely extended for all boards, additional operating points should not be added to the shipped DT.
Official Armbian builds are not about providing overclocking with the risk of instability.

regulator.13 is vdd10_lcd, you want regulator.4, vdd_arm
 
 

@plasta-blaster instead watching oil cooling, how about this, then you know how to fix YOUR Device-Tree-Source. 
I read the document a year ago "Device Tree for Dummies!" http://www.ohwr.org/documents/435

Thank you for your help. i will double check the download and try what you have advised. i am sorry for any inaccuracies in my first post i was in a mad dash out the door before work.
 
thank you again i will let you know how this works

Uploading patch to fix reboot on Tinker board 4.4 kernel.  The miqi must not use vmmc or vqmmc supplies, or else it would also be affected.  The shutdown sequence turns the SD card off completely before reboot, and fails to reset to 3.3 volts from 1.8 (for high-speed cards)

we have not decided yet to change, @Igor does a good job keeping the kernel up-to-date. The one I pointed to will work, but may not be that current.
I'll give it a go at the weekend, for a headless install that might be sufficient.
Something else I noticed about "our" kernel: reboot does not work.
I solved the issue of the changing eth0 mac address with 2 patches for u-boot. I use mainline u-boot 2017.05-rc2
In case anyone is interested, one patch is rockchip: tinker: set ethaddr in late init and the other one i2c_eeprom: add read and write functions
 

Two excerpts from the FAQ document dated: 15. February 2017 - I guess no changes so far.
 
6.What type of hardware interfaces does the Tinker board have
Tinker board has 4 x USB 2.0 ports, 1 x GbE LAN, 1 x 3.5mm audio jack with 192K/24bit audio, MIPI DSI/CSI
 
28. Is sound supported through HDMI
Yes, the sound output can be worked from HDMI or the 192K/24bit audio jack.
 
Did you have any luck with rebooting by now ?
 

Tinker OS is the only distribution to use UART 1 as the communications port.  All others I've tried, including Armbian, use Uart 2, pins 32 and 33.  I have an FTDI Friend and a little pigtail harness I made for that purpose, I've been using it to debug since I became involved, see:
 

We can add a small question mark near the torrent likns which will open a pop-up with explanation about BitTorrent (similar to the one here) and a client recomendation.
By default I would prefer to keep the download pages as simpe as possible - we already have enough text and links there

10,000mAh. They have the full specifications published on the website...
 
 
Can it still operate from AC power if you unplug the battery? Or is this a single power supply device like most cellphones?
 
Edit: according to the schematics, you should be able to disconnect the battery and still have it powered, unless I'm misunderstanding the function of the AXP803?
 
The only reason I ask is because it's probably easier to unplug the battery and observe the power consumption from the wall than trying to measure between the battery and the main PCB.
 
Or maybe there is a sysfs entry for the current out of the battery?

I'll now use this thread here to take some notes where to look into for further improvements since I'll stop working on this for a few weeks (waiting for a 'NEO Plus 2' dev sample from FriendlyELEC):
The installation routine I wrote suffers from a bug. When running inside the chroot of our build system Postfix configuration fails due to: 'newaliases: fatal: inet_addr_local[getifaddrs]: getifaddrs: Address family not supported by protocol' (see Ubuntu bug 1531299). This will lead to Postfix and OMV unconfigured with has then to happen at firstrun which is bad. We need a fix or workaround found a workaround On 'official' OMV images (I checked the one for RPi 2/3) all OMV Extras are ready to be installed. With our build it takes some time to download them after booting first. We need a fix. Also 'Jessie backports' repo is missing. We need to investigate how we can prevent OMV from overwriting /etc/default/cpufrequtils since the settings Armbian uses are the result of intensive testing and both set on a 'per device' and 'per kernel base' (eg. we use 'interactive' with Allwinner legacy kernels but 'schedutil' or 'ondemand' with mainline kernel). As soon as one touches powermanagement settings in OMV this gets overwritten with 'conservative' which is a good choice on x86/x64 but not with most kernels we have to use on our ARM boards. Performance drops notably while there's no consumption savings Disks can be connected/disconnected to a NAS dynamically (think of USB disks/sticks) so it's worth a look to identify the device type (HDD or flash media based on /sys/block/*/queue/rotational) and then set /sys/block/*/queue/scheduler accordingly: We can use noop, deadline or cfq here and it needs some testing how they correlate with other NAS settings on weak ARM devices Memory constraints on boards with low memory especially using 64-bit CPU cores (thinking of NEO 2 and NEO Plus 2 here at the moment). It has to be evaluated whether these boards perform better with a 32-bit userland or not since a Gigabit equipped NAS with slow storage (again NEO 2) greatly benefit from RAM to be used as buffers when it's about writing to the NAS (for reads it makes almost no difference). See also https://github.com/igorpecovnik/lib/issues/645 Filesystems and transparent file compression: using btrfs with LZO compression is a great way to improve performance on NAS devices that have plenty of network bandwidth but are bottlenecked by storage (again: NEO 2: with mainline kernel though Etherner driver still being WiP we can already saturate Gigabit Ethernet but USB storage bottlenecks). Note: this will only help with compressable data so for the typical media center only storing data in already compressed file formats that won't improve that much. Haven't looked into how to tell OMV to use compression yet. Partitioning: Currently official OMV image for RPi contains a boot partition (not needed on non Raspberries) and a root partition of fixed size. The remaining space on SD card will then be resized to one partition useable for shares. We should implement the same. Limiting rootfs resize is easy since mechanism is already implemented: 'echo 6905856s >/root/.rootfs_resize' prior to first boot and then the remaining space can be partitioned later or automagically (when detecting kernel 4.4 or above as btrfs for example). We support at least one board with faster SD card implementation than USB (ASUS Tinkerboard) and it could also make some sense to use a large SD card for storage also (energy efficient and when storage is set up correctly connected disks can spin down pretty often) rootfs will be resized to only 4GB, what's missing is a routine that partitions the unused space. Later Making IO more snappy: the Linux kernel implements different I/O scheduling classes and priorities. The defaults are made for systems with many (even hundreds) concurrent users. The NAS use case we're talking here about is usually quite the opposite since most of the time only one single user will access the shares. Therefore letting NAS server tasks run with realtime instead of 'best-efforts' scheduling class makes a huge difference on small ARM boards while it doesn't hurt. A background daemon using 'ionice' can make a great difference (or even starting whole subsystems like Samba or Netatalk already with realtime scheduling class through ionice) Now some numbers: many people believe a Raspberry 2 or 3 would make up for a great small OMV NAS. Couldn't be more wrong since all Raspberries suffer horribly from lowest IO bandwidth seen on all SBC. The CPU has only a single USB2 connection to the outside all 4 USB ports and the Fast Ethernet implementation have to share. This sounds as bad as performance numbers look -- see below. You can't even fix this by using a Gigabit Ethernet dongle since 'shared USB2' is the bottleneck here and it gets even worse due to USB bus collisions 
 
Test setup is a Raspberry Pi 3 with updated OMV to most recent 3.0.69 version and Pine64+ with freshly 3.0.69 built from scratch (GbE equipped and with Armbian default settings). Test disk is a 'SAMSUNG MZ7TE128HMGR-00004' in a JMS567 enclosure (externally powered to prevent underpowering hassles -- both Raspberries and Pine64+ unfortunately use the horrible/crappy Micro USB connector responsible for all sorts of problems including shitty performance!). Network is Gigabit Ethernet capable and known to allow +940 Mbits/sec.
 
Pine64+ with 1 GbE settings (using a 300 MB testfile which fits perfectly in RAM -- this benchmark is not remotely testing 'disk' but only CPU and DRAM, so it's both a great example for 'benchmarking gone wrong' but also a nice way to test for some bottlenecks and use cases individually. Since the more RAM a NAS has this situation with data buffered in DRAM while waiting to be written on slow storage will happen more frequently --> overall write performance improves)

 
So now testing Pine64+ with 10 GbE settings (using a 3 GB testfile which has to be written to disk since it doesn't fit into 1GB RAM any more: we're now seeing IO bottlenecking the test and also that even if that's just USB2 we get some extra performance due to 'USB Attached SCSI' possible with those cheap Allwinner boards!)

 
Now testing with RPi 3 with Fast Ethernet and official OMV image (updated to latest versions including kernel): All numbers much worse but also as expected:

 
Now trying to help RPi 3 with Gigabit Ethernet: one of those great and also cheap RTL8153 Ethernet dongles. But performance still sucks as expected since the single USB2 port is the real bottleneck here (forget about 480Mbits/sec, in reality it's a lot less and collisions on the bus further decrease real-world throughput). And while read performance looks great this is just another 'benchmarking gone wrong' symptom since in this case data is read from memory and no disk access is involved. If I would repeat the test with 10 GbE settings then read performance would also drop drastically since then USB disk and USB network access would start to interfere and destroy performance totally. It's obvious that this make no sense at all since Raspberries suffer from IO/network bandwidth being too low for an ARM NAS.

 
 

Sorry for my late answer, but I didn't realized your question.
 
At the moment I use the standard interface file that just starts up eth0 with dhcp.  After boot I start my script manually.
 
In the last days I tried to contact the driver developer in order to get more information on the switch configuration, perhaps working examples, some explanations, ... but he was not interested to support me.