TonyMac32

Interesting post, 4.20 is not supported, and I have a potato that I boot up periodically without issue, so perhaps this has to do with some additional hardware you have attached. 
 
You've been around long enough to know you need to provide an armbianmonitor -u link.

Funny place here...
 
All the RK3399 'benchmark' results collected so far were done with CONFIG_HZ=1000 (good for a responsive UI in Android and Linux, not so good for normal computing or server tasks) while everywhere around CONFIG_HZ=250 is the default. Is this affecting Blender or not? Anyone tested so far (latest ayufan images switched to CONFIG_HZ=250)? Anyone into Active Benchmarking instead of just firing up the next round of kitchen-sink benchmarks in fire-and-forget mode collecting more numbers without meaning? The challenge with 'overclocking' the N2 is not trottling but stability/reliability as can be easily seen with the cpuminer tests that are sufficient for reliability testing (see N2 notes here). The DVFS OPP are defined in a closed firmware BLOB and the whole thing happens on the Cortex-M3 inside S922X. N2 has no LPDDR4 but DDR4, memory performance depends not just on type of memory but on DRAM initialization (done with BLOBs on both RK3399 and S922X). TL Lim said Rockchip will provide a new BLOB to make use of faster LPDDR4 access on RockPro64 in 2018 but I don't know whether this has already happened or not Memory benchmark scores depend on stuff like dmc or CONFIG_HZ since how would you explain better memory performance when switching from CONFIG_HZ=1000 to CONFIG_HZ=250 on RK3399 (previously known as difference between RK's 4.4 kernel and mainline though it's just different CONFIG_HZ defaults). Same with executing a memory benchmark on a little vs. big core Memory bus width is different between S922X and RK3399 (32-bit vs. 64-bit) but whether this will result in faster execution depends on a lot of factors (application in question, DRAM initialization BLOB, kernel settings, kernel tunables, see dmc memory governor with RK3399, and so on)  
Added some updates to https://github.com/ThomasKaiser/Knowledge/blob/master/articles/Quick_Preview_of_ODROID-N2.md#updates

Agreed.  Which opens up a kernel question, so buckle up.  ;-)

There is a difficulty here, because we do not host the kernel sources.  Updates to kernel sources often break the configs/patchsets.  If you wish to continue an EOS board it would be recommended to clone the kernel, u-boot, and Armbian buildscript at the point of eos. 
 
  I agree money isn't the best discussion, I also see, however, a constant demand for professional-level support with no hint or interest of contribution of even time.  That is just as ugly, but hard to point to as easily.  
 
There is a reasonable technical answer with some supporting information:
 
- We have no requirement to support any board.  If it is not in our personal interest or benefit it simply won't happen.  I think some of the "regular devs" feel pressure and get frustrated that they can't satisfy the whims of the general public.
- We have too small of a team to deal with demands and general Linux questions.
- the code is all public and opensource, anyone can contribute/fork to do whatever they like board support wise.
 
My personal action in this has been that I don't answer any general questions I don't have an immediate answer for.  If no one else does either I can't help that.  I think it works out in the end.

It accepts 7.5V ~ 20V according to the specs, powering with a battery pack shouldn't be an issue
 
This range makes it perfect for automotive use, such as a CarPC.

I agree.  The 2B is the one I use when I have to, the 3A+ at least represents the SoC's physical reality.

Little follow-up:  I agree completely with @Larry Bank, the Nokia 5110 displays are terrible, the HX1230 is very nice.

Same SoC as Pi 3 clocked higher.
 
The only thing interesting at all, but not enough.
 
Same catastrophic design failure as every other Pi.  Useless "upgrade"
 
I could do this with any board I currently own, make a PoE board for it.  Not at all special.
 
Still goofy firmware nonsense.
 
Well thank God since it was garbage before.
 
Sadly the Pi 3 B+ brings nothing of interest to the table when it doesn't even match competing boards that have been released and available for months to years.  Until they move away from the current series of SoC's they won't be of interest.  And they won't do that because it would break their compatibility and destroy the only thing they have that is worth note: the homogenous community support situation.

