Werner

I keep forgetting we already move DEV branch to 4.20.y, but haven't tried H6 support yet. Porting to 4.19.y ... not sure if there is a point in that and if I want to get my hands dirty  

New features and restrictions for "Technical support" area:
 
 1. Validating users, those who just register are unable to reply to topics. They are forced to open a new topic.
 2. All users have to accept conditions (cookie last one day): 1. Call to use docs and search 2. Call to support us 3. Call to provide info
 3. Each time a topic is created, you need to add: armbianmonitor and accepty several conditions
 4. Auto lock topics is now set to 365 days, pinned and featured are exempt, ... and it will take a few days before locking will be completed. 

Agree. It's a step forward if there is a field ... it has to be optional and we have solved this problem.

I am torn about this. For various you may not be able to generate such a link. Like network issues (you still get the output but not the special link), I/O issues or boot issues.
 
 

I'm not a fan of this idea.. For sure it would reduce the support 'pressure'.. But I think it may also scare away the good people..
 
most of the support questions can be solved with google *fill in your preferred search engine*.. maybe we should encourage people more to use it.
tags could make sense.. e.g. in the sunxi.. where people must decide between H3/H5/H6 flag them with different colors and make H6 red..
this would simplify things a bit..
 
can we enforce an other input field where they've to post their armbianmonitor link? at least for those opening a thread.:D
 

Agree. This has to be used very carefully. If at all.
 

That's a good idea. I'll check if that is possible.

Most definitely...trying to do it over wifi could cause some REAALY bad lag

Level between development and stable is hard to define. To be more precise, IMO they match H3 levels which also have certain problems and shortcomings. Despite that, those boards can be used in production. Major problem in this sense is actually on the H3 side due to "power-off" problems.
 

Prefixes are supported by the forum software but we don't use them. They are only used here: https://forum.armbian.com/forum/26-research-guides-tutorials/ but also without any proper meanings since all subforum is anyway dedicated for Tutorials/Research. 

If this feature is not strictly used, it's pointless to have it there. And someone (which is not me ) would have to manually resolve prefixes for at least last two pages of topics.
 

Agree. In this sense it might be worth to think about merging "Armbian build framework" and redirect the rest to the "Technical support area" or "Peer to Peer" if it has nothing to do with Armbian.

Another option to limit pressure on support is by enforcing forum payment system. System is here, it's highly integrated in forum ... and it works. Not exactly to charge for support but to return a pressure back.

The questions which come up in the 'development' forum are anyway more like the average 'supportquestions' there's not much a difference... IMO development was never used the way it was supposed to be used..

could we 'switch' the behavior as well? E.g. default is mainline kernel and subforum is outdated 3.4 kernel which is only available for H3 anyway? Some kind force that people should move to mainline..

Forum enachements:
theme "armbian" updated with upstream version, manual fixes and adjustment with theme designer, fixed recycle bin, updated member map plugin added crowdfunding plugin (this will show supporters automagically) added "show new topic rules" plugin (currently enabled in recycle bin for test) added raffles and giveaway system (will be enabled for users when properly tested) Please report if you find any bugs in the forum theming

If one is running a DNS server for the LAN/WLAN - probably better to keep it on the wire

You can send a PR with your changes to the kernel config here: https://github.com/armbian/build

If you purchase one, they are so cheap, it will help a lot ...

All the information you can think of on an easy and simple webgui
https://github.com/netdata/netdata
 
Even has a really simple script to download all deps and compile the program for you
https://github.com/netdata/netdata#quick-start
 
Just thought you folks might be interested...if it's linux...this will work on it

Thanks. I saw the applied patches for testing.
I read your links and realized that it is customary to make changes in a separate branch and then pull request. 
Of course, first we need to discuss with the community the need to develop new functionality. I will do so in the future.
I'm currently laying out a number of patches that I think are the most important. Although it is not a tradition.
You can apply them on your own behalf, after testing, if you see them reasonable. I don't claim authorship.
Thank you for your understanding.

We, Armbian Devs, didn't found a way to fix that issue yet, so you will need another way to get ethernet, such as USB adaptor ...

Yes, I've just added NEXT to them : https://github.com/armbian/build/commit/c6e7f4fa4539d4aa1a9c9dc4b66a44a5619f4926
 

Share and we will take some  

I can share the fact that I've not resolved the H6 issue freezing at "starting kernel", I've even tried them with 5.0.0-rc1, still the same.
If someone can help narrow the issue, I will be glad ...

H6 can be created with NEXT now in as is state, but has to be enabled/added. If DEV is broken for some boards now ... that is not an issue.

after searching the internet we have to do it the blacklist way

for every module you doenst want to load create a file in /etc/modprobe.d with the name <modulname>.conf that will include the line
blacklist <modulname>
like that :
/etc/modprobe.d/xradio_wlan.conf : blacklist xradio_wlan  
If we do this for all 3 modules we get:
 
root@opi-zero(192.168.6.99):/etc/modprobe.d# cat xradio_wlan.conf mac80211.conf cfg80211.conf blacklist xradio_wlan blacklist mac80211 blacklist cfg80211 After a reboot the modules arent loaded anymore
root@opi-zero(192.168.6.99):~# lsmod Module Size Used by lz4hc 16384 4 lz4hc_compress 24576 1 lz4hc ftdi_sio 40960 0 sun8i_codec_analog 24576 1 sun4i_codec 32768 3 usbserial 24576 1 ftdi_sio snd_soc_core 118784 2 sun4i_codec,sun8i_codec_analog snd_pcm_dmaengine 16384 1 snd_soc_core snd_pcm 69632 2 snd_pcm_dmaengine,snd_soc_core zram 24576 5 snd_timer 24576 1 snd_pcm snd 45056 3 snd_timer,snd_soc_core,snd_pcm soundcore 16384 1 snd sun4i_gpadc_iio 16384 0 uio_pdrv_genirq 16384 0 uio 16384 1 uio_pdrv_genirq usb_f_acm 16384 1 u_serial 20480 3 usb_f_acm g_serial 16384 0 libcomposite 40960 2 g_serial,usb_f_acm ip_tables 20480 0 x_tables 20480 1 ip_tables pwrseq_simple 16384 1  
for reference:  KernelModuleBlacklisting
 
Howto: Create a file '/etc/modprobe.d/<modulename>.conf' containing 'blacklist <modulename>'. Run 'depmod -ae' as root Recreate your initrd with 'update-initramfs -u'  

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.