aprayoga

Members
  • Content Count

    20
  • Joined

  • Last visited

About aprayoga

  • Rank
    Member

Profile Information

  • Gender
    Male
  • Location
    Singapore

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @jimbolaya, I know it's quite late, ch341 driver would be included on next release. Refer to commit 14a0a54. @smith69085, we have updated the wiki page how to use the GPIO for button. You can take a look on https://wiki.kobol.io/gpio/#use-gpio-with-device-tree-overlay But currently the base dtb (armada-388-helios4.dtb) on Armbian 5.91 is still not compiled with overlay support. You can download the attached dtb, rename and replace the dtb on your system. lk4.14_armada-388-helios4.dtb is for Armbian Default (Stretch, Linux Kernel 4.14) sudo cp lk4.14_armada-388-helios4.dtb /boot/dtb/armada-388-helios4.dtb lk4.19_armada-388-helios4.dtb is for Armbian Next (Buster, Linux Kernel 4.19) sudo cp lk4.19_armada-388-helios4.dtb /boot/dtb/armada-388-helios4.dtb
  2. @Mangix have you check the wiki, https://wiki.kobol.io/cesa/ ? There are plenty of informations over there, for example the benchmark result and what kind of cipher can be hardware accelerated.
  3. I still confused with your configuration, you said you setup sdb & sdc as mirror but from the armbian log on first post, it's RAID level 5 with member sdb, sdc, &sdd Please run the following commands to make boot process more verbose sudo sed -i 's/verbosity=1/verbosity=7/g' /boot/armbianEnv.txt 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 sudo reboot and please capture serial console from very beginning of u-boot. Oh, with the configuration that has problem.
  4. Hi, Just wanted to make sure, do you see something like in screenshot below?
  5. Hi, We haven't started to work on 5.2 but maybe you can try the patch by Gontran Baerts for ArchLinux https://github.com/gbcreation/linux-helios4/blob/master/92-mvebu-gpio-remove-hardcoded-timer-assignment.patch
  6. Hi, currently booting directly to SATA1 is not supported. It was supported using Marvell U-boot 2013.01. If your intention is to boot without SD Card, you can boot from SPI NOR flash. The U-Boot on SPI NOR flash then would search boot.scr on following order USB SATA1 SD Card
  7. Hi, you're right, the driver is not included, you'd need to compile the driver by yourself if you need ASAP. I don't see any technical reason not to include the driver. After i test, I will enable it on Armbian kernel
  8. @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.
  9. Yes, you can boot from SATA disk but currently limited only from SATA1 port. Take a look on following log: U-Boot SPL 2018.11-00008-g8f200a3d28 (Jul 03 2019 - 08:01:15 +0800) High speed PHY - Version: 2.0 Detected Device ID 6828 board SerDes lanes topology details: | Lane # | Speed | Type | -------------------------------- | 0 | 6 | SATA0 | | 1 | 5 | USB3 HOST0 | | 2 | 6 | SATA1 | | 3 | 6 | SATA3 | | 4 | 6 | SATA2 | | 5 | 5 | USB3 HOST1 | -------------------------------- High speed PHY - Ended Successfully mv_ddr: mv_ddr-armada-17.10.4 DDR3 Training Sequence - Switching XBAR Window to FastPath Window DDR Training Sequence - Start scrubbing DDR3 Training Sequence - End scrubbing mv_ddr: completed successfully Trying to boot from SPI U-Boot 2018.11-00008-g8f200a3d28 (Jul 03 2019 - 08:01:15 +0800) SoC: MV88F6828-A0 at 1600 MHz DRAM: 2 GiB (800 MHz, 32-bit, ECC enabled) MMC: mv_sdh: 0 Loading Environment from SPI Flash... SF: Detected w25q32bv with page size 256 Bytes, erase size 4 KiB, total 4 MiB OK Model: Helios4 Board: Helios4 SCSI: MVEBU SATA INIT Target spinup took 0 ms. Target spinup took 0 ms. AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode flags: 64bit ncq led only pmp fbss pio slum part sxs Net: Warning: ethernet@70000 (eth1) using random MAC address - ee:e0:5b:09:22:72 eth1: ethernet@70000 Hit any key to stop autoboot: 0 starting USB... USB0: MVEBU XHCI INIT controller @ 0xf10f4000 Register 2000120 NbrPorts 2 Starting the controller USB XHCI 1.00 USB1: MVEBU XHCI INIT controller @ 0xf10fc000 Register 2000120 NbrPorts 2 Starting the controller USB XHCI 1.00 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 1 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Device 0: device type unknown ... is now current device scanning bus for devices... Device 0: (0:0) Vendor: ATA Prod.: TOSHIBA MK5065GS Rev: GJ00 Type: Hard Disk Capacity: 476940.0 MB = 465.7 GB (976773168 x 512) Device 0: (0:1) Vendor: ATA Prod.: TOSHIBA MK5065GS Rev: GJ00 Type: Hard Disk Capacity: 476940.0 MB = 465.7 GB (976773168 x 512) Device 0: (1:0) Vendor: ATA Prod.: STEC MACH8 SSD Rev: 1031 Type: Hard Disk Capacity: 57241.8 MB = 55.9 GB (117231408 x 512) Device 0: (1:1) Vendor: ATA Prod.: STEC MACH8 SSD Rev: 1031 Type: Hard Disk Capacity: 57241.8 MB = 55.9 GB (117231408 x 512) Found 4 device(s). Device 0: (0:0) Vendor: ATA Prod.: TOSHIBA MK5065GS Rev: GJ00 Type: Hard Disk Capacity: 476940.0 MB = 465.7 GB (976773168 x 512) ... is now current device Scanning scsi 0:1... Found U-Boot script /boot/boot.scr 2948 bytes read in 88 ms (32.2 KiB/s) ## Executing script at 03000000 Boot script loaded from scsi 199 bytes read in 54 ms (2.9 KiB/s) 18933 bytes read in 167 ms (110.4 KiB/s) 5408781 bytes read in 223 ms (23.1 MiB/s) 5590368 bytes read in 218 ms (24.5 MiB/s) ## Loading init Ramdisk from Legacy Image at 02880000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 5408717 Bytes = 5.2 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 02040000 Booting using the fdt blob at 0x2040000 Loading Ramdisk to 0fad7000, end 0ffff7cd ... OK reserving fdt memory region: addr=2040000 size=6a000 Loading Device Tree to 0fa6a000, end 0fad6fff ... OK Starting kernel ... Uncompressing Linux... done, booting the kernel. Helios4 boot from SPI with rootfs located on scsi 0:1 To access the SATA disk, you have to use scsi command instead of sata command
  10. 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.
  11. Could you do the following and connect the serial console We need more info what event causing the system to wake up. and how did you put the system to standby?
  12. 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.
  13. 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.
  14. Regarding OS on hard drive, it's possible as long as it does not reside on top of RAID. U-Boot does not understand MD so it could not load boot files from there. You need to sacrifice 1 drive to be used as OS drive or maybe, since i haven't tried it, allocated a partition for OS and let MD use the rest of the disk capacity. That being said, currently we don't support OS on hard drive. Personally I opt for OS in sdcard, because it does not poke out/extrude, easier to update the bootloader and i have plenty of them. I admit those are not strong reason. Small dimension reason can easily dismissed by some USB pendrive model that quite small such as these SanDisk Ultra Fit. Also there might be performance advantage using pendrive. SanDisk Ultra Fit stated that it has speed up to 130MB/s while SanDisk Extreme Pro *only* 100 MB/s. I'm not sure how reliable the USB pendrive to run in 24/7. Early model of SanDisk Ultra Fit (right hand side on above photo), quite hot after a while. The current model, which is fully plastic, does not have such issue.
  15. 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