Jump to content

aprayoga

Members
  • Posts

    138
  • Joined

  • Last visited

Posts posted by aprayoga

  1. @TDCroPower

    I could not reproduce your setup.
    First I tried with fresh Armbian 20.08.8 then transfer to eMMC using nand-sata-install.

    System can boot if sd card inserted.

     

    I clean up the eMMC. then run next test.
    I tried boot from fresh Armbian 20.08.4 then transfer to eMMC using nand-sata-install.
    System can boot if sd card inserted.

    Then boot from fresh Armbian 20.08.8 without cleaning the eMMC, then transfer to eMMC using nand-sata-install.

    System can boot if sd card inserted.

     

    Initially I though maybe previous u-boot on eMMC looking for old device tree name therefore your system failed to boot. But it does not seem the case.

     

    4 hours ago, TDCroPower said:

    Is it possible to do something with the file /boot/armbianEnv.txt and changing the variable "rootdev"?
    Because in the /boot/boot.scr the default value for "rootdev" -> "/dev/mmcblk0p1" is used and this is the partition of the microSD.

    You could try to set "rootdev=/dev/mmcblk1p1" in /boot/armbianEnv.txt as a workaround.

    But keep in mind that all of the actual boot files are still on sdcard and not accessible under /boot/

  2. 3 hours ago, antsu said:

    This one works "even less" (if that makes sense) since it's missing this patch and fails at an earlier stage in the compilation process. (With the patch applied it fails at the same point I mentioned in my previous post).

     

    Unrelated, but I should also note that today, after configuring my Helios64 with the legacy Armbian image and letting it run for a few hours with a moderate load, it crashed again with a kernel panic. Unfortunately I wasn't able to capture the panic messages as I had iftop open on the serial console at the time and it all mixed together beautifully.

    So with Armbian 20.08.8 LEGACY,  the system still crashed? Let us know if you managed to get the log and a way to reproduce the crash.

     

     

    3 hours ago, TDCroPower said:

    Did the team change anything about the boot variant with the 20.08.8?
    With the previous version I was able to boot from the eMMC with a detour and now I can't boot anymore, although the image was transferred via nand-sata-install!

    There is a change to rename device tree to follow mainline device tree naming.

    from /boot/rockchip/rk3399-helios64.dtb to /boot/rockchip/rk3399-kobol-helios64.dtb

     

    Did you use fresh image of 20.08.8 then transfer to eMMC via nand-sata-install?

  3. To summarize current status

     


     

    Feature Support Status
    Feature Legacy Remarks Current Remarks
    Shutdown Issue Failed to shutdown PMIC and trigger crash, HDD already parked OK  
    Reboot Issue Similar like shutdown but Watchdog trigger the reboot so it appear successful OK  
    Suspend to RAM Not Supported Yet Failed to resume operation after wake up Not Supported Yet USB host controller refuse to enter suspend mode
    2.5G Ethernet OK   Performance Issue Slightly improved with tx offload disabled
    Main Power/UPS Status OK Status can be read from sysfs OK Status can be read from sysfs
    Battery Charging Status Not Supported   OK Charging and Full charge can be read from sysfs
    UPS configuration Not Supported Yet Need user-space tool to monitor power status and trigger shutdown Not Supported Yet Need user-space tool to monitor power status and trigger shutdown
    USB Type C - Host OK   Not Supported Yet There are some issue with fusb302 driver and USB Host Controller driver
    USB Type C - Gadget OK   Not Supported Yet There are some issue with fusb302 driver and USB Controller driver
    USB Type C - DisplayPort OK   Not Supported Yet There are some issue with fusb302 driver and DisplayPort alternate driver
    eMMC Install Not Supported Yet The bootloader unable to load rootfs from eMMC Not Supported Yet The bootloader unable to load rootfs from eMMC
    SPI Boot Not Supported Yet   Not Supported Yet  
    Recovery key Not Supported Yet System can enter maskrom mode but need special OS image and rkdevelop Not Supported Yet System can enter maskrom mode but need special OS image and rkdevelop

     

    We are still working on eMMC issue.

     

     

  4. @piter75 @Pedro Lamas

    Helios64 also encounter some random crash, yesterday we tried to redefine opp just 408 MHz and 1.4/1.8 GHz and we don't see any random crash anymore.

    It seems similar DVFS problem as discussed in this thread. Then our customer point us to odroid n1 issue at

    https://forum.odroid.com/viewtopic.php?t=30303

    Maybe you can give it a try on Nano Pi M4v2.

     

    We are still testing on Helios64 (with value 40000), so far with reboot and power cycle does not trigger any kernel crash.

  5. @FredK and @bigbrovar, thanks for the info.
    on Friday, i did some initial investigation and as you said upper USB port seems only work at 2.0 (high-speed USB device) not 3.0.

    [   42.581478] usb 4-1: new high-speed USB device number 2 using xhci-hcd
    [   42.747232] usb 4-1: New USB device found, idVendor=0480, idProduct=0820, bcdDevice= 3.15
    [   42.755452] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    [   42.762635] usb 4-1: Product: External USB 3.0
    [   42.767095] usb 4-1: Manufacturer: TOSHIBA
    [   42.771225] usb 4-1: SerialNumber: XXXXXXXXXXX6F
    [   42.777009] usb-storage 4-1:1.0: USB Mass Storage device detected
    [   42.785088] scsi host4: usb-storage 4-1:1.0
    [   42.839846] usbcore: registered new interface driver uas
    [   49.139357] scsi 4:0:0:0: Direct-Access     TOSHIBA  External USB 3.0 5438 PQ: 0 ANSI: 6
    [   49.149674] sd 4:0:0:0: Attached scsi generic sg2 type 0
    [   49.161946] sd 4:0:0:0: [sdc] Very big device. Trying to use READ CAPACITY(16).
    [   49.171592] sd 4:0:0:0: [sdc] 7814037164 512-byte logical blocks: (4.00 TB/3.64 TiB)
    [   49.179392] sd 4:0:0:0: [sdc] 4096-byte physical blocks
    [   49.187768] sd 4:0:0:0: [sdc] Write Protect is off
    [   49.195302] sd 4:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
    [   49.334260]  sdc: sdc1 sdc2
    [   49.339876] sd 4:0:0:0: [sdc] Attached SCSI disk

    this morning i tried, and it works as 3.0 (SuperSpeed Gen 1 USB device)

    [   90.585477] usb 4-1: new high-speed USB device number 2 using xhci-hcd
    [   91.477501] usb 5-1: new SuperSpeed Gen 1 USB device number 2 using xhci-hcd
    [   91.503435] usb 5-1: New USB device found, idVendor=0480, idProduct=0820, bcdDevice= 3.15
    [   91.511642] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    [   91.518807] usb 5-1: Product: External USB 3.0
    [   91.523274] usb 5-1: Manufacturer: TOSHIBA
    [   91.527390] usb 5-1: SerialNumber: XXXXXXXXXXX6F
    [   91.534376] usb-storage 5-1:1.0: USB Mass Storage device detected
    [   91.540743] scsi host4: usb-storage 5-1:1.0
    [   91.583403] usbcore: registered new interface driver uas
    [   97.211091] scsi 4:0:0:0: Direct-Access     TOSHIBA  External USB 3.0 5438 PQ: 0 ANSI: 6
    [   97.221100] sd 4:0:0:0: Attached scsi generic sg2 type 0
    [   97.229812] sd 4:0:0:0: [sdc] Very big device. Trying to use READ CAPACITY(16).
    [   97.238524] sd 4:0:0:0: [sdc] 7814037164 512-byte logical blocks: (4.00 TB/3.64 TiB)
    [   97.246315] sd 4:0:0:0: [sdc] 4096-byte physical blocks
    [   97.253361] sd 4:0:0:0: [sdc] Write Protect is off
    [   97.258537] sd 4:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
    [   97.394956]  sdc: sdc1 sdc2
    [   97.402343] sd 4:0:0:0: [sdc] Attached SCSI disk

    we will need to investigate further

     

     

  6. On 6/5/2020 at 3:52 PM, Vin said:

    Another very vital point is software support, for what i can tell the RK3399 doesnt seem to run all too stable on other devices so far?

    as mentioned by @Werner, RK3399 runs best on the legacy, 4.4 kernel. Mainline, (LK 5.4), for example, still have some issue on DP over TypeC.

    We ran some burn-in test (stress-ng for cpu, parallel fio on all sata port, all usb port, emmc and microsd) under LK 4.4. we didn't encounter stability issue in 24 hours.

    Similar like Helios4, Helios64 will have legacy and current support.

     

    On 3/12/2020 at 12:29 AM, Userlab said:

    i have tried similar riser from Amazon, as you can see on following pictures, the riser is too long

    IMG_20200518_170801.thumb.jpg.8015598c97fb5d4abef820ea27100e76.jpg

     

    and M.2 modem is too wide

    IMG_20200518_115314.thumb.jpg.7d47d84fadd60b35c7eb1b245361e707.jpg

     

     

  7. 2 minutes ago, Tido said:

    Could you name the two families?   And maybe say one or two words about your expectation about each. So, people know where you come from and what you are looking for.

     

    the families are

    - rk3399

     only rockpro64 and rock pi 4 under this family

    - rockchip64

     the rest of rk3399 boards.

     

    Helios64 can boot with both family with the correct device tree (different dts for rk3399 and rockchip64).

    looking at this PR https://github.com/armbian/build/pull/1934 it seems the direction is to merge rk3399 to rockchip64 (implied by renaming the the patch folder from rk3399 into rockchip64 instead of the other way a round).

     

  8. Hi all,

     

    currently i'm working on upcoming Helios64 board. For RK3399 board there are 2 families, what are the differences between them?
    I've been following discussion on github and this forum for few months but still unsure which family i should use.


     

  9. 7 hours ago, FrancisTheodoreCatte said:

     

    After upgrading to the 4.19.104-mvebu kernel I also started experiencing the same complete cpu lockups, but here's the kicker: the lockups are continuing, even after downgrading to kernel 4.14.171-mvebu.

     

    Easy way for me to trigger it is by running echo check > /sys/block/md0/md/sync_action

     

    I managed to catch the CPU stall via the serial console:
    https://pastebin.com/C8yCQMAn

     

    Here's the output from armbianmonitor -u:

    http://ix.io/2h03

     

    edit:

    same lockup still happens when running an md data-check even after downgrading further, to 4.14.153-mvebu.

     

    Thanks for providing the crash log.
    Last weekend i ran some test with following image
     

    • Buster NEXT upgraded to buster CURRENT
    • fresh Buster CURRENT

    and load the system with

    stress-ng -c 2 -P 70

    It supposed to make the system busy and run with full speed (1.6 GHz). i ran it for about 20 hours each test but i did not encounter any issue.

    Looking on your log, it seems marvell_xor that trigger the crash. I will try your suggestion to trigger the crash

  10. On 2/12/2020 at 4:27 AM, shaddow501 said:
     

    Second issue:

    When "make scripts" and make modules_prepare instead of link to the 5.4.18-sunxi64 it creates a link for modules in 5.4.18 which makes the modules useless, since it doesnt go to the correct /lib/modules library.

    instead that the modules will be installed in lib/modules/5.4.18-sunxi64, it install it in /lib/modules/5.4.18.

     

    The way to fix it is to modify the Makefile and add the -sunxi64.

     

    VERSION = 5
    PATCHLEVEL = 4
    SUBLEVEL = 18
    EXTRAVERSION = -sunxi64
    NAME = Kleptomaniac Octopus

     

    linux-headers-5.4.18-sunxi64.tar.gz 14.83 MB · 1 download

    I don't think you need to modify the Makefile, you can set LOCALVERSION environment variable before compiling.
    You could try something like this when you invoke the make

    LOCALVERSION=-sunxi64 make modules

    Here is how Armbian compile the kernel:
    https://github.com/armbian/build/blob/master/lib/compilation.sh#L367-L371

  11. On 1/13/2020 at 5:35 AM, Carlo said:

    Hi,

      I have a problem with ch341 USB serial adapter, I tried to search on forum and on internet without luck.

      I'm runnig a Linux helios4 4.19.84-mvebu #19.11.3 on an helios4 board, off course.

      When I connect a CH341 device, like NodeMCU, serial adapter or an Arduino Mega Pro Mini, etc, for the first time or I boot the system with the device connected, it is enumerated correctly and I have it listed on dmesg and I give a /dev/ttyUSBx, but if I disconnect and reconnect it, the system, sometimes at the first time, sometimes after few times, give me these errors and didn't detects the usb adapter until the next boot.

    What's wrong ? What can I do, other usb device, link stick, works fine.

    Sotty for my english, I hope that my message is comprensible.

     

    Bye, Carlo

    
    [dom gen 12 23:28:15 2020] usb 2-1: new full-speed USB device number 7 using xhci-hcd
    [dom gen 12 23:28:15 2020] usb 2-1: New USB device found, idVendor=1a86, idProduct=5523, bcdDevice= 3.04
    [dom gen 12 23:28:15 2020] usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
    [dom gen 12 23:28:15 2020] ch341 2-1:1.0: ch341-uart converter detected
    [dom gen 12 23:28:15 2020] usb 2-1: ch341-uart converter now attached to ttyUSB0
    [dom gen 12 23:28:26 2020] usb 2-1: USB disconnect, device number 7
    [dom gen 12 23:28:26 2020] usb 2-1: ch341_read_int_callback - usb_submit_urb failed: -19
    [dom gen 12 23:28:31 2020] xhci-hcd f10f0000.usb3: xHCI host not responding to stop endpoint command.
    [dom gen 12 23:28:31 2020] xhci-hcd f10f0000.usb3: xHCI host controller not responding, assume dead
    [dom gen 12 23:28:31 2020] xhci-hcd f10f0000.usb3: HC died; cleaning up
    [dom gen 12 23:28:31 2020] usb 2-1: failed to send control message: -19
    [dom gen 12 23:28:31 2020] ch341-uart ttyUSB0: ch341-uart converter now disconnected from ttyUSB0
    [dom gen 12 23:28:31 2020] ch341 2-1:1.0: device disconnected

     

     

    A few months ago I enabled some USB-Serial converter driver on the kernel and test it. I used an USB hub then hotplug several USB-Serial (PL2303, FT232, FT2232, CH340G, CH341A, CP2101, CP2102), all detected correctly.
    According to your log, it seems something wrong with the USB Host controller driver, could you try with other USB device? maybe USB Flash drive

  12. 5 hours ago, Mangix said:

    My kernel right now is 4.19.63-mvebu. Is this the latest version? It doesn't sound like it is.

    Between middle-to end of November 2019, Armbian change the version and branch naming.

    Version from something like 5.91 become something like 19.11.x, if i'm not mistaken Year.Month, like Ubuntu versioning.

    Then the branch name,

    • DEFAULT become LEGACY
    • NEXT become CURRENT

    To upgrade to new version, use armbian-config.

    sudo apt-get update
    sudo apt-get -y upgrade
    sudo armbian-config
    

    armbian-config_main.png.07bfc6c651dd386525f75139ab2b1926.png

     

    Select System > Other, to switch to other kernel

    armbian-config_system.png.81450d3b2716adb516b43436d83e1c6c.png

     

    Confirm the action

    armbian-config_other_kernel_confirmation.png.d1ff808ec66794597d81271e039bee53.png

     

    And after some process, you will be presented by list of kernels

    armbian-config_other_kernel_list.png.ed40b0a7e75e15825c42959f325023af.png

     

    Select linux-image-current-mvebu. The system will install the new kernel and automatically reboot.

    Confirm the kernel installed correctly and Armbian changed to new branch CURRENT by executing,

    uname -a
    grep "BRANCH" /etc/armbian-release

     

  13. 13 hours ago, sirleon said:

    @aprayoga Thank you very much! It is working now after I followed your advice in combination with these instructions from David

    to solve this Error:

     

     

    Good to hear you got it working.  I tried the instructions first on my system and did not encounter such error. Could you share your u-boot version?

     

     

    On 12/29/2019 at 7:57 AM, Koen said:

    I'm trying to start afresh on the latest buster image, but failing miserably.

    1. Armbian-config setting Locale not working and subsequently giving perl errors.  (Fixed by manually editing /etc/default/locale)
    2. Arbmian-config setting Keyboard not doing anything.  (Fixed by manually edditing /etc/default/keyboard)

    3. Arbmian-config accessing "system - CPU" crashes armbian-config.

    
    cat: /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies: File or folder doesn't exist
    cat: /sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors: File or folder doesn't exist

    4. Can't do anything iptables, not even -L to see existing rules, let alone actually configuring anything.

    
    iptables v1.8.2 (nf_tables):  CHAIN_ADD failed (No such file or directory): chain INPUT

    Haven't been able to get around the last one.  Tried removing and reinstalling the iptables package, but same result.

    I test on fresh Armbian_19.11.3_Helios4_buster_current_4.19.84.img
     

    1. I don't encounter such error when accessing the system from Windows using PuTTY or thru serial console

       UPDATE: i tried to SSH from my Ubuntu machine (got id_ID locale), indeed there are perl warning regarding locale but armbian-config is still usable to generate the locale, no need to manually edit file. After the locale generated by armbian-config, no more perl locale warning.


    2. Confirmed

    3. Confirmed.

    cat: /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies: No such file or directory
    cat: /sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors: No such file or directory
    
    
    /usr/lib/armbian-config/jobs.sh: line 1075:
    Error: Expected at least 5 tokens for --menu, have 4.
    Use --help to list options. / 1000: syntax error in expression (error token is ": Expected at least 5 tokens for --menu, have 4.
    Use --help to list options. / 1000")
    

    The path is not exist, even though the driver is compiled. I will need to investigate further.

    ---

    I also tried using fresh Armbian 5.91 then upgraded to Armbian 19.11.3, but strangely i don't see the System - CPU menu.

    helios4_armbian_config_system-cpu.PNG.8520da8295bfa0cfc8d12c2c71acc05e.PNG

     

    4. As mentioned on @sirleon link, apparently Buster make use nftables by default and on our kernel is not enabled. You could try to switch to iptables-legacy version.

    CONFIG_NF_TABLES=m
    CONFIG_NF_TABLES_SET=m
    # CONFIG_NF_TABLES_INET is not set
    # CONFIG_NF_TABLES_NETDEV is not set
    # CONFIG_NF_TABLES_IPV4 is not set
    # CONFIG_NF_TABLES_ARP is not set
    # CONFIG_NF_TABLES_IPV6 is not set
    # CONFIG_NF_TABLES_BRIDGE is not set
    

    meanwhile, i will try to enable those modules and test.

     

    @Igor, could you take a look whether armbian-config issues also occur on other board?

  14. On 12/23/2019 at 12:20 AM, sirleon said:

    I tried to move the complete system from the SD-card to an SSD, so i followed the tutorial as described here.

    I'm not sure how to do the following steps:

    I can't move the target SATA-device because spi_workaround is enabled.

     

    What can I do to get rid of the SD-card and booting from SPI / SATA-device?

    Should I move the /boot partition from the SD-card to sdb1? Is it necessary to modify /etc/fstab ?

     

    (I alread tried moving the rootFS with sata-nand-install while spi_workaround is disabled. The system was booting and mounted from sdb1, but I can't get it to boot without the SD-card)

    Hi @sirleon, the tutorial is intended for moving the rootfs to USB thumb drive and due to spi_workaround it does not work with SATA seamlessly but you almost there..

    I suggest to move the rootfs to drive that connected to SATA0 (most likely /dev/sda), because there is known issue that u-boot failed to recognized SATA device other than on SATA0.

     

    To boot from SATA you need to:
    1. Move the rootfs with sata-nand-install while spi_workaround is disabled, and reboot.
        The system will boot from SD card.

    2.  Unmount /boot and copy over boot files from /media/mmcboot/boot to /boot

    umount /boot
    cp -rf /media/mmcboot/boot/* /boot/

    3.  Edit /etc/fstab and remove/comment 2 lines that have mount point to /media/mmcboot and /boot.

    4.  Reboot the system and cancel u-boot auto boot.

    5.  Run following commands on u-boot prompt to add sata boot and reboot

    setenv boot_targets "usb0 scsi0 mmc0 pxe dhcp"
    setenv bootcmd_scsi0 'devnum=0; run scsi_boot'
    saveenv

    You could reorder the boot order on boot_targets variable. On above command, it would tried to boot from USB and if failed try SATA/SCSI and so on.

     

  15. On 8/15/2019 at 9:48 AM, jimbolaya said:

    I just received and set up my Helios4. I set it up with Buster and it seems to be working OK.

     

    One thing that seems to be missing is the ch341 usb serial driver. I have this attached to an old APC UPS that has a serial port and a USB serial cable that uses the HL-340 serial chip.

     

    I was unable to find the driver in /lib/modules. Will I need to compile the driver myself or am I missing a package?

     

    If it wasn't included intentionally, is there a technical reason not to include the driver for this kernel?

     

    @jimbolaya, I know it's quite late, ch341 driver would be included on next release. Refer to commit 14a0a54.

     

     

    On 10/7/2019 at 6:00 PM, smith69085 said:

    Hello, I've been using the Helios4 for some time now and its working great. The only thing I'm missing is a soft shut down button, opposed to  using ssh.

     

    I'm pretty new to this and struggling to find info on a solution. CAn anyone point me in the right direction for a shutdown button connected through the gpio pins?

    @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

     

  16. On 9/6/2019 at 5:55 PM, Fefo said:

    Hi,

     

    Yes - System activity led is blinking

    Yes - power indicator led is also on

    System is not possible to reach either by console or network

     

    STEP-1

    I have tried starting system without mentioned disk on SATA port 4 and then is OK (access possible). 

    STEP-2

    I changed SATA cable for port4 and reconnecting disk - system becomes unnaccessible again.

    STEP-3

    I have tried starting system without disk on SATA port 3 and then is OK (access possible). 

    STEP-4

    I tried and changed SATA cable for port 3 and reconnecting disk - system becomes unnaccessible again.

     

    My result:

    If Disks on SATA3 and SATA4 are both connected - system doesnt start. 

    Last operation (before malfunction) was creating mirror (inside OpenMediaVault) between this two disks (both 1TB - on SATA 3 and SATA4 ports )

     

    image.png.712fc134f9ad7265ea5350b11c65a04b.png

     

    Is it a SW bug of some sort?

     

    Info:  At this point data loss is not a problem - I have this for testing purposes for now.

    Regards

     

     

    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

     

    Quote

    [ 2.858020] async_tx: api initialized (async)

    [ 2.864901] md/raid:md0: not clean -- starting background reconstruction

    [ 2.864938] md/raid:md0: device sdb operational as raid disk 0

    [ 2.864941] md/raid:md0: device sdc operational as raid disk 1

    [ 2.864943] md/raid:md0: device sdd operational as raid disk 2

    [ 2.866085] md/raid:md0: raid level 5 active with 3 out of 3 devices, algorithm 2

    [ 2.916888] md0: detected capacity change from 0 to 2000140894208

    [ 3.685359] random: crng init done

     

    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.

  17. 1 hour ago, prok said:

    Hello, I'm going through the setup tutorial, but I'm unable to connect to the Helios4 via serial port. I'm running PuTTY on Windows, and installed the FTDI driver (via setup executable) from the page linked in the installation guide. When I attempt to connect, nothing happens. The device shows under Device Manager using the COM3 port. I tried setting the speed to 115200 for the COM3 port via Windows settings, but that didn't make a difference. Is there something I'm missing?

     

    Hi,

    Just wanted to make sure, do you see something like in screenshot below?

    device_manager_copy.png.1e2f67676fb76ead463fd653f0c27668.png

     

     

     

  18. 5 hours ago, alchemist said:

    Hi,

     

    An other question : I would like to run the latest vanilla kernel (5.2.*). Is there a patch for the dual fan ? The patch provided in the pwm section seems for kernel 4.x and is is rejected.

     

    Thanks!

     

    Kind regards,

    Xavier Miller.

    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

     

     

  19. 18 hours ago, alchemist said:

    Hi,

    I am trying to compile and run U-BOOT on SATA1 but I don't succeed. What I can do is boot from flash memory using the armbian binary provided on the armbian sd card.

     

    And I cannot find the SATA installation documentation on the wiki, except the picture with the DIP switches (I used this from Solidrun, : dd if=u-boot-spl-sata.kwb of=/dev/sdX bs=512 seek=1 conv=sync, not working).

    And I cannot get a self-compiled working U-BOOT binary with helios4_defconfig

     

    So my questions is what options do I need to activate to have a self-compiled U-BOOT binary that can boot on SATA ? Is the dd command from Solidrun OK for the sata option ?

     

    (For now, I will boot from flash memory, running Gentoo Linux and concentrate later on U-Boot... I want to understand and master that part too)

     

    Kind regards,

    Xavier Miller

     

     

     

    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

    1. USB
    2. SATA1
    3. SD Card

     

  20. 1 hour ago, jimbolaya said:

    I just received and set up my Helios4. I set it up with Buster and it seems to be working OK.

     

    One thing that seems to be missing is the ch341 usb serial driver. I have this attached to an old APC UPS that has a serial port and a USB serial cable that uses the HL-340 serial chip.

     

    I was unable to find the driver in /lib/modules. Will I need to compile the driver myself or am I missing a package?

     

    If it wasn't included intentionally, is there a technical reason not to include the driver for this kernel?

    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

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

     

  22. 27 minutes ago, MarcC said:

    Hi @gprovost,

     

    Reading the wiki while waiting for the Batch3 , I was wondering if it would be possible to boot directly to a sata disk...

    SPI-NOR Flash wiki page only mentions booting to a microSD card or USB drives. Would something like the following work ?

    
    ext4load sata 0:1

    Or does the concurrent access issue between SPI NOR Flash and SATA drives currently prevents this ? Thanks.

     

    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

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines