aprayoga

Yes, you can boot from SATA disk but currently limited only from SATA1 port. Take a look on following log: U-Boot SPL 2018.11-00008-g8f200a3d28 (Jul 03 2019 - 08:01:15 +0800) High speed PHY - Version: 2.0 Detected Device ID 6828 board SerDes lanes topology details: | Lane # | Speed | Type | -------------------------------- | 0 | 6 | SATA0 | | 1 | 5 | USB3 HOST0 | | 2 | 6 | SATA1 | | 3 | 6 | SATA3 | | 4 | 6 | SATA2 | | 5 | 5 | USB3 HOST1 | -------------------------------- High speed PHY - Ended Successfully mv_ddr: mv_ddr-armada-17.10.4 DDR3 Training Sequence - Switching XBAR Window to FastPath Window DDR Training Sequence - Start scrubbing DDR3 Training Sequence - End scrubbing mv_ddr: completed successfully Trying to boot from SPI U-Boot 2018.11-00008-g8f200a3d28 (Jul 03 2019 - 08:01:15 +0800) SoC: MV88F6828-A0 at 1600 MHz DRAM: 2 GiB (800 MHz, 32-bit, ECC enabled) MMC: mv_sdh: 0 Loading Environment from SPI Flash... SF: Detected w25q32bv with page size 256 Bytes, erase size 4 KiB, total 4 MiB OK Model: Helios4 Board: Helios4 SCSI: MVEBU SATA INIT Target spinup took 0 ms. Target spinup took 0 ms. AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode flags: 64bit ncq led only pmp fbss pio slum part sxs Net: Warning: ethernet@70000 (eth1) using random MAC address - ee:e0:5b:09:22:72 eth1: ethernet@70000 Hit any key to stop autoboot: 0 starting USB... USB0: MVEBU XHCI INIT controller @ 0xf10f4000 Register 2000120 NbrPorts 2 Starting the controller USB XHCI 1.00 USB1: MVEBU XHCI INIT controller @ 0xf10fc000 Register 2000120 NbrPorts 2 Starting the controller USB XHCI 1.00 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 1 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Device 0: device type unknown ... is now current device scanning bus for devices... Device 0: (0:0) Vendor: ATA Prod.: TOSHIBA MK5065GS Rev: GJ00 Type: Hard Disk Capacity: 476940.0 MB = 465.7 GB (976773168 x 512) Device 0: (0:1) Vendor: ATA Prod.: TOSHIBA MK5065GS Rev: GJ00 Type: Hard Disk Capacity: 476940.0 MB = 465.7 GB (976773168 x 512) Device 0: (1:0) Vendor: ATA Prod.: STEC MACH8 SSD Rev: 1031 Type: Hard Disk Capacity: 57241.8 MB = 55.9 GB (117231408 x 512) Device 0: (1:1) Vendor: ATA Prod.: STEC MACH8 SSD Rev: 1031 Type: Hard Disk Capacity: 57241.8 MB = 55.9 GB (117231408 x 512) Found 4 device(s). Device 0: (0:0) Vendor: ATA Prod.: TOSHIBA MK5065GS Rev: GJ00 Type: Hard Disk Capacity: 476940.0 MB = 465.7 GB (976773168 x 512) ... is now current device Scanning scsi 0:1... Found U-Boot script /boot/boot.scr 2948 bytes read in 88 ms (32.2 KiB/s) ## Executing script at 03000000 Boot script loaded from scsi 199 bytes read in 54 ms (2.9 KiB/s) 18933 bytes read in 167 ms (110.4 KiB/s) 5408781 bytes read in 223 ms (23.1 MiB/s) 5590368 bytes read in 218 ms (24.5 MiB/s) ## Loading init Ramdisk from Legacy Image at 02880000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 5408717 Bytes = 5.2 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 02040000 Booting using the fdt blob at 0x2040000 Loading Ramdisk to 0fad7000, end 0ffff7cd ... OK reserving fdt memory region: addr=2040000 size=6a000 Loading Device Tree to 0fa6a000, end 0fad6fff ... OK Starting kernel ... Uncompressing Linux... done, booting the kernel. Helios4 boot from SPI with rootfs located on scsi 0:1 To access the SATA disk, you have to use scsi command instead of sata command

Hi, yes, you can see the boot process from serial. you can follow the instruction in our wiki. After the serial terminal ready, you can press the reset button to see the boot process since very beginning. You should see something like: U-Boot SPL 2018.11-armbian (Jan 20 2019 - 20:02:45 -0800) High speed PHY - Version: 2.0 Detected Device ID 6828 board SerDes lanes topology details: | Lane # | Speed | Type | -------------------------------- | 0 | 6 | SATA0 | | 1 | 5 | USB3 HOST0 | | 2 | 6 | SATA1 | | 3 | 6 | SATA3 | | 4 | 6 | SATA2 | | 5 | 5 | USB3 HOST1 | -------------------------------- High speed PHY - Ended Successfully mv_ddr: mv_ddr-armada-17.10.4 DDR3 Training Sequence - Switching XBAR Window to FastPath Window DDR Training Sequence - Start scrubbing DDR3 Training Sequence - End scrubbing mv_ddr: completed successfully Trying to boot from MMC1 U-Boot 2018.11-armbian (Jan 20 2019 - 20:02:45 -0800) SoC: MV88F6828-A0 at 1600 MHz DRAM: 2 GiB (800 MHz, 32-bit, ECC enabled) MMC: mv_sdh: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment Model: Helios4 Board: Helios4 SCSI: MVEBU SATA INIT Target spinup took 0 ms. SATA link 1 timeout. AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode flags: 64bit ncq led only pmp fbss pio slum part sxs Net: Warning: ethernet@70000 (eth1) using random MAC address - 52:fc:90:b3:be:70 eth1: ethernet@70000 Hit any key to stop autoboot: 3 2 1 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 1979 bytes read in 104 ms (18.6 KiB/s) ## Executing script at 03000000 Boot script loaded from mmc 220 bytes read in 86 ms (2 KiB/s) 19717 bytes read in 353 ms (53.7 KiB/s) 4714605 bytes read in 852 ms (5.3 MiB/s) 5460016 bytes read in 1037 ms (5 MiB/s) ## Loading init Ramdisk from Legacy Image at 02880000 ... Image Name: uInitrd Created: 2019-02-07 11:42:01 UTC Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 4714541 Bytes = 4.5 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 02040000 Booting using the fdt blob at 0x2040000 Using Device Tree in place at 02040000, end 02047d04 Starting kernel ... But i think you won't see that screen. LED8 near power inlet indicate the input voltage, if it's blink (nothing fancy here, just LED connected to 12V 3.3V) then it's a hardware problem. most probably the power adapter. Do you have a voltmeter? Could you measure the voltage on these pin to determine whether it's power adapter or on-board regulator failure.

Could you do the following and connect the serial console We need more info what event causing the system to wake up. and how did you put the system to standby?

Hi, could you append extraargs=no_console_suspend ignore_loglevel to /boot/armbianEnv.txt and set loglevel to 8? 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 then reboot the system to apply the changes. Those command would disable log filtering and print some debug info when the system entering suspend mode.

Well, you could boot from USB but first you need to set Helios4 to boot from SPI NOR flash. You can check how to do it on our wiki. In the end of the page there is Moving RootFS to Other Device section to transfer your existing OS in SDCard to USB Storage. Or if you want to start fresh, you could also write/burn the Armbian image directly to USB pendrive instead of SDCard.

Regarding OS on hard drive, it's possible as long as it does not reside on top of RAID. U-Boot does not understand MD so it could not load boot files from there. You need to sacrifice 1 drive to be used as OS drive or maybe, since i haven't tried it, allocated a partition for OS and let MD use the rest of the disk capacity. That being said, currently we don't support OS on hard drive. Personally I opt for OS in sdcard, because it does not poke out/extrude, easier to update the bootloader and i have plenty of them. I admit those are not strong reason. Small dimension reason can easily dismissed by some USB pendrive model that quite small such as these SanDisk Ultra Fit. Also there might be performance advantage using pendrive. SanDisk Ultra Fit stated that it has speed up to 130MB/s while SanDisk Extreme Pro *only* 100 MB/s. I'm not sure how reliable the USB pendrive to run in 24/7. Early model of SanDisk Ultra Fit (right hand side on above photo), quite hot after a while. The current model, which is fully plastic, does not have such issue.

I'm sorry, my bad, I accidentally include UHS-I SD card patch on that test kernel, the DTB to be exact, and apparently your card does not compatible. You can read more about this at SDIO (SD Card) page on our wiki. You just need to install the linux-image package. No need to install the dtb and headers. Regarding XOR, yes i notice it too. I think it would default to software implementation first then override later by async_tx if the hardware offload engine is available. You can see on kernel message below, the async_tx initialized quite late compared to xor and raid6. [ 0.004600] xor: measuring software checksum speed [ 0.043885] arm4regs : 2533.000 MB/sec [ 0.083885] 8regs : 1947.000 MB/sec [ 0.123884] 32regs : 1804.000 MB/sec [ 0.163884] neon : 1840.000 MB/sec [ 0.163887] xor: using function: arm4regs (2533.000 MB/sec) <...> [ 0.240055] raid6: int32x1 gen() 262 MB/s [ 0.307944] raid6: int32x1 xor() 271 MB/s [ 0.376037] raid6: int32x2 gen() 351 MB/s [ 0.443939] raid6: int32x2 xor() 329 MB/s [ 0.512026] raid6: int32x4 gen() 393 MB/s [ 0.579947] raid6: int32x4 xor() 319 MB/s [ 0.647890] raid6: int32x8 gen() 422 MB/s [ 0.715956] raid6: int32x8 xor() 324 MB/s [ 0.783897] raid6: neonx1 gen() 1212 MB/s [ 0.851888] raid6: neonx1 xor() 1150 MB/s [ 0.919918] raid6: neonx2 gen() 1296 MB/s [ 0.987897] raid6: neonx2 xor() 1347 MB/s [ 1.055893] raid6: neonx4 gen() 1349 MB/s [ 1.123902] raid6: neonx4 xor() 1377 MB/s [ 1.191883] raid6: neonx8 gen() 1073 MB/s [ 1.259882] raid6: neonx8 xor() 1041 MB/s [ 1.259885] raid6: using algorithm neonx4 gen() 1349 MB/s [ 1.259888] raid6: .... xor() 1377 MB/s, rmw enabled [ 1.259891] raid6: using neon recovery algorithm <...> [ 1.425544] mv_xor f1060800.xor: Marvell shared XOR driver [ 1.457595] mv_xor f1060800.xor: Marvell XOR (Descriptor Mode): ( xor cpy intr ) [ 1.457693] mv_xor f1060900.xor: Marvell shared XOR driver [ 1.485586] mv_xor f1060900.xor: Marvell XOR (Descriptor Mode): ( xor cpy intr ) <...> [ 4.580251] async_tx: api initialized (async) I built another test kernel with "DMA Engine verbose debugging" option enabled. These lines printed repeatedly (well, not exactly same address) during dd from /dev/zero to /dev/md0 and the interrupt counter increased. [ 416.505470] mv_xor f1060800.xor: mv_xor_prep_dma_xor src_cnt: 1 len: 4096 dest 0x216eb000 flags: 32 [ 416.514571] mv_xor f1060800.xor: mv_xor_prep_dma_xor sw_desc ed89d780 async_tx ed89d79c [ 416.522719] mv_xor f1060800.xor: mv_xor_tx_submit sw_desc ed89d780: async_tx ed89d79c [ 416.530582] mv_xor f1060800.xor: mv_chan_start_new_chain 190: sw_desc ed89d780 [ 416.537865] mv_xor f1060800.xor: activate chan. [ 416.542544] mv_xor f1060800.xor: intr cause 2 [ 416.546915] mv_xor f1060800.xor: mv_chan_clear_eoc_cause, val 0xfffffff8 [ 416.553658] mv_xor f1060800.xor: mv_chan_slot_cleanup 280 [ 416.559076] mv_xor f1060800.xor: current_desc 7f056380 [ 416.564253] mv_xor f1060800.xor: mv_chan_clean_completed_slots 227 [ 416.570461] mv_xor f1060800.xor: mv_desc_clean_slot 247: desc ed89d780 flags 32 [ 416.577803] mv_xor f1060800.xor: mv_xor_prep_dma_xor src_cnt: 1 len: 4096 dest 0x2ceaf000 flags: 32 [ 416.586894] mv_xor f1060800.xor: mv_xor_prep_dma_xor sw_desc ed89da00 async_tx ed89da1c [ 416.595019] mv_xor f1060800.xor: mv_xor_tx_submit sw_desc ed89da00: async_tx ed89da1c [ 416.602890] mv_xor f1060800.xor: mv_chan_start_new_chain 190: sw_desc ed89da00 [ 416.610142] mv_xor f1060800.xor: activate chan. --- Initially I had no idea why the update break the system. I did several time testing the update scenario from 5.64 to 5.68 & 5.69 (both are internal release). Then I realized that I missed that you started from 5.67 which i thought never released. I would say, the 5.67 contains broken u-boot 2018.11. It only compatible with boot-mvebu-next.cmd. It already fixed on this commit part of PR #1169. So version 5.68 onward should be compatible with both, boot-marvell.cmd and boot-mvebu-next.cmd. Since the fix just modify the environment variable, I suggest to run these commands to make it also compatible with boot-marvell.cmd. setenv boot_a_script 'load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; setenv boot_interface ${devtype};source ${scriptaddr}' setenv loadaddr 0x02000000 setenv fdt_addr ${fdt_addr_r} saveenv I have tested it on 5.67

@djurny Thanks to bring this up to us. Apparently we missed CONFIG_ASYNC_TX_DMA=y in kernel configuration during the transition from mvebu-default (LK 4.4) to mvebu-next (LK 4.1x). After enabling, recompile the kernel and creating new 8GB array (RAID 5, 3x 4GB), here is what i got 46: 483063 0 GIC-0 54 Level f1060800.xor 47: 554757 0 GIC-0 97 Level f1060900.xor You can find the kernel on our repo. We did some test and found no difference in term of CPU load and performance. We still investigating how to take advantage of MV_XOR to improve perf and/or system load.

@taziden which kernel version/release currently installed on your system? you can check using uname -r if it's 4.14.88-mvebu you can download the header and install it using wget https://apt.kobol.io/pool/main/l/linux-4.14.88-mvebu/linux-headers-next-mvebu_5.68_armhf.deb sudo dpkg -i linux-headers-next-mvebu_5.68_armhf.deb Other than that version you can install it using the usual apt sudo apt-get install linux-headers-next-mvebu

@malcolm armbianmonitor get the value from wrong sensor. It's inherited from sensor list under Linux kernel 4.4. We have reported it to Armbian on this issue 1135. We are working to fix this. Since this could affect other board as well, we need to test carefully. The correct reading is the one reported by htop. You could also read the CPU temp using cat /sys/devices/virtual/thermal/thermal_zone0/temp

Hi @thermalz, could you try sudo systemctl stop fancontrol echo 255 | sudo tee -a /sys/devices/platform/j17-pwm/hwmon/hwmon*/pwm1 and see whether the fan running full speed

Hi @Zykr, I just wanted to add on top of @gprovost instruction Replace the loglevel in the bootargs with "ignore_loglevel earlyprintk earlycon" so the kernel can output debug message as earliest as possible. And since you encountered problem with the ramdisk, maybe just skip it for now Below is the modified command setenv bootargs "console=ttyS0,115200 root=/dev/mmcblk0p1 rootwait rootfstype=ext4 ubootdev=mmc scandelay ignore_loglevel earlyprintk earlycon" load mmc 0:1 ${fdt_addr} /boot/dtb-4.14.83-mvebu/${fdtfile} load mmc 0:1 ${kernel_addr_r} /boot/vmlinuz-4.14.83-mvebu setenv fdt_high 0xffffffff setenv initrd_high 0xffffffff bootz ${kernel_addr_r} - ${fdt_addr}