wildcat_paris

Care to elaborate since you seem to be the only one running into these issues?
 
Without hardware modifications you can not power any Orange Pi through Micro USB so how do use PSUs made for Raspberries with Oranges?

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.

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 !

There needs to be an udev rule overriding this behavior. I'll add this to board support package later.
 
 
% dpkg -S $(which free) procps: /usr/bin/free

Meanwhile using OS X:
  By adding g_ether to /etc/modules and the following to /etc/network/interfaces any Armbian H3 device connected through USB this way can be accessed easily: allow-hotplug usb0 iface usb0 inet static address 169.254.1.1 netmask 255.255.0.0 pre-up /bin/sh -c 'echo 2 > /sys/bus/platform/devices/sunxi_usb_udc/otg_role' By using a 'link local' address (169.254.0.0/16) no further network setup is needed. OS X will choose a random IP address from within this range and network connectivity will be established without any hassles:     Doing currently a Time Machine backup to an OPi Lite that received the first TM backup through an RTL8153 GbE dongle, now connected locally using the g_ether network approach and will later test backup performance using OPi Lite's Wi-Fi as access point:  

@LarsN
 
zador.blood.stained just added quota for sunxi-next
 
but you will need to compile your kernel with http://www.armbian.com/using-armbian-tools/

@Tido, it is not a question, it is an answer for those who don't have Guvcview working with CMOS camera.
Guvcview works with USB camera only, unless you modify the source or get deb packages when ready.

linux-sun7i-default.config: CONFIG_QUOTA=y
linux-sunxi-next.config: # CONFIG_QUOTA is not set

Another update. Since I already created an 'el cheapo' RAID-0 made of two 2.5" 'USB disks' and therefore eliminated the 'single disk USB2.0 speed limitation' I tested again through the network (again: zero tuning, these are just 'Armbian defaults'):
 
Accessing this RAID-0 through OPi Plus 2E's GBit Ethernet we get 48/63 MB/s (write/read) -- this time I chose 3GB test size so buffers aren't involved that much in this mode: 
 

 
Accessing it through the RTL8153 dongle we get 25/30 MB/s. I tested the same installation then also on Orange Pi PC Plus (1 GByte) and Lite (512 GByte) by swapping the SD card and only relinking script.bin and adjusting /etc/defaults/cpufreq-utils with exactly the same results. In this mode amount of DRAM is not relevant since due to the large test file buffers are immediately flushed to disk and we have the Ethernet dongle as bottleneck (so results with a single disk instead of a RAID-0 will look identical. But in normal NAS use cases the more DRAM will result in better overall performance)
 
 
 
 
Funny: The first time I tried to test the Realtek Ethernet dongle connected to OPi Plus 2E I did what most people (me included) do most of the time when benchmarking: I did it wrong
 
I brought the RTL8153 up as eth1 using an address from within the same net range as eth0 (onboard GbE) and so the kernel decided to do some fancy routing and while trying to use eth1 the packets used eth0 instead. The following sequential transfer speeds are simply impossible with an USB2 device
 
 
 
 
(the RTL8153 results above showing 25/30 MB/s have been done with eth1 being in another net range than onboard eth0 on OPi Plus 2E and PC Plus)

Me not any more
 
The problem with A20 is that sequential SATA performance is still unbalanced (45/200 MB/s write/read under best conditions -- read as overclocked CPU and DRAM), that the same applies to Gbit Ethernet performance (here the read performance sucks so unfortunately in this direction network is the bottleneck) so that we end up here with the following situation if we're talking about NAS:
Client --> NAS: slow SATA write performance is the bottleneck NAS --> Client: slow GbE read performance is the bottleneck With H3 single disk access over USB 2.0 is the bottleneck (accessing data on disk that is not already cached will be limited to ~32 MB/s NAS throughput with legacy kernel, write performance to the NAS depends mostly on available DRAM and buffer settings/useage of the filesharing daemon in question). By switching to mainline kernel soon we're able to get close to 38/39 MB/s when UASP capable disk enclosures are used. And if disk performance really is an issue RAID-0 could be an option. I just created one on 3.4.112 without any tuning using 2 cheap crappy external 2.5" disks that also use crappy USB-to-SATA brudges, just by executing mdadm / mkfs.ext4 without using my brain:
iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 random random kB reclen write rewrite read reread read write 102400 4 6529 7440 6561 6320 934 2006 102400 16 15845 16920 16380 16963 2995 8821 102400 512 29908 30385 30048 30786 23447 30493 102400 1024 55131 56964 53047 57078 36459 54178 102400 16384 62542 62603 62128 63343 62864 61185 Now we're able to write/read to/from our H3 NAS already with ~60MB/s. And when using UASP capable disk enclosures and mainline kernel RAID-0 performance will increase even more (+75 MB/s since single disk access gets close to 39MB/s).
 
