Neko May

Last I checked, there were some outstanding stability issues with the M4V2 that have yet to be resolved. Current thoughts are that U-Boot is not training the RAM correctly which results in crashes/freezes once Linux is booted, but this is uncertain.

I had made a small configuration mistake in the original PR. I've submitted a second to rectify it. Apologies! (It was my first time making a PR and I jumped the gun a bit.)

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 )

PR submitted!

Still missing from the latest dev kernel package.

I got X11 running, it just worked after a reboot. (And crashes when trying to use it, exact same place.)

The rockchip64 kernels are missing wireless drivers for ralink chips.

Last I checked Rayson's site didn't have a datasheet or even list the part number for the DRAM chips used on the M4V2. That was a while ago, so it might be worth checking again (which I can do in a bit) and if all else fails I'll try asking FriendlyARM for a copy of the datasheet or whatever specs they may have for the chips. In addition, my partner's M4V2 also has 7z fail randomly with "Decoding ERROR" but was stable for a few days at least. The chips are marked RS512M32LZ4D2ANP-75BT, no luck at their site

I've been running mine now for 7 days with no reboots; using datasheet limits, uboot-nanopim4v2 20.05.0-trunk038 and kernel 5.5.2-rockchip64 #trunk.038 it seems to be stable. I do get "Decoding ERROR" at random when running the full 7z benchmark, however. Nothing else seems affected but if anyone has suggestions of other things to try (that are not sbc-bench, which changes the CPU max speed/governor) let me know and I'll give them a spin (unless they require 600 dependencies). I should install XFCE and xscreensaver and see how that runs and if X11 crashes; perhaps give it another week with that (or less, if it fails). Update: X11 fails to start, consistently segfaulting at OsLookupColor+0x188.

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.

Orange Pi Zero +2 H3 fails with both existing 20.02-RC images. Last 19 image is functional. Details:

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.

Very smart changes for sure! In the meantime, I have mine running, I'll give it a little push and let it go for a bit to see if there are still stability issues with the 5.5.2 kernel.

I've used a 5.x kernel on my Rock Pi 4 and did not experience any stability issues. That said, overclocking these chips is not recommended anyway (overclocking never is) and Armbian should not be doing it by default. The OPP table in the mainline kernel tree has the correct values for boards with a standard RK3399 or RK3399Pro; I do not know of any common boards with an RK3399K, and certainly none that are supported in any way by Armbian.