stamasd Posted March 28, 2016 Posted March 28, 2016 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.
Igor Posted March 28, 2016 Posted March 28, 2016 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.
Igor Posted March 28, 2016 Posted March 28, 2016 I made a test build and everything works fine. Debian Jessie / CLI ... BTW: Wheezy does not work and Trusty is untested.
Igor Posted March 28, 2016 Posted March 28, 2016 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
konradsa Posted March 28, 2016 Posted March 28, 2016 Quick question: The C2 (and also C1) image available for download, is that a 64 bit or 32 bit image?Thanks
stamasd Posted March 28, 2016 Posted March 28, 2016 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.
stamasd Posted March 29, 2016 Posted March 29, 2016 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)
stamasd Posted March 29, 2016 Posted March 29, 2016 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
Igor Posted March 29, 2016 Posted March 29, 2016 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.
minusdelta Posted March 29, 2016 Posted March 29, 2016 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
Igor Posted March 29, 2016 Posted March 29, 2016 ... unfortunately not. Serial log is here: https://gist.github.com/minusdelta/7c34e4af5d0d96168028 Thank you.
spacewalker Posted March 29, 2016 Author Posted March 29, 2016 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
Benjamim Gois Posted April 3, 2016 Posted April 3, 2016 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" ?
Igor Posted April 4, 2016 Posted April 4, 2016 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. 1
zador.blood.stained Posted April 4, 2016 Posted April 4, 2016 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. 2
Benjamim Gois Posted April 4, 2016 Posted April 4, 2016 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%
minusdelta Posted April 26, 2016 Posted April 26, 2016 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 ;-)
Igor Posted April 26, 2016 Posted April 26, 2016 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.
minusdelta Posted April 27, 2016 Posted April 27, 2016 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.
Igor Posted April 27, 2016 Posted April 27, 2016 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?
minusdelta Posted April 27, 2016 Posted April 27, 2016 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.
tkaiser Posted April 27, 2016 Posted April 27, 2016 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
Igor Posted April 27, 2016 Posted April 27, 2016 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.
leonidy-85 Posted April 28, 2016 Posted April 28, 2016 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
zador.blood.stained Posted April 28, 2016 Posted April 28, 2016 @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. 1
leonidy-85 Posted April 28, 2016 Posted April 28, 2016 @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
minusdelta Posted April 30, 2016 Posted April 30, 2016 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.
Igor Posted April 30, 2016 Posted April 30, 2016 Nice to hear this. If you succeed bringing aufs to the kernel, please do share. It might be useful to others too.
minusdelta Posted May 2, 2016 Posted May 2, 2016 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.
Recommended Posts