Tido

I have split 2 major support issues into their own threads, Bluetooth and Reboot.  I have gotten Bluetooth working on nightly builds of the default kernel, you need to use rtk_hciattach on every boot (add it to startup).  Next/dev kernels are still a work in progress.

Unfortunately "Authentication token manipulation error" may also mean that users don't understand or don't even try to understand the password change prompt that requires entering the old password first.
For the filesystem errors, it may be possible to prevent the system on a read-only SD to boot up to the login prompt, but I'm not sure how useful it can be.

Forum and other guiding changes will start showing results in a month or more. I hope they will go into the direction we want. We are in discussing, going to implementation stage and our mind has to adjust to changes we set. If we set new rules, we will need time to adopt. For example - we won't try to convince people that they are wrong, but simply left them in their belief.
 

If you need to step into the mud you get dirty. Perhaps we should have more radical policy: if error is not possible to reproduce, case is closed (thread locked) on the spot.
 

No we don't and you already know what the problem is. Why bother?

I used to be a moderator on a big, >30000 members of which about 1500 active, satellite reception related forum in the Netherlands and we found out back then that it did work. Another modification we made was showing a reminder above the text box where the new topic was started... 
If the tag is just the SBC, and all SBC tags have the same color, the christmas tree might not be so bad...
 
Another suggestion; Would it be possible to create per forum a FAQ sticky post, where a lot of the current stickies are mentioned in...? So reduce the number of sticky posts..
 
On the support side it might be good to only support the last 2/3 releases of Armbian, and if somebody asks anything about an older release then they just get the advice to update to be able to get support...
 
Just a few random thoughts..

Would it be an option to introduce mandatory tags for the subjects?  I am thinking of creating a tag for each SBC which is allowed in the forum section, and possibly a "General" tag for issues with all SBCs...  This would maybe force the topic starter to think about the location of the post; if the tag is not available you are in the wrong section. On top of that it would make it a lot easier to filter / search the forum...

I can see where there's situations where a communication might need some formality.   To me that a pinned post or a locked post probably achieves that.    Coming from the spirit of @tkaisers concerns about censorship, and avoid policing presence... I would be adverse to encouraging people to qualify their posts as coming from a moderator.   
 
Moderation vs. Mediation ( at least my version of it )
 
The terminology of Moderator is kind of an unfortunate standard.   I really wish forum culture had "administrators" and "mediators."   We need Administrators/Moderators to  support the mechanics of the forum...  Help with maintaining hierarchy, fix stupid, etc--- but that authority during a problematic topic is where Mediation is needed not Moderation.
 
The spirit of a mediator is a neutral party that is there keep opposing parties moving, and not because of authority, but because of reputation.   Peacekeepers don't need badges.
 

I've been tracking this thread for a few days, and been trying to get caught up.
 
So lots of good ideas have been posted about things to do and improvements that can be made, however they do feel like solutions to problems that haven't clearly been defined.   It may be worth a moment to take a step back to make sure we're focusing on the right challenges.
 
I've gone through most of the posts and tried to identify the spirit of the problems they appear to be speaking to.    Here's what I identified....please share thoughts and other observations:
 
Forum Challenges that need improvement
* No defined censorship policy
* Eliminate spam posts (solved by having more moderators)
* Tutorials hard to find
* Poorly formatted / difficult to read posts
* General Forum Structure not intuitive
* Forum Structure unclear for supported vs unsupported hardware
* Need differentiation for type of development threads
* Home for reviews unclear
* Homes needed for off-topic / tertiary projects
* Need a way to minimize repeated questions and unproductive newbie questions
* No policy for abandoned single post threads (old thread, 0 replies)
* Heated discussions going too far into negative space
  lane

For those of you who are interested in using a OPI zero as a small IoT-Server. I have some hints to get it working. It's more or less a lmgtfy How To plus some arduino code to test if it works.
Hardware:
OrangePi 0 with Armbian 5.25 connected over lan to my router DHT11 Module on a Wemos D1 mini (a small cheap wlan MCU for ~3$ which can be programmed via the Arduino IDE) Installation:
First of all we install node-red on the OPI. Instead of rewrite how to do that again I just give you the link who to do that: Node-Red on armbian
Second we install Mosquitto as a mqtt broker. If I have it right in mind I followed this instructable (I'm not shure, it's more than 2 weeks ago and I didn't save the link then): Mosquitto
To represent the data of our DHT sensor-node graphically we install the node red dashboard module in: /usr/lib/node_modules/
with npm i node-red-dashboard
If everything goes right you should have access to node-red via browser on port 1880:
192.168.1.xx:1880
and to the UI of dashboard:
192.168.1.xx:1880/ui/
Setting up everything:
Now we're setting up the Wemos D1 mini. DHT11 wiring (DHT-->Wemos):
VCC -->3.3V 
Signal --> D4
GND -->GND
Some of the Wemos pins are capable for 5V (A0 definitly not!) but the DHT readings gets noisier when the device is powered through 5V (don't ask me why, I'm not en electronic engineer...)
For the testprogramm we need two libraries which can be installed via the arduino IDE lib manager (+ ESP8266WiFi.h which comes when adding the generic ESP8266 board via Boardmanager):
PubSubClient.h (PubSubClient by Nick O'Leary) DHT.h (DHT sensor library by Adafruit) And here comes the simplyfied code publishing to the mqtt broker:
The code is more or less a combination of the examples which comes with the PubSubClient & DHT libraries + throw away all the stuff that we don't need (I had also a version of code where the Wemos D1 mini subscribe to the mqtt broker and gets a timestamp injected from node-red which was then added to the published sensor data).
Humidity data is stored in the "hum" topic, temperature in "temp". Keep in mind that if you plan use more than one senor-node, you should name the topics properly (see: MQTT topics best practices for more information about proper topic nameing)
We can now generate our test-flow on the node-red webpage (See printscreen). Subscribe to the mqtt topics and publish it on the chart and gauge (more information about Dashboard can be found on: Node-Red & Dashboard). 
Powering the Wemos and deploy the created flow shoud show us the graphs on 192.168.1.xx:1880/ui/ (see picture)
To call me an IoT expert is like someone calling tkaiser a fan of micro USB powered SBCs. According to the MIT licence this HowTo  is provided "as is", without warranty etc.

I doesn't expect that it differs so much from a opi zero.. so usage of the forum search engine would help.
Search for mqtt
 

| __ )  __ _ _ __   __ _ _ __   __ _  |  _ \(_) |  _ \ / _` | '_ \ / _` | '_ \ / _` | | |_) | | | |_) | (_| | | | | (_| | | | | (_| | |  __/| | |____/ \__,_|_| |_|\__,_|_| |_|\__,_| |_|   |_| Welcome to ARMBIAN 5.31 stable Debian GNU/Linux 8 (jessie) 3.4.113-sun7i System load:   0.62 0.50 0.23   Up time:       3 min Memory usage:  12 % of 984MB Up and running within about 7 minutes.  On-screen when process is running: http://sprunge.us/ELKE.
Before and after, all function working without problem.
Have a look here: http://wiki.lemaker.org/LeMaker_Guitar:Debug_COM

No worries there... I only edit when it's some thing silly like those quote-within-quote-within-quote posts (which don't seem to happen here), or code formatting hasn't been used. Basically readability stuff, and I make it known that is why the edit was done.  And point taken, all hail the mighty Igor! 
 
@Igor When it's obvious human spam, do we temporal ban or just kick? Case in point: jessica951 Just want to ensure I toe the company line!

I'll bite. I did say I was willing to help out any way I can. If it means spam control, so be it!  And thanks for the link to the article... I'll have to ram that down the throat of another "moderator" that I know someday...

Launch --- Due in 149 Days (or when it is ready)
 
and please put that somewhere were we can see that, like here (it is already written just needs a link to the lines above) 
    Countdown instead of frozen numbers ?
 

Really R1 ?
I know TK smashes on it by every chance, but
- no one ever beside TK complained about the design problem (just some speed junkies how want to have real Gigabit)
- short cable and IKEA PowerSupply I still power mine via MicroUSB - works like a charm other can use battery adapter explained on sunxi.
- it runs an A20  which is better supported than any other (which is the greenest in the table H3, H5??    NOOOO  it is the A10 A20)
- nowhere you find this 'smart design' HDD attached on the board.
- Igor ran the forum on an A20
I have no clue, why it didn't turn on the network properly after the changes, but it always did in the past.
 
And you want to kick this board - beside me there are many who use it and willing to test. Btw, even a customer of TK is having an R1 running, unless he replace the HW.
The loudest is not necessarily right.
 

5.30 may have been impacted by a u-boot issue.  I have attempted to use 5.31 image on a Lamobo R1, and the ethernet device would detect, but not send traffic.  To test it, I downloaded the 5.25 image and ethernet worked perfectly immediately.  To determine if u-boot or something else was the problem, I proceeded to upgrade a single package at a time to determine which was stopping the ethernet from working.  I start by upgrading linux-image-next-sunxi and reboot.  Upon reboot, the ethernet device stopped working exactly as it did with the 5.31 image.
 
I'm currently in the process of downgrading the kernel on a 5.31 image to determine if it fixes the issue.  But that is taking a very long time.  I only seem to be able to get between 300 bytes and 3 Kilobytes per second from the apt.armbian.com server.  So I'll post in a couple of hours with my results.  If you would like an specific details about my setup, please let me know.  I'm relatively new to using armbian and any commands that might be required to get specific data.  However I am experienced in Linux.

In other words: You think this has to happen: 
I'm out for now. Or maybe I just missed 5.30 release discussion? Is there a(nother) private subforum where open issues and needed testing efforts were discussed before 'we' (or you?) decided to push the button and roll out just another update that bricked devices (servers without network connectivity any more can be considered bricked IMO)?

Ok, I'm now only answering to the question 'board support decision'. We support already too much boards, a lot has changed in 2016 and in 2017 again and we just ignore this until Armbian project will collapse.
 
Who decides whether a new board will be supported? Is it you? Is it 'us'? If the latter who are 'we'? Is it a random hardware vendor just shipping some dev samples and trusting in 'Armbian morons' doing his job for free?
 
We're acting like the latter today.
 
We work on boards for which ZERO Armbian use cases exist (Orange Pi Zero Plus 2 H5 or however this unbelievable f*cking stupid name is written exactly, at least it's absolutely STUPID to bring Armbian to this board since the only possible use case is 'Desktop Linux' since this board unfortunately has HDMI but just 512MB DRAM which is simply not enough for a 64-bit Linux running a Desktop environment, for H5 we've only mainline kernel since H5 BSP is such an INSANE crap so not even video acceleration will work here. It's STUPID to bring Armbian to this device but we do it).
 
We work on boards that are not even supported by the hardware vendor. For example this BPi M2 Ultra thing, those SinoVoip folks only provide incorrect information (see DRAM timings, they write 733MHz, use 648 MHz but the SoC's memory controller supported 576MHz maximum --> reference, reference, reference look at the 'Technische Daten' PDF there, those irresponsible morons advertise this board with CPU @ 1.5GHz, DRAM at 733 MHz, Mali GPU at 500 MHz while in reality all numbers are way lower. Do we want later 'bug reports' that tell us 'Great Banana Pi M2 Ultra is able to run at 1500 MHz, Armbian is broken since allows only 1200 MHz'?!), those morons as usual do not even care about schematics being correct ('In schematic you can see two uart2 ports.'), they never release schematics timely, they're known to send out defective developer samples and they're either too stupid or too ignorant to get that this is a real problem.
 
And what do we do? We ignore that and play morons happily working on bringing support to their boards so they are ensured their behaviour is totally OK and nothing needs to be changed. We behave like the greater morons than them since they succeed with their irresponsible behaviour since some community idiots are doing their job for free even if they actively hinder us all the time (incorrect information/schematics, defective board samples, no changelog for hardware changes).
 
That's the whole purpose of a 'board bring up' DISCUSSION (that was the Rock64 example). Weighing pros/cons, benefits for users and developers, documenting what's missing (eg. incorrect information/schematics -- maybe even the most stupid board maker will get the idea he has to improve in this area if all his boards are rejected for the same simple reason: him behaving like an irresponsible asshole)
 
Board bring up is fun, board support is boring but more important depending on how we look at the Armbian project (playground vs. providing a distro able to run serious stuff). We have to reduce the number of supported boards but instead we add more and more. Unless such discussions start all babbling is useless anyway (eg. whether to differentiate .playground boards from .wip boards that will at least get support eventually since we came to the conclusion that it's worth the efforts in the beginning).

Ok: how to define a process to decide whether we want to support a new device or not?
 
Current situation: a hardware vendor sends out dev samples worth 50 bucks and we waste our time worth tens of thousands of bucks on these devices without even starting a discussion whether it's worth the efforts or not. Or someone with commit rights simply adds a board since... no idea. That sucks.
 
Can we agree on a process like https://forum.armbian.com/index.php?/topic/4451-example-support-proposal-for-rock64/ and if not what are your ideas?
 
Current situation: We support way too much boards to deal with, we scare away potential contributors (IMO due to lack of clear communication and the feeling for 'externals' there's an 'inner circle' or something like that) and we always just talk and talk and talk but nothing happens. This also sucks.
 
Using Armbian and having to fear an 'apt upgrade' really sucks. There was a lot of babbling about what has to happen prior to releasing major releases ('team testers' and stuff) but... today we're on 5.30 for whatever reasons (maybe I just missed discussion, call for testers and announcement?)
 
If we're not able to test through all those boards we claim to support why do we provide upgrades that break the most important things? This is not the first time and if we don't start to think about why we update all the time without most basic testing more of these situations will follow. If we don't have the resources to test through every f*cking u-boot update every two months everywhere why do we roll out these updates? We have devices where u-boot is from 2013 or maybe even older and that's just fine. Using 'latest and greatest' without even testing is quite the opposite of the distros we put on top of this (horribly outdated AKA stable Debian variants). 
 
This is how I would sum up Armbian engagement today: https://github.com/armbian/build/issues/512#issuecomment-269476270
 
(sorry for this rant but I consider current situation extremely discouraging)
 

@tkaiser & anyone else -> text at download pages comes from here: https://github.com/armbian/documentation/commit/10c08d02fbd67c9cf79e0e7fe8ff4d0ee2da3b9e
 
Feel free to alter - updated auto in matter of minutes.

When "include beta and deprecated images" is checked, Why is my board not supported? link pop's out and that will be relinked to github or rendered here: https://www.armbian.com/unsupported/
 
That's really all for today. Have to do some barbecue

To elaborate on this only for now. My main concern is 'communicating clearly to end users what to expect'. On our download page only devices should be listed that receive 100% full support.
 
All other devices should be moved to completely separated 'Unsupported' page. The devices listed here fall into the following 3 categories:
 
'Phased out': support has been removed for documented reasons (applies to those A20 Orange Pis and the two S500 devices now). Latest OS images are still accessible but behind a nag screen where people have to accept that support requests are ignored and support threads even deleted without replying (at least they clicked 'I agree' once). 'Work in Progress': these are the boards we're currently working on but that are not ready, where every question 'why not worky?!' is just useless and a waste of time. Preliminary or even nightly OS images are accessible but behind a nag screen where people have to accept that support requests are ignored and support threads even deleted without replying (at least they clicked 'I agree' once, we should add the 'nightly' motd disclaimer to .wip boards too) 'Not supported': these are the boards people would think will be supported by Armbian (soon) but won't. This is the process of a short discussion in development forum which ends up in a file below https://github.com/armbian/documentation and a link to the initial thread. This page clearly documents the reasons why there's no support for the board (not worth the efforts since support nightmare due to crappy Micro USB, vendor not releasing complete schematic, only crappy BSP available and so on  
The last category is the most important one for me since it allows us to document decisions and maybe even to change vendor behaviour (providing schematics earlier, becoming more cooperative).
 
How do we do today? A hardware vendor sends out a bunch of dev samples and we start like brain damaged retards immediately to work on getting all these boards supported in Armbian even if it makes no sense at all. For example OPi Zero Plus H5. For Xunlong it makes no difference to feed the reel with H3 or H5 SoCs and to push out boards with a slight price difference all running a 32-bit Android they already have from Allwinner. For whatever reasons (desktop replacement the only possible on this design) people buy these boards. But running a 64-bit distro especially with X on this limited device is just stupid with only 512 MB DRAM. So at least three reasons against: Armbian support would be stupid, Micro USB and high expectations combined with unreliable powering create a support nightmare. No thanks.
 
Since while supporting such devices might be absolutely wrong but board bring up could be fun we could treat these devices simply as 'WiP forever'. They just remain on the unsupported page marked 'Work in Progress' so software can be improved, support requests happily ignored and once something changes we could rethink and move the board to supported section (BTW: Having download statistics from dl.armbian.com as well as torrent tracking would be great to help with decisions regarding user acceptance)
 
To me it's really important to list devices we'll most probably never support on a page just to document this clearly, list requirements (so vendors looking this up could improve eg. providing schematics earlier) and maybe even educate users (what to look for prior to an impulse buy). We'll soon get more H3 boards with H5 instead (since it's that easy to exchange the SoC) and I really don't see why we should automatically support them since software support for H3 and H5 is somewhat different and higher memory requirements of a 64-bit distro render use cases useless.
 
Also we face SBC customers who were tricked into believing they buy 'upgrades'. This applies to eg. 'Cubieboard 6' (Actions Semi S500 --> no way at least for now) or the so called 'BPi R2' many users believe would be just an enhanced R1 version eliminating the many design flaws of R1 and being somewhat compatible. But it's a whole different product using a new SoC from a manufacturer that started just recently to become somewhat open (MTK guys now even send patches upstream so maybe in 2018 we can talk about R2 again then running with mainline only). But R2 customers have not the slightest idea how crappy software situation for R1 was in the beginning and that unlike R1 they can't expect any improvements with R2 since there's no community around this time. This needs to be clearly documented so people might get actual results when doing a web search for 'bpi r2 armbian'.

What about just removing unsupported board(s) from forum description & closing new topics with "no more active support"? I don't expect much if any activity on those boards.
 
If no objections pops out, those four will get last update with 5.30 and will be moved our from armbian mainline support.

So I'm trying to add Bluetooth support for Tinkerboard devices and after searching for any "Bluetooth" related option in the kernel, I stumbled into CONFIG_RTLBTCOEXIST . So in addition to CONFIG_BT_HCI_UART , this option might be needed to use the BT Coexist functionalities of the Realtek 8723 BS devices.
 
However, it turns out that CONFIG_RTLBTCOEXIST cannot be enabled directly. If you search for the symbol in menuconfig , you won't see any configuration section referenced. So, in order to enable it, you need to enable its dependencies, which are :
 
CONFIG_NETDEVICES (Network device support)
CONFIG_WLAN (Wireless LAN)
CONFIG_WLAN_VENDOR_REALTEK (Realtek devices)
CONFIG_RTL_CARDS (Realtek rtlwifi family of devices)
And also one of these drivers :
CONFIG_RTL8723AE (Realtek RTL8723AE PCIe Wireless Network Adapter)
CONFIG_RTL8723BE (Realtek RTL8723BE PCIe Wireless Network Adapter)
CONFIG_RTL8192EE (Realtek RTL8192EE Wireless Network Adapter)
CONFIG_RTL8821AE (Realtek RTL8821AE/RTL8812AE Wireless Network Adapter)
Which depend on :
CONFIG_PCI (PCI support)
 
So, I've generated a configuration that integrate these requirements. If any Tinkerboarder could give it a shot and see if they, at least, get a hci0 interface, this would be great !
 
The configuration file is :
 
https://github.com/Miouyouyou/MyyQi/blob/master/boot/config-4.12.0-rc4-The-Twelve-MyyQi%2B
 
If you don't get anything, could you paste the dmesg content ?

Thanks tkaiser, I obviously didn't look around hard enough.  :-/
 
*update*
 
wifi firmware added, kernel config updated, and device tree patched.  Anyone using 4.12 should be able to happily use wifi.
 
4.11 may not be worth the effort due to it not having any driver support for the rtl8723bs.  You would have to patch in the driver/etc.

The first time I looked closely to the first picture.
 
This is a really brilliant move from ASUS, an exact copy of the connectors placing and size, combined with a real CPU, twice as much RAM.
If the camera and display connector even have the same ports - hallelujah   
Really neat, the colored GPI/O pins 
 
Brilliant - as long as Rockchip and ASUS send their code upstream.