gprovost Posted January 8, 2019 Author Posted January 8, 2019 @matzman666 Thanks for pointing to your test. It's true OMV default settings are not the best to get the best performance out of Helios4. It's always a trade off between ease of use and expert mode tweaking. Will need to see if we can tweak those settings during OMV install, but not really our priority right now. @Tom3kK Yeah it's on top of our TODO list now to implement WoL. Should be implemented in the next 2-3 weeks.
gabest Posted January 12, 2019 Posted January 12, 2019 (edited) Is it still a bad idea to run zfs on a 32bit CPU? I heard that there was a problem with memory allocation and that there were efforts to re-implement zfs on linux to fix it, but not sure if the zfsonlinux project on github is that one or still the old one. I have compiled it nonetheless and it seems to be working fine for a 4x1.5gb raidz configuration. Won't use it though because it won't integrate with OMV and folder sharing is only possible with file systems it recognizes, and I'm not that big of linux guy to set it up myself. (the zlua module won't load because of some setjmp error, but I have temporarily disabled it and compiled it that way, only a newly implemented minor feature of zfs does not work because of it) Edited January 12, 2019 by gabest
djurny Posted January 13, 2019 Posted January 13, 2019 Hi, I'm not sure if this is a known bug or not, but just posting here FYI. I've been tinkering with 'fancontrol' recently. During testing I found that 'fancontrol' leaves the fans full stop when it bails out on any error. The 'disablepwm' function seems to have a tiny bug that actually sets the PWM value to it's minimum value in case a 'pwmX_enable' file cannot be found - which is the case for Armbian on Helios4: # ls /dev/fan-j1[07]/ /sys/class/hwmon/hwmon[23]/ /dev/fan-j10/: device name of_node power pwm1 subsystem uevent /dev/fan-j17/: device name of_node power pwm1 subsystem uevent /sys/class/hwmon/hwmon2/: device name of_node power pwm1 subsystem uevent /sys/class/hwmon/hwmon3/: device name of_node power pwm1 subsystem uevent This minimum value causes the fans on my box to come to a full stop. For my box, in case 'fancontrol' bails out, I'd like the fans to go full speed. # $1 = pwm file name function pwmdisable() { local ENABLE=${1}_enable # No enable file? Just set to max if [ ! -f $ENABLE ] then ##[BUG] echo $MINPWM > $1 ##[BUG] return 0 ##[begin] Fixup to make sure fans return to their full speed when we bail out for VALUE in "${MAXPWM:-}" "${MAX:-}" '255' do if expr "${VALUE:-}" : '^[0-9][0-9]*$' > /dev/null then # VALUE looks like a numerical value if ( echo "${VALUE:-255}" > $1 ) then echo "Successfully written value '${VALUE:-N/A}' to PWM file '${1:-N/A}'." return # to caller fi # ...try next method fi done false return The fixup above worked for me, but USE AT YOUR OWN RISK. Groetjes,
Harvey Posted January 13, 2019 Posted January 13, 2019 Hi, (happy) new Helios4 owner here. I have a questing regarding power consumption: I'm running a new, clean setup based on Armbian_5.68_Helios4_Debian_stretch_next_4.14.88.img.xz. With no additional drives powered up, a cheap power meter shows the following results: System running idle: 4-5 W System halted after "poweroff": 6-7 W. With two WD Red 8TB EFAX (still unconfigured) and one SSD 128GB (root fs) I get System running idle, disks spinning: 23 W System halted after "poweroff": 9 W. Why does the halted system consume that much energy? TIA Heinz
djurny Posted January 14, 2019 Posted January 14, 2019 On 2/21/2018 at 6:18 AM, gprovost said: @jnko In regards to XOR engine : Check your kernel message you should see the kernel has detected 2 XOR engines. [ 0.737452] mv_xor f1060800.xor: Marvell shared XOR driver [ 0.776401] mv_xor f1060800.xor: Marvell XOR (Descriptor Mode): ( xor cpy intr pq ) [ 0.776570] mv_xor f1060900.xor: Marvell shared XOR driver [ 0.816397] mv_xor f1060900.xor: Marvell XOR (Descriptor Mode): ( xor cpy intr pq ) In the current mvebu kernel configs, mv_xor driver is part of the kernel, not a module. But I agree there is no obvious way to say if the system offload on the hardware XOR engine. Hi, I'm building my second box and was going for a mdadm RAID setup there. After doing some throughput tests, I found that the mv_xor unit is not used when accessing data on a RAID array (in my case I'm trying RAID6 for now). It's indeed a kernel builtin, but it looks like it's initialized after the other builtins are initialized. Dec 14 08:56:44 localhost kernel: [ 0.004541] xor: measuring software checksum speed Dec 14 08:56:44 localhost kernel: [ 0.043886] arm4regs : 2534.000 MB/sec <...> Dec 14 08:56:44 localhost kernel: [ 0.163886] xor: using function: arm4regs (2534.000 MB/sec) <snip> Dec 14 08:56:44 localhost kernel: [ 0.239983] raid6: int32x1 gen() 270 MB/s <...> <...> Dec 14 08:56:44 localhost kernel: [ 1.259902] raid6: neonx8 xor() 1041 MB/s Dec 14 08:56:44 localhost kernel: [ 1.259904] raid6: using algorithm neonx4 gen() 1349 MB/s Dec 14 08:56:44 localhost kernel: [ 1.259906] raid6: .... xor() 1377 MB/s, rmw enabled Dec 14 08:56:44 localhost kernel: [ 1.259908] raid6: using neon recovery algorithm <snip> Dec 14 08:56:44 localhost kernel: [ 1.425179] mv_xor f1060800.xor: Marvell shared XOR driver Dec 14 08:56:44 localhost kernel: [ 1.461595] mv_xor f1060800.xor: Marvell XOR (Descriptor Mode): ( xor cpy intr ) Dec 14 08:56:44 localhost kernel: [ 1.461694] mv_xor f1060900.xor: Marvell shared XOR driver Dec 14 08:56:44 localhost kernel: [ 1.493578] mv_xor f1060900.xor: Marvell XOR (Descriptor Mode): ( xor cpy intr ) The previous builtins do benchmarking without seeing the mv_xor modules and both choose a SW method for xor'ing. This is also evident by checking if the xor units produce any IRQs during writing to RAID array: almost no IRQs for either xor module: 46: 2 0 GIC-0 54 Level f1060800.xor 47: 2 0 GIC-0 97 Level f1060900.xor Unfortunately, I don't have the time to deep-dive into this, but from previous experience with building kernels and doing some optimizations with changing initialization order of kernel builtins, it would help if this module is linked before both 'crypto/async_tx' and 'raid6' (not sure about the latter builtin/module name) - Link order determines the initialization order for builtin kernel modules. Where to address this? Groetjes,
gprovost Posted January 15, 2019 Author Posted January 15, 2019 Sorry guys for late reply. I'm getting soon married and I'm pretty overloaded between Helios4 delivery follow-up and taking care of this big personal event. So please bare the latency in the coming days. Everything will be back to normal in February. @gabest To be honest we haven't done much experiment with ZFS but we have couple of people that reported good feedback and performance with ZoL on Helios4. Most of them where using mirror vdev instead of raidz mode, you can find plenty of discussion on this topic but it's an important factor in the case of Helios4. The other important factor for good ZFS perf on Helios4 is deduplication. Actually the dedup mode is the main reason why ZFS need so much memory, so with 2GB in Helios4, you need to disable dedup if you want good perf. In regards to ZoL maturity / stability on 32bit system, I don't have much insight on this. I just know that starting v0.7.0 some improvement were made for 32-bit stability. So for this reason it is recommended to use ZFS from stretch-backports (https://packages.debian.org/stretch-backports/zfsutils-linux) @djurny Actually we modified fancontrol on purpose in order to set the fan speed to 0 when fancontrol exit. This was to address the use case when someone power down the system, in this case you don't want the fan to go full speed. But after the message from Harvey and my response below, I think there is a bit of contraction in our logic. Let me think about this and we might just revert the fancontrol to its original behavior. @Harvey Helios4 Power Management is rather simple since it was designed for a system that is running 24/7 (or in IDLE/DEEP IDLE state if you want to use Wake-on-LAN). We didn't include a PMIC in our design to address this specific use case of powered off system. When you halt your system, the Helios4 SoC power domain will remain ON and since there is no more OS running so there no more CPU Dynamic Frequency Scaling (DFS), so my guess is the SoC is running at its highest clock when system is halted compared to idle. This would explain the difference between in power consumption System IDLE and System Powered-Off. However we will need to double check that. @djurny Humm very good point. When I was doing benchmark during the early stage of the project, it didn't get to my mind to check the /proc/interrupts. Only later when working on the CESA engine I figured out checking the interrupts was the way to check if engines were used to offload operations. It completely slipped my mind to do the same check again for XOR engines. Well thanks to you, I can see my early assumption was wrong. We will need to investigate how to force system to use the MV_XOR and how it would improve performance and/or system load. 1
aprayoga Posted January 18, 2019 Posted January 18, 2019 @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.
djurny Posted January 18, 2019 Posted January 18, 2019 6 hours ago, aprayoga said: @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. Hi, Eager to test out the new linux-4.14.94-mvebu kernel, but I'm having some boot issues with it; SDcard refuses to be detected by the kernel: <snip> [ 1.657831] Key type encrypted registered [ 1.658709] USB-PWR: supplied by power_brick_12V [ 1.739202] mmc0: error -110 whilst initialising SD card [ 1.860846] ata1: SATA link down (SStatus 0 SControl 300) [ 1.861044] ata2: SATA link down (SStatus 0 SControl 300) <snip> Hopefully it's just the SDcard itself being broken. (Although it's a 4 weeks old branded one.) I'll give an update once I get my box going. -[ update ]- SDcard is fine. There is something NOK with the new image/headers/dtb. After hacking it back to 4.14.92-mvebu all was fine again. I still want to test this, but I'm not sure what is causing the mmc driver from not detecting my SDcard? Do I need to update/install more than just image, headers and dtb packages? -[ edit ]- Also, do note that during 4.14.94-mvebu kernel boot, both modules mentioned before are still opting for SW methods instead of using the xor engines. It looks like mv_xor initialization/publishing is still done after the benchmark & selection is done by crypto/async_tx & raid6? Thanks, Groetjes,
integros Posted January 18, 2019 Posted January 18, 2019 Finally found the time to assemble my Helios4, downloaded the Image (4.14.83 stretch), connected via ssh, created a new user and made some changes for my network. Rebooted and everything was working fine. Tried to update via armbian-config, but as soon as I rebooted the card/system was no longer recognised. Tried to update via apt upgrade/update and also tried the bionic image. Always the same result - the system doesn't boot after trying to update, no LED was blinking. Putting the original Image (4.14.83 stretch or bionic) back to the same SD-Card solved the boot problem.
Igor Posted January 18, 2019 Posted January 18, 2019 10 minutes ago, integros said: Tried to update via armbian-config, but as soon as I rebooted the card/system was no longer recognised. This should not happen. Can you explain exactly what you did and provide serial console logs.
integros Posted January 18, 2019 Posted January 18, 2019 1 hour ago, Igor said: This should not happen. Can you explain exactly what you did and provide serial console logs. It's late here, but I'll try to provide the serial console logs tomorrow. What I did was quite straight forward. Downloaded the Image, flashed it to a SD card with etcher, booted, logged in as root via ssh, created new user, changed IP to a static IP, rebooted, logged in as new user, tried to update, reboot - no more lights, no longer able to connect. Tried this with armbian-config, with apt update and with the bionic Image. Always the same result.
lanefu Posted January 19, 2019 Posted January 19, 2019 In the spirit of me too... here's my console output of failed boot Spoiler ## Loading init Ramdisk from Legacy Image at 02880000 ... Image Name: uInitrd Created: 2019-01-18 3:18:38 UTC Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 6595420 Bytes = 6.3 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Starting kernel ... Uncompressing Linux... done, booting the kernel. Error: unrecognized/unsupported machine ID (r1 = 0x00000000). Available machine support: ID (hex) NAME ffffffff Generic DT based system ffffffff Marvell Armada 39x (Device Tree) ffffffff Marvell Armada 380/385 (Device Tree) ffffffff Marvell Armada 375 (Device Tree) ffffffff Marvell Armada 370/XP (Device Tree) ffffffff Marvell Dove Please check your kernel config and/or bootloader. and here's what printenv says Spoiler => printenv arch=arm baudrate=115200 board=helios4 board_name=helios4 boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr} boot_efi_binary=if fdt addr ${fdt_addr_r}; then bootefi bootmgr ${fdt_addr_r};else bootefi bootmgr ${fdtcontroladdr};fi;load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/bootarm.efi; if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r};else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}extlinux/extlinux.conf boot_net_usb_start=usb start boot_prefixes=/ /boot/ boot_script_dhcp=boot.scr.uimg boot_scripts=boot.scr.uimg boot.scr boot_targets=mmc0 usb0 pxe dhcp bootcmd=run distro_bootcmd bootcmd_dhcp=run boot_net_usb_start; if dhcp ${scriptaddr} ${boot_script_dhcp}; then source ${scriptaddr}; fi;setenv efi_fdtfile ${fdtfile}; if test -z "${fdtfile}" -a -n "${soc}"; then setenv efi_fdtfile ${soc}-${board}${boardver}.dtb; fi; setenv efi_old_vci ${bootp_vci};setenv efi_old_arch ${bootp_arch};setenv bootp_vci PXEClient:Arch:00010:UNDI:003000;setenv bootp_arch 0xa;if dhcp ${kernel_addr_r}; then tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r}; else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi;fi;setenv bootp_vci ${efi_old_vci};setenv bootp_arch ${efi_old_arch};setenv efi_fdtfile;setenv efi_old_arch;setenv efi_old_vci; bootcmd_mmc0=setenv devnum 0; run mmc_boot bootcmd_pxe=run boot_net_usb_start; dhcp; if pxe get; then pxe boot; fi bootcmd_usb0=setenv devnum 0; run usb_boot bootdelay=3 console=ttyS0,115200 cpu=armv7 distro_bootcmd=setenv scsi_need_init; for target in ${boot_targets}; do run bootcmd_${target}; done efi_dtb_prefixes=/ /dtb/ /dtb/current/ fdt_addr_r=0x2040000 fdt_high=0x10000000 fdtcontroladdr=7fb69b78 fdtfile=armada-388-helios4.dtb initrd_high=0x10000000 kernel_addr_r=0x2080000 load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}${efi_fdtfile} mmc_boot=if mmc dev ${devnum}; then setenv devtype mmc; run scan_dev_for_boot_part; fi pxefile_addr_r=0x3100000 ramdisk_addr_r=0x2880000 scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;run scan_dev_for_efi; scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; if test -z "${fdtfile}" -a -n "${soc}"; then setenv efi_fdtfile ${soc}-${board}${boardver}.dtb; fi; for prefix in ${efi_dtb_prefixes}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${efi_fdtfile}; then run load_efi_dtb; fi;done;if test -e ${devtype} ${devnum}:${distro_bootpart} efi/boot/bootarm.efi; then echo Found EFI removable media binary efi/boot/bootarm.efi; run boot_efi_binary; echo EFI LOAD FAILED: continuing...; fi; setenv efi_fdtfile scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}extlinux/extlinux.conf; then echo Found ${prefix}extlinux/extlinux.conf; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done scriptaddr=0x3000000 scsi_boot=run scsi_init; if scsi dev ${devnum}; then setenv devtype scsi; run scan_dev_for_boot_part; fi scsi_init=if ${scsi_need_init}; then setenv scsi_need_init false; scsi scan; fi soc=mvebu stderr=serial@12000 stdin=serial@12000 stdout=serial@12000 usb_boot=usb start; if usb dev ${devnum}; then setenv devtype usb; run scan_dev_for_boot_part; fi vendor=kobol Environment size: 4002/8188 bytes uhh /boot is there a way to cat a file in u-boot? Spoiler => ls mmc 0 /boot <DIR> 4096 . <DIR> 4096 .. <SYM> 21 uInitrd <SYM> 21 zImage <SYM> 17 dtb 123807 config-4.14.92-mvebu 38518 boot.bmp 0 .next 1536 armbian_first_run.txt.template 6595420 initrd.img-4.14.92-mvebu 207 armbianEnv.txt 6595484 uInitrd-4.14.92-mvebu 4882 boot-desktop.png 1907 boot.cmd 1979 boot.scr <SYM> 17 dtb.old 5457936 vmlinuz-4.14.92-mvebu 2180543 System.map-4.14.92-mvebu <DIR> 4096 dtb-4.14.92-mvebu
lanefu Posted January 19, 2019 Posted January 19, 2019 so i copied the boot.cmd from the helios4 armbian 5.67 image and then made the boot.scr from it and put it on the sd card... booted up cleanly. the file size between the old boot.cmd and the failing one is significant... failing one is like half the size here's a diff Spoiler lane@gpiolite:~$ diff boot.cmd badboot.cmd 6d5 < setenv load_addr "0x300000" 11a11 > setenv spi_workaround "off" 17,20c17,19 < echo "Boot script loaded from ${devtype}" < < if load ${devtype} ${devnum} ${load_addr} ${prefix}armbianEnv.txt; then < env import -t ${load_addr} ${filesize} --- > # fdtfile should come from compile-time u-boot patches > if test -z "${fdtfile}"; then > setenv fdtfile "armada-388-clearfog.dtb" 23c22,24 < setenv bootargs "console=ttyS0,115200 root=${rootdev} rootwait rootfstype=${rootfstype} ubootdev=${devtype} scandelay loglevel=${verbosity} usb-storage.quirks=${usbstoragequirks} ${extraargs}" --- > test -z "${boot_interface}" && setenv boot_interface "mmc" > > echo "Boot script loaded from ${boot_interface}" 25,55c26,27 < load ${devtype} ${devnum} ${fdt_addr_r} ${prefix}dtb/${fdtfile} < load ${devtype} ${devnum} ${ramdisk_addr_r} ${prefix}uInitrd < load ${devtype} ${devnum} ${kernel_addr_r} ${prefix}zImage < < fdt addr ${fdt_addr_r} < fdt resize 65536 < for overlay_file in ${overlays}; do < if load ${devtype} ${devnum} ${load_addr} ${prefix}dtb/overlay/${overlay_prefix}-${overlay_file}.dtbo; then < echo "Applying kernel provided DT overlay ${overlay_prefix}-${overlay_file}.dtbo" < fdt apply ${load_addr} || setenv overlay_error "true" < fi < done < for overlay_file in ${user_overlays}; do < if load ${devtype} ${devnum} ${load_addr} ${prefix}overlay-user/${overlay_file}.dtbo; then < echo "Applying user provided DT overlay ${overlay_file}.dtbo" < fdt apply ${load_addr} || setenv overlay_error "true" < fi < done < if test "${overlay_error}" = "true"; then < echo "Error applying DT overlays, restoring original DT" < load ${devtype} ${devnum} ${fdt_addr_r} ${prefix}dtb/rockchip/${fdtfile} < else < if load ${devtype} ${devnum} ${load_addr} ${prefix}dtb/overlay/${overlay_prefix}-fixup.scr; then < echo "Applying kernel provided DT fixup script (${overlay_prefix}-fixup.scr)" < source ${load_addr} < fi < if test -e ${devtype} ${devnum} ${prefix}fixup.scr; then < load ${devtype} ${devnum} ${load_addr} ${prefix}fixup.scr < echo "Applying user provided fixup script (fixup.scr)" < source ${load_addr} < fi --- > if load ${boot_interface} 0:1 ${loadaddr} ${prefix}armbianEnv.txt; then > env import -t ${loadaddr} ${filesize} 57a30,38 > setenv bootargs "console=ttyS0,115200 root=${rootdev} rootwait rootfstype=${rootfstype} ubootdev=${boot_interface} scandelay loglevel=${verbosity} usb-storage.quirks=${usbstoragequirks} ${extraargs}" > > load ${boot_interface} 0:1 ${fdt_addr} ${prefix}dtb/${fdtfile} > load ${boot_interface} 0:1 ${ramdisk_addr_r} ${prefix}uInitrd > load ${boot_interface} 0:1 ${kernel_addr_r} ${prefix}zImage > > setenv fdt_high 0xffffffff > setenv initrd_high 0xffffffff > 60a42,43 > fdt addr ${fdt_addr} > fdt resize 76c59 < bootz ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r} --- > bootz ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr}
integros Posted January 19, 2019 Posted January 19, 2019 15 hours ago, Igor said: This should not happen. Can you explain exactly what you did and provide serial console logs. Here is the serial console log: Spoiler U-Boot SPL 2018.11-armbian (Nov 26 2018 - 09:25:57 +0100) 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 (Nov 26 2018 - 09:25:57 +0100) 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. 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 - aa:61:eb:18:90:59 eth1: ethernet@70000 Hit any key to stop autoboot: 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 106 ms (17.6 KiB/s) ## Executing script at 03000000 Boot script loaded from mmc load - load binary file from a filesystem Usage: load <interface> [<dev[:part]> [<addr> [<filename> [bytes [pos]]]]] - Load binary file 'filename' from partition 'part' on device type 'interface' instance 'dev' to address 'addr' in memory. 'bytes' gives the size to load in bytes. If 'bytes' is 0 or omitted, the file is read until the end. 'pos' gives the file byte position to start reading from. If 'pos' is 0 or omitted, the file is read from the start. load - load binary file from a filesystem Usage: load <interface> [<dev[:part]> [<addr> [<filename> [bytes [pos]]]]] - Load binary file 'filename' from partition 'part' on device type 'interface' instance 'dev' to address 'addr' in memory. 'bytes' gives the size to load in bytes. If 'bytes' is 0 or omitted, the file is read until the end. 'pos' gives the file byte position to start reading from. If 'pos' is 0 or omitted, the file is read from the start. 4707429 bytes read in 886 ms (5.1 MiB/s) 5457936 bytes read in 1033 ms (5 MiB/s) ## Loading init Ramdisk from Legacy Image at 02880000 ... Image Name: uInitrd Created: 2019-01-19 11:57:53 UTC Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 4707365 Bytes = 4.5 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Starting kernel ... Uncompressing Linux... done, booting the kernel. Error: unrecognized/unsupported machine ID (r1 = 0x00000000). Available machine support: ID (hex) NAME ffffffff Generic DT based system ffffffff Marvell Armada 39x (Device Tree) ffffffff Marvell Armada 380/385 (Device Tree) ffffffff Marvell Armada 375 (Device Tree) ffffffff Marvell Armada 370/XP (Device Tree) ffffffff Marvell Dove Please check your kernel config and/or bootloader.
Igor Posted January 19, 2019 Posted January 19, 2019 3 hours ago, integros said: Here is the serial console log Fixed by removing broken files from repository: pool/main/l/linux-bionic-root-next-helios4/linux-bionic-root-next-helios4_5.70_armhf.deb pool/main/l/linux-stretch-root-next-helios4/linux-stretch-root-next-helios4_5.70_armhf.deb 2
integros Posted January 19, 2019 Posted January 19, 2019 36 minutes ago, Igor said: Fixed by removing broken files from repository: pool/main/l/linux-bionic-root-next-helios4/linux-bionic-root-next-helios4_5.70_armhf.deb pool/main/l/linux-stretch-root-next-helios4/linux-stretch-root-next-helios4_5.70_armhf.deb Thank you very much. Problem fixed. Time to set my Helios4 up. Some Questions to all Helios4-Users: - I have 3 HDDs and 1 SSD. Is there a way to put the whole System to the SSD and boot from it? Couldn't find an instruction how to achieve that. - I am planning to make all drives accessible to different Users in our LAN (no RAID). What is the most energy efficcient solution? OMV or setting everything manually up? - Is there a way to use an UPS with the Helios4? Similar to the use with a Synology?
aprayoga Posted January 19, 2019 Posted January 19, 2019 On 1/18/2019 at 7:57 PM, djurny said: Hi, Eager to test out the new linux-4.14.94-mvebu kernel, but I'm having some boot issues with it; SDcard refuses to be detected by the kernel: <snip> [ 1.657831] Key type encrypted registered [ 1.658709] USB-PWR: supplied by power_brick_12V [ 1.739202] mmc0: error -110 whilst initialising SD card [ 1.860846] ata1: SATA link down (SStatus 0 SControl 300) [ 1.861044] ata2: SATA link down (SStatus 0 SControl 300) <snip> Hopefully it's just the SDcard itself being broken. (Although it's a 4 weeks old branded one.) I'll give an update once I get my box going. -[ update ]- SDcard is fine. There is something NOK with the new image/headers/dtb. After hacking it back to 4.14.92-mvebu all was fine again. I still want to test this, but I'm not sure what is causing the mmc driver from not detecting my SDcard? Do I need to update/install more than just image, headers and dtb packages? -[ edit ]- Also, do note that during 4.14.94-mvebu kernel boot, both modules mentioned before are still opting for SW methods instead of using the xor engines. It looks like mv_xor initialization/publishing is still done after the benchmark & selection is done by crypto/async_tx & raid6? Thanks, Groetjes, 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. --- 16 hours ago, lanefu said: so i copied the boot.cmd from the helios4 armbian 5.67 image and then made the boot.scr from it and put it on the sd card... booted up cleanly. the file size between the old boot.cmd and the failing one is significant... failing one is like half the size here's a diff Hide contents lane@gpiolite:~$ diff boot.cmd badboot.cmd 6d5 < setenv load_addr "0x300000" 11a11 > setenv spi_workaround "off" 17,20c17,19 < echo "Boot script loaded from ${devtype}" < < if load ${devtype} ${devnum} ${load_addr} ${prefix}armbianEnv.txt; then < env import -t ${load_addr} ${filesize} --- > # fdtfile should come from compile-time u-boot patches > if test -z "${fdtfile}"; then > setenv fdtfile "armada-388-clearfog.dtb" 23c22,24 < setenv bootargs "console=ttyS0,115200 root=${rootdev} rootwait rootfstype=${rootfstype} ubootdev=${devtype} scandelay loglevel=${verbosity} usb-storage.quirks=${usbstoragequirks} ${extraargs}" --- > test -z "${boot_interface}" && setenv boot_interface "mmc" > > echo "Boot script loaded from ${boot_interface}" 25,55c26,27 < load ${devtype} ${devnum} ${fdt_addr_r} ${prefix}dtb/${fdtfile} < load ${devtype} ${devnum} ${ramdisk_addr_r} ${prefix}uInitrd < load ${devtype} ${devnum} ${kernel_addr_r} ${prefix}zImage < < fdt addr ${fdt_addr_r} < fdt resize 65536 < for overlay_file in ${overlays}; do < if load ${devtype} ${devnum} ${load_addr} ${prefix}dtb/overlay/${overlay_prefix}-${overlay_file}.dtbo; then < echo "Applying kernel provided DT overlay ${overlay_prefix}-${overlay_file}.dtbo" < fdt apply ${load_addr} || setenv overlay_error "true" < fi < done < for overlay_file in ${user_overlays}; do < if load ${devtype} ${devnum} ${load_addr} ${prefix}overlay-user/${overlay_file}.dtbo; then < echo "Applying user provided DT overlay ${overlay_file}.dtbo" < fdt apply ${load_addr} || setenv overlay_error "true" < fi < done < if test "${overlay_error}" = "true"; then < echo "Error applying DT overlays, restoring original DT" < load ${devtype} ${devnum} ${fdt_addr_r} ${prefix}dtb/rockchip/${fdtfile} < else < if load ${devtype} ${devnum} ${load_addr} ${prefix}dtb/overlay/${overlay_prefix}-fixup.scr; then < echo "Applying kernel provided DT fixup script (${overlay_prefix}-fixup.scr)" < source ${load_addr} < fi < if test -e ${devtype} ${devnum} ${prefix}fixup.scr; then < load ${devtype} ${devnum} ${load_addr} ${prefix}fixup.scr < echo "Applying user provided fixup script (fixup.scr)" < source ${load_addr} < fi --- > if load ${boot_interface} 0:1 ${loadaddr} ${prefix}armbianEnv.txt; then > env import -t ${loadaddr} ${filesize} 57a30,38 > setenv bootargs "console=ttyS0,115200 root=${rootdev} rootwait rootfstype=${rootfstype} ubootdev=${boot_interface} scandelay loglevel=${verbosity} usb-storage.quirks=${usbstoragequirks} ${extraargs}" > > load ${boot_interface} 0:1 ${fdt_addr} ${prefix}dtb/${fdtfile} > load ${boot_interface} 0:1 ${ramdisk_addr_r} ${prefix}uInitrd > load ${boot_interface} 0:1 ${kernel_addr_r} ${prefix}zImage > > setenv fdt_high 0xffffffff > setenv initrd_high 0xffffffff > 60a42,43 > fdt addr ${fdt_addr} > fdt resize 76c59 < bootz ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r} --- > bootz ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr} 6 hours ago, integros said: Here is the serial console log: Reveal hidden contents U-Boot SPL 2018.11-armbian (Nov 26 2018 - 09:25:57 +0100) 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 (Nov 26 2018 - 09:25:57 +0100) 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. 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 - aa:61:eb:18:90:59 eth1: ethernet@70000 Hit any key to stop autoboot: 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 106 ms (17.6 KiB/s) ## Executing script at 03000000 Boot script loaded from mmc load - load binary file from a filesystem Usage: load <interface> [<dev[:part]> [<addr> [<filename> [bytes [pos]]]]] - Load binary file 'filename' from partition 'part' on device type 'interface' instance 'dev' to address 'addr' in memory. 'bytes' gives the size to load in bytes. If 'bytes' is 0 or omitted, the file is read until the end. 'pos' gives the file byte position to start reading from. If 'pos' is 0 or omitted, the file is read from the start. load - load binary file from a filesystem Usage: load <interface> [<dev[:part]> [<addr> [<filename> [bytes [pos]]]]] - Load binary file 'filename' from partition 'part' on device type 'interface' instance 'dev' to address 'addr' in memory. 'bytes' gives the size to load in bytes. If 'bytes' is 0 or omitted, the file is read until the end. 'pos' gives the file byte position to start reading from. If 'pos' is 0 or omitted, the file is read from the start. 4707429 bytes read in 886 ms (5.1 MiB/s) 5457936 bytes read in 1033 ms (5 MiB/s) ## Loading init Ramdisk from Legacy Image at 02880000 ... Image Name: uInitrd Created: 2019-01-19 11:57:53 UTC Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 4707365 Bytes = 4.5 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Starting kernel ... Uncompressing Linux... done, booting the kernel. Error: unrecognized/unsupported machine ID (r1 = 0x00000000). Available machine support: ID (hex) NAME ffffffff Generic DT based system ffffffff Marvell Armada 39x (Device Tree) ffffffff Marvell Armada 380/385 (Device Tree) ffffffff Marvell Armada 375 (Device Tree) ffffffff Marvell Armada 370/XP (Device Tree) ffffffff Marvell Dove Please check your kernel config and/or bootloader. 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 2
integros Posted January 19, 2019 Posted January 19, 2019 1 hour ago, aprayoga said: 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 5.67 ist the official/latest release. How do I enter your commands? With bash (default shell here) I always get "setenv: command not found".
martinayotte Posted January 19, 2019 Posted January 19, 2019 1 hour ago, integros said: How do I enter your commands? With bash (default shell here) I always get "setenv: command not found". Those are u-boot command line ... This mean you need to hit <spacebar> at the moment u-boot start booting, then you can type those commands ...
gprovost Posted January 20, 2019 Author Posted January 20, 2019 Let me explain a bit more the issue that was experienced by @integros @lanefu and could happen to anyone that did a fresh install using release 5.67 and then attempting a system upgrade. This boot issue happens because new u-boot package (5.70) doesn't anymore update automatically the u-boot bootloader binary on target however bsp package (aka linux-****-root-next-helios4_5.**_armhf.deb) still update the bootscript. Therefore it will create an incompatibility case between bootloader and bootscript that we experience already in the past following upgrade form u-boot 2013 to u-boot 2018. We did address this incompatible use case previously but we didn't foresee it would happen again because of that recent decision that u-boot package shouldn't anymore be automatically updated. We unfortunately created a tricky situation and we need to find a solution that works for everyone, that includes people running release 5.67, they should be able to upgrade without being aware of this issue. In the meantime : To everybody, when you do a fresh install please don't use version 5.67 on Armbian website, but use our latest image build (5.68) that is available on our wiki here until a new image build is done by Armbian. 1
gprovost Posted January 20, 2019 Author Posted January 20, 2019 @Igor Any chance you could build and publish a 5.70 image, and remove all the previous image release on armbian download page ? Or instead you could copy over our 5.68. In the meantime we are looking at a solution for people to be able to upgrade to 5.7x from version prior to 5.68 without facing the above issue.
Igor Posted January 20, 2019 Posted January 20, 2019 1 hour ago, gprovost said: Any chance you could build and publish a 5.70 image, and remove all the previous image release on armbian download page ? Or instead you could copy over our 5.68. Rebuilding images is the easiest part, its fully automated and it was ignited. I will also push updated packages to the repository but I don't have time to check. I hope problems are solved.
gprovost Posted January 20, 2019 Author Posted January 20, 2019 (edited) @Igor The problem is upgrade from 5.67 and prior to version 5.7x. So if you publish updated packages the issue will still be there. Please don't publish any new packages till our next PR. I think I found a nice workaround to address people running 5.67 or prior who want to update to 5.7x without messing up their system. In a nutshell I'm moving the bootscript upgrade to nand-sata-install. When you update your bootloader via armbian-config (nand-sata-install) if it detect there is a new boot script in /boot (boot.cmd.new or boot.ini.new) then it will update the bootscript on target. This way it also become an action that can only be manually trigger by user, it should avoid bad surprise. Edited January 20, 2019 by gprovost
Igor Posted January 20, 2019 Posted January 20, 2019 1 minute ago, gprovost said: The problem is upgrade from 5.67 and prior to version 5.7x. So if you publish updated packages the issue will still be there. Please don't publish any new packages till our next PR. OK, images only then.
gprovost Posted January 20, 2019 Author Posted January 20, 2019 @Igor What's your opinion on this approach ? https://github.com/helios-4/build/commit/c386e19adc924630af9023604a92fc0f1d4fe420 https://github.com/helios-4/build/commit/2498982be2656a741f7a7fd2e21ef1c3b09fdeef Will still need to test it, @aprayoga will take care of testing, if all OK he will rise a PR. FYI this upcoming PR also include some improvement to address previous discussion on MV_XOR and fancontrol ;-)
Igor Posted January 20, 2019 Posted January 20, 2019 6 minutes ago, gprovost said: What's your opinion on this approach Can check in a day or two. Now have family/life troubles. Images are done:https://dl.armbian.com/helios4/Debian_stretch_next.7z.torrenthttps://dl.armbian.com/helios4/Ubuntu_bionic_next.7z.torrent 2
gprovost Posted January 20, 2019 Author Posted January 20, 2019 @Igor Thanks man ;-) Same here, getting score because i should be focusing on wedding preps.
Igor Posted January 20, 2019 Posted January 20, 2019 7 minutes ago, gprovost said: i should be focusing on wedding preps. Do that - congrat! I think we have the problem under control now. 1
johanvdw Posted January 28, 2019 Posted January 28, 2019 On 1/19/2019 at 8:00 PM, aprayoga said: 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 I can confirm this works for me as well. It might be useful to say you should also run boot after these commands to continue booting.
Harvey Posted January 29, 2019 Posted January 29, 2019 I have updated my lcd4linux.conf for a cheap AX206 picture frame (320x240) connected to my Helios4. If someone is interested: https://github.com/hkramski/my-lcd4linux-conf. 1
Recommended Posts