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.

I have noticed that the NanoPi M4V2 has an OPP table which causes the device to overclock; the table is suitable for an RK3399K SoC, but the M4V2 has a standard RK3399 SoC with maximum speeds of 1.42GHz for the A53 cores and 1.80GHz for the A72 cores (despite FriendlyArm themselves citing the K speeds in marketing material, which is incorrect). I believe that this may also be causing stability issues with my unit, however I will be performing additional testing (I cannot find where it is getting the "extended" OPP tables from, so I am limiting it via cpufreq-set and testing for stability.) Does anyone have any insight or ideas?

Alright, I will try tomorrow. (Though it should still be noted that the 20.02-RC appears to be nonfunctional!)

This indicates it's a 19.x build, the current build available (and marked as supported) is 20.02

It's present. Silkscreen on the board indicates it's a V1.0; it was ordered from their official AliExpress shop in December 2019.

Boards (I've tried on two) are new. All possible local causes eliminated.

I waited an hour. Add in that the screen cursor AND heartbeat LED stop blinking and it's clear something else has gone wrong.

Everything proceeds normally, then: [ 11.372152] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-11), device may have limited channels available [ 11.384297] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43430/1 wl0: Mar 30 2016 11:30:56 version 7.45.77.h8.4 FWID 01-ee8a6268 [ 11.795217] EXT4-fs (zram0): mounted filesystem without journal. Opts: discard [ 11.802525] ext4 filesystem being mounted at /var/log supports timestamps until 2038 (0x7fffffff) [ 16.152485] EXT4-fs (mmcblk0p1): resizing filesystem from 299008 to 7712800 blocks Note the roughly 5 second pause before the resize operation, after which it immediately hardlocks. An attempt with a fresh, brand new SD card gave near identical results, instead freezing before printing the "resizing" line.

USB cable is well tested and known working. Power supply is capable of 4A maximum and also well tested. Same with SD Cards and adapter, all very well tested. I'm aware of the maturity of H3 support but that does not preclude bugs. Anyway, I've now done exhaustive testing with the latest Buster image, ruling out any sort of hardware issues (including testing on a second board) and it consistently locks up on boot. Attempting to view kernel output over the serial port yields literally nothing; the "booting the kernel" message is displayed then nothing else (heartbeat LED flashes until lockup). The same behavior is encountered with or without the HDMI display attached.

The Orange Pi Zero +2 H3 with USB hat will hard lock up on boot at "Starting Armbian Hardware Monitoring" when booting the latest (and at least one previous) available Buster (and Bullseye) images over HDMI console. Tested on multiple SD cards with the same result. (I will test with serial later, I do not have the time to remove it from the case at the moment; I figured I would post it now in case anyone had a chance to check before I could.)

I can confirm the same on a Banana Pi M64 with the latest available image and the one before. Panic is always random, and sometimes U-Boot can't even find the SD Card. Verified reproducible on a second board, and the Fedora image with kernel 5.3 available from BPI's site boots fine every time.