Werner

Agree. Maybe things should not be pushed so hard. Not only there is (from gut feels) little effect on (to use @Tido's scheme for simplification) patch releases, it also increases the administration effort as @Igor noted.
What about this? Do not push out intermediate releases (like 20.08.4) UNLESS there are critical issues like board does not boot.
Everything else can most likely be pushed via apt kernel upgrade anyways and will be merged in the next 3-month-release as well.
If somebody wants a provided fix faster they have to build their own either image or kernel package from master or wait. No discussion.
 
my two cents.

For a common understanding..  semantic versioning   8.5.4 == MAJOR.MINOR.PATCH - for a programm, not a distribution. But, people really care which version they have and they want the latest an greatest - as we know from questions in the forum.
Ubuntu LTS on the other hand fixes stuff and after a period they release 20.04.1  that incorporates all the fixes. However, I guess your release cycle is too short.

From what I saw it was a direct commit to master without PR. Therefore nobody had to accept and merge it.

USBImager V1.0..4 is now 2 months old, but I today recommend by cnx-software:
https://www.cnx-software.com/2020/09/08/usbimager-a-lightweight-alternative-to-balenaetcher/
 
Filter out drives on the same disk as C:
https://gitlab.com/bztsrc/usbimager/-/commit/1775cdc628a3d28ce454c181952aa283334d0991

Congratulations. You are now a mortal once again.

so no more hiding for @TonyMac32 btw. didn't have @JMCC also mod rights? and speaking about mods, due to busy times I had to step back from the whole project for quite a while now... Things cleaned up a bit and I might find some time to do arm related linux stuff again but likely not as active as before and so I decided to only focus on stuff I enjoy and I'm interested in. honestly 'customer service' aka user complaining about random stuff doesn't work isn't something I enjoy anymore. So @Igor @Werner and @lanefu (or who ever is in charger for that now) feel free to revoke the mod status.

Actually from the schematic (http://wiki.friendlyarm.com/wiki/images/f/fd/Schematic_NanoPi-NEO-V1.4-1801-20180320.pdf), the NEO H3 has an MP2143DJ GPIO regulator, which supports switching betwen 1.1v/1.3v - the board DT is just missing the regulator entry.  This is why the default maximum CPU clock is too high; adding this regulator will correctly address this problem by default and will also allow the board to be overclocked (potentially to 1.3GHz) using the overclocking overlays.  I'll look at adding support for this in the DT.

The GPIO pins are very low current, 3-5 mA if I remember correctly. I don't think you'll damage the SoC, but it certainly won't drive a fan if my memory is correct.

Sent from my Pixel using Tapatalk

Default User/Password for a new flashed image on SDCard is
User: root
Initial Password: 1234
 
after that you have to enter a new root-password

There is not really "translation" between android dts to linux dts. Android could be considered a Linux distribution like Ubuntu or Debian.
What you are referring as "android" dts is nothing more than a device tree wrote for a very old Linux kernel (probably 3.10 or 3.14).
As long as things change during time, so the device tree specifications become more standardized and well-defined. Device trees for old kernels (3.10 is very old nowadyas) are very messy and generally harder to read and understand.
 
Device trees describe the hardware equipment of  your board. On the x86 world there is something which was used to be called Plug&Play in the early days: Plug&Play let the devices expose themselves to the operating system, which is able to discover and configure them properly without the user intervention. On ARM side this mechanism does not yet exists (to be precise, something exists, but is not available on SBCs), so to let the hardware being discovered you have to tell the operating system. The device tree does exactly this.
 
All the properties and nodes in the device tree are read back by the kernel and kernel drivers. The "compatible" property tells the kernel which driver needs to be loaded, the driver then reads the node properties to know the resources associated with the device (memory regions, registers, interrupts, dma channels, gpio pins, etc...) and its specific characteristics (for example the clock frequency, FIFO queues, etc...), so it can proceed to initialize and make the device available to the system.
 
Being aware of this and getting back to the original question, there is no magic translation tool, you have to do the hard job of reading the old device tree and translate into the new. Experience and documentation are fundamental (you can find the documentation on the device tree bindings shipped with every linux kernel in Documentation/devicetree/bindings directory). Intuition and general knowledge of how electronic devices work are very helpful for such task.
 
 

At the moment there are three different saved actions that kind of cover the same thing: Complain about missing data
I suggest to merge those to one standardized reply that covers missing data and armbianmonitor -u as well as tips.
Something like this (with a bit of additional formatting):
 
Will unhide and add this reply.

some people solve Sudoku, with zero output but train-their-brain. Others fix device tree and get training and output

It is no longer possible to add tags, either custom or pre-defined, to topics in all Bug Tracker forums and TV boxes. Existing tags are kept.
Prefixes have been adjusted and fixed in those forums to fit actual needs and reduce uncontrolled growth.

Ok

Sometimes the syntax of DTS changes (by upstream). That is why adjustments might be necessary.
Next is also drivers in the kernel change and therefore adjustments to the device tree might be necessary as well to fit the intersection with the kernel.

Fixed.

Or meanwhile better 20.04 (Focal)
You may run into some unsatisfying QEMU messages when building particular images with Bionic. Still supported though but might break someday. At the latest when it becomes EOL in three years
 
 
 

Yep, something like this.
Another reason to get rid of one of those 
 
Understand. But it seems to me it is kind a mixed at the moment because there was not much such "movement".

I searched and found solution.
After install fresh armbian, I added this to "/etc/network/interfaces"
 
auto wlan0
allow-hotplug wlan0
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
iface default inet static
    address 2.1.1.38
    netmask 255.255.255.0
    gateway 2.1.1.1
    dns-nameservers 168.126.63.1 168.126.63.2
wireless-mode Managed
wireless-power off
 

With the Armbian build script.
https://docs.armbian.com/Developer-Guide_Build-Preparation/
 
You'll need Ubuntu 18.04 for this in your vm.
 
Please do not put duplicate messages in the forum.

Another minor update.
Contact information has been updated. You can access and edit these information by clicking on your avatar at the very top right corner, click on Profile and then hit the Edit Profile button.
 

I also noticed that the subforums SD card and PSU issues and the garbage collector Board doesn't start are kind of redundant. Should those be merged too?

Hello there,
I'm trying to adapt the cron script to deluged and I came out with this
#!/bin/bash # # armbian torrents auto update # # download latest torrent pack TEMP_DIR=$(mktemp -d || exit 1) chmod 700 ${TEMP_DIR} trap "rm -rf \"${TEMP_DIR}\" ; exit 0" 0 1 2 3 15 wget -qO- -O ${TEMP_DIR}/armbian-torrents.zip https://dl.armbian.com/torrent/all-torrents.zip # test zip for corruption unzip -t ${TEMP_DIR}/armbian-torrents.zip >/dev/null 2>&1 [[ $? -ne 0 ]] && echo "Error in zip" && exit # extract zip unzip -o ${TEMP_DIR}/armbian-torrents.zip -d ${TEMP_DIR}/torrent-tmp >/dev/null 2>&1 # create list of current active torrents deluge-console 'info' | sed '1d; $d' > ${TEMP_DIR}/torrent-tmp/active.torrents # loop and add/update torrent files for f in ${TEMP_DIR}/torrent-tmp/*.torrent; do deluge-console "add ${f}" > /dev/null 2>&1 # remove added from the list pattern="${f//.torrent}"; pattern="${pattern##*/}"; sed -i "/$pattern/d" ${TEMP_DIR}/torrent-tmp/active.torrents done # remove old armbian torrents while read i; do [[ $i == *Armbian_* || $i == *gcc-linaro-* || $i == *tar.lz4 ]] && deluge-console "rm $(echo "$i" | awk '{print $1}';) --remove_data" done < ${TEMP_DIR}/torrent-tmp/active.torrents I'm not sure with the "active.torrents" part because i don't have transmission and i don't know how the informations from the "-l" are listed.
For now the adding part is working and the "active.torrents" file is written! 

Patch has been upstreamed and is available in 5.8.6. No changes for us but to remove the previously added patch.

Yes, one part of this patch is included in the v5.9 mainline upstream, so that particular part is rejected as it is already present.  This patch is a general patch for all builds (it is present in patch/misc), so it's a little more work to address - e.g., it's a matter of splitting the patch and doing a kernel version check during the build.  I simply haven't gotten around to addressing this yet in the build process (there's no impact because of this).