aprayoga

@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

@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 device tree name therefore your system failed to boot. But it does not seem the case. You could try to set "rootdev=/dev/mmcblk1p1" in /boot/armbianEnv.txt as a workaround. But keep in mind that all of the actual boot files are still on sdcard and not accessible under /boot/

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?

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 wake up Not Supported Yet USB host controller refuse to enter suspend mode 2.5G Ethernet OK Performance Issue Slightly improved with tx offload disabled Main Power/UPS Status OK Status can be read from sysfs OK Status can be read from sysfs Battery Charging Status Not Supported OK Charging and Full charge can be read from sysfs UPS configuration Not Supported Yet Need user-space tool to monitor power status and trigger shutdown Not Supported Yet Need user-space tool to monitor power status and trigger shutdown USB Type C - Host OK Not Supported Yet There are some issue with fusb302 driver and USB Host Controller driver USB Type C - Gadget OK Not Supported Yet There are some issue with fusb302 driver and USB Controller driver USB Type C - DisplayPort OK Not Supported Yet There are some issue with fusb302 driver and DisplayPort alternate driver eMMC Install Not Supported Yet The bootloader unable to load rootfs from eMMC Not Supported Yet The bootloader unable to load rootfs from eMMC SPI Boot Not Supported Yet Not Supported Yet Recovery key Not Supported Yet System can enter maskrom mode but need special OS image and rkdevelop Not Supported Yet System can enter maskrom mode but need special OS image and rkdevelop We are still working on eMMC issue.

@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.

@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-storage 4-1:1.0: USB Mass Storage device detected [ 42.785088] scsi host4: usb-storage 4-1:1.0 [ 42.839846] usbcore: registered new interface driver uas [ 49.139357] scsi 4:0:0:0: Direct-Access TOSHIBA External USB 3.0 5438 PQ: 0 ANSI: 6 [ 49.149674] sd 4:0:0:0: Attached scsi generic sg2 type 0 [ 49.161946] sd 4:0:0:0: [sdc] Very big device. Trying to use READ CAPACITY(16). [ 49.171592] sd 4:0:0:0: [sdc] 7814037164 512-byte logical blocks: (4.00 TB/3.64 TiB) [ 49.179392] sd 4:0:0:0: [sdc] 4096-byte physical blocks [ 49.187768] sd 4:0:0:0: [sdc] Write Protect is off [ 49.195302] sd 4:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 49.334260] sdc: sdc1 sdc2 [ 49.339876] sd 4:0:0:0: [sdc] Attached SCSI disk this morning i tried, and it works as 3.0 (SuperSpeed Gen 1 USB device) [ 90.585477] usb 4-1: new high-speed USB device number 2 using xhci-hcd [ 91.477501] usb 5-1: new SuperSpeed Gen 1 USB device number 2 using xhci-hcd [ 91.503435] usb 5-1: New USB device found, idVendor=0480, idProduct=0820, bcdDevice= 3.15 [ 91.511642] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 91.518807] usb 5-1: Product: External USB 3.0 [ 91.523274] usb 5-1: Manufacturer: TOSHIBA [ 91.527390] usb 5-1: SerialNumber: XXXXXXXXXXX6F [ 91.534376] usb-storage 5-1:1.0: USB Mass Storage device detected [ 91.540743] scsi host4: usb-storage 5-1:1.0 [ 91.583403] usbcore: registered new interface driver uas [ 97.211091] scsi 4:0:0:0: Direct-Access TOSHIBA External USB 3.0 5438 PQ: 0 ANSI: 6 [ 97.221100] sd 4:0:0:0: Attached scsi generic sg2 type 0 [ 97.229812] sd 4:0:0:0: [sdc] Very big device. Trying to use READ CAPACITY(16). [ 97.238524] sd 4:0:0:0: [sdc] 7814037164 512-byte logical blocks: (4.00 TB/3.64 TiB) [ 97.246315] sd 4:0:0:0: [sdc] 4096-byte physical blocks [ 97.253361] sd 4:0:0:0: [sdc] Write Protect is off [ 97.258537] sd 4:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 97.394956] sdc: sdc1 sdc2 [ 97.402343] sd 4:0:0:0: [sdc] Attached SCSI disk we will need to investigate further

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

the families are - rk3399 only rockpro64 and rock pi 4 under this family - rockchip64 the rest of rk3399 boards. Helios64 can boot with both family with the correct device tree (different dts for rk3399 and rockchip64). looking at this PR https://github.com/armbian/build/pull/1934 it seems the direction is to merge rk3399 to rockchip64 (implied by renaming the the patch folder from rk3399 into rockchip64 instead of the other way a round).

Hi all, currently i'm working on upcoming Helios64 board. For RK3399 board there are 2 families, what are the differences between them? I've been following discussion on github and this forum for few months but still unsure which family i should use.

Thanks for providing the crash log. Last weekend i ran some test with following image Buster NEXT upgraded to buster CURRENT fresh Buster CURRENT and load the system with stress-ng -c 2 -P 70 It supposed to make the system busy and run with full speed (1.6 GHz). i ran it for about 20 hours each test but i did not encounter any issue. Looking on your log, it seems marvell_xor that trigger the crash. I will try your suggestion to trigger the crash

@Userlab @gprovost, a correction, most likely WWAN module won't work as they usually required SIM card on carrier board and maybe some other signals such as Radio/Wireless Disable.

I don't think you need to modify the Makefile, you can set LOCALVERSION environment variable before compiling. You could try something like this when you invoke the make LOCALVERSION=-sunxi64 make modules Here is how Armbian compile the kernel: https://github.com/armbian/build/blob/master/lib/compilation.sh#L367-L371

A few months ago I enabled some USB-Serial converter driver on the kernel and test it. I used an USB hub then hotplug several USB-Serial (PL2303, FT232, FT2232, CH340G, CH341A, CP2101, CP2102), all detected correctly. According to your log, it seems something wrong with the USB Host controller driver, could you try with other USB device? maybe USB Flash drive

Between middle-to end of November 2019, Armbian change the version and branch naming. Version from something like 5.91 become something like 19.11.x, if i'm not mistaken Year.Month, like Ubuntu versioning. Then the branch name, DEFAULT become LEGACY NEXT become CURRENT To upgrade to new version, use armbian-config. sudo apt-get update sudo apt-get -y upgrade sudo armbian-config Select System > Other, to switch to other kernel Confirm the action And after some process, you will be presented by list of kernels Select linux-image-current-mvebu. The system will install the new kernel and automatically reboot. Confirm the kernel installed correctly and Armbian changed to new branch CURRENT by executing, uname -a grep "BRANCH" /etc/armbian-release

Good to hear you got it working. I tried the instructions first on my system and did not encounter such error. Could you share your u-boot version? I test on fresh Armbian_19.11.3_Helios4_buster_current_4.19.84.img 1. I don't encounter such error when accessing the system from Windows using PuTTY or thru serial console UPDATE: i tried to SSH from my Ubuntu machine (got id_ID locale), indeed there are perl warning regarding locale but armbian-config is still usable to generate the locale, no need to manually edit file. After the locale generated by armbian-config, no more perl locale warning. 2. Confirmed 3. Confirmed. cat: /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies: No such file or directory cat: /sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors: No such file or directory /usr/lib/armbian-config/jobs.sh: line 1075: Error: Expected at least 5 tokens for --menu, have 4. Use --help to list options. / 1000: syntax error in expression (error token is ": Expected at least 5 tokens for --menu, have 4. Use --help to list options. / 1000") The path is not exist, even though the driver is compiled. I will need to investigate further. --- I also tried using fresh Armbian 5.91 then upgraded to Armbian 19.11.3, but strangely i don't see the System - CPU menu. 4. As mentioned on @sirleon link, apparently Buster make use nftables by default and on our kernel is not enabled. You could try to switch to iptables-legacy version. CONFIG_NF_TABLES=m CONFIG_NF_TABLES_SET=m # CONFIG_NF_TABLES_INET is not set # CONFIG_NF_TABLES_NETDEV is not set # CONFIG_NF_TABLES_IPV4 is not set # CONFIG_NF_TABLES_ARP is not set # CONFIG_NF_TABLES_IPV6 is not set # CONFIG_NF_TABLES_BRIDGE is not set meanwhile, i will try to enable those modules and test. @Igor, could you take a look whether armbian-config issues also occur on other board?

