Igor

This method might not work at present images for download but it has been fixed. If you start with your own image, it should work.
 
BTW. There is a serial console via USB port. Just connect to your USB3(to make sure you get enough power) port and power the board.

https://invisioncommunity.com/forums/topic/439176-haze-42x-by-ips-themes/?do=findComment&comment=2751318

Updated images. https://www.armbian.com/nanopi-fire3
 
Thanks!

Updated images. https://www.armbian.com/nanopi-fire3
 
Thanks!

It is applied. Perhaps in some rare cases, even this adjustment might not be enough? And powering with microUSB ?

Random crashes are usually related to DRAM clocked too high. Your DRAM configuration might be below average quality and ... the second option is DVFS, which is also not done properly yet. Setting to fixed CPU speed might help. For first you need to recompile u-boot with lower DRAM speed, second, you need to adjust /etc/default/cpufrequtils

Try:
cd /usr/src/linux-headers-4.17.5-sunxi
make scripts
 
and repeat building.

after:
sudo apt-get install bison libbison-dev flex libfl-dev
 
make scripts
Sucsess!
 
orangepiplus2e:~/v4l2loopback$ make VERBOSE=1
Building v4l2-loopback driver...
make -C /lib/modules/`uname -r`/build M=/home/aaa/v4l2loopback modules
make[1]: Entering directory '/usr/src/linux-headers-4.17.5-sunxi'
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /home/aaa/v4l2loopback/v4l2loopback.mod.o
  LD [M]  /home/aaa/v4l2loopback/v4l2loopback.ko
make[1]: Leaving directory '/usr/src/linux-headers-4.17.5-sunxi'
 
Sucsess!
 
Thank you!!

Hello guys, firstly I want to apologize for creating a big post without taking proper care of my setup, I guess it was a power related issue at all. I`ve managed to boot all the images (current stables, and developers one).
I`m posting this from the Orange Pi Win Plus with the current desktop stable image (Armbian_5.41_Orangepiwin_Ubuntu_xenial_default_3.10.107_desktop.img) and it`s working great. I`ll do more testings and share my finds with you.
I`ll use the server version, but wanted to try the desktop image.
My problem was inside the power jack plug, it was someway loose inside and thus not offering proper contact with the central pin of jack (plus) off the board. The connection between the plug and the board was pretty fit so I didn`t thought that this would be the origin of my issue. I discovered this because I decided to power the board using some testing logic clamps I have laying around instead of the plug itself and then the board booted flawlessly with all the images and with all micro sd cards I have.
I thought the problem would be a bad solder joint on the plug itself, but in fact it was a problem inside the jack`s barrel. I crack it open to see what was going on and the metal connection inside the barrel was broken and barely making contact, it was only "working" because when I plugged it onto the board the pressure between the metal parts and the central pin of the board provided some contact. 
 
Thank you guys for the responses.     

I'm suspecting that this issue I'm facing is power related. When I get back home I'll do some testing and let you guys know about.

Thank you for the help.

Learning by doing...  Nobody starts as a 'perfect' contributor doing everything right from the beginning. Read through this:
and probably this one:
H6 boards have plenty of stuff to step in. Try to fix something and then start to send patches. If you struggle somewhere report what you've tried, where you failed and maybe someone can give you some hints to solve it and maybe not, in case 42 isn't a sufficient answer.   The great thing armbian provides is the build-script which everybody can use, not only @Igor when he provides Images for a *random board*. It saves you in the beginning a lot of headache cause you don't have to deal with patch creation, applying those patches and choose a proper compiler for your tests (you'll understand the scirpt better and better as soon as you start to use it).  

That is normal. Aptly 1.3.0 is broken on Bionic and I couldn't find any more elegant solution yet.

Thank you! I tried to follow the directions, it was just not the right directions. I created a Ubuntu 18.04 VirtualBox like you said, changed LIB_TAG to sunxi-4.18 and built and ran mainline 4.17 and touch screen, wifi, GPIO are working. I will test more.  So far all is good.
 
I really appreciate everyone's help.

Upgraded my Orange Pi One to the beta and it mostly seems to work as before, with a couple of issues:
 
[ 5.717969] x_tables: section 3 reloc 5 sym 'mutex_lock': relocation 10 out of range (0xbf80008c -> 0xc080faf9) [ 5.750496] systemd[1]: Failed to insert module 'ip_tables': Exec format error Some module loading failure caused by the module being loaded too far from the kernel code, not sure why this has started happening for me after the upgrade.
 
Also, the lack of working device tree overlay parameters makes the pps-gpio overlay unusable on this board, since the overlay's default pin PD14 isn't an interrupt pin and so pps-gpio fails to find the interrupt it needs. The underlying code works fine, there's just no way to use it without compiling a custom device tree overlay that uses a different pin (I chose PG9).  I also couldn't find a way to get armbian-add-overlay to work; there wasn't any obvious way to install kernel headers that included the device tree compiler it needs.
 
armbianmonitor log: http://ix.io/1gKB

Not exactly the best way  There could be some automated apt process with some purpose in the background. For example, we run index updates (apt update) every 21 days which means usually also at the first boot. This is getting some changes lately ... but on most images, it goes that way. 

The best tactic is to wait for a minute that index is updated, then proceed with apt get ...

apt update & upgrade will also do
https://github.com/armbian/upload/commit/553477df85dfdd33810d1536409d62bd3a4cb789
 
Thanks.

apt update & upgrade will also do
https://github.com/armbian/upload/commit/553477df85dfdd33810d1536409d62bd3a4cb789
 
Thanks.

Start with a last known working and switch kernel to NEXT if you want to follow ... but this information might be changed soon.

You will not get commit rights, so you will not be able to break anything  You can try to work on some features which were not be addressed and when you have a working solution, patch, you send it to Github as PR. I am just pointing you to the latest sources, that you will not deal with something that has already been solved.
 

It is true in both cases. On build script branch sunxi-4.18, NEXT was already moved to 4.17.y, while master branch have NEXT on 4.14.y and DEV on 4.17.y or 4.18RC ... it doesn't matter. Just read my post once again

Aha. I am working on an Allwinner patches cleanup. Perhaps you could join? 
https://github.com/armbian/build/tree/sunxi-4.18

I haven't try to build H6 images yet, but I think you need to enable NEXT in board configuration since we only have NEXT kernel, v. 4.17.y ... 4.18.y when it's ready. This whole part will be merged into master when current regressions are solved and when its tested well enough.

Hi:
    thanks a lot for your hint!!
    google "armbianEnv.txt" I learn a lot of things.
    BTW, I can use "extraargs" to add boot parameters now.
    thanks again for your kindly help.
 
 
  

We stopped to deal with this kernel (3.4.y) a long time ago and you will not find many people around that still do something about it. We fixed a ton of issues but it's impossible to fix them all with resources that are around. Fixes that were discovered are usually implemented. That's what our project essentially do.
 
Virtually all devs are working only on a modern kernel, (4.17.y ->), which will soon cover most of the functionality. Actually, when video/3D acceleration is working, these old kernel images are going to be trashed. We keep them solo for multimedia capabilities.
 
This is an old issue which is gone from my head so rather try to do some search for a possible solution.

What about starting with this: https://apt.armbian.com/pool/main/l/linux-source-4.4.120-default-rockchip/

Edit /etc/default/armbian-zram and disable it.

Please switch to nightly (armbian-config), update and repeat the tests. You should be running 4.17.4