Tido

I think you meant "expect the user to read and not just mindlessly tick checkboxes that prevent them from posting their question"?

Ideally/must: we want to deal only with a problems that are a consequence of our actions. General Debian problems and help on users solutions have to be filtered out. I don't want to see them not even close to the bug tracker and TBH not even on a forum. At least not in any official areas. I am aware that many people have no idea whether issue is Armbian or generic Debian and sometimes I have to think as well. Only a few people jump straight to Debian bug tracker list while other simply expect a few people (they don't even ask that) that work on Armbian is going to fix all (their) (upstream) problems. 
 
Setting a clear line what can be considered an issue is a first problem we have to solve.
 

My biggest concerns goes here. Relation between people that want something and people that do something is extreme and even for lighter tasks, there is no interest to help: https://forum.armbian.com/staffapplications Having a bug tracker without additional help will only put more pressure on the usual suspect which means all this can can be one step forward and two back.

Let's try to figure out how to reinforce the crew.
 
 
If we limit who can open a ticket (groups: moderators, developers, angel) in a system as this https://invisioncommunity.com/files/file/9085-database-tickets/ a problem is almost solved. We only need people to solve those issues ...  

Like most things there needs to be a balance, and where there is a balance, few of anyone is truly pleased with the outcome because it means compromise.  The compromise is reduced with more active participation all around. 
 
Now, who is participating?  
 
