pfeerick

I still have it, it's gotten so old it's actually a collectible by this point...

Well, if the under-powered hardware is the talking point, I used my TRS-80 model 100 portable as a linux terminal just to prove it could be done...

We are trying to keep the config balanced for different use cases (server, desktop, multimedia, IoT), and if a kernel option has a recommended value it would be best to use it.
config NO_HZ_IDLE bool "Idle dynticks system (tickless idle)" depends on !ARCH_USES_GETTIMEOFFSET && GENERIC_CLOCKEVENTS select NO_HZ_COMMON help This option enables a tickless idle system: timer interrupts will only trigger on an as-needed basis when the system is idle. This is usually interesting for energy saving. Most of the time you want to say Y here.  
Usually if there is a patch foir the mainline kernel, then somebody needs to maintain this patch, adopting to kernel changes, otherwise this patch will be thrown out if it doesn't apply cleanly or breaks the compilation.
 
The most reasonable solution in my opinion for this rather unusual use case would be to compile the kernel with required changes and patches, put the kernel packages on hold and forget about it unless you require a newer kernel for some reason.

Heh, I love looking at other people's workbenches, seeing all the cool toys and the minor oddities we all keep. Look, a pile of floppies and a torroidal transformer. My eye is drawn to the line of partly glimpsed objects at the top of the frame. My inner 5 year old would never have been able to resist the temptation to see what was in every box...
 
My own workbenches are just wildly embarrassing. I need to tidy. No, I need to excavate.

Oops! Well, can't please everyone. But it was better to have been done sooner than later, as if we left it for a month or so we're either be stuck with that thread as it was, or break a load more sites when it does get split. 
 
Edit: Alasdair just updated the link

Oops! Well, can't please everyone. But it was better to have been done sooner than later, as if we left it for a month or so we're either be stuck with that thread as it was, or break a load more sites when it does get split. 
 
Edit: Alasdair just updated the link

Since this thread is started, a lot of improvements are made to clean up the forum. Also a lot of cool ideas to avoid same questions again and again. I have one for the Getting Started guide. Here's the part of burnig the SD-Card:
Why don't we add one sentence about why we use Etcher to burn Armbian on a SD-Card? Something like: Compared to other burnig software like win32 etc. etcher validates the image after burning so that you don't run into SD-Card corruption. 
On the SD-Card part there is clearly writte what TK found out with all his tests, but the reason why someone should use etcher isn't that clear. It's obvious that not every one will read it, but most of the blogs I saw in the past, copy-past their sentences from docs to save time, and hopefully they'll 'spreading of the gospel' 
 
Thinking about 'The Ten Commandments' of armbian:
1. Use a reliable powersource
2. Burn your image with etcher
3. Tbd
Nobody calls into question the ten commandments, whereas a lot of people does this on armbians recommendations...  Ok, sounds like a religious armbian sect (time to go to bed  ). 
 
Edit: Just had to search to find my own thread about my IoT stuff that I'm doing.  I miss somehow a subforum where users can describe their projects. For sure they can write a tutorial, but it can inhibit the less experienced users to call it a tutorial (I would never call my thread a tutorial cause it started more or less as a link sharing of some stuff I found with google, as soon as I have more time & being sure that everything works fine, I'll rewrite it to make something that I would call a tutorial).

Well, we have to force (with nice words of course) to check at least 1,2,3 basic things. If they would do that in first place, huge amount of time would be saved. On both sides and we would be less stressed out.

The main idea is that, they do something, before seeking for attention. Basic checks and preparation  .... that not first question on support is: please provide logs, chech this ... but filing an issue looks like this: "here are logs, I checked this but the problem is still here ..."
 
I changed the title to some generic one. I hope it sounds better now  ... I am adjusting, unpinning and moving stuff, starting in A20 section. Let's wait if anyone else has any complains about this message, than we can enable this ... 
 

Yes, that's way better than my idea! And both 'armbianmonitor -c $HOME' as well as starting a 3 min cpuburn run should be accessible via armbian-config so mods/users can try to help other users reporting stability issues by simply asking them to follow a few simple steps (underpowering testing should be accompanied by some USB consumers added after each successful 'Armbian underpowering test' run)

I did some measurements on both PC (connected to a plastic case wall plug 5V2A rated voltage power supply, actual output voltage is 5.36V), and PC2's (connected to the SMPS mentioned above, actual voltage is 5.40V) from GPIO pins and USB cable ends under load (running stress command):
I get exact same 5.36V on bot GPIO pins and USB cable ends on PC I get regulated 5.23V on GPIO pins and 5.23V on USB cable ends on PC2 (5.40V->5.23V) As I use these SBC's for headless server use with no USB device attached to them, haven't encountered to any problem. But you may be right that 5.36V is dangerous for USB devices though.

It just fixes it barely enough to work without crashing (and fix is not related to the xradio driver, it's a kernel-wide fix)
 
My opinion here would be "definitely no", we had enough crap about this driver and none of that was fixed (packet losses, open AP connection, virtual interfaces, P2P mode, etc.)

This might work in case of a read-only rootfs (as a clear indication of 'something's wrong with SD card since if this happens already at the first boot there can be only one reason for it). Catching this type of error also allows from then on dealing with forum posts that talk about 'Authentication error' since then it's users not getting how to change root passwd.
 
The other problem -- underpowering -- we can not detect and provide a nice notification and some polite guidance since on the vast majority of boards we can not measure voltage/current. IMO it's way better to create a worst case scenarion already at first boot (starting cpuburn from firstrun task and do a 'pkill cpuburn' at the end of it) so boards that suffer from severe underpowering simply will never boot unless this problem is fixed. With boards using shitty DC-IN connectors it will look simply like this: a nice boot/crash cycle https://www.youtube.com/watch?v=y4EIhh0VT5g&feature=youtu.be&t=2m18s or just a freeze.
 
At least Armbian will refuse to boot on such a device so the user will not waste his time with an instable Armbian freezing/crashing later, then already adding more instabilities to rootfs gone corrupted so the user will not even be able to learn that once he fixed powering something improves since Armbian running off a corrupted rootfs will still crash/freeze or at least behave erratic/instable.
 
This won't work great in the beginning. But after some time this will be simply a measure of quick check. User will ask eg in Tinkerboard forum why he runs in instabilities and mods and other users will immediately recommend 'Burn Armbian with Etcher, if it does not boot you have a powering issue that needs to be resolved first'. Care to remember how much time and efforts it took to promote Etcher here and there? In the meantime it's getting recommended by many more people around and in 2018 no one will even think about using Win32DiskImager any more. But it takes some time, people even get angry about stubborn guys like me repeating that over and over again and there's always one who has to make the first step. 
 
 
That's good but again I see I couldn't make my point. It's about a PSYCHOLOGICAL ISSUE. Preventing users (especially the smart ones) running in a 'them vs me' situation since many people seem to be offended by that which prevents them thinking calmly about the real issue.
 
Collecting various user threads here and there that are short and understandable is something completely different than a forum post made by a moderator. Let's call it success stories: people who report weird failures, get Etcher / SD card recommendation, come back immediately with 'That made it!'. If we have at least 10 of them instead of lenghty explanations no one reads or wants to accept it's simply a pinned two liner like this 'Please be aware that crappy SD cards (example, example, example, example, example, example, example, example, example, example) and insufficient power supply (example, example, example, example, example, example, example, example, example, example) are reason N° 1 why things are failing' (example all the time just the link to such a success story).
 
Then it's not a 'them vs me' issue but turns into a 'me being part of the same community and learning from other's mistakes'.
 

Wasted a bit time over there so that link might qualify for 'success story' collection too. Re-opening original thread would be the better idea though.

Done. I had been avoiding this as I didn't want to edit the original post (in the new split thread) which was the only way I know of to contextualise the thread on this forum system. However, I've done that, and the new thread is here. I think I've pulled all the more board specific posts out, leaving this thread to focus on the proposal.
 
 

Thank you for confirming! In other words: you totally missed what's that all about. I was talking about current situation (everyone with commit rights to Armbian repo decides on his own when to start supporting a new board) and I proposed a change to that. A developer (not forum moderator) wanting to add support for a new board should requires him to 
outline the reasons why he wants to support a new board and which level of support he thinks the device deserves collects available resources so other devs save some time so they don't have to search the net first weighs pros/cons from both a developer and 'average Armbian user' perspective And the main reason to start with something like that is not to ease board bring up BUT EXACTLY THE OPPOSITE! Establish a process/protocol a dev has to follow that requires at least some thoughts why it's worth the efforts especially if we should decide that the board deserves full support status later. And you're asking for templates! You can't substitute the results of using your brain with templates (same with this boilerplate BS you're constantly recommending to me). It's all about understanding/consensus and nothing can be handled with templates (that's why I titled the ROCK64 thread with 'Example' since it could look like this if another dev wants to propose adding a new board but of course it can also look like this depending on the thoughts and what the purpose is)
 
You calling yourself the agile sprint type (the 'doer') most probably won't notice that running in the wrong direction isn't really smart (same with you having the ability to edit posts -- a person who doesn't even get why there is something written should really never ever edit stuff. Same with your personal reaction to this -- again a proof that you've not the slightest idea what's going on!)
 
For the others: We could have another 'SD card was the issue' result: https://organicmonkeymotion.wordpress.com/2017/06/25/setup-for-house-server/
 
And zero responses to 'preventing boards to boot when rootfs is read-only and executing cpuburn-a7 or cpuburn-a53 as part of firstrun crashing/freezing underpowered boards' reminds me why I consider this babbling here a waste of time.

Forum does look "cleaner"..
There will always be those who join and post without searching / reading, people...in general... are a lazy bunch, and those with a little tech knowledge, think ….
Hey we are “special” and any tech issue we are having can not be anything WE are doing / not doing wrong, so it must be the software / hardware..
Right, I mean come on I got X number of years this so I must be right.
 
You must FORCE us provide the info. needed to help us, get us to READ the docs and How to’s.
 
The more effort you make us put into solving our own problems... the more we learn.
 
Because I used cheap SD cards for weeks without issue, once a issue came up, I dismissed the SD as the possible problem because it had never been an issue before,
and I JUST KNEW it could not be...well you know what happened….wasted hours of time...time I do not have much of…
 
By not listening to the folks here.. who know what’s what’s….I broke one of my basic rules….
 
“You must learn from other people’s mistakes. You can’t possibly live long enough to make them all yourself.”
Sam Levenson
 

Sounds nice in principle, but I'm with Zador... Christmas tree clutter, and just makes things more confusing to newcomers, who are the ones who are the ones most likely to post stuff in the wrong place. Enough moderators who pay attention (duly slapped by Igor and Thomas) make this a relative non-issue. But please keep the suggestions coming!

IMO this would make the forum look like a christmas tree with different colored tags and still won't stop people from posting things not really related to Armbian or in wrong forum sections.

Keep it minimalist and keep in mind that wall of text is never / rarely read, especially not by those which we are addressing
 

Not very much familiar, have to study more, but we need more than only my point of view ... since its a forum plugin and very integrated, it should be simple to adopt and migrate. I notice it's one click job for making existing tutorials into this subsystem. Moderators will get another option: "Make this post tutorial".

@pfeerick
 
What about joining those two into one general notice /
https://forum.armbian.com/index.php?/topic/4571-power-supply-issues/
https://forum.armbian.com/index.php?/topic/4570-sd-card-issues/
announcement, which are present on the top of each topic and can be defined per groups and per forums. It's kind of repeating this over and over again. Probably more effective than pinned post?
 
Example:
https://forum.armbian.com/index.php?/topic/4465-nanopi-neo-internal-usb-seems-disabled/

What is way more important is to understand how the physical environment affects thermal readouts especially in the Pinebook. There PMIC and SoC are both attached with thermal pads to a metal plate. When the Pinebook charges, the PMIC gets very hot and transfers this heat over to the SoC, so SoC temperatures seem to increase for no reason and people are scared. In general it's the old story about data vs information. People love numbers (since easy to compare), love graphs (since nice looking) but don't like information (need to switch on the brain).
 
So what does monitoring provides? Data but no information. You need to have some knowledge to make use of it, in this case about PMIC+SoC placement.
 
This RPi-Monitor stuff is great for developing good settings (as we did last year for H3 and A64 devices, this year it was just a quick check if we can throw Allwinner's Pinebook settings away and replace with the way better Pine64 settings community developed last year) but once this is done it's not that useful anymore unless you want to experiement yourself (testing out different heatsinks or cooling solutions for an enclosure for example)
 
BTW: position of the CPU cores matters wrt temperature sensor: https://forum.armbian.com/index.php?/topic/1614-running-h3-boards-with-minimal-consumption/&do=findComment&comment=12525 (A64 is more or less a H3 with exchanged CPU cores and crippled USB)
 
 
 
This is not related to GPU/Mali400 (this Mali crap is useless with A64 anyway). Allwinner's video engine is doing this stuff, we can use HW accelerated video decoding on A64 since March 2016 (even if over in Pine64 land still some believe they need 'the Mali' for that), we were able to use hardware accelerated video encoding a few months later. Temperatures increase just by a few degree: https://forum.armbian.com/index.php?/topic/789-breaking-news-choosing-armbian-speeds-up-your-orange-pi-multiple-times/&do=findComment&comment=6005 (video engine in H3 and A64 is exactly the same, at the top of that thread you also find a nice example why Allwinner's defaults are so shitty and why it matters to replace them with community settings)
 

https://github.com/armbian/build/blob/master/scripts/armbianmonitor/templates/pine64_default.conf#L85-L101 (but useless anyway, this Mali400 bullshit is of no interest since there's no use case for Mali400 on this platform! But I guess it will take until 2018 until everyone over in Pine64 land will be cured from the stupid Mali hype so many are still suffering from)

Of course, not ...
 

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