Neko May

There's an issue with Panfrost and Mesa 19.3 that causes X11 to crash in "OsLookupColor" which you may run into on Armbian on RK3399 devices; it can be solved by enabling the experimental branch in your /etc/apt/sources.list by adding the following line:
 
deb http://deb.debian.org/debian experimental main contrib non-free  
You can then run 'apt update' and install experimental branch packages with 'apt -t experimental install <package>'. To fix the crash in X11, update the following from experimental:
libegl-mesa0 libgbm1 libgl1-mesa-dri libglapi-mesa libglx-mesa0 mesa-va-drivers mesa-vdpau-drivers mesa-vulkan-drivers This should allow X11 to run properly.
 
Thanks to zackw at the Pine64 forums (Original post: https://forum.pine64.org/showthread.php?tid=8915&pid=61701#pid61701 )

There's an issue with Panfrost and Mesa 19.3 that causes X11 to crash in "OsLookupColor" which you may run into on Armbian on RK3399 devices; it can be solved by enabling the experimental branch in your /etc/apt/sources.list by adding the following line:
 
deb http://deb.debian.org/debian experimental main contrib non-free  
You can then run 'apt update' and install experimental branch packages with 'apt -t experimental install <package>'. To fix the crash in X11, update the following from experimental:
libegl-mesa0 libgbm1 libgl1-mesa-dri libglapi-mesa libglx-mesa0 mesa-va-drivers mesa-vdpau-drivers mesa-vulkan-drivers This should allow X11 to run properly.
 
Thanks to zackw at the Pine64 forums (Original post: https://forum.pine64.org/showthread.php?tid=8915&pid=61701#pid61701 )

and sometimes it's more or less the 'works for me' approach where it worked in the first place for 'developer x' and as long as nobody could show the opposite it was assumed to be 'good'. Mostly with one or maybe two boards of the SoC in question.. So our sample amount to optimize parameter might not be high enough to call this scientific. So our settings are based on observations but likely not on a scientific relevant sample amount.
oh most of the few OC-er I know spend an unhealthy amount of time to ensure their OC setup works perfect stable at highest possible settings for their CPU/GPU/RAM, probably a way more time than we invest in our settings (my last AMD64 except my notebook where thermals don't allow to think about OC at all is now 7years old and has probably 2-3k hours stable at slightly overclocked settings, I don't see a difference between overclocking between architectures)..
 
Now back to the topic and back to my observations.. I probably packed the linux kernel with 7z a few hundred times when I played around zram trying to find a difference in performance between lzo and lzo-rle (which is claimed to be faster on arm, and 7z is great to soak up a lot of memory). The board itself run for roughly 2 weeks with the image (5.3 kernel back then) and 7z run for hours over night packing and unpacking kernel sources. On my board I didn't notice instabilities except oom can kicks in (it mostly happened when trying to compile large libraries, but also happens sometimes with 7z and reducing available ram with kernel bootargs below 2GB iirc - could be less, I barley keep notes of such stuff when I don't see promising results. I sometimes should, turns out my brain runs oom too and I forget stuff over time). On my NanoPi M4V2 our default 2GHz/1.5GHz settings worked just fine.. Could be that I just got 'a better board than yours' which allows higher defaults (the same happens in AMD64 world - some CPUs from the same spec just perform better than others) or that something else on your settings isn't in a great shape and if this is the case I would bet on your powersupply. We see first indications that we run into the same nightmare with powering as we did with microUSB back then now on boards using USB-C in 'dump mode' being not PD compliant (USB-C is better than microUSB but the boards it's mostly used are also more powerhungry so being better doesn't mean being good). My setting was headless with a RPi4 PSU which is to my knowledge rated at 5.1V/3A. What PSU did you use for your board.
 
@piter75 (maybe adding the other usual suspects too, so @TonyMac32 and @martinayotte) if this turns out to be a issue for m4v2 whereas the other boards do fine we could simply solve it by DT overlay and having it as default for those boards do well and disable it for the M4V2. Similar to https://github.com/armbian/build/blob/e78f6db215c9444ce83b8e80c85af88158ce4c2e/config/boards/orangepizero.conf#L6 to bring up USB2 on pinheader by default.
 
 

I've seen it on a few boards, but the only one I can definitively say right now is the Orange Pi 3. I'd have to check the other boards one by one and see whether they do the same.
 
As for the verbosity setting, yes, setting it to 7 will give you all the kernel output on serial (as well as HDMI if applicable).

The kernels shipping with the 20.02-RC builds have their kernel message buffer size set far too small; the beginning of the message buffer has already started to be overwritten by the time the login prompt comes up. This rather unfortunately complicates testing the images due to the loss of information. Similarly, the default setting of "verbosity=1" in armbianEnv.txt has the similar effect of frustrating testing efforts as there is no output on the serial port until the login prompt. I propose the friendly suggestion to increase the dmesg buffer size to at least 256KB, and set the verbosity to 7 by default; I don't think the kind of people who use these boards are going to be afraid of kernel messages.

Ah, sorry, haven't checked the last 19 build yet, had some other stuff come in and got busy with that. (I did update the 20.02-RC Google Doc, though, with my results.)
 
Armbian_19.11.6_Orangepizeroplus2-h3_bullseye_current_5.4.8.img is fine. Boots to login prompt, so it's a 20.02-RC issue.

I don't know the reason for the decision to do it, as it predates the beginning of my usage of Armbian, but I tend to agree that we should play safe by default.
 
I did not have any issues with it on my boards so I did not pursue to change it but...
When I was suspecting CPU issues with M4V2 I created the changes to disable the overclocking but also to make it easy to overclock with the overlay if one wanted to experiment:
https://github.com/armbian/build/compare/rk3399-disable-overclocking
 
It did not fix the M4V2 mainline issues but I think we can reconsider the default behaviour anyway.