rodolfo

http://forum.armbian.com/index.php/topic/1675-reboot-problem/#entry12979

According to this post in broken english by famous user @sinovoip Banana Pi M2+ chose a partially incompatible pin mapping for the 40 pin GPIO header. They seem to use
Pin# | GPIO | Function | Pin# | GPIO | Function --- | --- | --- | --- | --- | --- 01 | --- | SYS_3.3V | 02 | --- | VCC_5V 03 | A-12 | TWI0_SDA | 04 | --- | VCC_5V 05 | A-11 | TWI0_SCK | 06 | --- | GND 07 | A-06 | PWM1 | 08 | A-13 | UART3_TX/SPI1_CS 09 | --- | GND | 10 | A-14 | UART3_RX/SPI1_CLK 11 | A-01 | UART2_RX | 12 | A-16 | UART3_CTS/SPI1_MISO 13 | A-00 | UART2_TX | 14 | ---- | GND 15 | A-03 | UART2_CTS | 16 | A-15 | UART3_RTS/SPI1_MOSI 17 | ---- | SYS_3.3V | 18 | C-04 | --- 19 | C-00 | SPI0_MOSI | 20 | ---- | GND 21 | C-01 | SIP0_MISO | 22 | A-02 | UART2_RTS 23 | C-02 | SPI0_CLK | 24 | C-03 | SPI0_CS 25 | ---- | GND | 26 | C-07 | --- 27 | A-19 | TWI1_SDA | 28 | A-18 | TWI1_SCK 29 | A-07 | --- | 30 | ---- | GND 31 | A-08 | --- | 32 | L-02 | --- 33 | A-09 | --- | 34 | ---- | GND 35 | A-10 | --- | 36 | L-04 | --- 37 | A-16 | --- | 38 | A-21 | --- 39 | ---- | GND | 40 | A-20 | --- And that's what all Orange Pi use:
 
 

 
 
That means GPIO definitions in fex file (provided by famous 'Team BPi') are wrong and at least it would explain why I failed a few weeks ago reading out 1-Wire slaves since GPIO pin 37 is connected to PA16 instead of PA20.
 
Their fex file still does not reflect these 'findings' (a hardware manufacturer being surprised that his own pin mappings are different than intended? Or just the usual 'we don't give a shit about documentation or correct hardware description'?) and some other changes let me believe that the best idea is to drop Armbian support for this board (eg. audio defined as active but there is no audio out, now the redefined audio_pa_ctrl to share the same pin as the recovery key and so on -- you can't trust their way to describe the hardware)

Adding to this: If I would want to use a cheap H3 board with 2.4GHz WiFi (which I clearly don't since 2.4GHz is too overcrowded in this area) I would choose an appropriate H3 device board with onboard 2.4Ghz WiFi -- for example OPi Lite. And if I would need both Ethernet and WiFi maybe OPi PC Plus instead. And if I already have a couple of OPi One lying around and want to equip them with WiFi I would follow the known to work tutorial from Rodolfo and ensure I buy exactly those cheap Realtek thingies since they are confirmed to work even without driver compilation. It's simply a matter of choice:
OPi One + cheap RTL8188CUS dongle = $17 ($5 for SD card calculated) OPi Lite with onboard RTL8189FTV = $17 ($5 for SD card calculated) OPi PC Plus with onboard RTL8189FTV = $20 (no need for SD card due to onboard eMMC) All these combinations are known to work (client and AP mode, with RTL8189FTV also monitor mode possible if module is loaded appropriately), tutorials are available and the only caveat I know of seems to be the crappy wicd GUI that needs some weird settings for WPA to work?
 
BTW: @Igor have you checked whether package 'wpagui' could be a replacement for wicd or network-manager?

1. Armbian is non experts friendly. You can compile drivers out of the box if drivers are made properly and supported with (old) kernel. H3 is just about to get a modern kernel, where things will be better in this area.
2. This does not mean it's our fault. Perhaps driver is made dirty or it's simply not compatible. We can't do anything - supporting 3rd party hardware is out of our reach. We try to make onboard wireless cards to work, the rest is too huge.
 
And to add one more thing if you referring Raspberry PI. There are lot's of USB adaptors on the market, which does not and won't work within Linux even manufacturer declared "Linux support". You should be happy if there is a list of "supported / recommended" and buy one of those. Even in that case, complications are possible, since if it's working on one kernel, it's not necessarily supported in another. If you buy blindly and try to make it work, you usually need to be an expert.

Ok, It worked... after many hours... the true is I dont know what is the difference now, but it works. And serial communication is up and running between the PI One and PC. Thanks /R

Idle consumption is just perfect for the null use case RasPI Zero/ A+ are great as low power IoT gateways for sub-Arduino ATTINYs operating on watchdog. Higher up in the food chain OPIs deliver all the Linux fun at reasonable consumption. "Power on demand" for OPIs, idling at very low power and bursting to full blast when actually needed, is a very interesting strategy when running the boards from batteries. Thank you for the hints .

@rodolfo
 
le travail laborieux

Open source was a marketing gag by IBM trying to usurp the professional work of the free software world. The Armbian team does a stellar professional job to convert some random heaps of assorted hardware into useful working systems. There is a lot of dedication, pride and hard work to put some basic sanity into this tinker world.
 
True FREEDOM in software is complete CONTROL.   Don't blame professionals for doing their job. Feel free to run your car off the cliff.

Why don't you look at original Loboris settings then? Nobody here is comfortable to give you instructions how to shorten your board life. After all, a lot of time was spent to convince everyone that 1.6 GHz @ 1.5V hurts the chip.

-

Try http://docs.armbian.com/User-Guide_Getting-Started/

/etc/network/interfaces 
auto eth0
allow-hotplug eth0   
 
auto wlan0
allow-hotplug wlan0
 
You might get some ideas from http://forum.armbian.com/index.php/topic/1237-tutorial-opi-one-wireless-success/
Check your configuration and retry. Good luck.

It seems the QA person who tested your board before shipping has very BIG fingers to get this kind of issue (fitting a SD card to see if it boots is part of QA testing) Orange boards are usually of a decent quality and design.
 
Either you can ask for a board exchange or you can live with this bothering but quite "minor" contact issue
 
The nice thing, the Board boots, lucky. I guess you appreciate your board even more now

So you made one DIY cable that does not work when using it with 7 different OPi One? The problem with most USB cables is that they're already insufficient (small cable diameters --> resistance too high --> voltage drops when consumption increases). I don't know about your soldering skills but mine are terrible and I created underpowering situations this way several times already.
 
All Oranges can be powered absolutely reliable through barrel plug or GPIO header, simply ensure that cable/PSU are good enough so input voltage doesn't drop below 4.8V (is you want to use HDMI and USB -- otherwise even 4.5V are still fine). I did some experiments with OPi PC that are valid for the One too: http://forum.armbian.com/index.php/topic/504-quick-review-of-orange-pi-pc/
 
At least the symptoms you describe sound like the usual 'undervoltage' problem related to USB cables.

i made my own cable from an old usb cable and a power connector of the correct size.
 
i can confirm that:
a. with a good quality 2a psu i get no power or stability issues
b. with a crappy 2a psu - its unpredictable
c. With a good quality 1a psu its works fine.

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 !

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/

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.

What do you need to solve here? The "universal" part? If you prepare u-boot images and .bin files (H3) and .dtb file (A10/A20) for all available boards and give user a selection menu, this part is solved. The only requirements are
a ) Linux host (another SBC will work)
b ) network connection (wired Ethetnet or g_ether will work, wireless is significantly harder AFAIK due to shared libraries dependencies for wpasupplicant).

@tk
 
to please your eyes, bold & righteous TK
 
added feature requests.
https://github.com/raspberrypi/piclone/issues

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 !

@tkaiser
 
g_serial tested working on OPI ONE.

The following is a short overview what you can expect from small and big H3 devices when used as a NAS. I chose the least capable device (OPi Lite for $12: not even Ethernet and just 512MB DRAM) and the best possible (OPi Plus 2E for $35: GBit Ethernet, 3 USB host ports exposed that do not have to share bandwidth, 2GB DRAM).
    I wanted to test also a H3 device in between with 1GB DRAM but since results are somewhat predictable I dropped the whole idea (the performance bottleneck on all Fast Ethernet equipped devices will be network unless you add the $7.50 for an USB-Ethernet dongle -- see below -- and all other Gbit Ethernet capable H3 devices are not priced competitive)   Low end   3 weeks ago I ordered 2 cheap USB3-Ethernet dongles (Realtek RTL8153 based and recommended by @Rodolfo): http://www.ebay.com/itm/141821170951   They arrived in the meantime so I thought: Let's make OPi Lite an Ethernet device. With our current legacy kernel config and network settings you simply connect the adapter and an Ethernet cable, boot and have eth0 up and running (well, this should apply to most available USB-Ethernet adapters since we enabled every device available in kernel config). The dongle according to lsusb: Bus 001 Device 002: ID 0bda:8153 Realtek Semiconductor Corp.   Since I want Lite's both USB host ports for disks, I used the OTG port and a Micro USB to USB adapter: a simple iperf test against a GbE device showed 270/300 Mbits/sec (depending on direction).   Power requirements when adding Ethernet using this dongle: Plugging in the dongle without network cable attached: +700mW Connecting network cable to USB dongle (GbE!): another +400mW GbE transmission in one direction (limited to ~300 Mbits/sec): another +800mW So you can calculate with ~2W additional peak consumption per Ethernet adapter (at least 1.1W more if connected to a GbE network -- this is slightly more than the average 0.9W on Gbit Ethernet equipped SBC when the usual RTL8211E PHY establishes a GBit connection)   I connected then a 3.5" Seagate Barracuda with external PSU (ext4 since with a 3.4 kernel we can not use more interesting filesystems like btrfs -- iozone shows ~35MB/s in both directions), compiled Netatalk 3.1.18 and tested NAS performance from my MacBook (no further tuning except 'echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor' -- without this write performance totally sucks):     Read performance is quite ok given that iperf shows just 270-300 Mbits/sec but write performance needs some tuning (not today). By looking at 'iostat 5' output it was obvious that write buffers were flushed only every few seconds so for normal NAS useage with small files the whole problem doesn't exist and it also should be possible to increase performance (not today). Anyway: search the net for correctly measured performance numbers of other SBC used as NAS and you will be already satisfied given that we're talking here about a $12+$7.50 combination   High end   Orange Pi Plus 2E is -- in my very personal opinion -- the best H3 device available if you think about NAS useage. It is equipped with the maximum amount of DRAM H3 can deal with, has Gbit Ethernet, exposes all 3 USB host ports + 1 OTG and comes with 16GB of pretty fast eMMC. At a competitive price (please keep in mind that you can install the OS on eMMC so you don't have to add the price of an SD card here).   You can attach up to 4 USB disks (with mainline kernel and UASP capable enclosures they will show sequential speeds close to 40 MB/s, with legacy kernel it's ~5MB/s less)     What you see here is the result of Gbit Ethernet paired with way more RAM and a test data size too small (only 300 MB fit perfectly into memory) so this is the increase in speed you will benefit from in normal NAS situations (dealing with files that do not exceed a few hundred MB in size). In case you try to write/read files larger 1 GB (or use software that often uses sync calls to ensure data is properly written to disk) be prepared that USB 2.0 becomes the bottleneck. In these situations sequential transfer speeds between NAS and clients will drop down to ~32MB/s without further tuning (applies to legacy kernel, for mainline see new post coming in the next days)   Anyway: Please keep in mind that these are 'single disk' measurements. You can attach up to 4 disks to an OPi Plus 2E (using individual spindown policies to save energy or RAID modes to improve performance and/or availability), with Armbian defaults at least two of them can be accessed concurrently at full speed (USB2 maxing out at ~35MB/s and GbE being able to exceed 70MB/s easily) and with some tuning that might apply even to 3 disks accessed at the same time.   And if I compare these benchmark results based on defaults (burning Armbian to SD card, firing up the NAS software, measuring performance, done) with what had to be done prior to being able to simply use Armbian as 'NAS distro of choice', eg. these one year old results with A20 then choosing OPi Plus 2E is a no-brainer.   Regarding OPi Lite (or One or the smaller NanoPi M1) as NAS: This was more proof of concept than a recommendation. Being able to use as much RAM as possible for buffers is something especially a NAS / fileserver benefits from. So choosing a device with only 512MB is not the best idea. 'Native' Gbit Ethernet as present on a few H3 devices also clearly outperforms USB based solutions (iperf throughput with a recent Armbian without any tuning: 680/930 Mbits/sec). And if you add costs for USB-Gbit-Ethernet adapter and SD card the smaller boards aren't priced that competitive any longer.

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.

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.