Igor

Let me try...
 
I extracted it from file linux-u-boot-bananapi_5.00_armhf.deb and used command below to write it to microsd.
 
dd if=u-boot-sunxi-with-spl.bin of=/dev/sdx bs=1024 seek=8
 
It was not necessary to touch anything else ... and u-boot sucessfully started kernel.
It was u-boot problem and it is sorted out now.
 
Thank you Igor

Kernel boots:
uname -a Linux odroid64 3.14.29-odroidc2 #4 SMP PREEMPT Thu Mar 24 09:10:24 CET 2016 aarch64 aarch64 aarch64 GNU/Linux

Kernel boots:
uname -a Linux odroid64 3.14.29-odroidc2 #4 SMP PREEMPT Thu Mar 24 09:10:24 CET 2016 aarch64 aarch64 aarch64 GNU/Linux

Just made a first boot (stock Ubuntu) with C2 from eMMC ... fast!
 
Now, when possible, building and booting Armbian

http://odroid.com/dokuwiki/doku.php?id=en:c1_hardware
 
this says the C1/C2 are 3V3 logic on the Serial, so no problems in blowing it with a standard PL2303 cable. You are correct tho that other ODROID are 1V8 tho.

using armbian , sound comes from TV without doing anything .
armbian is best choice of orange pi PC .
 
video shot : 

Cool Igor
 
Today i received my Odroid C2, it would be great to see armbian support really soon,
so let me know how i can help. i really enjoyed your work on my BPi ^^

Hi,
Got it to work now,
Accidently ran the hostapd command instead of the hostapd-rt.
After a restart it would not work with tidos exact Daemon config - replaced the daemon_sbin also with hostapd-rt and it worked after another restart
Is it possible that there is a mistake with your tutorial at that part?
Anyway thanks a lot to both of you

If anybody is following this thread awaiting a solution for booting a eMMC board; I'm still empty handed.
Truth is since this isn't my daytime job I have very limited time to try things out, even less these past few weeks.
 
I did get last night off and tried some stuff but regardless my attempts I was empty handed.
I'm now trying to compile the u-boot image myself rather than patching existing ones, but the u-boot fork 
doesn't seem to have support for booting over UART.
 
I did find something slightly amusing though, there seems to be two u-boot forks implementing the a38x support.
There's the MarvellEmbeddedProcessors which SolidRun has forked of, then there's the mainline support now based
on code from Stefan Roese (https://www.mail-archive.com/u-boot@lists.denx.de/msg189083.html).
 
The Turris Omnia project has a u-boot fork of the mainline version, which also has fixes for the UART kwb image generation.
Since the Turris Omnia will be shipping in just a month I assume their fork is somewhat stable so I will harvest whatever
of the UART patches I can and see if any of it fixes my problems.
 
Funny thing is though that SolidRun tech. support guys boot through UART, but they never replied on my last email so
I'm clueless on how they do it.
 
Edit: Finally got the damn thing booting from UART, it all boiled down to the timing of the first xmodem package basically.
What I did was I put the kwboot command line in a while loop and reset the device every time I got the "Bad message".
After about ten attempts it finally booted! 

http://www.armbian.com/clearfog/
 
3.10.96 and 4.4.1
 
Jessie and Trusty

Some more measurement:
 
M2 SSD TRANSCEND MTS400 128GB   Write: 1073741824 bytes (1.1 GB) copied, 6.65401 s, 161 MB/s Read: 1073741824 bytes (1.1 GB) copied, 2.07552 s, 517 MB/s   Mechanical 2.5" drive Western Digital 500Gb / 5400rpm   Write: 1073741824 bytes (1.1 GB) copied, 9.56753 s, 112 MB/s Read: 1073741824 bytes (1.1 GB) copied, 10.4673 s, 103 MB/s   SD card Sandisk Extreme PRO 8Gb   Write: 1073741824 bytes (1.1 GB) copied, 68.9829 s, 15.6 MB/s Read 1073741824 bytes (1.1 GB) copied, 68.4105 s, 15.7 MB/s

Hi,
 
the upgrade to Armbian worked for me from Bananian 15.04 Wheezy with Openmediavault 2 on Banana Pro without problems. The sources from Bananian were deleted automatically.
 
I've just followed Igor instructions.
 
Now I've Linux bananapi 3.4.110 sun7i.
 
I needed Sunxi sndi2s driver for my Beaunanas (a Banana Nas server boxed in a French Burgondy Beaune wine bottle box in wood    ) to make working my DAC with MPD, missed driver on Bananian 15.04.
 
Thanks for Armbian !

Igor , this command worked!

I was trying to compile dahdi Asterisk and this error occurred in the process .

But the important thing is that it worked!


Thank you so much! For your attention and help!

Indeed there are some troubles with the SD media. I replaced it, installed ARMBIAN new (with Win32 Disk Imager) and now all runs well. Thanx.

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?

You are probably referring to this:
 
 
http://lists.denx.de/pipermail/u-boot/2014-September/190239.html
 
This is done in uboot so you need to experiment with this parameter:
CONFIG_GMAC_TX_DELAY= (try with numbers from 1-10)
 
File is here:
 
u-boot-sources/configs/A20-OLinuXino-Lime2_defconfig
 
I don't know for any better way than this:
 
1. compile - DD to SD card - reboot
2. test
3. change parameter and try again

Thank you very much for the answer and for armbian in general :-)

Strange indeed. I've just successfully tested OrangePiOne with Armbian_5.05 on any old crappy sdcards ( "class" 4,6,10 4G ). Cards were prepared on a linux host ( dd ), installed on OrangePiOne  and heavily used ( actually misused ) with random reboots, shutdowns, disconnecting power. Despite some (probably erroneous) error messages (mmc) the boards booted without any problems and even heavy abuse did not corrupt the sdcards.
 
I've noticed some other phenomena which are HW-related. Crappy power cables or crappy power supplies lead to erratic boot behaviour. Attach the serial console and run the board power cable through a voltmeter/ammeter. During a normal boot you'll notice current going up from <100mA to >200mA. I've traced all boot failures to problems with power supply. Practical jokes like powering an USB-attached disk from the USB connection yield rather strange results too
 
By the way - use a cheap working any-old-class 4G sdcard for testing until you are satisfied with a working basic image. Create a backup image and use this as a basis for copying to a "high class zillion-G"  sdcard. Expanding is so much more fun than shrinking.

I'm sorry guys, I had one wrong value in FEX in lcd0_para section, lcd_if = 8 (should read 0). I don't know what I was thinking about. Now everything works OK, including touch interface with ft5x_ts. Thank you for your support.

Absolutely!  As it turns out my issue (I'll argue the driver still has a *bug* but will 100% concede it has nothing to do with Arabian or your excellent built) was that my access point was allowing for the legacy 802.11b data rates.  Once I limited it to only 802.11g data rates, then the radio in the Banana Pro works great.  the issue is really deep in the driver and not limited to the brcmfmac driver as it would fail with the ap6210 driver on older kernels as well.  I tried several of the LeMaker posted or linked distros and they all had the same issue.  An AP supporting the old 802.11b data rates will cause it to fail.  If for kicks anyone wants to see if they can reproduce the issue, go into their access point an enable 1, 2, 5.5 & 11 megabit data rates.  I'd bet that on attempt to associate the driver fails.

Ah, yes of course. Like I said, it had to be something 'obvious'
 
Removed the nodm package and things are working a treat now.
 
Thanks!

@Igor, zador ...
 
sorry for my late response.
 
I finally got the logging and mixed kernel issue solved. Nevertheless I struggled to boot from nand - and surrendered at last after trying different approaches. Meanwhile I decided to skip the upgrade process and start with a new Ubuntu installation. This will suit my application much better anyway.
 
Thanks again.
 
Rgrds,
 
Mark

Changing U-Boot to v2015.10 as recommended by Igor above solved the problem in Armbian 5.05 build.
 
I deleted only U-Boot as Debian package (probably not needed) in cache so only kernel and U-Boot staff become rebuild.
 
Thanks a lot Igor for the great project and the prompt help.

@igor
Thanks for the info and keep up the good work. I'll try to contribute in areas I'm knowledgeable about, mainly testing, documenting and high level use cases.

Yes, all three bananas share one image. This is a first build - problems, beside those documented, could exists.
 
v5.04 / 1.3.2016
Banana M1/PRO/M1+ rebuilded fixed SATA problem set OTG port in HOST mode in vanilla kernel wireless is working on PRO out of the box added utility to switch between OTG and HOST in vanilla kernel Bugs left: OTG mode not working, M1+ wireless not work in vanilla kernel