Well, the USB hub isn't the end of the world, since it isn't the center of the system's modern connectivity like a Pi.  I'd take one if I could get it. 

@Tommy21 perhaps a snippet of the errors?  :-)

So, since RK started to create tags, I guess we can just use them and forget about the old problem of the default 4.4 kernel being a constant pain, right? It's also very comforting to see that they paid attention to our requests in that matter.

You should like my Wayland example, then :3
 
Anyway, I see that Ezecquiel Garcia is currently pushing patches to adapt the V4L2 patches from Ayaka, into something that works with V4L2 (and a few modifications) without the MPP layer in-between.
He pushed support for MPEG-2 decoding support... I'll see if he pushes support for H264 this week.
If not, I'll try to adapt Ayaka's patches.

Irrelevant.  If someone doesn't recognize the main contributors without such a tag already they'll be too dense to figure it out even with that extra help.  It's a tracking tool, far more effective than guessing.  The entire point is, if the board number is reduced to both vendors and users who give a damn, then we can focus more completely on the task at hand, the quality and consistency of the thing. 
 
Board hierarchy  would go like this:
 
Is a community member willing to "own" it? y/n
Does the vendor support it on their side? y/n
Does the vendor help Armbian in some way (either with the board or generally)? y/n
 
Ignore them, I've seen an uptick in the Amlogic and Rockchip forums of community helping each other.  Necessity is the mother of all invention.  See if it is a legit build system problem, if not, politely say "sorry I can't really help, that looks like a use-case issue" or something similar, and move on.  Or simply ignore it.  The problem I'm seeing develop here is 150% typical for engineering/software/technical sales types:  They expect the user to know too much, and get grouchy when they don't.  Asking questions is almost never done in malice, don't act as though it's a criminal act.  Someone saying they got ignored on the forums is infinitely better than someone saying "I asked a question on the Armbian forums and that Tido guy called me an idiot and said I was wasting his time" (example only, but you get the point). Rules are good, but ignoring unless you have the time is more effective.  Making people fill out a questionnaire before posting a question is also bad, but until now I hadn't seen enough of a reason to complain about it.  Ignore them.  It's honestly quite simple.  They get noisy toss the rules at them, and we live peacefully.  Any of us answering questions is entirely voluntary, including Igor.  Treat it as such.
 
That was my plan in any case.  I need one for my personal projects anyway.
 

Checked 4K playback (full screen) on TV boxes. The main cause of the brakes and stop playback 4K  - overheating. If run a 4K video in MPV or Gstreamer, within the first few tens of seconds the temperature rises to a critical 70 (this is the first stage of regulator) and the video begins to slow down and does not play smoothly. When reach the next level of adjustment 80, the video simply stops working. I added a fan and the temperature immediately dropped when playing 4K to 45-55. And all the video began to work smoothly during the entire playback period. By the way. there was a reason for the green bars when working in 4K mode on MX10-incorrect parameters in DTB. Now assembled a new version of Armbian 5.73 with new DTB (memory optimization and increased frequency to 1500). I run the system on MX10 with TV 4K, MPV gstreamer KODI - everything works on a full screen without interference.
 
By the way, it is very convenient to run "armbianmonitor-m" through the UART console (or SSH console) and see the temperature in real time with any playback program.

I would guess there are some similarities between the Allwinner method and the Amlogic one, both using a small mcu to handle the laundry and cooking.  ;-)  But, a look at the Amlogic kernel would be the most certain way to know

Agreed.
 
I think the logs are a good call,  if we have SoC sub forums in "community forums" we can allow more or less anything appropriate.

That's a separate issue, but it lies in the reality vs. what we would like to see be true.  The simple reality is you can't force people into line without draconian policy/rules/etc that will choke off the community in general.
 
Now, if it were possible, I would say, along some reorganization lines as Igor posted, that we have a "select your board" drop down requirements for the Support subforum, and if we can go even further, sort them appropriately by that tag.  Then it gets easier, we only have spammers posting in whatever the first board on that list is.  ;-)
 
 
Well, the forum is the part people see above ground, a lot of its issues relate to the roots, so it's bound to get complicated.  For example, WIP/CSC's having downloadable images on armbian.com results in user questions, which increases our support traffic for boards we obviously don't find interesting enough to support directly.
 
Ignoring them is somewhat effective, but like I said above, making a single part of the forum a "gated community" with curated/controlled input should make it so stuff like that can be ignored with a documented reason, without necessarily causing any collateral damage.  And of course keeping boards to a minimum or at least defining what the core boards are should help as well. 
 
My thoughts on this fall more into the perception and the actual scale of the project.  The act of imposing regulation and setting a bar is viewed as pretentious or exclusionary by the human psyche in general.  That's not necessarily a bad thing, however it's being introduced into a space that was previously open to admittedly "too free" of discussion.  Is it possible to sort posts automatically by tag and then by age?  At that point, a fully filled out questionnaire (with a check so that http://Idontfillout.form won't be accepted ;-) ) would receive a tag that puts it at the top of the non-pinned pile, and above anything that skipped a step.  That simple feedback of basically demoting the content instead of downright blocking it should passively take care of the issue, and if someone gets noisy a mod can point out their stuff is under all the properly filled threads because it wasn't done correctly.  I'd guess there'd have to be some sort of qualifier based on age for when that sorting stops, otherwise the first improperly filled out post would be on page 12 or some nonsense.
 
 

After fighting to get FFMPEG compiled, MPV compiled (with Debian putting ffmpeg includes inside /usr/include/arm-what-ever-arch-hf/ and /usr/include/arm-what-ever-arch-hf/ having priority over /usr/include !) and then patching MPV to get the OpenGL display working correctly (stop using eglGetDisplay when you can use eglGetPlatformDisplayEXT !), I got the same error as you had...
 
And then I realized that the error states that the buffer allocation failed...
 
So I tried as root and it led to RKMPP failing to get the right frames in time. And then it crashed... badly.
 
I'll retry with Gstreamer, since Rockchip seems to love gstreamer. And if that doesn't work, then the VPU is still in a shit state... But at least, they can communicate with it so I guess it's something...

Here the Lichee Pi Zero Dock that I got Ethernet port working that I will use
 
 
 
 

this fix my problem
https://github.com/mripard/sunxi-mali/blob/master/patches/0018-mali-support-building-against-4.20.patch

They manage OpenCV on github, so I think that would be great to continue there for Armbian. Jira is chock full of unnecessary complexity. We use it at work and you become a slave to the process instead of programming.  This is really the only method that really works http://programming-motherfucker.com

I see some structural challenges here.  One is a perceived hierarchy perhaps keeping some people from mentioning issues (to be honest we already have that problem, I've had small issues in images for months before someone pointed it out).  If we take this route, then the forum has to be as open as possible to general user complaints.  Restricting access results in a shrinking of community in general, it's a difficult position because in order to grow the community you have to allow "know-nothings" to ask questions and hopefully become "know-somethings".  We also need to find a good way to appeal to a more diverse user base, application wise. 
 
People like @Larry Bank and @sgjava have done some great work, but our willingness (and ability) to support ends with server-type environments (nothing wrong with this, but it is a *very* limited niche of people who can contribute to that specific task thing)
 
@JMCC is doing great work with media, if we can roll at least some of what he's doing into the build script it would be fantastic (I was thinking we should package his scripts as part of a board or family specific armbian-config menu)
 
So we have the groundwork for IoT and Multimedia applications, which will make our little Linux project more interesting for the general public, especially if we can make these things somewhat standard, we get more users.  from those users, some programmers/maintainers/mods/etc will show up.  The issue is the age old one of humanity:  Talent and interest are hard to find together. If the vendors are not willing to help, despite the value, then we need to move an insane number of people through the forums to snag ones that are able and willing to contribute.
 
I think we do need to approach the "slimming down" of our boards a bit more carefully.  This is something along the lines of @tkaiser's comments about this being a project for us, with our help to everyone else being a happy side-effect.  If we are not overwhelmed, we make better things, the community benefits.  If a high-level user wants their board supported badly enough, they will work to support it (Me with Tinker Board)  We need to add a "maintainers" list or something similar, this is for one simple reason:  boards with no maintainer need to be put on probation.  A stronger definition of individual roles (not in a leadership sense, just in a contribution sense) will help as well I think. 
If a board has no maintainers and no vendor support, it should be "CSC'd", with a list on the website with "looking for maintainers"  I would propose we not make images for those boards available on the download page, allow people to build them if they want.  That alone filters who would be asking questions.
 
So, for boards:
 
Each board entry should include 2 additional fields:
Maintained-by  (Member or members) Vendor-supported (Does the Vendor give Armbian anything more than just a couple boards?  I include technical support here) So Tinker Board and Le Potato would look like:
supported-by: tonymac32 vendor-supported: yes  (or we could make tiers, everything from boards on demand, technical support, direct code contribution, money)  
For Member-contrubtors:
 
boards hosting documentation etc So Igor (sorry if I massively under-represent:
 
Build Script Author (obviously multiple people can have each tag) Web Admin Build Hosting Family-Allwinner Family-Freescale Documenter etc I can expand on this later in a specific thread since it covers a wide topic matter.

I see some structural challenges here.  One is a perceived hierarchy perhaps keeping some people from mentioning issues (to be honest we already have that problem, I've had small issues in images for months before someone pointed it out).  If we take this route, then the forum has to be as open as possible to general user complaints.  Restricting access results in a shrinking of community in general, it's a difficult position because in order to grow the community you have to allow "know-nothings" to ask questions and hopefully become "know-somethings".  We also need to find a good way to appeal to a more diverse user base, application wise. 
 
People like @Larry Bank and @sgjava have done some great work, but our willingness (and ability) to support ends with server-type environments (nothing wrong with this, but it is a *very* limited niche of people who can contribute to that specific task thing)
 
@JMCC is doing great work with media, if we can roll at least some of what he's doing into the build script it would be fantastic (I was thinking we should package his scripts as part of a board or family specific armbian-config menu)
 
So we have the groundwork for IoT and Multimedia applications, which will make our little Linux project more interesting for the general public, especially if we can make these things somewhat standard, we get more users.  from those users, some programmers/maintainers/mods/etc will show up.  The issue is the age old one of humanity:  Talent and interest are hard to find together. If the vendors are not willing to help, despite the value, then we need to move an insane number of people through the forums to snag ones that are able and willing to contribute.
 
I think we do need to approach the "slimming down" of our boards a bit more carefully.  This is something along the lines of @tkaiser's comments about this being a project for us, with our help to everyone else being a happy side-effect.  If we are not overwhelmed, we make better things, the community benefits.  If a high-level user wants their board supported badly enough, they will work to support it (Me with Tinker Board)  We need to add a "maintainers" list or something similar, this is for one simple reason:  boards with no maintainer need to be put on probation.  A stronger definition of individual roles (not in a leadership sense, just in a contribution sense) will help as well I think. 
If a board has no maintainers and no vendor support, it should be "CSC'd", with a list on the website with "looking for maintainers"  I would propose we not make images for those boards available on the download page, allow people to build them if they want.  That alone filters who would be asking questions.
 
So, for boards:
 
Each board entry should include 2 additional fields:
Maintained-by  (Member or members) Vendor-supported (Does the Vendor give Armbian anything more than just a couple boards?  I include technical support here) So Tinker Board and Le Potato would look like:
supported-by: tonymac32 vendor-supported: yes  (or we could make tiers, everything from boards on demand, technical support, direct code contribution, money)  
For Member-contrubtors:
 
boards hosting documentation etc So Igor (sorry if I massively under-represent:
 
Build Script Author (obviously multiple people can have each tag) Web Admin Build Hosting Family-Allwinner Family-Freescale Documenter etc I can expand on this later in a specific thread since it covers a wide topic matter.

Well, it's one of only two with 4 fast cores, the other being XU4.  The RK3399 doesn't even have that going for it.  It honestly is in the top 3 performers in any case, every time I use any other board I get a rude awakening about how bad a desktop experience can be. RK3399 is somewhat better but is still poorly supported kernel wise by comparison.

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.