Well I managed to build the image after the change. I did notice some errors during the build (unfortunately I can't copy/paste as I did the building in a real console not a xterm)

1. unsupported ioctl, cmd=0x5331 after update-initramfs

2 missing cp destination file operand after installing RT8192 external driver

 

I wrote the image to a card, plugged it in and connected the odroid to my router via cable, the blue LED blinks meaning it's alive, but it makes no DHCP request to the router. I don't have a display available right now to plug it into, I'll try that tomorrow.

Well, it should work but since sources are changing on daily basis, problems might arise. You got blue blinking led - that's a good sign. Attach a monitor and Ethernet cable and see what's going on. I'll make one build test just to make sure it's working.

 

1. unsupported ioctl, cmd=0x5331 after update-initramfs

2 missing cp destination file operand after installing RT8192 external driver

 

It's safe to ignore those errors, btw. they are in a process of fixing.

I made a test build and everything works fine. Debian Jessie / CLI ... BTW: Wheezy does not work and Trusty is untested.

New test image for C1 - I hope this one boots fine.

 

http://mirror.igorpecovnik.com/test/Armbian_5.06_Odroidc1_Debian_jessie_3.10.101.7z

Quick question: The C2 (and also C1) image available for download, is that a 64 bit or 32 bit image?

Thanks

64bit. Having a pure 32bit image is only feasible for a headless server-type install, since some drivers (notably the mali-fbdev) are 64bit only AFAIK.

BTW my problem yesterday with not being able to connect to the C2 with my self-built image - it was a power supply problem. With a good PS it boots just fine.

 

However apt-get update fails with

W: Failed to fetch http://apt.armbian.com/dists/jessie/InRelease  Unable to find expected entry 'main/binary-arm64/Packages' in Release file (Wrong sources.list entry or malformed file)

Also, after compiling the kernel again, when I try to install the packages it gives me

 

sudo dpkg -i linux-dtb-odroidc2_5.06_arm64.deb
(Reading database ... 48160 files and directories currently installed.)
Preparing to unpack linux-dtb-odroidc2_5.06_arm64.deb ...
Unpacking linux-dtb-odroidc2 (5.06) over (5.06) ...
dpkg: error processing archive linux-dtb-odroidc2_5.06_arm64.deb (--install):
 unable to make backup link of `./boot/dtb/meson64_odroidc2.dtb' before installing new version: Operation not permitted
Errors were encountered while processing:
 linux-dtb-odroidc2_5.06_arm64.deb

apt-get update fail is not critical and it will stop failing (actually it's only a warning) once arm64 package list will exists. Currently there are no arm64 packages in the repository apt.armbian.com

 

The other problem is generic (known) issue and affect all images with fat boot partition. Current workaround is to remove the DTB package, linux-dtb-odroidc2 in this case, before installing new. It's annoying, I know ... will be fixed.

New test image for C1 - I hope this one boots fine.

 

http://mirror.igorpecovnik.com/test/Armbian_5.06_Odroidc1_Debian_jessie_3.10.101.7z

... unfortunately not. Serial log is here: https://gist.github.com/minusdelta/7c34e4af5d0d96168028

... unfortunately not. Serial log is here: https://gist.github.com/minusdelta/7c34e4af5d0d96168028

 

Thank you. 

for the c1 - it requires uImage to boot... it doesn't like wrappers I guess

 

you can compile it from the kernel source directory"make uImage". I had to enable cec as it seems the odroidc_defconfig is broken by default without it

 

edit boot.ini from z to u 

 

this got my c1 booting

I was using odrobian on my C2 for 2 weeks, today i discovered the armbian and give it a try. I ram really impressed so far. I only have one question, when a i connect a ethernet usb adaptor the system recognizes it as interface "usbnet0". In raspian on raspberry pi2 the system recognizes it as eth1, is it a kernel thing ? If we got a 4.x kernel will the interface "usbnet0" change to "eth1" ?

I was using odrobian on my C2 for 2 weeks, today i discovered the armbian and give it a try. I ram really impressed so far. I only have one question, when a i connect a ethernet usb adaptor the system recognizes it as interface "usbnet0". In raspian on raspberry pi2 the system recognizes it as eth1, is it a kernel thing ? If we got a 4.x kernel will the interface "usbnet0" change to "eth1" ?

 

This should be the same as on Odrobian since we don't use much different kernel config and all those patches on the top of stock kernel also should not affect this. I need to take a close look to provide valuable answer.

I was using odrobian on my C2 for 2 weeks, today i discovered the armbian and give it a try. I ram really impressed so far. I only have one question, when a i connect a ethernet usb adaptor the system recognizes it as interface "usbnet0". In raspian on raspberry pi2 the system recognizes it as eth1, is it a kernel thing ? If we got a 4.x kernel will the interface "usbnet0" change to "eth1" ?

This is probably related to udev and depends on base distribution used (jessie, wheezy or trusty) and not on kernel version. Please read this for explanation or just google "udev rename network interface".

 

Edit: It may depend on kernel version, but in any case you should be able to rename your interface by creating an udev rule.

This is probably related to udev and depends on base distribution used (jessie, wheezy or trusty) and not on kernel version. Please read this for explanation or just google "udev rename network interface".

 

Edit: It may depend on kernel version, but in any case you should be able to rename your interface by creating an udev rule.

 

Thanks for the udev tip, i´ll take a look... But i really wish it the system just recognizes it as a common ethernet interface. I´m bulding a C2 applicance and didn´t want people to see the usb-ethernet adapter on interfaces list. But it´s a minor problem, i am comparing armbian with odrobian and noted significant drop in CPU temperature and consumption. On Odroibian i was running a quagga OSPF system with a routing table of 200 routes, the system temperature use to be around 49ºC - 52ºC and the cpu usage was around 22,5%. Now on Armbian the temperature is around 39ºC-40ºC and cpu usage around 2,5% 

 

First of all many thanks for supporting the Odroid C1!

 

After I noticed the "Final C1 fixes" commit I flashed the C1 image (labeled "Docker ready") and ran the "check-config.sh" from docker.

Surprisingly it mentioned some missing items and I found that /proc/config.gz of this image differs from linux-odroidc1-default.config.

 

Booting a self compiled image failed, serial log is here as always ;-)

Thank you for feedback. I'll take a look - perhaps I forgot something, but the image boots and docker should work. Of course not all things are here, since it's an old kernel, but all required flags are green.

Thank you for looking into it.

A propos "old kernel" - will there be a NEXT for C1 ?

There are two reasons why I am asking:

One is AUFS: with help of your wonderful toolchain I could compile a NEXT for my Banana M1 including AUFS (aufs4), aufs3 is unsupported since Jan 2015 and doesnt compile at 3.10.101.

Second, some (IPVlan) of the new docker libnetwork features want 4.2 at least. 

We can add NEXT / Vanilla / modern kernel if one exists. I saw some tips around for building but I never try to build / boot it. If it is possible, at least for server scenarios, we should add it.

 

Anyone using 4.x+ on C1?

Beside armbian I know 4 images for C1 (Hardkernel official, community eg. Odrobian, hypriot's image-builder-odroid-c1), all 3.10.x.

4.x is mentioned here.

4.x is mentioned here.

 

Unfortunately it's still more or less a one man show (Carlo Caione): http://www.linux-meson.com/doku.php#kernel_mainlining_progress

Booting a self compiled image failed, serial log is here as always ;-)

 

Github conf is little updated compared to image but that's not a problem since update for all kernels is here within a week. We are doing last fixes ...

 

I compiled image from scratch and it booted without a problem. I guess you had some issues with building process. Try to clean things and start over.

 

Regarding 4.x ... doesn't look good.

I can't build kernel for odroidc1 

[ error ] ERROR in function source [ main.sh:210 ]

[ error ] Could not find required u-boot toolchain [ < 5.0 ]

For orangepi h3 build without problems

@leonidy-85

 

What is your build host OS release?

 

In case it is 15.10 Wily (x64) or 16.04 Xenial (x64), you need to install linaro 4.9 toolchain to compile u-boot for C1.

Next to "lib", "userpatches", "output" and "sources" there should be "toolchains" directory.

cd toolchains
wget "https://releases.linaro.org/components/toolchain/binaries/4.9-2016.02/arm-linux-gnueabihf/gcc-linaro-4.9-2016.02-x86_64_arm-linux-gnueabihf.tar.xz"
tar xf gcc-linaro-4.9-2016.02-x86_64_arm-linux-gnueabihf.tar.xz

and repeat compilation.

@leonidy-85

 

What is your build host OS release?

 

In case it is 15.10 Wily (x64) or 16.04 Xenial (x64), you need to install linaro 4.9 toolchain to compile u-boot for C1.

Next to "lib", "userpatches", "output" and "sources" there should be "toolchains" directory.

cd toolchains
wget "https://releases.linaro.org/components/toolchain/binaries/4.9-2016.02/arm-linux-gnueabihf/gcc-linaro-4.9-2016.02-x86_64_arm-linux-gnueabihf.tar.xz"
tar xf gcc-linaro-4.9-2016.02-x86_64_arm-linux-gnueabihf.tar.xz

and repeat compilation.

Thank you

 

Try to clean things and start over.

 

Regarding 4.x ... doesn't look good

 

.

 

I recompiled and all is fine now. Thanks for checking! I forgot to re-add "CLEAN_LEVEL" after the last upgrade of compile.sh.

Regarding 4.x you confirmed my fears. Now I have to find out how to compile aufs3 with armbian or to stick w/ my current OS.

Nice to hear this. If you succeed bringing aufs to the kernel, please do share. It might be useful to others too.

bringing aufs to the kernel, please do share.

You mean for aufs3 and armbian? Or aufs4 too? (I ask because this is quite simple and well documented.)

For aufs3: I will start experimenting after a failing test of device mapper storage driver only ... this route is my current favourite to go for a working docker with c1 and armbian.

aufs3, it should be easy, yes.