piter75

Great. Will it cover all the boards? If not please add NanoPi M4V2 images to the build. It also contains a long overdue stability issue fixed in current and dev.

I am still thinking that this "fix" is actually only a workaround covering for some other issue. It sets "rootdev" to "/dev/nvme0n1p1" device but it should be overridden anyway with variables loaded from /boot/armbianEnv.txt. It also sets "ubootpart" in the kernel command line but this is only used by Armbian scripts for writing u-boot later on. IMHO it has nothing to do with the boot process. With those two facts combined - either /boot/armbianEnv.txt is not loaded correctly and does not use "rootenv=UUID=xxx" (I see in your armbianmonitor log that the variable is properly configured) or the fix is simply a placebo effect and it "works" because something else has also changed in the system. If you look at the last full dmesg of http://ix.io/2Rtz you see that the kernel command line uses "root=UUID=94xxx" which actually confirms that the fix is actually ineffective. If you look at the lsblk part of the log after this dmesg it shows that the system actually booted with nvme. What I suspect is that your drive is not always recognised by kernel. That would explain the missing UUID=5xxxx message in your screenshot. If you look at the screenshot there are actually no nvme* devices present in "ls /dev" output - that would corroborate my suspicion. What I would try would be a bit of testing: cold booting and rebooting at least a few times with SD card present and verify if the nvme device is actually present after booting.

No problem Thanks for the testing of mdadm scenarios. I decided this was good enough (+ my memtester tests) and also got some time to verify if the fix did not affect other boards. Since it is merged it means that v21.05 should finally run stable on M4v2 in mainline... it may also be sooner if there is another revision of v21.02

You are right. It does not depend on the way the board is powered. My electronics education is long diminished after spending years in software industry but I suppose it's either issue with rk808 pmic or the low pass filter in its output circuitry. The former is less likely as there are quite a few rk3399/rk808 boards that do not exhibit these issues so I guess it's more likely to be the output filter issue.

Known issue with hdmi enabled in u-boot and rk3399. NanoPi M4V2 is long known to be unstable in current and dev branches - you can search the forum. Fortunately there is hope ;-) Try the image referred in the following message and report your results. It contains both stability fix and the "lying around patch" to disable hdmi in u-boot.

@i5Js you can download these packages and install them with apt/dpkg: https://users.armbian.com/piter75/nanopim4v2-stability-fix/ You need both of them for the fix. When they are correctly installed and the board is rebooted you should see this message in your dmesg: piter@nanopim4v2-4:~$ dmesg | grep rk808-regulator.*buck [ 2.840331] rk808-regulator rk808-regulator: max buck steps per change: 4 The last "4" means you have the fix. No message or "8" means you don't have a fix.

Could you test this image with your procedure? It should fix the issues with voltage scaling on little cores cluster that made my units unstable and fail in the first loop of "memtester 3280M". With the fix it run 150 loops without failures.

@i5Js any constant frequency should do, switching cpufreq to performance profile also solved M4V2 stability issues in the past @i5Js @Glock24 I would appreciate if you verified the image referred in the previous post. If it works without crashes and we merge the change into master we could finally have stable M4V2 in Armbian current out of the box.

If it fails which I think it will... Can you try this image? https://users.armbian.com/piter75/Armbian_21.05.0-trunk_Nanopim4v2_buster_current_5.10.18_minimal-stability-fix.img.xz It contains a fix/workaround to dvfs issues I found and makes all of my M4V2 units running stable. Tested with hours of memtester running without failures. It failed pretty quick without the fix.

When I first read your post about MP510 not working I was a bit surprised because I was testing my SPI/NVMe changes with Silicon Power's SP34A80 512GB which uses exactly the same controller - Phison E12. I verified again with SP and it still works properly. I also have a few MP510s and decided to retest it with MP510 240GB which is normally mounted in ROCK Pi 4B. To my surprise MP510 240GB is not recognised in roc-rk3399-pc with neither u-boot nor kernel. I then tested another MP510 (480GB) that is newer and using a bit worse flash chips. This one is recognised in both u-boot and kernel. I guess this is good because I can reproduce it (and maybe try to fix when I find some spare time) but it still keeps me wondering why... All drives use a standard Phison E12 design and should be AFAIK (almost) identical. Maybe it's the firmware version that makes a difference...

Thanks for feedback. "rootdev" from /boot/boot.cmd should be overridden by the "UUID=" stanza in your /boot/armbianEnv.txt It is possible that something went wrong with the nand-sata-install and it did not update the value correctly. Can you post the link to a report generated with `sudo armbianmonitor -u`? Maybe we can identify the issue. I tested the procedure quite a few times and never needed to tinker with those files manually but one thing that comes to my mind is that I always used the first partition of the drive. I will need to test some other scenarios too ;-)

I totally agree and if I understood the communication in the corresponding PRs correctly - having separate configuration for P1/M1 was always a temporary solution until the changes were merged back into the main family.

IIRC I already agreed to changing the patch naming scheme for rockchip64 legacy kernels in the github discussion few weeks ago. I would interpret the lack of response from others as indifference ;p ... or are we talking about other missing response? BTW. I also received my mezzanine board which I reordered from AliExpress seller after previous order being cancelled resulted in a refund. The order went smooth this time.

I wonder if it hangs in u-boot or in kernel later on. Did you have a chance to catch such hanging boot with a serial console?

At first I (somehow...) thought you were using OrangePi 4. Now I see you have OrangePi RK3399 - the issue may stem from something else here. The board has AP6356S module but rk3399-bluetooth service is configured as it was using AP6256. Try one more substitution (and reboot): sudo sed -i s%BCM4345C5%BCM4356A2%g /lib/systemd/system/rk3399-bluetooth.service

Are you sure you are actually using SPI 0? It's not routed out to GPIO pins and its pins are indeed used by ethernet interface. Shouldn't you set bus 2 or 1 according to which GPIO pins you decided to use?

You can fix your current installation by running: sudo sed -i s/Type=exec/Type=simple/g /lib/systemd/system/rk3399-bluetooth.service followed by a reboot. Bluetooth in legacy Bionic images will be fixed when they are built next time.

Hmmm... now that you say it... I need to retest it with some fresh SPI image from Radxa. Maybe there still is some interoperability issue between our u-boot images.

Done. Thanks for feedback! No problem. I am glad it may help someone. It reminded me that I should update the instructions anyway - current instructions still work but some steps are unnecessary. With Armbian 20.11.4+ pins shorting is not needed anymore for folks that already have Radxa's u-boot in their SPI flash.

Did you also test this image with HDMI unplugged? What display are you using BTW? Can you test if this image boots? https://users.armbian.com/piter75/Armbian_21.02.0-trunk_Nanopim4v2_buster_legacy_4.4.213_minimal.img.xz It is built from master but disables HDMI in u-boot as it still seems to cause troubles. It is not a desktop image but if it boots you can make it one with armbian-config. To boot with NVMe you need to load u-boot first but RK3399 can only load u-boot with SPI flash, eMMC or SD. NanoPi M4V2 does not contain SPI flash so either eMMC or SD is needed to load u-boot.

I just verified the mentioned image and it seems to boot fine with SD and my unit: https://pastebin.com/uzyzb4Zh Try the JMCC's suggestion regarding the SD card. Serial console output would also increase the chance of getting the grip as to what may be wrong...

I had the same. They explained after a few days that it had some outgoing customs issues and asked me to place the order again. Yesterday I opened a dispute which was resolved by Aliexpress within an hour in my favour and today I got the money back. Seeing how well it went with the dispute I ordered it again - it was 0.25EUR more expensive now. Let's see how it fares this time ;-)

The tag was always there but at a different configuration level so no need to change it manually ;-) Nonetheless the ideas to explore for this issue (which I will unfortunately have no time for in foreseeable future) would be: Disable HDMI support for rk3399 boards in u-boot again - something like this PR (may need adjustments) It was already disabled once because of similar issues (which were supposed to be fixed with v2020.07) but I am leaning towards disabling it for all rk3399 boards again; Blacklist panfrost module, reboot and see if it helps - there was quite some development in panfrost between 5.4 and 5.8 This however does not apply to issues found in legacy; Try both of the above at the same time if none helps on its own; If you can spare some time - try testing the above scenarios.

You can use "dwc3-0-host" overlay in /boot/armbianEnv.txt to enable it now - it switches to port from otg to host mode. overlays=dwc3-0-host I will prepare some corrections to the device tree soon and will enable the host by default to make it consistent with vendor's configuration.

@JMCC This should do the trick to fix it for boards in rk3399 family: https://github.com/armbian/config/pull/134/files