Jump to content

Armbian for Odroid C1 and C2


Recommended Posts

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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)
Link to comment
Share on other sites

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
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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" ?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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%  :)

 

armbiam_c2.jpg

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

@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
Link to comment
Share on other sites

 

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines