Igor

And why do you hide information about your hardware and ask for help? Provide full logs with: armbianmonitor -u and hope that someone will see what is the problem. Bananian had two kernels, Armbian has three ... Edit: i havent notice before. Armbian-config way of setting AP sometimes doesn't succedd. In that case you are on your own. Like you were on Bananian. Manual way ...

You need to switch to the nightly repository and update the actual kernel. Kernal can be a default, dev or next branch.

Yes, it looks so. I already reverted back to 4.14.y few weeks ago https://github.com/armbian/build/blob/master/config/sources/cubox.conf#L20 and you can get it from beta repository or DIY.

Have you try this way? If it fails, you need to dig in into the hostapd config.

Current DVFS implementation and both kernels for H5 are still in development and therefore not receiving end user support. You will need to dig in on your own and find out why this was not lifted up yet. Perhaps higher frequencies can be enabled now, perhaps not. In any case, there is usually not worth to crank speed to advertised max values since you only get into overheating, throttling, lower stability ... Since support is expensive and nobody pays for it (we are developing Armbian extremely underpowered), we are forced to stay away from extreme situations. They result in unpredicted behavior and that is a support nightmare.

Thank you for your correction!

You mean such way? https://www.youtube.com/watch?v=6K9zJULoFpU On some kernels, we have to choose either serial either HDMI verbose output. Sometimes it can be done on both, sometimes HDMI is enabled too late and can't be changed or we have no idea how ... Remember hardware diversity. Even UART speed is not the same, but it's usually on "standard" RPi pins. If something is broken on a DEV board, you need at least a serial console. Other options are too limited.

General ARM kernel exists in some upstream distros but is mostly useless here and supports only basic features. Also, we could merge certain kernels today ... actually, we do merge them all the time, but most people don't notice since merging takes years to complete. Most of those cheap boards have no BIOS and you need to init hardware with u-boot or something similar. You need loader per board. For this reason, we need a different approach. Since most of the boards have one media for boot and system, there is no much need for classical Debian installer, but can and will probably be implemented once. One of the project's aims is to get a grip over ARM diversity and so far there are no known shortcuts and that's why so many great mainstream distribution struggle or rather not deal with anything else than RPi. In general, there is a big diversity among ARM hardware and it is much more complex than unified, standardized and boring x86 world. You can add Raspberry Pi to this group since its design is simple, outdated and already comes with fairly good support. You "only" need to play with userspace, while Linux ... is the kernel. Ask Torvalds which distro he prefers? Years to go. But Raspbian is also not Debian and will never be. A Debian which needs a FAT boot partition? BTW. Armbian desktop boots into the desktop without a password by default. You can switch to the regular display manager if you like and you can switch desktop from user mode to root with editing one config file. We use nodm display manager. https://packages.debian.org/jessie/misc/nodm ARM.bian philosophy: get the best possible kernel (usually and unfortunately that one doesn't come from the mainstream) and take most matured userspace. Don't complicate. When you start to ask yourself which distribution or which desktop (features) you want or like on your ARM hardware ... Stop and go back to the kernel. Only in x86 you can forget about the kernel since most of the distributions have the same, the one and only (kernel.org + perhaps minor distro related hacks). Compiling and mixing is easy. On our ARM boards, nothing from this is simple and easy. That's is another reason why our project exists. To bring complexity down to the earth.

The issue is you are not using Armbian. We don't support factory builds. Start here: https://www.armbian.com/nanopi-m1-plus/ and follow the documentation https://docs.armbian.com/User-Guide_Getting-Started/ and you will end up with a much better OS.

How do you define more Debian? What is missing, what is too much, what you can not do? BTW. I use Debian Stretch with Gnome3 on my Notebook, but my server runs Ubuntu Bionic with XFCE. Both with reasons. The same or similar situation is with most mainstream Linux distribution. You can grab "clean" Debian or whatever, but almost nothing will work as you already figured out. You literally jump back few years. Not worth to have supposable cleaner Debian with no support, which will changed only a little since it's a generic distro. Raspbian is Debian Stretch based with possible Wheezy compatibility hacks. I don't use it. I never did and don't plan to. Armbian is as clean as possible Jessie, Stretch and Stallmanised Ubuntu Xenial and Bionic.

Also on a DEV branch. Now check what I need to fix that next patch will not need editing.

Nope, no changes. Check if your script.bin is changed after running tools. Perhaps sunxi-tools package is somehow missing. Reported change tells nothing. We would know more if you used our tool for reporting: armbianmonitor -u

It is possible that this screen resolution is not well tuned -> someone with such troublesome monitor and knowledge would need to poke around here. We will ditch this kernel as soon as we get up video acceleration, MALI and sufficient stability with a modern kernel. How about this one, is it working ok? https://dl.armbian.com/orangepipcplus/Ubuntu_bionic_dev_nightly.7z

On update, old scrips are (should be) removed and replaced with new which are at the new location. Next step is to divide functions as @tkaiser and @zador.blood.stained proposed and clean up. It's too soon and things can be twisted around ... after it is merged into master branch.

https://github.com/armbian/build/commit/57d5ec2a952b49677af4b272f6c204fbd988b25d I hope this goes in the right direction?

Use drivers supplied with an armbian kernel (I could not find better ones) ... update your PC+ to nightly NEXT (or DEV) with kernel 4.14.y./4.17.y Drivers work perfectly fine with all my 8811, 8812, 8814 wifi adaptors and on any board that I tried.

I doubt that this will change the project from amateur to professional level or to make foundations to develop this board further. To illustrate the gap. Let's say we already make 500 or 1000 of working hours every month to make this project running. According to this only 15 minutes per month is awarded/covered with the end user donation (luckily there are few companies to cover at least few basic costs and most of the infrastructure), while we are getting daily requests for more and more and more and more and more of free extreme, demanding and long-term work ... here and on all private channels. People have absolutely no clue how much work is behind this free software and also think our resources are free and open for their wishes and personal problems Probably only a long-term advocacy can change this perception unlike any of your or our actions. Thanks and keep working on your videos!

... and hire people. https://www.google.com/search?q=hire+freelancers Free technical support applies to Armbian related stuff, stable releases only and comes as is.

HW support situation with this particular board is already very good and it was an investment, which will never be repaid in any form, to get to this level. If we want to resolve all remaining "small" issues and keep aligned with mainline development, we need to hire help. Last month whole project raised around 150 EUR of end-user donations ... which means we can't. Features work in the stock kernel, yes ... but having support in the modern kernel, aka mainlining, takes a lot of time even with sufficient, dedicated and well-paid people.

I have no interest nor resources to deal more with this board. https://docs.armbian.com/Process_Contribute/

You can install specific version this way: apt install linux-image-next-sunxi64=5.38 But first, check which are available: apt-cache policy linux-image-next-sunxi64 Why we have a regression here ... hard to say. I assume you have enabled UARTS in armbianEnv.txt ... in case you made changes to DTB, it is overwritten on upgrade.

This functionality is not yet arrived into the armbian-config stable package. Scripts are specifically designed for a modem which I have around (armbian-config will show you options to connect only if you have one of supported), for others init scripts, you need to look at @Stanislav Sinyagin blog. I sent you this link to peek into the code and DIY.

No need. We are sticking to LTS. I don't really pay a lot of attention to what is enabled for nightly ... changed to NEXT https://github.com/armbian/build/commit/8f47d7fab97f3a97da9af671365dc5d6dca64052

On Intel machine with SSD or on the same hardware with SD card? This would explain the diff. Rock64 has not a matured kernel support yet which means it can be anything while userspace is not much changed. We use upstream Debian base + few optimizations on the top which, I doubt, has anything to do with this.

Most likely above It is already hard to provide support for existing hardware or do any serious development. Majority of current engagement is sponsored by our private resources which means we probably can't expand this project further since it can become more fragile and could collapse. We actually need to step down a bit and from my personal perspective, I need to get few weeks off to recharge.