Jump to content

chradev

Members
  • Posts

    224
  • Joined

  • Last visited

Reputation Activity

  1. Like
    chradev got a reaction from Igor in Armbian customization   
    Hi to All,
     
    I would like to inform you about my post on Lime2-eMMC board application in Ground Penetrating Radar (GPR) system.
     
    I would also like to express our gratitude to Armbian project, its whole team and everybody here in for the great effort and help.
     
    Best regards
    Chris
  2. Like
    chradev got a reaction from tkaiser in Armbian customization   
    Hi to All,
     
    I would like to inform you about my post on Lime2-eMMC board application in Ground Penetrating Radar (GPR) system.
     
    I would also like to express our gratitude to Armbian project, its whole team and everybody here in for the great effort and help.
     
    Best regards
    Chris
  3. Like
    chradev got a reaction from neomanic in LIME2-eMMC application in Ground Penetrating Radar system   
    Hi to All,
     
    I am proud to announce that our effort to embed Olimex' Lime2-eMMC board in Application Controller for Ground Penetrating Radar (GPR) systems meets with success to the final phase.
    Our product EGPR (Easy Ground Penetrating Radar) is ready for demo and field tests.
     
    Everybody can take a look on our just finished web site.
    There is link to the real application from Demo page.
     
    We would like to express our gratitude to Armbian project, its whole team and everybody here in for the great effort and help.
     
    Best regards
     
    EGPR team
     


  4. Like
    chradev got a reaction from zador.blood.stained in LIME2-eMMC application in Ground Penetrating Radar system   
    Hi to All,
     
    I am proud to announce that our effort to embed Olimex' Lime2-eMMC board in Application Controller for Ground Penetrating Radar (GPR) systems meets with success to the final phase.
    Our product EGPR (Easy Ground Penetrating Radar) is ready for demo and field tests.
     
    Everybody can take a look on our just finished web site.
    There is link to the real application from Demo page.
     
    We would like to express our gratitude to Armbian project, its whole team and everybody here in for the great effort and help.
     
    Best regards
     
    EGPR team
     


  5. Like
    chradev got a reaction from Igor in LIME2-eMMC application in Ground Penetrating Radar system   
    Hi to All,
     
    I am proud to announce that our effort to embed Olimex' Lime2-eMMC board in Application Controller for Ground Penetrating Radar (GPR) systems meets with success to the final phase.
    Our product EGPR (Easy Ground Penetrating Radar) is ready for demo and field tests.
     
    Everybody can take a look on our just finished web site.
    There is link to the real application from Demo page.
     
    We would like to express our gratitude to Armbian project, its whole team and everybody here in for the great effort and help.
     
    Best regards
     
    EGPR team
     


  6. Like
    chradev got a reaction from berkovsky in No USB on banana pi after manual kernel update   
    Hi Berkovsky,
    I have similar problem with Lime2-eMMC (A20 & AXP209) board and customized Armbian build always using latest mainline Kernel versions (4.8.10 at the moment).
    The problem is discussed from here to here but some HW dependency on UART0 RxD was found.
     
    Can you check if the bug disappears in case of serial console disconnecting if one is used.
     
    Best regards
    Chris
  7. Like
    chradev got a reaction from neomanic in Banana Pi USB OTG   
    Hi to All,
    It is proved to work on Kernel 4.7.6 and can be tested without Kernel build using following procedure:
    cp /boot/dtb/sun7i-a20-olinuxino-lime2-emmc.dtb . dtc -I dtb -O dts -o sun7i-a20-olinuxino-lime2-emmc.dts sun7i-a20-olinuxino-lime2-emmc.dtb nano sun7i-a20-olinuxino-lime2-emmc.dts Change and remove to fit following:
     
     
    where the original staff is:
     
     
    and the difference is:
    root@egpr:~# diff sun7i-a20-olinuxino-lime2-emmc.dts.orig sun7i-a20-olinuxino-lime2-emmc.dts 830c830 < dr_mode = "otg"; --- > dr_mode = "host"; 845,848d844 < pinctrl-names = "default"; < pinctrl-0 = <0x29 0x2a>; < usb0_id_det-gpio = <0x21 0x7 0x4 0x0>; < usb0_vbus_det-gpio = <0x21 0x7 0x5 0x0>; Re-compile device tree, copy it back to /boot/dtb/ and reboot
    dtc -I dts -O dtb -o sun7i-a20-olinuxino-lime2-emmc.dtb sun7i-a20-olinuxino-lime2-emmc.dts cp sun7i-a20-olinuxino-lime2-emmc.dtb /boot/dtb/ reboot USB device can be connected to OTG port via USB OTG cable and registered in the system.
    You will see musb massages at 'dmesg' and corresponding Bus Device in 'lsusb' printout.
     
    The procedure can be applied for other boards using corresponding DT file.
    Some of the staff may differ from Lime2-eMMC one above.
     
    Best regards
    Chris
  8. Like
    chradev got a reaction from tkaiser in Armbian customization   
    Hi to All,
     
    Thanks to Arox' assistance I have managed to get to my preferred reboot button control.
     
    Button is controlled by 'gpio-keys-polled' mainline Kernel driver as described here.
    Trigger Happy daemon is used to listen and execute an user script as described here.
     
    Finally, after installation of triggerhappy from the official Debian repository following files ware added:
     * /etc/triggerhappy/triggers.d/reboot.conf
    # EV_KEY BTN_0 1 /dev/input/event0 BTN_0 1 /bin/reboot.sh  * /bin/reboot.sh with mode 766
    #!/bin/bash /bin/echo none > /sys/class/leds/egpr-sys\:green\:usr/trigger /bin/echo timer > /sys/class/leds/egpr-sys\:red\:usr/trigger /bin/echo none > /sys/class/leds/egpr-sys\:blue\:usr/trigger /sbin/reboot and /etc/init.d/triggerhappy script is modified as follows:
    sed -i 's/--user nobody/--user root/g' /etc/init.d/triggerhappy to allow running privileged command.
     
    The effect of pushing the PG0 button is: the red system LED on PG0 starts blinking and system is restarted what is the main goal as a beginning.
     
    Additionally, file '/etc/udev/rules.d/72-system-reboot-button.rules' can be created for adding link to the right /dev/input/eventX device:
    # Handle user button with systemd ACTION=="remove", GOTO="power_switch_end" SUBSYSTEM=="input", KERNEL=="event*", ATTRS{name}=="egpr-keys", SYMLINK+="rebooter" LABEL="power_switch_end" After reboot ther will be the following:
    root@egpr:~# ls -la /dev/rebooter lrwxrwxrwx 1 root root 12 Oct 17 17:24 /dev/rebooter -> input/event0 which can be used if needed.
     
    Best regards
    Chris
     
  9. Like
    chradev got a reaction from neomanic in Armbian customization   
    Hi to All,
    After discussion with the author of the patch for adding of lime2-emmc as a new board to Kernel 4.7 Olliver Schinagl I have tested and found that the problem can be overcome by removing of the staff around mmc2_pwrseq and PC16 using following patch:
    index 5ea4915..7e6b703 100644 --- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts +++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts @@ -46,22 +46,6 @@ / { model = "Olimex A20-OLinuXino-LIME2-eMMC"; compatible = "olimex,a20-olinuxino-lime2-emmc", "allwinner,sun7i-a20"; - - mmc2_pwrseq: pwrseq { - pinctrl-0 = <&mmc2_pins_nrst>; - pinctrl-names = "default"; - compatible = "mmc-pwrseq-emmc"; - reset-gpios = <&pio 2 16 GPIO_ACTIVE_LOW>; - }; -}; - -&pio { - mmc2_pins_nrst: mmc2@0 { - allwinner,pins = "PC16"; - allwinner,function = "gpio_out"; - allwinner,drive = <SUN4I_PINCTRL_10_MA>; - allwinner,pull = <SUN4I_PINCTRL_NO_PULL>; - }; }; &mmc2 { @@ -71,7 +55,6 @@ vqmmc-supply = <&reg_vcc3v3>; bus-width = <4>; non-removable; - mmc-pwrseq = <&mmc2_pwrseq>; status = "okay"; emmc: emmc@0 { As tested for months (with my patches for older Kernel versions and 'lime2' config) the system works fine without above staff probably because eMMC chip makes internal reset when powered.
     
    If above staff is present the system makes sw reset using pin PC16 but the reset procedure takes too long and it is the reason for the observed delay and errors.

    If the system is booted from eMMC delay caused by the reset sequence makes device busy at the moment when rootfs has to be mounted. That is way the boot process stops.
     
    In my opinion even with observed delay the system has to continue with rootfs mounting when device become ready but this is another issue or maybe limitation.
     
    Unfortunately, Oliver has no time to work on this issue at the moment but maybe somebody else experienced in that field can help.
     
    Best regards
    Chris
     
  10. Like
    chradev got a reaction from Igor in Armbian boot process unification   
    Hi to All,
     
    I have decided to publish my posts in PM with Neomatic (Josh) answering his questions noted above in this tread.
     
    Sent 17 July 2016 - 03:03 AM
     
     
    Sent 20 July 2016 - 04:15 PM
     
     
     
    Best regards
    Chris
  11. Like
    chradev got a reaction from tkaiser in Armbian customization   
    Hi to All,
     
    Following Igor's and Zador's advises I have build U-Boot with 384 MHz DRAM speed and run it before more than 10 hours with a server and 4 clients application load.
    Because the system do not hang for more than 10 hours I decided to add more load running continuously both 'iperf3' and 'stress' tests with following arguments:
    iperf3 -s (on a Lime2-emmc) / while true; do iperf3 -c IP; done; (on a VM with Ubuntu 14.04 running on i7/Windows 7 desktop) - both connected via Linksys' WRT1900ACS routed over GBit LAN while true; do stress -c 1 -i 1 -m 1 --vm-bytes 128M -d 1 --hdd-bytes 128M -t 60; done; - with disk operation running on SATA SSD Total load and other parameters measured by RPI Monitor are:
    ~8 (1 min averaged) CPU load ~320kBps upload transfer rate ~40MBps download transfer rate (~64MBps without stress test) 210-430Mbps download bandwidth measured by iperf3 ~3.7W consumption measured by PMU ~4.4W consumption measured before DC-IN 960MHz CPU frequency (all the time) Temperatures: 34°C CPU, 44°C PMU and 35°C Cooler Unfortunately, the drawback is that the application clients decrease the visualization speed from 56 to 10 FPS because of server's overload but the good news is that the system continues running.
     
    Best regards
    Chris
     
     
  12. Like
    chradev got a reaction from tkaiser in Armbian boot process unification   
    Hi to All,
     
    I have decided to publish my posts in PM with Neomatic (Josh) answering his questions noted above in this tread.
     
    Sent 17 July 2016 - 03:03 AM
     
     
    Sent 20 July 2016 - 04:15 PM
     
     
     
    Best regards
    Chris
  13. Like
    chradev got a reaction from Igor in Armbian customization   
    Hi to All,
     
    Following Igor's and Zador's advises I have build U-Boot with 384 MHz DRAM speed and run it before more than 10 hours with a server and 4 clients application load.
    Because the system do not hang for more than 10 hours I decided to add more load running continuously both 'iperf3' and 'stress' tests with following arguments:
    iperf3 -s (on a Lime2-emmc) / while true; do iperf3 -c IP; done; (on a VM with Ubuntu 14.04 running on i7/Windows 7 desktop) - both connected via Linksys' WRT1900ACS routed over GBit LAN while true; do stress -c 1 -i 1 -m 1 --vm-bytes 128M -d 1 --hdd-bytes 128M -t 60; done; - with disk operation running on SATA SSD Total load and other parameters measured by RPI Monitor are:
    ~8 (1 min averaged) CPU load ~320kBps upload transfer rate ~40MBps download transfer rate (~64MBps without stress test) 210-430Mbps download bandwidth measured by iperf3 ~3.7W consumption measured by PMU ~4.4W consumption measured before DC-IN 960MHz CPU frequency (all the time) Temperatures: 34°C CPU, 44°C PMU and 35°C Cooler Unfortunately, the drawback is that the application clients decrease the visualization speed from 56 to 10 FPS because of server's overload but the good news is that the system continues running.
     
    Best regards
    Chris
     
     
  14. Like
    chradev got a reaction from spacebass in Armbian customization   
    Hi to All,
     
    Following the need to install and customize too many times RPI Monitor (for Lime2) I find useful to gzip in a single file all the staff have to be added or modified (in case of mainline kernel usage) afterwards. Reading all discussions, advises and own experience I succeed to reduce the procedure to a file and 5 easy steps:
    root@lime2:~# armbianmonitor -r // Check if RPI Monitor is working on: http://lime2-ip-address:8888/ root@lime2:~# tar -zxvf /path-to-archive/armbianmonitor.tar.gz -C / root@lime2:~# service rpimonitor restart // Check if RPI Monitor is customized on: http://lime2-ip-address:8888/ Find attached armbianmonitor.tar.gz file including a couple of goodies as well.
     
    On the other hand it is a time to offer RPI Monitor itself to be added to the main Armbian distribution because of:
    it is quite useful for almost all users its adding to the customization script is quite tricky to be leaved to the users its customization is board dependent and could be leaved to the users because the support is not finished yet Best regards
    Chris
    armbianmonitor.tar.gz
  15. Like
    chradev got a reaction from lanefu in Armbian boot process unification   
    Hi to All,
     
    I decided to start this new tread for searching of the best solution for unification of the boot process from any available media.
     
    Main target is Armbian next and development branches and mainline Kernel and U-Boot.
    Boot device can be eMMC, SD/MMC, USB Flash/HDD and SATA HDD/SSD probed in given order.
    In case of booting from eMMC, SD/MMC and USB Flash Read-Only Root FS can be used optionally.
    In case of booting from SD/MMC or USB Flash eMMC and / or SATA devices can be updated automatically.
     
    Some effort in this direction was done by me and described in Armbian Customization thread.
    The tests was done on Olimex' A20-Olimexino-Lime2-eMMC (HW rev. E) board with following additional staff:
    60GB SATA SSD with SATA-CABLE-SET MOD-WIFI-R5370 mounted on the rear panel - only antenna outside USB-ETHERNET-AX88772B - optional BATTERY-LIPO6600mAh ALUMINIUM-HEATSINK-20x20x6MM later changed with special high efficient cooling system A10-OLinuXino-LIME-BOX later changed to water and dust resistant solution based on Aluminum box FTDI FT4232H based USB Hi-Speed Serial/Hub Module AC/DC 5V/4A wall adapter Dual LED Red + Blue Display Digital Voltmeter Ammeter DC 3.5-28V 3A Additional User Push Button and 3 LEDs are connected via Lime2 GPIO-1 connector 1-Wire GPIO based Master and additional Device Boot control is implemented via Lime2 GPIO-1 connector Reset, Power On/Off buttons and Charge LED are wired to front panel doubles Console, DC-IN, USB and Ethernet connectors are wired to rear panel doubles The current status is:
    U-Boot is patched to:recognize eMMC; search a boot-able device on SATA, USB, SD/MMC, eMMC etc.; boot from the boot-able device with the highest priority; send to the kernel via the command line right root=PARTUUID=${uuid}; Kernel is patched to recognize eMMC; firstrun script is modified to resize right MMC device (mmcblk0 or mmcblk1); eMMC and SATA device experimental update scripts are implemented and tested; it is investigated the classical and overlayfs way to run Debian on RO Root FS; Described staff is working fine on latest Armbian (5.17), Kernel (4.6.3) and U-Boot (2016.05). Not solved issues are:
    to mount root accordingly without explicit setting in /etc/fstab; to resize root partition from firstrun script in case of USB and / or SATA devices; to prepare and use Read-Only Root FS on eMMC, SD/MMC and USB Flash optionally; to start eMMC and /or SATA device update procedure from firstrun script if boot from SD/MMC or USB Flash. The main use case will include following steps:
    If the system will be setup for the first time SD/MMC has to be used for been able to install U-Boot on empty eMMC; In case of next FW update USB Flash will be used to boot from by installed on eMMC U-Boot; Booting from SD/MMC will be forced by pushing of user button or renaming of /boot/boot.scr file on the devices with higher priority; Booting from USB Flash will be done always when present because of highest priority; firstrun script will be executed always if booting from image cloned device and the system will reboot if necessary; At the end of firstrun script eMMC and / or SATA device update scripts will be executed to update them from image or SD/MMC or USB Flash itself. The following staff was used to customize Armbian:
     
    Mainline U-Boot patch to enable eMMC:
     
     
     
    Mainline U-Boot patch to change boot order:
     
     
     
    Mainline U-Boot boot script:
     
     
     
    Mainline Kernel patch to enable eMMC:
     
     
     
    Change in do_expand_rootfs() function of firstrun script to recognize right MMC device to resize:
    # DEVICE="/dev/"$(lsblk -idn -o NAME | grep -w mmcblk0) DEVICE=$(mount|grep ' / '|cut -d' ' -f 1 | cut -dp -f1) Reboot script and service looking for user button push:
     
     
     
    Experimental script to update eMMC from image:
     
     
     
    Experimental script to update SATA SSD from image:
     
     
     
    Whole customization process with more details and test results can be found on Armbian Customization thread.
    Latest prototype insides and test results can be found in the attached files.
     
    Any ideas, comments and references are welcome.
     
    Best regards
    Chris
     

    Lime2-rev-C-E-comp-06-p8.pdf
    Lime2-rev-C-E-comp-06-7p.pdf
  16. Like
    chradev got a reaction from wildcat_paris in Armbian boot process unification   
    Hi to All,
     
    I decided to start this new tread for searching of the best solution for unification of the boot process from any available media.
     
    Main target is Armbian next and development branches and mainline Kernel and U-Boot.
    Boot device can be eMMC, SD/MMC, USB Flash/HDD and SATA HDD/SSD probed in given order.
    In case of booting from eMMC, SD/MMC and USB Flash Read-Only Root FS can be used optionally.
    In case of booting from SD/MMC or USB Flash eMMC and / or SATA devices can be updated automatically.
     
    Some effort in this direction was done by me and described in Armbian Customization thread.
    The tests was done on Olimex' A20-Olimexino-Lime2-eMMC (HW rev. E) board with following additional staff:
    60GB SATA SSD with SATA-CABLE-SET MOD-WIFI-R5370 mounted on the rear panel - only antenna outside USB-ETHERNET-AX88772B - optional BATTERY-LIPO6600mAh ALUMINIUM-HEATSINK-20x20x6MM later changed with special high efficient cooling system A10-OLinuXino-LIME-BOX later changed to water and dust resistant solution based on Aluminum box FTDI FT4232H based USB Hi-Speed Serial/Hub Module AC/DC 5V/4A wall adapter Dual LED Red + Blue Display Digital Voltmeter Ammeter DC 3.5-28V 3A Additional User Push Button and 3 LEDs are connected via Lime2 GPIO-1 connector 1-Wire GPIO based Master and additional Device Boot control is implemented via Lime2 GPIO-1 connector Reset, Power On/Off buttons and Charge LED are wired to front panel doubles Console, DC-IN, USB and Ethernet connectors are wired to rear panel doubles The current status is:
    U-Boot is patched to:recognize eMMC; search a boot-able device on SATA, USB, SD/MMC, eMMC etc.; boot from the boot-able device with the highest priority; send to the kernel via the command line right root=PARTUUID=${uuid}; Kernel is patched to recognize eMMC; firstrun script is modified to resize right MMC device (mmcblk0 or mmcblk1); eMMC and SATA device experimental update scripts are implemented and tested; it is investigated the classical and overlayfs way to run Debian on RO Root FS; Described staff is working fine on latest Armbian (5.17), Kernel (4.6.3) and U-Boot (2016.05). Not solved issues are:
    to mount root accordingly without explicit setting in /etc/fstab; to resize root partition from firstrun script in case of USB and / or SATA devices; to prepare and use Read-Only Root FS on eMMC, SD/MMC and USB Flash optionally; to start eMMC and /or SATA device update procedure from firstrun script if boot from SD/MMC or USB Flash. The main use case will include following steps:
    If the system will be setup for the first time SD/MMC has to be used for been able to install U-Boot on empty eMMC; In case of next FW update USB Flash will be used to boot from by installed on eMMC U-Boot; Booting from SD/MMC will be forced by pushing of user button or renaming of /boot/boot.scr file on the devices with higher priority; Booting from USB Flash will be done always when present because of highest priority; firstrun script will be executed always if booting from image cloned device and the system will reboot if necessary; At the end of firstrun script eMMC and / or SATA device update scripts will be executed to update them from image or SD/MMC or USB Flash itself. The following staff was used to customize Armbian:
     
    Mainline U-Boot patch to enable eMMC:
     
     
     
    Mainline U-Boot patch to change boot order:
     
     
     
    Mainline U-Boot boot script:
     
     
     
    Mainline Kernel patch to enable eMMC:
     
     
     
    Change in do_expand_rootfs() function of firstrun script to recognize right MMC device to resize:
    # DEVICE="/dev/"$(lsblk -idn -o NAME | grep -w mmcblk0) DEVICE=$(mount|grep ' / '|cut -d' ' -f 1 | cut -dp -f1) Reboot script and service looking for user button push:
     
     
     
    Experimental script to update eMMC from image:
     
     
     
    Experimental script to update SATA SSD from image:
     
     
     
    Whole customization process with more details and test results can be found on Armbian Customization thread.
    Latest prototype insides and test results can be found in the attached files.
     
    Any ideas, comments and references are welcome.
     
    Best regards
    Chris
     

    Lime2-rev-C-E-comp-06-p8.pdf
    Lime2-rev-C-E-comp-06-7p.pdf
  17. Like
    chradev got a reaction from Igor in Armbian customization   
    Hi to All,
     
    Following http://linux-sunxi.org/1-Wire, thanks to http://forum.armbian.com/index.php/topic/1267-armbian-511-fails-to-build-kernel/ and after a whole night fighting I finally succeed to find how to patch Lime2-eMMC device tree to support OneWire devices in Armbian 5.12 with kernel 4.5.5:
     
     
    and the result is:
     
     
    There are 2x DS18B20 devices measuring ambient (24.2°C) and PMU (34.9°C) temperatures.
     
    Following http://rpi-experiences.blogspot.bg/2013/06/rpi-monitor-version-20-advance-usage.html  I have also added them to status and statistics of RPI Monitor:
     
     
     
    Best regards
    Chris
  18. Like
    chradev got a reaction from tkaiser in Testers wanted: SD card performance   
    Hi to All,
     
    Some results from the performance tests of eMMC on A20-Olinuxinot-Lime2-eMMC can be found on the following  posts:
    http://forum.armbian.com/index.php/topic/853-armbian-customization/page-4#entry8846 - in graphics form
    http://forum.armbian.com/index.php/topic/853-armbian-customization/page-4#entry8847 - data in raw format
     
    Best regards
    Chris
  19. Like
    chradev got a reaction from Igor in Armbian customization   
    Hi to All,
     
    I have extend performance tests with measurement of eMMC, SD/MMC and SATA SSD R/W speed with kernel 4.6-rc7.
     
    Interesting phenomenon is up to 87% eMMC read speed increase with kernel 4.6-rc7 (38.9 vs. 20.8 MB/s at iozone read with 512+ kB buffer).
    Olliver Schinagl has reported the similar result for eMMC read speed with kernel 4.6-rc7 explaining it with added advances driver features.
     
    Unfortunately, the better write speed of 17 MB/s reported by him is not observed in my tests.
    A possible reason for that could be multiply writes of big files to eMMC in my case.
     
    Best regards
    Chris
    eMMC-RW-speed-1.pdf
  20. Like
    chradev got a reaction from djojo in Armbian customization   
    Hi Igor,
     
     
    I use dev branch and put the new patch in userpatches/kernel/sunxi-dev.
    The new patch create a new device tree source file named sun7i-a20-olinuxino-lime2-emmc.dts and add it to Makefile be compiled.
     
    Unfortunately, I cannot find a way to add new board lime2-emmc without modifying Armbian code base.
     
    Is there such a way or I have to modify Armbian code base for adding the new board?
    And if so where and what I have to add as a staff for the new board?
     
    I prefer to add completely new board named lime2-emmc with all needed configuration staff instead of patching other board staff.
     
    Best regards
    Chris
  21. Like
    chradev got a reaction from tkaiser in Armbian customization   
    Hi to All,
     
    Here you can find raw data from iozone test of 4BG eMMC on A2-Olinuxino-Lime2-eMMC:


    and the info printed from mmctest script:


     
    For reference here you can also find the info and the speed test results of 4GB SD card class 10:


     
    and 60GB SATA SSD:


     
    Best regards
    Chris
  22. Like
    chradev got a reaction from Igor in Armbian customization   
    Hi to All,
     
    I decided to continue with my Armbian (5.07 from git) customization effort using latest U-Boot v2016.05-rc1, Kernel 4.5.1.
    There you are the messages taken while booting from SD card prepared with 'dd' an without any modifications afterwards.
     
    U-Boot:
     
     
     
    Console:
     
     
     
    dmesg:
     
     
     
    In addition to A20-Olimexino-Lime2-eMMC (HW rev. E) board there are:
    60GB SATA SSD with SATA-CABLE-SET MOD-WIFI-R5370 USB-ETHERNET-AX88772B BATTERY-LIPO6600mAh ALUMINIUM-HEATSINK-20x20x6MM A10-OLinuXino-LIME-BOX FTDI FT4232H based USB Hi-Speed Serial/Hub Module AC/DC 5V/4A wall adapter Dual LED Red + Blue Display Digital Voltmeter Ammeter DC 3.5-28V 3A In addition to the standard Armbian staff following packages are installed and configured at build time:
    mc pmount dnsutils dnsmasq nginx-full Additional packages installed from none Debian sites:
    Node.JS (v. 4.4.3) incl. a few npm packages - at build time from customization script PRI Monitor v. 2.10 - at first run PRI Monitor is also customized to work with A20/AXP209 and integrated in nginx web server based on Armbian forums.
    System is configured to boot from either eMMC or SD card if present. SSD has 2 EXT4 partitions for data and system.
    Network configuration is like a router with WAN on native Ethernet interface and LAN on USB-LAN and USB-WiFi adapters in bridge.
    DHCP and DNS services are accessible only from LAN while and web one from both interfaces. Iptables is used to manage network access.
     
    Total power consumption (in idle state) is 470mA@5.25V and 240mA@5.18V passes through PMU up to maximal 9.2W (DC-IN) and 6.7W (PMU).
    The most power hungry devices are USB-LAN adapter (more than 160mA) and GBit ethernet PHY (more than 60mA) in system idle state.
    CPU and PMU temperatures measered at open box was 43.5°C/26.5°C (in idle) up to 58.2°C/58.2°C (at extreem load incl. battery charge).
     
    No system hangs are observed except in closed box case with system load (not always maximal).
    The best performance results measured (with U-Boot 2015.10 and Kernel 4.4.6) are:
    980Mbps GBit LAN throughput 48/90 MB/s SSD R/W speed 10 hours (all HW staff) and 16 hours (without USB-LAN) life on battery in idle state  
    It will be nice if somebody while looking around catch some unusual case or problem and share it or any thought.
     
    Best regards
    Chris
  23. Like
    chradev got a reaction from Igor in Armbian customization   
    Hi to All,
     
    I have successfully build and boot Armbian 5.07 with mainline kernel 4.4.6 supporting eMMC on A20-OLinuXIno-Lime2-eMMC board.
    For successful booting I add in userpatches/lib.config:
    BOOTBRANCH=v2015.10 in userpatches/kernel/sunxi-next I add a20-lime2-emmc-mainline.patch
     
     
    after building of the image and booting I did:
     
     
    where a20-lime2-emmc-dts.patch is:
     
     
    Note that line vmmc-supply = <0x1b>; have to refer the same vmmc-supply as mmc@1c0f000
    After booting you can find following messages:
     
     
    lsblk command reports:
    root@lime2:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT mmcblk1boot0 179:16 0 16M 1 disk mmcblk1boot1 179:24 0 16M 1 disk mmcblk0 179:0 0 3.7G 0 disk └─mmcblk0p1 179:1 0 3.5G 0 part / mmcblk1 179:8 0 3.6G 0 disk └─mmcblk1p1 179:9 0 3.6G 0 part The good news is that mmc0 was registered as device mmcblk0 so no changes have to be made at boot script.
    'ls -la /dev/mmc*':
    root@lime2:~# ls -la /dev/mmc* brw-rw---- 1 root disk 179, 0 Apr 9 02:54 /dev/mmcblk0 brw-rw---- 1 root disk 179, 1 Apr 9 02:54 /dev/mmcblk0p1 brw-rw---- 1 root disk 179, 8 Apr 9 02:53 /dev/mmcblk1 brw-rw---- 1 root disk 179, 16 Apr 9 02:53 /dev/mmcblk1boot0 brw-rw---- 1 root disk 179, 24 Apr 9 02:53 /dev/mmcblk1boot1 brw-rw---- 1 root disk 179, 9 Apr 9 02:53 /dev/mmcblk1p1 'fdisk /dev/mmcblk1'
    root@lime2:~# fdisk /dev/mmcblk1 ... Command (m for help): p Disk /dev/mmcblk1: 3.6 GiB, 3867148288 bytes, 7553024 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0xe84940b0 Device Boot Start End Sectors Size Id Type /dev/mmcblk1p1 2048 7553023 7550976 3.6G 83 Linux eMMC read and write performance is better then with default kernel 3.4.111 (especially at reading):
    root@lime2:~# dd if=/dev/zero of=/mnt/1GBfile bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 81.1107 s, 13.2 MB/s root@lime2:~# dd of=/dev/null if=/mnt/1GBfile 2097152+0 records in 2097152+0 records out 1073741824 bytes (1.1 GB) copied, 49.7389 s, 21.6 MB/s Ethernet is connected as:
    [ 686.791628] sun7i-dwmac 1c50000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx [ 686.791706] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Network performance measured by scp command is like with default kernel 3.4.111:
    root@chr-vm-yocto:/data# scp root@192.168.1.190:/mnt/1GBfile . root@192.168.1.190's password: 1GBfile 100% 1024MB 8.2MB/s 02:05 More test should be done to prove if the Ethernet connection is really GBit.
     
    Best ragards
    Chris
  24. Like
    chradev got a reaction from tkaiser in Armbian customization   
    Hi candratech,
     
    It is good idea in case of having specifics you describe. Choosing Armbian was in competition with Yocto project which is on the other side as complexity and flexibility. It support own repositories for all packages and images built but it is quite complex for my needs.
     
    Fortunately or not my use case is slightly different:
    single board (could be more in future but limited as number and close as HW) FW update will be based on complete SD image (not on packages) Armbian basically fits my needs as staff, configuration and supported boards customization needed is mainly in package set and configuration a set of data files have to be embedded in final images That is why I prefer the simplest solution giving me the flexibility to produce final image(s) on demand using only third party packages (from Debian repositories) and produced on place once thanks to Armbian. If I heed of package to compile in future Armbian will make it possible as external one.
     
    Of course, if the proposed change is not acceptable a fork is possible as exception but the feature offered is quite general and will make Armbian better as flexibility.
     
    Should I issue it as a feature request?
  25. Like
    chradev got a reaction from Igor in Armbian customization   
    Hi guys,
     
    You are right about endlessly customization but my needs for now are much close to current Armbian staff as is.
    Fortunately or not, it is better to use Armbian code base as is following its mainline process with desired customization.
    For me the project fork, copying files via network, script etc. are not options.
     
    So let's me explain my fast and dirty solution that help me to continue.
     
    In userpatches/customize-image.sh I added some staff like (more will be added):
        jessie)     # Change network configuration to hostapd     sed -i 's/DAEMON_CONF=/DAEMON_CONF=\/etc\/hostapd.conf/g' /etc/init.d/hostapd     sed -i 's/ssid=SSID/ssid=egpr2/g' /etc/hostapd.conf     ln -sf /etc/network/interfaces.hostapd /etc/network/interfaces     # Remove annoying user creation at login     rm -f /root/.not_logged_in_yet     echo -e "password\npassword" | (passwd root)     ;; I added in lib/debootstrap.sh a single line:
    source $SRC/userpatches/customize-distro.sh after:
    display_alert "Possible after install." "customize-image.sh" "info" Next I created new userpatches/customize-distro.sh and put in it some staff like (more will be added):
    # Add udev based auto mounting staff cp $SRC/userpatches/misc/storage-automount.sh $DEST/cache/sdcard/lib/udev/ cp $SRC/userpatches/misc/storage-autounmount.sh $DEST/cache/sdcard/lib/udev/ cp $SRC/userpatches/misc/85-storage-automount.rules $DEST/cache/sdcard/etc/udev/rules.d/ Files to copy I put in userpatches/misc. Maybe later on I will reach some more limitations but it is enough for now.
     
    For preserving single hook usage the staff:
    cp $SRC/userpatches/customize-image.sh $DEST/cache/sdcard/tmp/customize-image.sh chmod +x $DEST/cache/sdcard/tmp/customize-image.sh chroot $DEST/cache/sdcard /bin/bash -c "/tmp/customize-image.sh $RELEASE $FAMILY $BOARD $BUILD_DESKTOP" chroot $DEST/cache/sdcard /bin/bash -c "sync" can be moved from lib/debootstrap.sh to new userpatches/customize-distro.sh.
     
    About customizing of packet set PACKAGE_LIST_* can be overwritten in lib.config adding / removing needed / unnecessary staff.
     
    In my opinion this use case will fit my customization needs tightly following mainline Armbian development process.
     
    On the other hand I am definitely agree with "trimming down firstrun script" and leaving this actions to the user decision.
     
    And finally, is it possible to rely on a small change (at least 1 additional line) described above about customization?
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines