Jump to content

Helios4 Support


gprovost

Recommended Posts

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

Link to comment
Share on other sites

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 by gabest
Link to comment
Share on other sites

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,

 

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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,

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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,

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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}

 

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • Igor unpinned this topic
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?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

@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 by gprovost
Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

@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 ;-)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines