tkaiser

Your lsusb output looks like USB DT overlays are missing...

You use nmtui[-connect] ONLY ONCE to activate a connection. Then NM stores a profile and will use this based on policies (eg. after reboot connecting to the wireless network defined in the respective profile -- if the profile contains the MAC address of the device you initiated the wifi connection the first time it will try to use this, if not then it will use any available wifi network device to connect. This works totally reliable). So there's no need to fiddle around with /etc/network/interfaces, there's no need to call nmtui multiple times (only if you want to edit profiles later), there's especially no need to fiddle around with ifup and other conflicting stuff! Remove everything you added to /etc/network/interfaces or in /etc/network/interfaces.d/ then remove every profile you defined below /etc/NetworkManager/system-connections/ then use nmtui-connect to join the wireless network and you're done. And as already said: If you want help you need to provide information ('armbianmonitor -u' and iwconfig output would be helpful too) This means you joined already a wireless network (success on network layer 2! Check with iwconfig), now you need to figure out why DHCP isn't working (and therefore DNS as well if you chose to use DNS server provided by DHCP server -- you could have configured something different with nmtui) but that problem is located in the network you joined or in a messed up nmtui config (so better delete existing profiles and the stuff below /etc/network, reboot and simply start with nmtui-connect again)

Yes, I think so. At least we know that either schematics are wrong or vendor's hardware description. So everything as expected and still no improvement. But it's not important anyway (at least for people doing their homework and some research about Banana compatibility to Raspberries first). Though still a bit curious why they did this change.

Are you aware that FriendlyELEC adjusts DRAM clockspeed in a proprietary way not compatible with upstream u-boot (also leading to wrong clockspeed commits in mainline u-boot as a 'nice' side effect)?

And which is the default and how can be switched between (PL01 it seems?).

Can you help me interpreting voltage regulation on this board? With its only compatible Banana sibling M2+ the schema (still) looks like this: It's labeled as 1.2V (which is wrong of course since @Tido measured and asked and according to some forum post they eventually confirmed that it's 1.3V on production batches and another one of their employees even explained how to fix the developer samples using 1.4V) Now it looks like this: According to their hardware description PMIC type is 0 (no voltage regulation), schematic lists the usual SY8113B suitable to switch between two or even 4 voltages. So what happens here? Is VDD_CPUX adjustable and if yes which voltages are used? According to their fex file 1200 MHz cpufreq are allowed (which would be an indication that VDD_CPUX must be at least 1.3V) but then I found weird stuff like this.

https://docs.armbian.com/User-Guide_Allwinner_overlays/

Driver and firmware are two different things. With ROCK64/RK3328 we currently use a 'vendor kernel' and Rockchip added a bunch of Wi-Fi drivers to their kernel sources. Part of Armbian images is an installed package 'armbian-firmware' which should at least address onboard adapters and most common dongles. So all that should be needed is nmtui-connect, done. No need to fiddle around with interfaces files and names. There's a reason we recommend using nmtui-connect (since usually 'just works') but I have no idea how to improve the current situation that users don't read/follow this documentation...

Why? Interface names don't matter and the new 'predictable names' are an improvement anyway compared to before. Why? According to this thread armbian-firmware 'was installed', according to dmesg driver+firmware load (the 'module is from the staging directory, the quality is unknown, you have been warned' can be ignored, just search the web for it, it's pretty common for those types of drivers) so next step is 'nmtui-connect'. And if that doesn't work 'armbianmonitor -u' again. I don't understand the whole thread since most probably following the documentation would simply work. Though what needs discussion is why people don't follow/find the documentation.

No, since it's necessary to... Depending on the board you use and what you want to achieve different adjustments are needed before you execute the following two lines and power off the board prior to cloning: systemctl enable firstrun systemctl enable resize2fs

What about using dtc (package device-tree-compiler)? Different count of USB ports is most probably related to usb0 (OTG) not enabled by Armbian while FriendlyELEC's 4.11 kernel added the necessary patches and DT bits)

As expected -- thanks for confirming. But I think I already learnt my lesson back in 2015 to not try to use ever again a HDMI attached display with exotic native resolution (if the device to attach to is not a Raspberry where it's easy to configure/use 1024x600 unlike almost everywhere else)

No, you've been told to provide 'armbianmonitor -u' output (which you refuse to do -- you actively hinder people trying to help you) and you have been told to not fiddle around with these files at all (there's a reason technical documentation has been written. To be read and not ignored)

Thanks for confirming. It's only the better heatsink that makes a difference. When you do a few hours some disk benchmarks (then the HDD starts to emit more heat and heats up the air inside the enclosure) the difference between with and w/o enclosure would be larger. IIRC when doing such an enclosure test the internal temperature was able to increase up to 7°C. But this really doesn't matter that much since the components are made for this and also HDDs don't have a problem with higher temperatures.

I ordered only a few times from Xunlong (late 2015, early 2016) and the stuff always arrived within 2 weeks. I dealt with a similar HDMI display years ago and had to figure out fbset settings myself back then: https://www.cnx-software.com/2017/09/15/7-lcd-display-with-hdmi-input-audio-output-launched-for-orange-pi-boards/#comment-546014 -- would be interesting whether the display provides correct EDID data so at least with mainline kernel and the new HDMI driver @jernej wrote there's a chance using the display's native resolution with some SBC.

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

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)

Honestly I really don't trust that much into those internal readouts anyway. But back on topic, you're talking about a case responsible for lower temperatures now. But isn't the main difference now that your NEO2 is wearing FriendlyELEC's heatsink while it had no heatsink before? In case that's different now I would be interested how temperatures look like without case. I just worked on providing clean and performant OMV images for ARM boards relying on Armbian's Debian Jessie flavour [1] since almost all available OMV images I found were more or less horrible (using shitty kernels and crappy settings). Settings matter a lot on those slow ARM boards, if you choose the wrong ones (or rely on distros that 'optimize'/'tune' only irrelevant stuff like DietPi for example) NAS performance might drop drastically. And I posted the links above for a reason: since it's easy to get which settings are important by studying the respective install scripts. [1] since when trying to install OMV on Ubuntu it can't work due to dependency mismatches -- that's why you find so many reports on the net of 'OMV does not work on Armbian' since people don't understand that it's either Debian or Ubuntu what they run.

How's that possible? I always thought air is an insulator? USB on headers not active by default is due to kernel maintainers wanting it that way. On our OMV images this gets changed by default: https://github.com/armbian/build/blob/fcd1ee15c38289f696ace5072c794d633d3c067c/config/templates/customize-image.sh.template#L159 (see there also for a few other performance tweaks that might be suitable for performant NAS operation, especially the smb.conf tweaks, I would strongly recommend to use latest softy script to install Samba or if you're using a Debian flavour maybe even OMV)

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 not since AFAIK the kernel RK's Android uses is a 3.10.$something while the Linux images rely on 4.4 or mainline. Of course you can fetch the various .dts for ROCK64 from ayufan's repos (3.10, 4.4 and 4.14) and compare to get a clue how to adopt stuff.

Still no news about OPi Plus 3 Plus (other than Xunlong is planning two more H6 boards) but the next H6 thing is just around the corner:

For this thread maybe but in other threads the numbers are even more off: https://forum.armbian.com/index.php?/topic/5250-improving-small-h2h3-board-performance-with-mainline-kernel/&do=findComment&comment=42050 Moral of the story: Seems to be numbers without meaning and there's something seriously wrong with calibration of the thermal readouts. Not fixable since all the people only report internal readings but not how hot the SoC is in reality (using a good IR thermometer or at least touching the chip)

One of the Banana Pi employees took @zador.blood.stained's work, added a Windows GUI and extended SoC support from H3 only to A64, A83T and even H5: http://forum.banana-pi.org/t/the-3rd-party-emmc-flash-tool-for-bpi/4080

Thanks for confirming. It's exactly that attitude why moderators who want to delete posts should not be moderators.