rodolfo

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

So far USB OTG port has been defined in host mode, the same as the regular USB port. To change this behaviour and use it in gadget (device) mode see http://forum.armbian.com/index.php/topic/1417-testers-wanted-g-ether-driver-h3-device-as-ethernet-dongle/

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 !

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.

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

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 !

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.

@zador Thanks - I'll have a look at it.

@zador Sounds great ! .Is there a working example of a live-system ( RAM only ) for H3 ( OPI ONE/LITE) I could play with ?

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.

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

Disclaimer : The script does not save the planet.

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 !

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 !

@tkaiser g_serial tested working on OPI ONE.

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.

Try 'depmod' .

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

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

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 !

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

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

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 ).

@shamanches Please read exact instructions on tested working dongles and capabilities in suggested link. Good luck.

1. Started with heavily used customized images on el-cheapo 4G no-name SDcards ( more or less worst case scenario ) 2. Udates/upgrades of OPI ONE / OPI LITE Armbian_5.10 ( earlier upgrade from 5.05 ) to latest versions took only 45 mins. 3. Minor cleanups, no hickups -> GREAT JOB !