Jump to content

piter75

Members
  • Posts

    306
  • Joined

  • Last visited

2 Followers

Recent Profile Visitors

3384 profile views
  1. There might also be some variances in components between units (different manufacturers, batches, etc..) that might have been "uncovered" by some minor change in kernel code. I remember having a unit of Rock Pi 4A (no wifi) that did not boot with eMMC while the other unit 4GB 4B (wifi) did boot without issues. I consulted other Rock Pi 4A Armbian users and they did not observe such behaviour. I finally found the cause in the mmc kernel driver and even implemented a patch for it in Armbian, but that did require lots of fiddling and debugging. Unfortunately at this point I cannot reproduce the issue with my NanoPi R4S unit.
  2. Is anything printed on the serial console during boot?
  3. Just tested mine with the latest image (buster / current) with 16GB Sandisk Ultra SD card and it seems to work fine: http://ix.io/3Rxb It is a 1GB model however. Any chance to get the bootlog over serial?
  4. The truth is I did not test the SPI booting lately. Will give it a shot as soon as I find some spare time. It's not merged into master yet: https://github.com/armbian/build/pull/3489
  5. I did not make it to send the PR yesterday although prepared the switch. I am totally unsure however how PineBook Pro fares after the switch (the changes are pretty substantial) so we should probably keep rockchip64-current at 5.10 and catch-up after the release.
  6. Ok, I will try to finish it by tomorrow night anyway.
  7. I gave it a shot tonight and well... edge and current diverged quite a bit functionally between themselves during my absence . With as much time as I can spare on it at the moment I am not confident enough that I can synchronise them correctly during the next 1-2 evenings. @Igor Do we consider keeping rockchip64 current at 5.10.y for this release?
  8. +100 😉 @wureka given this report it may either work or not, or... work intermittently. I don't have any sm2262en(g) based drive to verify...
  9. Armbian "current" (5.10.y) compiles without issues. I second @Igor's opinion that a change somewhere in this diff broke the eMMC. I tried reverting a few obvious parts of it, like the mmc driver changes, but without success. However I did find that with the unit I have the issue happens only in hs400{,es} modes. With those disabled my unit works fine and I can use nand-sata-install to transfer os from SD to eMMC successfully which is not possible with 5.10.60+ and hs400 enabled on eMMC. If anyone wants to check if switching eMMC to hs200 mode works also on their unit, here is how: Upgrade the kernel to 5.10.60, but don't reboot yet. Run: curl -o rk3399-kobol-helios64.dtb https://users.armbian.com/piter75/helios64/rk3399-kobol-helios64.dtb sudo cp rk3399-kobol-helios64.dtb /boot/dtb/rockchip/rk3399-kobol-helios64.dtb sudo reboot If this workaround works I will disable hs400{,es} (again) in Armbian until the underlying issue is found. There will be a performance penalty to that change but keep in mind that Helios64 was originally released with hs200 and only recently gained hs400 back ;-) Below you can find the comparison between hs400 and hs200 modes using iozone.
  10. You have probably used the option "Boot from SPI - system on SATA, USB or NVMe" which transfers the current system to SSD and needs to clean it. There is another option - better suited for your case - "Install/Update the bootloader to SPI Flash". It does not touch the existing partitions only writes to SPI Flash.
  11. @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
  12. It will be fixed with https://github.com/armbian/build/pull/2877
  13. @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.
  14. Something similar to this hat most probably ;-) https://www.aliexpress.com/item/33029451117.html
  15. 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.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines