Jump to content

aprayoga

Members
  • Posts

    138
  • Joined

  • Last visited

Posts posted by aprayoga

  1. 16 hours ago, Iskren Chernev said:

    I've had a running Helios4 system for almost a year, and it suddenly stopped working (there could have been a power outage, I don't know). When booted, the led next to the power inlet blinks slowly green, but it won't connect to the wired network, and it won't show me a login prompt over the serial connection.

     

    - can I review the boot screen/tty from serial, without logging (boot process)?

    - Shall I try to use the reset button on the board?

    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

    839584136_male4pin.jpg.96ab051398e49235d1ddbcab0a9f76c7.jpg

     

    to determine whether it's power adapter or on-board regulator failure.

  2. 11 hours ago, uzair said:

    Hi, I seem to have a problem with my batch 2 Helios4 that I'm unable to figure out why it happens.
    every time I put it in standby mode, it does not stay in standby but restarts after approx. a minute.

     

    I've tested it with 2 different SD-cards, one with a clean install.
    During the standby I also tested it with disconnecting the network cable, so it seems the it's an internal trigger or crash
    which makes the Helios4 restart.

     

    I'm using the latest Armbian version: 5.77 and kernel 4.14.106.

     

    One thing I've noticed is that the system time is always incorrect after the forced restart.
    after a normal restart the time is correct. Could it be related? I don't know, I'm out of ideas
    and it's driving me crazy for the last few days. Hope you guys can help.

     

    Could you do the following and connect the serial console

    On 4/2/2019 at 2:13 AM, aprayoga said:

    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.

     

     

    We need more info what event causing the system to wake up.

    and how did you put the system to standby?

  3. On 4/1/2019 at 9:04 PM, djurny said:

    Hi,

    Box #0 (4x WD Red 4TB):

    • /dev/sda  30  WDC  WD40EFRX-68N32N0  WD-WCC7K1KS6EUY
    • /dev/sdb  32  WDC  WD40EFRX-68N32N0  WD-WCC7K2KCR8J9
    • /dev/sdc  31  WDC  WD40EFRX-68N32N0  WD-WCC7K1RVY70H
    • /dev/sdd  31  WDC  WD40EFRX-68N32N0  WD-WCC7K6FE2Y7D
       

    Box #1 (4x WD Blue 2TB):

    • /dev/sda  32  WDC  WD20EZRZ-00Z5HB0  WD-WCC4M2VFJPP7
    • /dev/sdb  31  WDC  WD20EZRZ-00Z5HB0  WD-WCC4M0JNZ8EX
    • /dev/sdc  31  WDC  WD20EZRZ-00Z5HB0  WD-WCC4M6HPXZFZ
    • /dev/sdd  29  WDC  WD20EZRZ-00Z5HB0  WD-WCC4M6HPX4AP

    No other devices connected to either box. The 2nd colum is HDD reported temperature in Celcius, it's always around 30~35. 
     

      Hide contents

     

    I've sligthly modified fancontrol to link the top fan (-j10) to maintain the average HDD temperature around between 30~45 Celcius. Bottom fan (-j17) is linked to CPU temperature (/dev/thermal-cpu/temp1_input).

     

     

    Groetjes,

    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.

     

  4. 8 hours ago, tuxd3v said:

     

    I realized that, for having the OS in a Hard drive...better it to be a 2.5", so less power consumption..

    But that also means penalize one disk for the mdRaid..

     

    Its not a easy answer in fact,

    A Solution could be having a small harddrive 2.5", attached to USB, with the OS, and logs..

    Or have it, like its already..., in a SDCard, with logs in a Zram..

     

    Right now after, your response and also after thinking better at it sdcard seems a easier way to go.

    But could be nice to have there a USB boot option, for a pendrive or a usb attached disk.

     

    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.

  5. On 2/5/2019 at 8:23 PM, tuxd3v said:

    Doubts about OS in Disk array,

     

    Could we put OS in hard drives?

    Or should we put it in a spare one/usb pendrive or let it in 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. 

    IMG_20190208_231833.jpg.73e3f28e83c045916c3df01616e7cec0.jpg

    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.

     

     

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

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

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

     

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

     

  10. 7 hours ago, thermalz said:

    Hi all,

    received my kit last week and put it together today.

    I seem to be having issues with one of the fans. Only one will spin up, the other connected to J17 does not rotate. It's specific to J17 as swapping the fans around reverses the fan which doesn't spin.

    I unplugged J17 connector and plugged it back in, the fan spun up for around 3 seconds then stopped, so I currently have a system with only 1 fan functioning.

    Does anyone have any hints?

     

     

    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

     

  11. Hi @Zykr, I just wanted to add on top of @gprovost instruction

    On 12/8/2018 at 3:36 PM, gprovost said:

    @Zykr to complement what I wrote before. You could use following u-boot commands to boot manually on the correct kernel. Then once booted as wrote above, you should fix the wrong symlink in /boot ;-)

    
    setenv bootargs "console=ttyS0,115200 root=/dev/mmcblk0p1 rootwait rootfstype=ext4 ubootdev=mmc scandelay loglevel=1"
    
    load mmc 0:1 ${fdt_addr} /boot/dtb-4.14.83-mvebu/${fdtfile}
    load mmc 0:1 ${ramdisk_addr_r} /boot/initrd.img-4.14.83-mvebu
    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} ${ramdisk_addr_r} ${fdt_addr}

     

    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}

     

     

     

     

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines