aprayoga

Members
  • Content Count

    13
  • Joined

  • Last visited


Reputation Activity

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

     
    to determine whether it's power adapter or on-board regulator failure.
  3. Like
    aprayoga got a reaction from djurny in Helios4 Support   
    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. Like
    aprayoga reacted to Harvey in Helios4 Support   
    Hi tuxd3v,
    my experience is quite different.
    When setting up my new box, CPU temp always was below 58 °C, so the fans never got started. (According to https://wiki.kobol.io/pwm/#configuration-file, fans only start at 70 °C CPU temp.)
    The inactive fans quickly led to quite high disk temps (two WD RED 8TB) of 52 °C (the upper one) and 53 °C (the lower one, directly above the board) . This seems too high given the fact WD specifies operating temps of only 0-60 °C, so one of the first things I did was to modify  /etc/fancontrol to
    # Helios4 PWM Fan Control Configuration # Temp source : /dev/thermal-cpu INTERVAL=10 FCTEMPS=/dev/fan-j10/pwm1=/dev/thermal-cpu/temp1_input /dev/fan-j17/pwm1=/dev/thermal-cpu/temp1_input MINTEMP=/dev/fan-j10/pwm1=70 /dev/fan-j17/pwm1=70 MAXTEMP=/dev/fan-j10/pwm1=90 /dev/fan-j17/pwm1=90 MINSTART=/dev/fan-j10/pwm1=75 /dev/fan-j17/pwm1=75 MINSTOP=/dev/fan-j10/pwm1=75 /dev/fan-j17/pwm1=75 MINPWM=/dev/fan-j10/pwm1=75 /dev/fan-j17/pwm1=75 #MINPWM=0 With these settings, my fans are always running slowly and silently, but efficiently cooling my disks to not more than approx. 33 °.
  5. Like
    aprayoga reacted to Igor in Helios4 Support   
    Can check in a day or two. Now have family/life troubles. Images are done:
    https://dl.armbian.com/helios4/Debian_stretch_next.7z.torrent
    https://dl.armbian.com/helios4/Ubuntu_bionic_next.7z.torrent
  6. Like
    aprayoga got a reaction from integros in Helios4 Support   
    I'm sorry, my bad, I accidentally include UHS-I SD card patch on that test kernel, the DTB to be exact, and apparently your card does not compatible. You can read more about this at SDIO (SD Card) page on our wiki. You just need to install the linux-image package. No need to install the dtb and headers.
     
    Regarding XOR, yes i notice it too. I think it would default to software implementation first then override later by async_tx if the hardware offload engine is available.
    You can see on kernel message below, the async_tx initialized quite late compared to xor and raid6.
    [ 0.004600] xor: measuring software checksum speed [ 0.043885] arm4regs : 2533.000 MB/sec [ 0.083885] 8regs : 1947.000 MB/sec [ 0.123884] 32regs : 1804.000 MB/sec [ 0.163884] neon : 1840.000 MB/sec [ 0.163887] xor: using function: arm4regs (2533.000 MB/sec) <...> [ 0.240055] raid6: int32x1 gen() 262 MB/s [ 0.307944] raid6: int32x1 xor() 271 MB/s [ 0.376037] raid6: int32x2 gen() 351 MB/s [ 0.443939] raid6: int32x2 xor() 329 MB/s [ 0.512026] raid6: int32x4 gen() 393 MB/s [ 0.579947] raid6: int32x4 xor() 319 MB/s [ 0.647890] raid6: int32x8 gen() 422 MB/s [ 0.715956] raid6: int32x8 xor() 324 MB/s [ 0.783897] raid6: neonx1 gen() 1212 MB/s [ 0.851888] raid6: neonx1 xor() 1150 MB/s [ 0.919918] raid6: neonx2 gen() 1296 MB/s [ 0.987897] raid6: neonx2 xor() 1347 MB/s [ 1.055893] raid6: neonx4 gen() 1349 MB/s [ 1.123902] raid6: neonx4 xor() 1377 MB/s [ 1.191883] raid6: neonx8 gen() 1073 MB/s [ 1.259882] raid6: neonx8 xor() 1041 MB/s [ 1.259885] raid6: using algorithm neonx4 gen() 1349 MB/s [ 1.259888] raid6: .... xor() 1377 MB/s, rmw enabled [ 1.259891] raid6: using neon recovery algorithm <...> [ 1.425544] mv_xor f1060800.xor: Marvell shared XOR driver [ 1.457595] mv_xor f1060800.xor: Marvell XOR (Descriptor Mode): ( xor cpy intr ) [ 1.457693] mv_xor f1060900.xor: Marvell shared XOR driver [ 1.485586] mv_xor f1060900.xor: Marvell XOR (Descriptor Mode): ( xor cpy intr ) <...> [ 4.580251] async_tx: api initialized (async)  
    I built another test kernel with "DMA Engine verbose debugging" option enabled. These lines printed repeatedly (well, not exactly same address) during dd from /dev/zero to /dev/md0 and the interrupt counter increased.
    [ 416.505470] mv_xor f1060800.xor: mv_xor_prep_dma_xor src_cnt: 1 len: 4096 dest 0x216eb000 flags: 32 [ 416.514571] mv_xor f1060800.xor: mv_xor_prep_dma_xor sw_desc ed89d780 async_tx ed89d79c [ 416.522719] mv_xor f1060800.xor: mv_xor_tx_submit sw_desc ed89d780: async_tx ed89d79c [ 416.530582] mv_xor f1060800.xor: mv_chan_start_new_chain 190: sw_desc ed89d780 [ 416.537865] mv_xor f1060800.xor: activate chan. [ 416.542544] mv_xor f1060800.xor: intr cause 2 [ 416.546915] mv_xor f1060800.xor: mv_chan_clear_eoc_cause, val 0xfffffff8 [ 416.553658] mv_xor f1060800.xor: mv_chan_slot_cleanup 280 [ 416.559076] mv_xor f1060800.xor: current_desc 7f056380 [ 416.564253] mv_xor f1060800.xor: mv_chan_clean_completed_slots 227 [ 416.570461] mv_xor f1060800.xor: mv_desc_clean_slot 247: desc ed89d780 flags 32 [ 416.577803] mv_xor f1060800.xor: mv_xor_prep_dma_xor src_cnt: 1 len: 4096 dest 0x2ceaf000 flags: 32 [ 416.586894] mv_xor f1060800.xor: mv_xor_prep_dma_xor sw_desc ed89da00 async_tx ed89da1c [ 416.595019] mv_xor f1060800.xor: mv_xor_tx_submit sw_desc ed89da00: async_tx ed89da1c [ 416.602890] mv_xor f1060800.xor: mv_chan_start_new_chain 190: sw_desc ed89da00 [ 416.610142] mv_xor f1060800.xor: activate chan.  
    ---
     
     
     
    Initially I had no idea why the update break the system. I did several time testing the update scenario from 5.64 to 5.68 & 5.69 (both are internal release). Then I realized that I missed that you started from 5.67 which i thought never released. 
     
    I would say,  the 5.67 contains broken u-boot 2018.11. It only compatible with boot-mvebu-next.cmd. It already fixed on this commit part of PR #1169.  So version 5.68 onward should be compatible with both, boot-marvell.cmd and boot-mvebu-next.cmd.
     
    Since the fix just modify the environment variable, I suggest to run these commands to make it also compatible with boot-marvell.cmd. 
    setenv boot_a_script 'load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; setenv boot_interface ${devtype};source ${scriptaddr}' setenv loadaddr 0x02000000 setenv fdt_addr ${fdt_addr_r} saveenv I have tested it on 5.67
  7. Like
    aprayoga got a reaction from lanefu in Helios4 Support   
    I'm sorry, my bad, I accidentally include UHS-I SD card patch on that test kernel, the DTB to be exact, and apparently your card does not compatible. You can read more about this at SDIO (SD Card) page on our wiki. You just need to install the linux-image package. No need to install the dtb and headers.
     
    Regarding XOR, yes i notice it too. I think it would default to software implementation first then override later by async_tx if the hardware offload engine is available.
    You can see on kernel message below, the async_tx initialized quite late compared to xor and raid6.
    [ 0.004600] xor: measuring software checksum speed [ 0.043885] arm4regs : 2533.000 MB/sec [ 0.083885] 8regs : 1947.000 MB/sec [ 0.123884] 32regs : 1804.000 MB/sec [ 0.163884] neon : 1840.000 MB/sec [ 0.163887] xor: using function: arm4regs (2533.000 MB/sec) <...> [ 0.240055] raid6: int32x1 gen() 262 MB/s [ 0.307944] raid6: int32x1 xor() 271 MB/s [ 0.376037] raid6: int32x2 gen() 351 MB/s [ 0.443939] raid6: int32x2 xor() 329 MB/s [ 0.512026] raid6: int32x4 gen() 393 MB/s [ 0.579947] raid6: int32x4 xor() 319 MB/s [ 0.647890] raid6: int32x8 gen() 422 MB/s [ 0.715956] raid6: int32x8 xor() 324 MB/s [ 0.783897] raid6: neonx1 gen() 1212 MB/s [ 0.851888] raid6: neonx1 xor() 1150 MB/s [ 0.919918] raid6: neonx2 gen() 1296 MB/s [ 0.987897] raid6: neonx2 xor() 1347 MB/s [ 1.055893] raid6: neonx4 gen() 1349 MB/s [ 1.123902] raid6: neonx4 xor() 1377 MB/s [ 1.191883] raid6: neonx8 gen() 1073 MB/s [ 1.259882] raid6: neonx8 xor() 1041 MB/s [ 1.259885] raid6: using algorithm neonx4 gen() 1349 MB/s [ 1.259888] raid6: .... xor() 1377 MB/s, rmw enabled [ 1.259891] raid6: using neon recovery algorithm <...> [ 1.425544] mv_xor f1060800.xor: Marvell shared XOR driver [ 1.457595] mv_xor f1060800.xor: Marvell XOR (Descriptor Mode): ( xor cpy intr ) [ 1.457693] mv_xor f1060900.xor: Marvell shared XOR driver [ 1.485586] mv_xor f1060900.xor: Marvell XOR (Descriptor Mode): ( xor cpy intr ) <...> [ 4.580251] async_tx: api initialized (async)  
    I built another test kernel with "DMA Engine verbose debugging" option enabled. These lines printed repeatedly (well, not exactly same address) during dd from /dev/zero to /dev/md0 and the interrupt counter increased.
    [ 416.505470] mv_xor f1060800.xor: mv_xor_prep_dma_xor src_cnt: 1 len: 4096 dest 0x216eb000 flags: 32 [ 416.514571] mv_xor f1060800.xor: mv_xor_prep_dma_xor sw_desc ed89d780 async_tx ed89d79c [ 416.522719] mv_xor f1060800.xor: mv_xor_tx_submit sw_desc ed89d780: async_tx ed89d79c [ 416.530582] mv_xor f1060800.xor: mv_chan_start_new_chain 190: sw_desc ed89d780 [ 416.537865] mv_xor f1060800.xor: activate chan. [ 416.542544] mv_xor f1060800.xor: intr cause 2 [ 416.546915] mv_xor f1060800.xor: mv_chan_clear_eoc_cause, val 0xfffffff8 [ 416.553658] mv_xor f1060800.xor: mv_chan_slot_cleanup 280 [ 416.559076] mv_xor f1060800.xor: current_desc 7f056380 [ 416.564253] mv_xor f1060800.xor: mv_chan_clean_completed_slots 227 [ 416.570461] mv_xor f1060800.xor: mv_desc_clean_slot 247: desc ed89d780 flags 32 [ 416.577803] mv_xor f1060800.xor: mv_xor_prep_dma_xor src_cnt: 1 len: 4096 dest 0x2ceaf000 flags: 32 [ 416.586894] mv_xor f1060800.xor: mv_xor_prep_dma_xor sw_desc ed89da00 async_tx ed89da1c [ 416.595019] mv_xor f1060800.xor: mv_xor_tx_submit sw_desc ed89da00: async_tx ed89da1c [ 416.602890] mv_xor f1060800.xor: mv_chan_start_new_chain 190: sw_desc ed89da00 [ 416.610142] mv_xor f1060800.xor: activate chan.  
    ---
     
     
     
    Initially I had no idea why the update break the system. I did several time testing the update scenario from 5.64 to 5.68 & 5.69 (both are internal release). Then I realized that I missed that you started from 5.67 which i thought never released. 
     
    I would say,  the 5.67 contains broken u-boot 2018.11. It only compatible with boot-mvebu-next.cmd. It already fixed on this commit part of PR #1169.  So version 5.68 onward should be compatible with both, boot-marvell.cmd and boot-mvebu-next.cmd.
     
    Since the fix just modify the environment variable, I suggest to run these commands to make it also compatible with boot-marvell.cmd. 
    setenv boot_a_script 'load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; setenv boot_interface ${devtype};source ${scriptaddr}' setenv loadaddr 0x02000000 setenv fdt_addr ${fdt_addr_r} saveenv I have tested it on 5.67
  8. Like
    aprayoga got a reaction from taziden in Helios4 Support   
    @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