Werner

Very good!! it is working for me as well
 

I've received my OrangePi-RK3399 recently ...
Just for trials, before doing any real development, I gave a try with a NanoPC-T4 4.19.y image compiled a month ago, and it worked "as is", even eMMC and WiFi is running fine.
That it is a good starting point !
 
Of course, to be able to boot from SDCard, we need to short the eMMC clock using the test point TP50265 :
 

The reason for this seems to be a regression or a missing commit from @Icenowy sources (https://github.com/Icenowy/linux/commits/h6-integrate-2-ugly) which has not made the jump into mainline (yet).
Therefore you either have to use the 4.18.0-rc7 kernel image (which I run two OPi 1+ perfectly fine on right now) or temporarily disable dwmac like @martinayotte did as workaround to successfully boot up the board with a kernel built from newer sources (and use a USB-Ethernet adapter).
For confirmation you can utilize a UART serial adapter to check the kernel boot for errors like "sun8i_dwmac_probe+0x164/0x518".
 
As stated mainline support has still a long way to go to better support the H6 SoC. Do not just discard the board. Just put it on the shelf and it may run fine in a couple of month.

On my side, I kept my previous OPiOne+ build done with h6-integrate-2-ugly branch.
I didn't investigate further about Mainline 4.18.10 since Icenowy suggested to check with 4.19.y, but I didn't take the time to check ...
 

I've just started new build with 4.18.12, and when finished, I will disable the dwmac and check if it boot properly, I think it will.
This would mean that patches for dwmac added in 4.19.y would need to be backported, or we wait for 4.19, which can still take awhile ...

Armbian is mostly ahead of the upstream kernel releases in board specific functions. Up to about one year. Regarding the biggest group (Allwinner), the only change will be that we will remove a few patches  and when 4.19.y is sorted out it will become our NEXT for A10/A20/H3/H5/H6/A64 and Armada 3700, Rockchip, Meson, ... almost all supported board as a first or second kernel.
 

Thanks. It turned out two topics on one big question:
How to do better?
I will prepare an explanatory note and patch, or as you said:
I think then the two topics can be combined.

Do it as you think it's best and if it turns out that it isn't perfect, the PR can still be edited before it gets merged. I would link to those two threads when sending the PR, so that a reviewer know where it comes from.  

There are still (many)some (short and) long-term questions which are scattered on the forum and in our heads which we would need to discuss.
 
- release naming, 2018.10 or 18.04 + some RFC as shown on the pic,
- collecting wishes on a special web page or forum topic. When someone approaches with "I want to help" that it is appointed to 1. Check issues on GH, 2. Fixing sound ... 3. Creating this ...
- improving testing protocols, automating what is possible. I'm low on ideas what more is possible to do.
- what to add to »end of support«?
- secure project longterm survival, leverage maintenance costs to users or drastically limit down free support,
- enforce browser of choice for desktop images, Firefox and/or some lighter alternatives?
- fix Bluetooth on all Broadcom AP62xx devices. Its the same on most boards, but we have it working only on a Cubietruck IIRC
- sum most frequent problems under »The Ten Commandments« / FAQ and promote it as much as possible
 
- does forum need structure update?
- add/remove moderators? Disable rights if not moderating content in past 6months?
- enforce forum rules? Some very simple ones.
- users are still seeking for help without providing logs. What to do about?

Download UX:
- make a bigger diff between nightly and stable, desktop and CLI (Gorazd)
- add a warning when nightly is downloaded, (Gorazd)
- tested devices lead to their test page where exists instead of Amazon affiliate, (Gorazd)
- tested hardware have information to which kernel is attached to but not displayed, (Gorazd)
- check other download option still no visible enough, (Gorazd)
- add a support box with 1. Check common issues 2. Search for solution 3. Ask (with a link to the correct forum) (Gorazd)
- add a button »alternative builds« with a link to dl.armbian.com/DEVICE (Gorazd)
 
To keep things in place, I would like to ask @Tido and @chwe  to help keep this 2do list up2date according to with our decisions.

@martinayotte
 
Ok, new image is up and running:
 
AP6255 Wifi works, however somewhat flaky. Ping times are normal for Wifi, but when I type it takes some time to show the characters.
 
USB3 Ethernet is not being recognized in dmesg nor does it show up in lsusb
 
USB Wifi can scan, however it does not let me connect, complaining about a wrong WPA2 Password.
 
 
update:
just switched to the nightly built via armbian-config. Update to 4.18.11 went successful
USB Wifi works now, USB3 Ethernet still not recognized

Yes, that is planned, but we still have weeks - we also don't need to jump on v4.19.0 ... It's DEV kernel and the idea is that DEV becomes NEXT when the time is right. Which is even more distant. Since 4.19.y is the next LTS it will be worth to prepare it and port support from more recent versions. 4.19.y is for 2019

You're right ! My resulting build faced the same "oops" issue :

 
I don't know why since it was running fine using @Icenowy h6-integrate-2-ugly branch, but it crash here with 4.18.10, but not on the Lite2 (since it doesn't have ETH port).
 

It finished:
[ o.k. ] Writing U-boot bootloader [ /dev/loop0 ]
[ o.k. ] Done building [ /home/data/build/output/images/Armbian_5.61_Orangepilite2_Ubuntu_bionic_dev_4.18.10.img ]
[ o.k. ] Runtime [ 16 min ]
 
Too bad I have to go now Will report later

I'm not sure, my distro uses 4.19 and omitted 4.18.

I didn't rebuild my OPiOne+, it still on Icenowy's branch build done 4 week ago.
Let me start a build for that one too and I will report back ...
 

Because that branch is temporarily development branch with a purpose to develop a few things. We only have two choices here - switch to current 4.18.y, say goodbye to HDMI for a while and fix other things, wifi perhaps ... or wait until HDMI is not mainlined. Other options are too expensive.

I have to remind you that this board is under development and regressions are possible. Some are intended, some not.

Relevant swapping occurred. Still no idea why so I added monitoring of virtual memory settings few hours ago. I'll look into this within the next months but no high priority since there is detailed monitoring in sbc-bench we know exactly why numbers differ currently between Orange Pi One Plus (1 GB) and PineH64 (more than 1 GB).

EDIT: This is NOT about a (hidden) backdoor but just a local privileges escalation that affects one single 3.4 kernel variant for 2 Allwinner SoCs. In case you came here through lurid headlines please read this comment here first and help stop spreading further BS like "all Allwinner devices contain a hidden backdoor" -- the code has been found since Allwinner could be convinced to open their Github repos in the past so everyone is able to audit their Android kernel source!
 
 
 
It has been brought to our attention two days ago on 2016-04-30 in linux-sunxi IRC that Allwinner's 3.4 legacy kernel for H3/A83T/H8 contains a nasty local privileges escalation. Any process running with any UID can become root easily by simply doing this:
echo "rootmydevice" > /proc/sunxi_debug/sunxi_debug Combined with networked services that might allow access to /proc this means that this is also a network enabled root exploit. As usual we fixed such an issue within a few hours, on May 1st new Armbian 5.10 images were rolled out and in the meantime the fix is also in Armbian's apt repo so please upgrade now (apt-get update/upgrade or start with a fresh OS image) if you're affected! If you're already running Armbian 5.10 then this vulnerability is already fixed.
 
This security flaw is currently present in every OS image for H3, A83T or H8 devices that rely on Kernel 3.4: this applies to all OS images available for Orange Pis (except Armbian 5.10 available since May 1st), any for FriendlyARM's NanoPi M1, SinoVoip's M2+ and M3, Cuebietech's Cubietruck + and Linksprite's pcDuino8 Uno
 
We informed all vendors where possible also two days ago (FriendlyARM and SinoVoip took notice, the others still ignore the issue) FriendlyARM: https://github.com/friendlyarm/h3_lichee/issues/1 SinoVoip M3: https://github.com/BPI-SINOVOIP/BPI-M3-bsp/issues/10 SinoVoip M2+: https://github.com/BPI-SINOVOIP/BPI-M2P-bsp/issues/1 Cubietruck +: https://github.com/cubieboard/Cubietruck_Plus-kernel-source/issues/2 LinkSprite pcDuino8 Uno: https://github.com/pcduino/pcduino8-uno-kernel/issues/3 Users of any of the available OS images for H3 based Orange Pis are somewhat lost since none of the OS images or kernels used for these are maintained any longer. Loboris disappeared (so the opened issue is more like a reference) and Xunlong themselves do not maintain their software at all (not even possible to open an issue there).   In case some readers here do also have accounts at Orange Pi forums, please spread the word and inform the users that their OS images are exploitable unless they already use Armbian 5.10. Same applies to Banana Pi forums, please spread the word there also that all M3 and their M2+ OS images are affected (I deleted my account there since talking to @sinovoip is like talking to a wall and just makes me sick, but it might be worth the efforts to try to warn their users)

Quick summary:
unfortunately all the time throttling happened so results are not comparable other than expected with vm.swappiness=1 less swap activity happened compared to vm.swappiness=0 (while 'everyone on the Internet' will tell you the opposite): vm.swappiness=0 Compression: 2302,2234,2283 Decompression: 5486,5483,5490 Total: 3894,3858,3887 Write: 1168700 Read: 1337688 vm.swappiness=1 Compression: 2338,2260,2261 Decompression: 5506,5480,5512 Total: 3922,3870,3887 Write: 1138240 Read: 941548 vm.swappiness=60 Compression: 2266,2199,2204 Decompression: 5512,5495,5461 Total: 3889,3847,3832 Write: 1385560 Read: 1584220 vm.swappiness=100 Compression: 2261,2190,2200 Decompression: 5421,5485,5436 Total: 3841,3837,3818 Write: 1400808 Read: 1601404  
Still no idea why with with Orange Pi Plus and 1 GB RAM massive swapping occurs while the same benchmark on NanoPi Fire3 also with 1 GB results in low swapping attempts (different kernels, maybe different contents of /proc/sys/vm/*)

Sure thing.  I'll catch up later.

Haha, but now I know. I was an idiot before since it's simply zram/swap as can be easily seen by comparing iostat output from before and after:
before: zram1 0.93 3.69 0.01 1176 4 zram2 0.93 3.69 0.01 1176 4 zram3 0.93 3.69 0.01 1176 4 zram4 0.93 3.69 0.01 1176 4 after: zram1 588.13 1101.08 1251.45 1408792 1601184 zram2 586.62 1094.84 1251.62 1400808 1601404 zram3 582.01 1087.59 1240.44 1391524 1587092 zram4 587.14 1098.00 1250.54 1404848 1600016 That's 5.3GB read and 6.1GB written on the zram devices. I still have no idea why this benchmark on some boards (most probably kernels) runs with 1 GB without swapping but not on others like here:
RAM size: 994 MB, # CPU hardware threads: 4 RAM usage: 882 MB, # Benchmark threads: 4 NanoPi Fire3 also with just 1 GB RAM finishes with only minimal swapping:
RAM size: 990 MB, # CPU hardware threads: 8 RAM usage: 901 MB, # Benchmark threads: 8 Maybe vm.swappiness is the culprit. Can you repeat the bench another three times doing the following prior to each run:
sysctl -w vm.swappiness=0 sysctl -w vm.swappiness=1 sysctl -w vm.swappiness=60  

I'll try to bring it up in 4.19.y ... some basic support is getting mainlined and it will be less troublesome. I hope.

Exactly same numbers as PineH64 which is not that much of a surprise given same type of memory is used with same settings. Your 7-zip numbers seem to be lower but that's just some background activity trashing the benchmark as the monitoring reveals. If you see %sys and especially %iowait percentage in the monitoring output you know you need to repeat the benchmark and stop as many active processes as possible prior to benchmark execution:
System health while running 7-zip multi core benchmark: Time CPU load %cpu %sys %usr %nice %io %irq Temp 16:15:10: 1800MHz 5.63 23% 1% 18% 0% 3% 0% 25.0°C 16:15:31: 1800MHz 5.05 84% 1% 83% 0% 0% 0% 48.2°C 16:15:51: 1800MHz 4.77 86% 1% 84% 0% 0% 0% 43.1°C 16:16:31: 1800MHz 5.15 88% 15% 53% 0% 19% 0% 39.6°C 16:16:51: 1800MHz 4.94 80% 1% 78% 0% 0% 0% 42.7°C 16:17:11: 1800MHz 4.82 92% 1% 89% 0% 0% 0% 45.0°C 16:17:31: 1800MHz 4.64 87% 1% 85% 0% 0% 0% 41.9°C 16:17:52: 1800MHz 4.74 94% 16% 72% 0% 5% 0% 43.8°C 16:18:13: 1800MHz 4.69 81% 1% 80% 0% 0% 0% 48.6°C 16:18:33: 1800MHz 4.56 86% 1% 84% 0% 0% 0% 39.5°C 16:19:28: 1800MHz 6.93 84% 12% 38% 0% 34% 0% 31.2°C I bet unattended-upgrades was running in the background (you could check /var/log/dpkg.log)

Well, but that's what the extensive monitoring is for: to be able to throw results away quickly (no fire&forget benchmarking since only producing numbers without meaning).
 
The kernel reported high %sys and %io activity starting at the end of the single threaded 7-zip benchmark and that's the only reason your 7-zip numbers are lower than mine made on PineH64. Same H6, same type of memory, same u-boot, same kernel, same settings --> same performance.
 
IMO no more tests with improved cooling needed. The only remaining question is how good heat dissipation of both boards would be with otherwise identical environmental conditions (PineH64's PCB is rather huge and in both boards the copper ground plane is used as 'bottom heatsink' dissipating the heat away. But most probably PineH64 performs way better here with an appropriate heatsink due to larger PCB). But such a test is also pretty useless since results are somewhat predictable (larger PCB wins) and type of heatsink and whether there's some airflow around or not will be the more important factors. If heat dissipation problems are solved both boards will perform absolutely identical.

I hope I didn't miss anything.
https://github.com/armbian/build/commit/735a3679e2de12db555e17b0485f99f86a1d106a