aprayoga

Members
  • Content Count

    43
  • Joined

  • Last visited

About aprayoga

  • Rank
    Advanced Member

Profile Information

  • Gender
    Male
  • Location
    Singapore

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. You should see something like this when capturing serial console from power on We are investigating what change causing this crash, what changes on upstream kernel could have an impact. Meanwhile, if you want to revert to previous kernel, 5.8.14, used on Armbian 20.08.10, you could use armbian-config > System > Other or you could also get previous image from https://archive.armbian.com/helios64/archive/
  2. I forgot to answer this. the power staggering is handled by bootloader and not user configurable. We have tested various HDD brand/model and the highest current during spin up can go up to 7 seconds. We are considering the delay to be user configurable in future. Strange, that kind of crash should be fixed since 20.08.8. I don't encounter such crash on latest image. Could you get the serial console log start from power up?
  3. Could you try edit the /boot/armbianEnv.txt and add idVendor and idProduct of your drive to usbstoragequirks ? usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u,0x174c:0x5106:u,0x1e68:0x003a:u reboot the system and see whether your external USB drive can be recognized.
  4. The LED brightness is not adjustable. You would need to use semi transparent plastic/tape to reduce the brightness, or change the resistor on front panel board. Does FTDI USB serial still connected to your PC? That image should switch USB MUX to RK3399 internal USB and you would see the FTDI disconnected on your PC. On Windows, if you ever installed rockusb driver then you would need uninstall it otherwise it will be recognized as rockusb device instead of usb drive. How did you test? After remove the file, shutdown the system and unplug the power supp
  5. Armbian 20.08.10 has been released with eMMC boot fixed. Please do a fresh install. If you want to boot from eMMC, you can transfer using armbian-config > System > Install > 2 Boot from eMMC - system on eMMC
  6. you could re-enable auto power on by removing /lib/systemd/system-shutdown/disable_auto_poweron . You can check the file to see how to control the gpio pin for the auto power on feature. The auto power on is always enabled by bootloader. As @flower answered, SPI boot is not yet working. Theoretically after boot from SPI you could change boot target to first SATA drive
  7. You could use armbian-config, System->Other to switch branch but we are not recommend it. It might break the system. You can poll /sys/class/power_supply/gpio-charger/online to check main power supply status. Yes, this is performance issue mentioned on our table. Our iperf test shown, only a few first transfer correctly at 2.5gbits
  8. @TDCroPower The eMMC boot fixed on this PR . The wiki instruction more on new install using new u-boot that able to emulate eMMC as USB Mass Storage. You should wait new Armbian update
  9. @TDCroPower I could not reproduce your setup. First I tried with fresh Armbian 20.08.8 then transfer to eMMC using nand-sata-install. System can boot if sd card inserted. I clean up the eMMC. then run next test. I tried boot from fresh Armbian 20.08.4 then transfer to eMMC using nand-sata-install. System can boot if sd card inserted. Then boot from fresh Armbian 20.08.8 without cleaning the eMMC, then transfer to eMMC using nand-sata-install. System can boot if sd card inserted. Initially I though maybe previous u-boot on eMMC looking for old d
  10. So with Armbian 20.08.8 LEGACY, the system still crashed? Let us know if you managed to get the log and a way to reproduce the crash. There is a change to rename device tree to follow mainline device tree naming. from /boot/rockchip/rk3399-helios64.dtb to /boot/rockchip/rk3399-kobol-helios64.dtb Did you use fresh image of 20.08.8 then transfer to eMMC via nand-sata-install?
  11. To summarize current status Feature Support Status Feature Legacy Remarks Current Remarks Shutdown Issue Failed to shutdown PMIC and trigger crash, HDD already parked OK Reboot Issue Similar like shutdown but Watchdog trigger the reboot so it appear successful OK Suspend to RAM Not Supported Yet Failed to resume operation after
  12. @piter75 @Pedro Lamas Helios64 also encounter some random crash, yesterday we tried to redefine opp just 408 MHz and 1.4/1.8 GHz and we don't see any random crash anymore. It seems similar DVFS problem as discussed in this thread. Then our customer point us to odroid n1 issue at https://forum.odroid.com/viewtopic.php?t=30303 Maybe you can give it a try on Nano Pi M4v2. We are still testing on Helios64 (with value 40000), so far with reboot and power cycle does not trigger any kernel crash.
  13. aprayoga

    aprayoga

  14. @FredK and @bigbrovar, thanks for the info. on Friday, i did some initial investigation and as you said upper USB port seems only work at 2.0 (high-speed USB device) not 3.0. [ 42.581478] usb 4-1: new high-speed USB device number 2 using xhci-hcd [ 42.747232] usb 4-1: New USB device found, idVendor=0480, idProduct=0820, bcdDevice= 3.15 [ 42.755452] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 42.762635] usb 4-1: Product: External USB 3.0 [ 42.767095] usb 4-1: Manufacturer: TOSHIBA [ 42.771225] usb 4-1: SerialNumber: XXXXXXXXXXX6F [ 42.777009] usb-stor
  15. as mentioned by @Werner, RK3399 runs best on the legacy, 4.4 kernel. Mainline, (LK 5.4), for example, still have some issue on DP over TypeC. We ran some burn-in test (stress-ng for cpu, parallel fio on all sata port, all usb port, emmc and microsd) under LK 4.4. we didn't encounter stability issue in 24 hours. Similar like Helios4, Helios64 will have legacy and current support. i have tried similar riser from Amazon, as you can see on following pictures, the riser is too long and M.2 modem is too wide