With mainline kernel we can also use btrfs and transparent filesystem compression so files that are able to be compressed 1:2 will then be read/written with 78MB/s instead of 39MB/s. Also with mainline kernel we can combine 3 USB disks in a way that sequential performance is twice the USB2 bandwidth while getting a fully redundant setup by combining RAID-0 with RAID-1 (mdraid + btrfs' own RAID implementation). This works even with disks of different size since when partitioning intelligently (using stripes of a specific size and combining striping/mirroring) you get a fully redundant disk setup showing doubled performance and 50 percent of the added capacity of all individual disks -- But that's stuff for another article I prepare for being released after the first H3 vanilla Armbian OS images
 
I always talked about sequential transfer speeds above (since that's the most important parameter for normal NAS useage). Let's have a look at random IO: here the current situation clearly sucks with H3 compared to A20. Since with legacy kernel we can only use USB2.0 BOT mode (slower sequential transfer speeds and especially way slower when it's about random IO compared to UAS) while A20 here shows native SATA 2.0 capabilities (native command queueing and stuff like that). Therefore accessing many small files in random fashion on a SSD A20 might be ten times faster than H3 (or even more depending on the USB-to-SATA bridge used between H3 and the disk in an USB disk enclosure).
 
Again: this might change with mainline kernel and an UASP capable disk enclosure since then also random IO over USB gets way faster. So always check which SATA bridge chip is used inside an enclosure. And BTW: That's the really great thing when we're talking about H3 for NAS useage: Since switching to mainline kernel (when UASP capable disk enclosures are in use!) increases disk access performance automagically for free (and when you use Armbian it's just a simple switch to exchange legacy kernel with vanilla).
 
Further readings:
http://linux-sunxi.org/Sunxi_devices_as_NAS http://linux-sunxi.org/USB/UAS http://linux-sunxi.org/SATA https://olimex.wordpress.com/2015/07/09/allwinner-did-it-again-new-quad-core-powerful-chip-pin-to-pin-compatible-with-a10-and-a20/#comments

Eth0 always works for me.
You have to give more details about your problem in order for some one to be able to help you.

Almost forgot: The test of the cheap RTL8153 USB Ethernet dongle was also intended to give our H3 users the idea what to expect from spending additional $7.50 regarding network throughput if your H3 device is only 10/100 Mbits/sec capable (with Fast Ethernet you're limited to ~8 MB/s NAS throughput anyway).
 
The most important detail to consider is whether you're dealing with USB ports that have to share bandwidth or not. H3 features 3 USB2.0 host ports and 1 OTG port (that can be switched to host mode and shows just a little performance drop) but unfortunately some devices use an internal USB hub.
 
The performance numbers for OPi Lite above are only valid for other H3 devices where USB ports do not have to share bandwidth. So in case you own a Beelink X2 for example (2 USB host ports available) you're able to increase NAS performance by adding a GbE USB dongle and connecting an USB disk to the other port. If you own an Orange Pi 2 (or '2 mini') that's not true since the 4 USB ports available there have to share bandwidth since they are behind an internal USB hub.
 
The count of USB ports doesn't matter at all. The question is just whether an internal USB hub (shared bandwidth) is used or not.
 
Back to NAS useage again: That means horrible hardware designs like every Raspberry Pi (only one USB 2.0 port available between SoC and the outside) or moronic stuff like Banana Pi M3 (A83T SoC features two host ports but the 'engineers' chose to use just one of them connecting to an internal USB hub so all external USB ports and the ultra-slow GL830 USB-to-SATA bridge have to share bandwidth) will show worse NAS performance compared to an Orange Pi Lite with external Gbit Ethernet adapter

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.

My project is also a git "around" Armbian. - I found it a little uncomfortable to store this kind of data there as I would either copy it into my git repo or need some .gitignore(s). I fiddled with it but it was no fun as I'm experimenting a lot and so it got messed up quite often. I wanted to keep it clean so I prefer to only put somewhat "static" scripts and .deb files there.

It's a SinoVoip product. I bought many M1 (good product), tried to buy M1+ (not possible back then, European distributor as weird as vendor), bought M2 (crap) just to donate it to linux-sunxi community so that at least mainline kernel support is ok now, bought Lamobo R1 (crap) and wasted many hours/days to get this up and running since SinoVoip refused to hand out hardware information, then decided to never buy anything else than M1 from them ever again.
 
Please report your issues here: http://forum.banana-pi.org/c/Banana-pi-BPI-M2and maybe open up an own thread here in the H3 section to discuss SinoVoip hardware issues.

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.

no hard feeling tkaiser
Development boards comes across lot of misconception , errors, bugs, this is the way to mature the OS , after thorough test i realized my sd adapter failed . but it takes some time and realization as well as feedback from some enthusiast.
 I thank you for your response.

@Melanrz @wildcat_paris, Thx for the reply.
 
Think I'll buy another screen.

Than our patches doesn't work since we don't start with clean code. 
 
So we added debug mode, which stops the compilation and waits that user made some changes and produce a patch afterwards. This is o.k. for tiny and known changes, but when there is a lot to do?

Actually, mi boot.ini looks like:
 
 
and /media/boot
 
 

@jobenvil
 
I haven't looked at "lib" code, only build an image for XU4
 
u-boot is 2012.07
the tsz/bl1/bl2 should be burned
 
maybe an update of boot.ini is need
 
the current Armbian boot.ini (kernel 3.x)
 
maybe an update has to be done to reference
dtb/exynos5422-odroidxu4.dtb and not dtb/exynos5422-odroidxu3.dtb
and making sure zImage is used
 
 
 
 

Looks like Markdown to me - same that we use now and that can be used on GitHub based wikis.

I like it the way C.H.I.P does it http://docs.getchip.com/chip.html
I cannot remember which markup language they are using ... something with M ?
 
Ah, and it should be possible to export article or pages to PDF.
 
Licence like: Creative Commons

OK.
 
It's also a good time to create a new tag before this / any major rework. Current system is building fine / without major flaws.

I don't want to be funny in such situations. It's a simple matter of fact that software has to rely on hardware working reliably. Hardware will die sooner or later (it's not the question whether it will die, the only question is when and in which form: dying slowly which is bad since it's not easy reproducable or dying fast which is great since you know the reason immediately).
 
These 3 @wanriz threads are the perfect examples for doing it wrong: Using crappy / unreliable hardware, blaming the software instead and wasting your own and others time instead of starting fault localisation.
 
We already waste an insane amount of time to test each and every OS image release and while we're still far away from doing it perfect and still too much mistakes happen... i should stop here and take a break. C'mon: If Armbian would've problems writing/reading to USB disks the forums would be full of!