-Vendors: Almost every vendor has some software team, or they pay for one.  They could spend more time making sure their hardware is well supported here directly, or indirectly upstream (Libre Computer does well here, if only Amlogic wasn't playing games with their firmware)
 
-Advanced Users: OMV-like special distros, products with special hardware where our build system would be advantageous, etc.
 
-Users: buy the board, try our software, ask for/provide help from/to others.  Very important for a project, a bit lacking here.  Of course the bulk of users come from the RPi train and, because they don't care to improve the hardware support, can talk to users all day.
 
Targeting a group in this requires time of its own, but honestly we need the feet on the ground.  It's a paradox, @tkaiser disagrees with the terminology of support, I agree to a point, but also, @tkaiser is adamant about refusing to add shitty boards because of support issues.  I think we are all in this boat, I love seeing what Armbian runs on, hate getting insane questions or dealing with SD card issues, but also don't want to say (or really see someone have the ultimate authority to say) "no, you get no help because we hate your board".  A prime example is the Tinker Board, which somehow has failed to create the support issue even I thought it would despite a respectable download number. 
 
For other issues that have been a gnawing problem:
 
Decouple the kernel updates from the image type.  That way if we move our "next" images to 4.19 from 4.14 is doesn't cause a meltdown.  I'm going to guess this is on the "very complicated" side, but I think boards should maintain kernel number with only patch level increases unless the user specifically chooses to change.  The tag "default, next, dev" would be the build recipe only, ideally.  We require the diagnostic output that gives you the kernel anyway.  (Tinker has to have 2 dtbs because of adding overlays, and mismatch between vender kernel dtb name and mainline). Odroid C2 can never have a kernel update for "default" because there is absolutely no way to properly migrate from 3.16 to 4.19+ .  Etc.

I guess this speaks for yourself...

here you find the overview:  https://linux-sunxi.org/Linux_mainlining_effort#Status_Matrix

Don't get me wrong, I'm not a fan of the current form implementation, but it's only the first iteration. Since "Technical support" section is mostly used as a bug tracker and we wouldn't be able to support a standalone bug tracker / task management system, adding data collection form to the forum is a step in the right direction.

Unfortunately "getting information" != "answering the same questions and requesting even the basic info again and again and again".
 
For example, threads like this one would have 1 reply with a simple answer - eMMC CSD checks for revision 8 were fixed more than a year ago. It took 5 posts to confirm that this is the culprit and it is still impossible to tell which kernel version (I mean kernel compilation date) is used due to missing dmesg from "armbianmonitor -u".
 
Funny thing is that this thread was created after the addition of the new information collection form, so we may as well make providing armbianmonitor -u output mandatory with 2 exceptions in dedicated subforums - devices without network connection and devices that failed to boot completely.
 
Applying your knowledge and experience while at the same time learning something new is fun, and it can happen when you are talking with a person who at least tries to understand what he is doing and who respects your time by trying to provide requested (and even more than requested) information.
Reading 90% of threads in the "Allwinner H2/H3" section made by people who expect performance and software quality of at least a $200 PC like a J5005 based NUC7 from a $20 board like Orange Pi PC is definitely not fun for me. YMMV.
Unfortunately supporting low end (by price) boards attracts their target audience aka people for whom even the Raspberry Pi is too expensive.

Technical support section is mainly a feedback to improve Armbian as operating system. We can only deal with Armbian images and our tweaks. That's plenty of work and we have to do something about that.

"If you deal with everything you fix nothing"
 
Common issues sections is already on the edge/outside since mainly contains generic Debian/Ubuntu problems, which we don't have intention nor resources to deal with. Armbian specific problems are already enough. I am seriously thinking to move it to less restricted "community" area, where only general restriction apply.
 
More topics in technical support could also mean developers are doing a lousy job in making Armbian. But since overall user base is growing and since we people are lazy by default (I also belong to that tribe), this section also grow. No forum around is happy on opening more topic for the same issue. Over and over again. Technical support questions are specific. They need to contain certain things or they are useless.
 

That was also intendenten. When you are putting a pressure and wasting precious time, you are making a damage and if you are aware of this, a progress was made. For all of us. It's like traffic regulations.
 

Yes, that's all about. All this is just yet another SPAM filter. One out of many that we already use.

Not  armbian,  of LINUX. 
The implementation of the PCI Express controller of H6 is broken, you find more information here and here.
(the above text is from Pine64 H6  https://www.armbian.com/pine-h64/ )
 
Well, at least it is powered via barrel jack == one problem less 

cnx-software-Link: https://www.cnx-software.com/2019/01/19/orange-pi-3-allwinner-h6-sbc/
 
Quote from cnx-software:
 
...but who want to use a OrangePi with a OrangePi-image?
The H6-support of armbian is very limited - so I wouldnt buy a H6-board now
 
Last year I did buy a NanoPi K1 Plus because the H5 is much better supported.
The H6 is also "only" a QuadCore A53 like the H5 - so only the newer Mali T720 GFX is the difference.
 
The OPi 3 H6 would be nice for the price if the complete hardware is supported by armbian
 
https://aliexpress.com/store/product/Orange-Pi-3-H6-1GB-LPDDR3-8GB-EMMC-Flash-Gigabyte-AP6256-Bluetooth5-0-4-USB3-0/
 
 
 
 

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.
 
 

armbianmonitor -u output is here http://ix.io/1ytO

It's baking in the oven... 

35C3 - MicroPython – Python for Microcontrollers  https://www.youtube.com/watch?v=xCPnOxWxHIc 
at min 5:30 you see also Adafruit, haven't seen it completely, but stumbled across it
 

I use "screen"  instead of  picocom. Have you ever tried this software?

As most of us were in the beginnings..
 
I don't guarantee but I think it's not that easy to fry something with a wrong devicetree.. It's a way easier with connecting random crap to the pin-header.
 
Since you want to get closer to group 1 let's give an example:
 
That's the original DT for the RockPi4b (4.4.x kernel) spoiler cause it just messes up to show the whole one for everyone (https://github.com/radxa/kernel/blob/release-4.4-rockpi4/arch/arm64/boot/dts/rockchip/rockpi-4b-linux.dts):
 
the first few lines after comment tell us which other DT files are included here e.g. (rk3399.dtsi):
#include <dt-bindings/pwm/pwm.h> #include <dt-bindings/input/input.h> #include "rk3399.dtsi" #include "rk3399-linux.dtsi" #include "rk3399-opp.dtsi" basically just another 'layer' of describing hardware, since a lot of stuff is shared with all rk3399 based boards this stuff is usually described once there and the nodes are used again and again for every board.
 
The nodes after it describe the hardware and how it is connected (also partly software e.g. there are multiple UARTs available, a node has to tell the kernel which one should be used to output the debug console).
 
Now let's look at such a node:
fiq_debugger: fiq-debugger { compatible = "rockchip,fiq-debugger"; rockchip,serial-id = <2>; rockchip,signal-irq = <182>; rockchip,wake-irq = <0>; rockchip,irq-mode-enable = <1>; /* If enable uart uses irq instead of fiq */ rockchip,baudrate = <1500000>; /* Only 115200 and 1500000 */ pinctrl-names = "default"; pinctrl-0 = <&uart2c_xfer>; }; the compatible part is the first one which is interesting cause it gives you some hints where you get further information. (https://github.com/radxa/kernel/blob/release-4.4-rockpi4/Documentation/devicetree/bindings/serial/rockchip_fiq_debugger.txt)
From there you get most of the information out what this node does and how it can be configured.. E.g. for the fiq node, it could be worth to set baudrate to 115200 cause this is the common baudrate for all SBCs (except rockchips which often favor higher baudrates for whatever reasons ). So obviously when you connect an USB-UART you've to set it to 1500000 not the default 115200 (keep in mind, if it's patched in the kernel, it should also be patched in u-boot, otherwise things get messy).
 
That's just a short introduction and you've to read a lot of stuff until all this stuff makes sense. Maybe I write something about the buildsystem tomorrow.

@TonyMac32I found a regression, can you test this fix ? https://github.com/superna9999/linux/commit/b9edb9c9eec654ba57f8da7966e4b1b81a6d7c7b

Wait, what? Not much faster? If you say at burning energy during operation, I agree; otherwise, I think every benchmark on the planet is against you. I have 2 Pi3's, I can't use them because they are slower than very nearly every other board I possess, they collect dust. My Pi2 serves to play music for me.

Sent from my Pixel using Tapatalk

Just did right now, thanks for the reminder

And also Terms of Use / Community guidelines should be linked somewhere in plain sight. Right now it can be accessed when registering, and even there it is not clearly shown as a link. IMO it should be on the top menu row as it is more important than i.e. Privacy policy that exists mostly for legal reasons.
 
Edit: It's also on the bottom bar, but it will be hidden after you click "Accept", looks like by a specific cookie.
 
Edit 2: Now that I'm looking at those (Registration Terms specifically) - they should be a numbered list instead of a bullet list, and we should probably add a new rule "Try to stay on topic defined by the starting post or developer posts in the thread. Off-topic posts that derail the discussion may be hidden, moved or deleted."

Quick suggestion --- also add donate link  in plain site at top of forum....    

I was further along in the thread, and I impulsively decided to donate, and so I scrolled to top of forum and no link so i had to work for it ;P

That`s a joke. Learn to laugh
Don`t joke about C, that`s serious stuff. (again...)
Greetings

I've broken these things down (perhaps too far, but I will give a case for it, and we can all discuss), here are the overlays:
 
- ds1307
- i2c1
- i2c4
- spi0
- spi2
- spidev0
- spidev2
- uart1
- uart2
- w1-gpio
 
The DS1307 was simply pulled from ASUS as a simple test overlay while I was working through implementing the scripts.  it can be jettisoned for all I care.
 
These are all written with only the Tinker Board in mind, of course they are all SoC-centric other than the 1wire and ds1307
 
"Pi" ports:
 
- i2c1 is the "Pi" I2C channel.  Make it configurable in case you just want the GPIO
- i2c4 is the "Pi" ID I2C channel.  Make it configurable in case you just want the GPIO
- spi2 is the "Pi" SPI channel. Makes it configurable in case you want just the GPIO
- spidev2 enables the user space spidev driver with 2 chip selects for spi2
- uart1 is the "Pi" UART position. 
 
Tinker ports:
 
- spi0 is the "extra" spi channel on Tinker, on pins 11/13/15/29/31.  Disabled by default, it occupies the same pins as UART4  *Not Pi Compliant in location*
- spidev0 enables the user space spidev driver with 2 chip selects for spi0
- uart2 is the debug port for Tinker.
 
There are some interesting extra features exposed on some of the pins (PWM/etc) that I would like to experiment with, we'll see. 
 
I have pulled the spi out as an overlay separate from the peripheral attached to it, my thought is, there may be 2 unrelated devices tied into the board on each chipselect that the user has their own overlay for.  (So up to 4 devices on hardware SPI)

When I copy/pase links from AliExpress or eBay, I always shortening them manually to before the first "?" and check if link still relevant ...