• Content Count

  • Joined

  • Last visited

Everything posted by piter75

  1. @Chalix You have done quite a research already Helios64 is Rockchip RK3399 based so you are better off with the theory found here http://opensource.rock-chips.com/wiki_Boot_option as a starter. U-boot and vendor blob binaries are found in "/usr/lib/linux-u-boot-$BRANCH-helios64_$RELEASE_arm64" folder on your system. You are probably using "current" $BRANCH and the latest $RELEASE is 21.02.3. The recipe to write the images to device (more or less) is to be found here.
  2. Something similar to this hat most probably ;-) https://www.aliexpress.com/item/33029451117.html
  3. With that setting you are actually disabling the DVFS after the short period of time during boot - before cpufrequtils kicks in. My experience is that you could also set it to min/max 2GHz and it would be just as good. Yes, this mod/tweak/hack ;-) fixes the behaviour of my boards with ondemand governor. It seems that the instability of little core's voltage during the voltage change was the issue. Rockchip has already limited max change per single step for this regulator to 100mV (because of "overshooting") and I did limit it further to 50mV (75mV was still
  4. +1 We need to do that from time to time. I am not particularly missing them ;p
  5. I am not sure of that. My understanding is that we are still building release images from master branch and the removal of this line from targets.conf: -rockpi-4b legacy focal cli stable yes means that focal legacy image for rockpi-4b will not be built. Lack of focal legacy image among 20.02.3 release images (built after the referred commit was merged) seems to corroborate that theory ;-)
  6. IMHO it's more than that ;-) There will be older releases in the archive but no new ones.
  7. Not that it is relevant to SPI/NVMe booting ;-) but it is no longer built for that combination automatically. You can build it yourself or download focal current and switch kernel to legacy with "armbian-config".
  8. @Salvador Liébana I would be very cautious about comparing with results that I don't know how they were obtained. In fact I would avoid it ;-) We cannot say much about Radxa's benchmarking looking at the presented graph. Nonetheless below you will find the iozone run I performed with LK 5.10.20: piter@rockpi-4c:~$ uname -a Linux rockpi-4c 5.10.20-rockchip64 #1 SMP PREEMPT Fri Mar 5 10:47:39 CET 2021 aarch64 GNU/Linux It was performed using iozone (429) on EXT4 with ROCK Pi 4C and Corsair Force MP510B 480GB (yes, the model with degraded flash chips):
  9. RK3399 officially supports version 1.0 (2.5GT/s) and unofficially 2.0 (5GT/s). PCIE 3.0 support is needed for 8GT/s. https://en.wikipedia.org/wiki/PCI_Express#History_and_revisions
  10. True, it makes no difference because the unsupported by Rockchip Gen 2 link speed was mainlined into ROCK Pi 4(a/b/c) device trees so you don't need the overlay ;-) https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi#L472 I am not sure it should be mainlined this way but it's another story. It confirms that you are indeed running at Gen2 speeds and have 1GiB/s physical bandwidth.
  11. Glad to hear that. BTW The fix is now included in Armbian v21.02.3 images
  12. Thanks for sharing drive details! I will add it to the opening post.
  13. Great. Looking forward to hear about your results.
  14. 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.
  15. 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 proper
  16. 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
  17. 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.
  18. 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.
  19. @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.
  20. 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.
  21. @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.
  22. 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.
  23. 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
  24. 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
  25. 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.