Jump to content

rodolfo

Members
  • Posts

    204
  • Joined

  • Last visited

Posts posted by rodolfo

  1. @reamond

     

    Seems like the serial gadget is created ( /dev/ttyGS0 ) on OPI and does show up on the MAC side ( tty.usbmodemxxxx ). Without any further configuration OPI serial defaults to 115200 baud. For testing purposes work as root user ( sudo ) and retry the simple procedure outlined above . It is tested and works on the OPI side - you might have to google the OS-X part. Good luck.

  2. Update on Tested Working OPI Remote Desktops :

     

    Fast reliable ssh-protected remote desktops ( LXDE-based for best performance )

    • OPI x2goserver - x2goclient - LINUX
    • OPI x2goserver - x2goclient - WinXP, Win7 , Win10
    • OPI x2goserver - x2goclient - OSX (+Xquartz)

    Traditional workaround Windows-style ( safer and faster if tunneled via x2goserver-proxy )

    • OPI xrdp - rdesktop - LINUX
    • OPI xrdp - rdp - WXP / W7 / W10
    • OPI xrdp - MS rdp - OSX
    • OPI xrdp - aFreeRDP - Android 4.1 / 5.1

    OPI as Remote Desktop Client ( Universal Thin Client )

    • LINUX x2goserver - x2goclient - OPI
    • WXP,W7,W10 terminal server - rdesktop - OPI
    • OSX remote - rdesktop - OPI
    • Virtualbox remote - rdesktop - OPI

    VNC has not been separately tested, use cases are all covered by x2go or rdp

     

    Conclusion :

     

    OPI ONE/LITE both show excellent performance when used as terminal servers or remote desktop clients. X2go as a ssh-based terminal service uses the processing power of H3 to dwarf any Windows based RDP setup. X2go on OPI as a proxy for Windows rdp even enables secure and reasonably faster terminal services for Windows.

     

    Even the bitty-gritty embedded masters of bitbanging might profit from a multi-desktop grand view of their tiny victims shown on BIG screens and thus enjoy the best of both worlds. Armbian has proven to be a reliable useful platform to turn OPI bricks into useful gadgets.

     

    Enjoy !

  3. It's not a "live system" exactly, it is "root on NFS" started from FEL: https://github.com/igorpecovnik/lib/blob/master/documentation/fel-boot.md

     

    Setting up RAM only system is not wise because FEL transfer speed is too slow (less than 1 MB/s) to load anything close to full OS. If you don't want to use NFS at all, you can try to pack busybox and rsync into initrd and don't use rootfs at all.

     

    Thanks for the info. Trying to set that stuff up ended in dependency hell ( Stable Debian e basta ! ). Digging a bit deeper into the sunxi u-boot stuff I just realized how simple a real solution could be.

     

    Working backup/restore/imaging solutions are simple, self-contained and independent

     

    OPI ONE/LITE ( probably also other H3 boards ) can start from SDcard, USB storage, network and default to FEL-mode when started without SDcard. Network nfs, tftp-boot and FEL-mode have ugly external dependencies

    on other systems clearly violating that principle. That leaves us basically with SDcard and USB storage. SDcard is eliminated by the fact that our "rescue" attempt should probably restore that SDcard. So we are at USB storage.

     

    Here's the trick :

     

    - Create a bootable USB-Drive/Partition from your working installation ( you can hotclone the sdcard to USB and adjust /boot/boot.cmd and /etc/fstab  or use the armbian utility nand-sata-install.sh )

    - Properly label the USB-Rescue-Partition ( e.g set a mark /boot/xxrescuexxx for low-level u-boot to recognize it )

    - Use a costumized boot.cmd that checks for the xxrescuexxx flag and boots from usb if found. Install it on SDcard and USB-storage

    - et voilà : a completely independent rescue system running on the board accessing FROZEN ASSETS WITH 100% DATA CONSISTENCY.

     

    I've tested the workability of this approach on OPI ONE. All USB ports ( in the case of OPI ONE 1 normal and 1 OTG ) can be fully used in host mode. All one needs for a fully working rescue mode is one ( additional or single ) partition on USB storage.

     

    Now that an independent rescue system is solved on the basis of stock Armbian and requiring nothing but stock Armbian people can use their favourite brand of Linux, Windows, OS-X to flash their first Armbian SDcard and from then on simply carry on with Armbian.

     

    Next step will be prototyping a simple versioned backup/restore/imaging setup for OPI ONE/LITE.

  4.  

    Orange Pi One serial console works normally.

     

     

    Yes, it definitely does. In the cases it did not, wrong connections or missing configuration in boot.cmd were found. 

  5. Quick workaround to enable serial console on OPI :

     

    cd /boot

    sudo nano boot.cmd

     

    -----------------------------------enable serial console

    setenv bootargs "console=tty1 console=ttyS0,115200 root=/dev/mmcblk0p1 ......................

    -----------------------------------

     

    sudo mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr

     

    reboot

     

    enjoy !

     

     

     

  6. speed is 115200?

    I use same connection with Raspberry and it works fine so I do not suspect its wrong connection

     

    Speed is 15200.

     

    The Raspis have the serial console on the rows of GPIO pins. Orange PI ONE has a separate UART-connector (three pins, no power connection) see link @tkaiser.

    I used the serial console regularly from Linux host with

    screen /dev/ttyUSB0 115200

    I just rechecked with Armbian_5.14 and it looks like there is no login console anymore. Boot messages appear and then the console switches to HDMI.

    Leave the host side connected and reboot the OPI. You should see start messages in your terminal window. This would confirm you have a correct

    hardware setup. For the needed changes in configuration see @tkaiser's posts above.

  7. And it's absolutely necessary to get the idea that what you're trying to do can NOT work reliably in every situation

     

    There is no way to do a safe "hotclone" no matter what precautions ( double, triple, quadruple rsyncs etc.. ) you do and any efforts in that direction are a simple waste of time. I've seen enough sad hopeless hapless restore attempts by "backup-experts" on systems costing magnitudes more than thousands of ARM boards. It probably takes a bit of restore practice instead of all the academic backup concepts for the learned to realize what actually works ;)

     

    Working backup/restore/image solutions always depend on a complete freeze of the ressources envolved. The rest is either quick-and-dirty or the more common slow-and-dirty. In other words - you need an independent second rescue system. There are several ways to accomplish this task :

     

    - Run everything virtualized ( silly joke - we are talking embedded )

     

    - Rip the storage medium out of the board ( Only works with SDcard or other removable storage ) and handle it on another system ( External solution with ugly dependency ). Then dd,rsync,tar,zip... yadda,yadda,yadda.

     

    - Run an  "Armbian rescue system" in ram on the board itself and fully access all storage on the board.  Then dd, rsync, tar, zip, <any-odd-way> .. yadda,yadda,yadda.

     

    The reason we are already at post #42 in solving the simple tasks of backup/restore/image is that the discussion concentrates on solving the wrong problem. Once "Universal booting to rescue system in ram with mount/unmount read/write-access to all board storage" ( FEL-boot a live-system ) is solved, the rest is a simple matter of dd, rsync, tar, zip , <any-odd-way> ... yadda,yadda,yadda.

  8. That being sad: A normal fresh Armbian installation without many apps running might be cloneable.

     

    Bingo !

     

    You are of course perfectly right about "cloning". To properly backup/restore a system image you always need another system or proper virtualization.

    People with Linux or any other X-ses background will not need explanations.

     

    We are here in the world of tinker boards and some people might enjoy a "quick and dirty" way to replicate the SDcard of a $12 board :)

  9. Hotcloning Armbian SDcard ( tested on OPI ONE/LITE  )

     

    You need a USB card reader and Linux. With a running Armbian you've got all the Linux you'll ever need. The aim is to copy the entire system on SDcard including bootstuff and our personal belongings, roots, cats, dogs etc... to a new SDcard. The new card must only hold the data content of the old card and can be of different size (smaller, larger). The new SDcard contains one big partition of maximum size and is bootable.

     

    Setup

     

    1. Download the script and rename it to armbian_hotclone.sh

     

    2. Start your OPI ONE with the SDcard you want to copy and connect to it via ssh ( or putty ).

     

    3. The script needs to be run on the board ( in my case OPI ONE ). Copy the script to your board and make it executable ( chmod +x )

     

    4. Attach a USB card reader to the OPI ONE. Make sure there is NO OTHER USB storage attached.

     

    Running the script

     

    5. Insert the target SDcard into the card reader and check it has been detected ( lsblk )

     

    6. Run the script as root ( sudo ) and depending on the card reader and SDcards wait 10-60 minutes

     

    Test the new SDcard

     

    7. Shutdown the OPI ONE.

     

    8. Replace the SDcard in the slot with the new copy

     

    9. Make sure the OPI ONE boots correctly before you put the SDcard into the cookie jar for desaster recovery and worse.

     

    Notes on usage

     

    The script is just a skeleton to showcase the basics. A break needs to be added to prevent it from running accidentally and eating up disks.

     

    Warning : Do NOT run the script on your host

     

    armbian_hotclone.sh.txt

     

    Enjoy !

  10. OPI ONE as serial gadget

     

     

    Code snippets to enable/disable usb serial gadget on OPI ONE with Armbian_5.14

     

     

    g_serial_start() {

    echo -n 0 > /sys/bus/platform/devices/sunxi_usb_udc/otg_role
    modprobe g_serial
    echo -n 2 > /sys/bus/platform/devices/sunxi_usb_udc/otg_role
    }

    g_serial_stop() {

    echo -n 0 > /sys/bus/platform/devices/sunxi_usb_udc/otg_role
    rmmod g_serial
    echo -n 1 > /sys/bus/platform/devices/sunxi_usb_udc/otg_role
    }

     

    On the OPI ONE side the serial port is /dev/ttyGS0

     

    On the host side the serial port is /dev/ttyACM0

     

     

    Testing the serial connection ( plug in USB-cable on host , new interface /dev/ttyACM0 is created )

     

    ( OPI ONE )

     

    echo "xxxxxxxxxxxx hello from OPI xxxxxxxxxxxx" >/dev/ttyGS0

     

    ( host )

     

    cat /dev/ttyACM0

     

    ( OPI ONE )

     

    cat /dev/ttyGS0

     

    ( host )

     

    echo "xxxxxxxxxxxx hello from host xxxxxxxxxxxx' >/dev/ttyACM0

     

    ( OPI ONE )

     

    <ctrl><c> to close

     

     

    Note on usage :

     

    Only basic functions for simple serial communication tested. A quick test setting up a login console on /dev/ttyGS0 and conneting to it with screen /dev/ttyACM0

    quickly showed the limits of g_serial gadget. To use it as a USB serial console does not make sense as g_ether provides a full fledged fast ethernet connection providing reliable network commmunication.

     

    Enjoy !

  11. After a lot of tests with different HDDs, SSDs and USB Flashdrives attached to USB ( host and OTG ports ) on OPI ONE/LITE with recent Armbian versions ( jessie vanilla server 5.10 , 5.12 , 5.13, 5.14 ) I've come to the following conclusions :

     

    - Armbian USB-storage on H3 is reliable and performant ( up to 35MB write/read per port )

    - Host and OTG ports show equal performance

     

    All problems encountered while testing OPI ONE/LITE with Armbian could be traced to

     

    - insufficient power supply ( not enough juice, overly noisy, large voltage drops on power spikes )

    - crappy lossy cables

    - crappy mismatching adapters ( old USB2-SATA on newer 1T HDD degraded performance to <1MB/s )

     

    I've been randomly using sdcards of dubious quality and never ran into any sort of problems either.

  12. @tkaiser

     

    I can confirm OTG port with patch applied works equally well in host mode. Read/write performance for HDD on powered SATA adapter is around 35MB/s. When permanently adding the patch and setting OTG gadget mode as default, it might be worthwhile to add a default static IP for usb0. This would add a simple interface independent of working LAN / WAN / DHCP setup for ssh-ing into headless boards.

  13. @wanriz

     

    You probably face power problems. Use a good 5V/2A PSU for the OPI and extra power supply for the hdds. Powering USB flash drives directly from OPI ports woks well, SSDs and mainly HDDs can have power spikes leading to sudden voltage drops. Two connected HDDs most likely need additional power source.

  14. compatibility reports (does the necessary one-line patch affects reliability of the OTG port used in host mode?)

     

    Patched OPI ONE running in host mode with LAN1000 dongle on OTG-port ( eth1 ) works reliably as before with pleasing performance.

     

    LAN performance of OPI ONE

     

    1) RJ45 direct link ( eth0 )                             95 Mbits/s                        

     

    2) OTG port in device mode ( usb0 )                     124 Mbits/s

     

    2) LAN1000 dongle on OTG port in host mode ( eth1 )     277 Mbits/s

     

    Enjoy !

  15. @tkaiser

     

    Brilliant - works right out of the box without breaking anything. Performance measured between two OPI ONEs linked by USB/microUSB compared to directly linked RJ45/RJ45 is very pleasing.

     

    USB-link

    -----------

     

    iperf -c 192.168.5.167        
    [  3]  0.0-10.0 sec   148 MBytes   124 Mbits/sec

    iperf -c 192.168.5.167 --dualtest

    [  5]  0.0-10.0 sec   109 MBytes  90.9 Mbits/sec
    [  4]  0.0-10.2 sec   112 MBytes  92.2 Mbits/sec

    LAN-patch
    -------------

    iperf -c 192.168.3.167

    [  3]  0.0-10.1 sec   116 MBytes  96.1 Mbits/sec

    iperf -c 192.168.3.167 --dualtest

    [  5]  0.0-10.0 sec   110 MBytes  92.6 Mbits/sec
    [  4]  0.0-10.2 sec   108 MBytes  88.7 Mbits/sec

     

    Two use cases pop up immediately :

     

    - OPI ONE el cheapo portable router/firewall/proxy

     

    - Simple headless access with static IP independent from working DHCP/LAN/WLAN.

  16. Just successfully tested another Realtek usb wifi dongle with the OPI ONE. Both AP and managed mode work as decribed for 0bda:0179 Realtek Semiconductor Corp. in instructions.

     

    lsusb

     

    Bus 001 Device 009: ID 0bda:8179 Realtek Semiconductor Corp. ( noname identified as 8188EU )

     

    Aliexpress Link : http://www.aliexpress.com/item/1pc-Mini-USB-WiFi-Wireless-802-11-n-g-b-150M-LAN-Adapter-Network-Card/32292872916.html

  17. Wifi is fixed on all H3 boards. I will push new update later in the evening where 8189fs and 8189es are updated. I made brief testing and AP mode also works on both chips.

     

     

    USB wireless dongles for OPI ONE continue working in Armbian_5.13. The internal wifi 8189fs for OPI LITE with factory antenna works well in managed and AP mode in Armbian_5.13.

     

    Performance tests with OPI LITE internal wifi show excellent results compared to USB dongles. Wireless connection is reliable and surprisingly performant ( 40 mbps crossing 2 walls in noisy environment, compared to 20mbps from notebook and 2 mbps from OPI ONE USB dongle ).

     

     

     

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines