piter75

  • Posts

    289
  • Joined

  • Last visited

2 Followers

Recent Profile Visitors

1360 profile views

piter75's Achievements

  1. @TCB13 I am a bit late to the party but I figured it may still be needed ;-) spi-spidev is a special / dynamic overlay. Besides enabling it you need to also configure it and armbian-config cannot currently do that. For configuration options have a look here: https://github.com/armbian/build/blob/master/patch/kernel/archive/rockchip64-5.10/general-rockchip-overlays.patch#L98-L126 You can also consult the local README file located in: /boot/dtb/rockchip/overlay/README.rockchip-overlays
  2. It will be fixed with https://github.com/armbian/build/pull/2877
  3. @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.
  4. Something similar to this hat most probably ;-) https://www.aliexpress.com/item/33029451117.html
  5. 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 unstable). It takes a bit longer to switch between frequencies now (at least 456uS vs at least 196uS for full swing between 408MHz and 1512MHz) but it is stable.
  6. +1 We need to do that from time to time. I am not particularly missing them ;p
  7. 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 ;-)
  8. IMHO it's more than that ;-) There will be older releases in the archive but no new ones.
  9. 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".
  10. @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): As you can see it reaches 1GB+/s speeds both writing and reading with large enough block size, hovers around 1GB/s with medium block size and dives to 50-200MB/s with small blocks. pcie-gen2 overlay is not needed with ROCK Pi 4C as unsupported gen2 link speed was mainlined for all ROCK Pi 4 boards. BTW. Is the guy Jeff Geerling (https://github.com/geerlingguy)? If so then I am actually using the way he was using to compare different SD cards' performance with Raspberry Pi ;-) https://github.com/geerlingguy/raspberry-pi-dramble/issues/7
  11. 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
  12. 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.
  13. Glad to hear that. BTW The fix is now included in Armbian v21.02.3 images
  14. Thanks for sharing drive details! I will add it to the opening post.
  15. Great. Looking forward to hear about your results.