Hi @sirleon, the tutorial is intended for moving the rootfs to USB thumb drive and due to spi_workaround it does not work with SATA seamlessly but you almost there.. I suggest to move the rootfs to drive that connected to SATA0 (most likely /dev/sda), because there is known issue that u-boot failed to recognized SATA device other than on SATA0. To boot from SATA you need to: 1. Move the rootfs with sata-nand-install while spi_workaround is disabled, and reboot. The system will boot from SD card. 2. Unmount /boot and copy over boot files from /media/mmcboot/boot to /boot umount /boot cp -rf /media/mmcboot/boot/* /boot/ 3. Edit /etc/fstab and remove/comment 2 lines that have mount point to /media/mmcboot and /boot. 4. Reboot the system and cancel u-boot auto boot. 5. Run following commands on u-boot prompt to add sata boot and reboot setenv boot_targets "usb0 scsi0 mmc0 pxe dhcp" setenv bootcmd_scsi0 'devnum=0; run scsi_boot' saveenv You could reorder the boot order on boot_targets variable. On above command, it would tried to boot from USB and if failed try SATA/SCSI and so on.

@jimbolaya, I know it's quite late, ch341 driver would be included on next release. Refer to commit 14a0a54. @smith69085, we have updated the wiki page how to use the GPIO for button. You can take a look on https://wiki.kobol.io/gpio/#use-gpio-with-device-tree-overlay But currently the base dtb (armada-388-helios4.dtb) on Armbian 5.91 is still not compiled with overlay support. You can download the attached dtb, rename and replace the dtb on your system. lk4.14_armada-388-helios4.dtb is for Armbian Default (Stretch, Linux Kernel 4.14) sudo cp lk4.14_armada-388-helios4.dtb /boot/dtb/armada-388-helios4.dtb lk4.19_armada-388-helios4.dtb is for Armbian Next (Buster, Linux Kernel 4.19) sudo cp lk4.19_armada-388-helios4.dtb /boot/dtb/armada-388-helios4.dtb

@Mangix have you check the wiki, https://wiki.kobol.io/cesa/ ? There are plenty of informations over there, for example the benchmark result and what kind of cipher can be hardware accelerated.

I still confused with your configuration, you said you setup sdb & sdc as mirror but from the armbian log on first post, it's RAID level 5 with member sdb, sdc, &sdd Please run the following commands to make boot process more verbose sudo sed -i 's/verbosity=1/verbosity=7/g' /boot/armbianEnv.txt echo "extraargs=no_console_suspend ignore_loglevel" | sudo tee -a /boot/armbianEnv.txt sudo sed -i 's/exit 0/dmesg -n 8\nexit 0/g' /etc/rc.local sudo reboot and please capture serial console from very beginning of u-boot. Oh, with the configuration that has problem.

Hi, Just wanted to make sure, do you see something like in screenshot below?

Hi, We haven't started to work on 5.2 but maybe you can try the patch by Gontran Baerts for ArchLinux https://github.com/gbcreation/linux-helios4/blob/master/92-mvebu-gpio-remove-hardcoded-timer-assignment.patch

Hi, currently booting directly to SATA1 is not supported. It was supported using Marvell U-boot 2013.01. If your intention is to boot without SD Card, you can boot from SPI NOR flash. The U-Boot on SPI NOR flash then would search boot.scr on following order USB SATA1 SD Card

Hi, you're right, the driver is not included, you'd need to compile the driver by yourself if you need ASAP. I don't see any technical reason not to include the driver. After i test, I will enable it on Armbian kernel

@MarcC it is possible to write U-Boot directly to SATA disk but currently no U-Boot image for SATA available. and AFAIK, the procedure a bit different but more similar like PC. Write U-Boot SPL to disk boot sector then put u-boot.bin into FAT formatted 1st partition. We are still experimenting with this, can not say when it would be ready.