Jump to content

piter75

Members
  • Posts

    306
  • Joined

  • Last visited

Everything posted by piter75

  1. +1 By default Armbian uses MBR so it's strange that you found GPT here. Looking at your logs I think that you did overwrite u-boot in the process. Your root partition starts at 2048 (0x800) sector instead of 32768 (0x8000) - which is Rockchip "standard". You may need to start over with a fresh image
  2. There seems to be a race condition involving eth0 device discovery and armbian-hardware-optimize service. Restarting the service after logging in with: systemctl restart armbian-hardware-optimize does not exhibit this issue. Nope, the board is based on rk3399 and it uses separate optimisations - this is part of the ongoing rockchip64 / rk3399 mixup saga ;-)
  3. If you can mount the SD with some ext4 capable system... Add the following stanza to boot/armbianEnv.txt in the mounted volume and you should be good to go. fdtfile=rockchip/rk3399-kobol-helios64.dtb There was a device tree file rename in the meantime and your u-boot does not know that
  4. Can you post the log of the boot process captured with serial? Can you also try if booting with "BOOT" button pressed is successful? - to rule out any incompatibilities between the u-boot in eMMC and SD
  5. It is fixed in master as of https://github.com/armbian/build/commit/1c29779e573956461b985c03cd293f5cf6ae1609 It will be part of v20.11 release. If you want it sooner... Put the following content into fix-es8316.dts file. Run "armbian-add-overlay fix-es8316.dts", reboot and enjoy!
  6. I don't know which htop versions you are using on both units but... Current htop implementation in Armbian makes a wrong assumption that big cores are the ones with bigger cpu ordinal numbers (eg. rk3399 where cpu0-3 are .LITTLE and cpu4-5 are .big). It does not work properly with your Exynos 5422 SoC where cpu0-3 are .big and cpu4-7 are .LITTLE. As you already observed it is mostly a reporting issue and I will probably fix it for the next version of Armbian's htop.
  7. Trying to boot with eMMC if you don't have one will get you nowhere ;-) 1 is the correct devnum in this situation. Why do you use this method anyway? Do you have trouble booting? What is the console output if you don't do anything during boot? And BTW, please use "Spoiler" for long pasted listing.
  8. This should be good enough. It's not a dumb 5V one.
  9. I am glad it works! What's the power supply you are using? Is it a PD one? This combination (accompanied by cpu load) is most probably too much for most of 5V dumb usb power supplies.
  10. This is most probably not caused by the commit you have mentioned as this commit is not part of any released artefacts yet (neither images not debs). Please provide some more details about the behaviour (link to armbianmonitor -u results would also help).
  11. Did you verify if your troubles have returned with the mentioned commit? The commit is switching boot loading for RockPi4 (and RockPro64) to a different process - it is using mainline's u-boot TPL/SPL combination instead of binary DDR blob from Rockchip. That's why the DDR_BLOB reference is gone.
  12. What is this u-boot's source? Does it have overlays support enabled (CONFIG_OF_LIBFDT_OVERLAY)? Can you also verify if you have uart4 overlay in your filesystem? root@rockpro64:~# ll /boot/dtb/rockchip/overlay/rockchip-uart4.dtbo -rwxr-xr-x 1 root root 384 Sep 4 18:23 /boot/dtb/rockchip/overlay/rockchip-uart4.dtbo* Your dmesg still contains spi-nor entry so either there is no uart4 overlay or it is not applied. [ 4.152295] spi-nor spi0.0: gd25q128 (16384 Kbytes)
  13. @aprayoga Fingers crossed! I remember playing with "regulator-ramp-delay" with M4V2 before (after noticing slow big cpu cluster transitions) but I probably did not got that high and definitely did not see that post you mentioned (and was not successful). I started some tests with 40000 right now. @Pedro Lamas if you want to also try testing it... Save below overlay into a file in your M4V2 (let's name it rump-delay-test.dts), run "sudo armbian-add-overlay rump-delay-test.dts" and reboot your M4V2. /dts-v1/; /plugin/; / { compatible = "rockchip,rk3399"; fragment@0 { target = <&vdd_cpu_b>; __overlay__ { regulator-ramp-delay = <40000>; }; }; };
  14. Yes. They are treated as separate groups/clusters when it comes to scaling and they also have separate regulators assigned to them. cpufrequtils however cannot configure their limits separately - the same limits are applied to both clusters
  15. With one of my boards I have had good results with min set to 1008000 and max to 2016000 (ondemand governor). You could also try that range. However the other one is still unstable in this scenario but runs stable with performance governor (meaning 2016000 all the time).
  16. Did you use the w same image for ROCK Pi 4C and 4B? 4C needs different images for all usb ports to work properly. You could also adjust the currently burnt image by editing fdtfile setting in /boot/armbianEnv.txt. Make sure fdtfile contains 4c and not 4b and reboot. All usb ports should be working after the reboot.
  17. To tell you the truth I did not pay much attention to wifi when bringing ROCK Pi S to Armbian ;-) One thing is certain - Radxa's image is plagued by the same issue. Care to test this image? It was built with Armbian's master and a bit fresher wifi driver. For me it still has stalls but they are much shorter - ~1s vs ~6s currently.
  18. What is your setup? What board revision is it? What image did you use before upgrading? Do you boot it with SD or eMMC? If eMMC - what are the markings on your module? That is odd indeed. I just tested fresh install of v20.05.4 (kernel 5.4.46 / focal / cli) from https://archive.armbian.com/rockpro64/archive/ with my unit (v2.1). I then upgraded it to v20.08.2 (kernel 5.8.6) and it boots fine. The issue obviously affects only some specific hardware configurations.
  19. Yes. IMHO by far the easiest option is flashing the image to SD card, booting it with SD (and eMMC module inserted). After booting you can run "nand-sata-install" command and choose "Boot from eMMC / system on eMMC option there. Some other options: if you have eMMC to USB or eMMC to SD adapter then you can flash it directly to eMMC module if you have USB-A to USB-A cable and then you can use the maskrom mode install
  20. There are no specific overlays for rk3308 in Armbian mainline builds for ROCK Pi S, yet. Remember also that this branch is very experimental for this board and YMMV. You can try downloading overlay straight from Radxa and install it with "armbian-add-overlay rk3308-i2c0.dts" command.
  21. Filesystem of your SD card has different UUID than the one in eMMC and the UUID is used to find root fs. Definitely. The root/boot partition should start at 16MiB and it needs u-boot images at correct locations. Maybe (most probably) there is some easier way but I believe you could be more successful this way: flash Armbian to SD and boot it; boot from eMMC and make new fs on the SD partition (be careful to not erase your eMMC partition); mount it at /mnt/sd and run rsync -avx / /mnt/sd/ run "lsblk -o PATH,UUID" to find the UUID of your new fs on SD; modify UUID value in /mnt/sd/boot/armbianEnv.txt (rootdev=UUID=...) and /mnt/sd/etc/fstab (UUID=.... for / mountpoint) to the one found on SD; unmount and try to boot from SD No warranty it works for you but the chance is definitely higher ;-)
  22. At this point I do not recommend running M4v2 with mainline linux. The reason for this instabilities and the remedy are yet to be discovered The board runs stable with legacy though.
  23. Rather not. This happens before eMMC is even probed. It could. At this point it is unfortunately a mystery to me what the real cause of this issue is.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines