• Content Count

  • Joined

  • Last visited


About piter75

  • Rank
    Elite member

Recent Profile Visitors

1079 profile views
  1. 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.
  2. 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.
  3. @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.
  4. 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.
  5. @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.
  6. 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.
  7. 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 an
  8. 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 sc
  9. 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.
  10. 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.
  11. 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?
  12. 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
  13. 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?
  14. 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.
  15. 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.