ODroid C2

Peter Scargillodroid, odroid c229 Comments on ODroid C2

Odroid C2You’ll see in an earlier post a little picture of the Odroid C2 and following on from a previous last blog, I’ve had tremendous fun playing with the Virtual Debian – i.e. DietPi – and I just happened to be looking at the Dietpi site (which is very nice incidentally) and I noted a board I recently acquired – the Odroid C2.  I’m getting quite excited about this – read on…

As you click on the various boards you see comparisons of performance of the various boards including the Raspberry Pi, Orange Pi and others – most of which I have – AND the C2 – and the latter appears to out on top by some way and in some cases by a LONG way (and as you’ll see later it is not expensive)!

  • Amlogic ARM® Cortex®-A53(ARMv8) 1.5Ghz quad core CPUs
  • Mali™-450 GPU (3 Pixel-processors + 2 Vertex shader processors)
  • 2Gbyte DDR3 SDRAM
  • Gigabit Ethernet
  • HDMI 2.0 4K/60Hz display
  • H.265 4K/60FPS and H.264 4K/30FPS capable VPU
  • 40pin GPIOs + 7pin I2S
  • eMMC5.0 HS400 Flash Storage slot / UHS-1 SDR50 MicroSD Card slot
  • USB 2.0 Host x 4, USB OTG x 1 (power + data capable)
  • Infrared(IR) Receiver
  • Ubuntu 16.04 or Android 5.1 Lollipop based on Kernel 3.14LTS (and of course as you’ll see – DIETPI – Debian !!)

Well, I had to give that a shot! They mention it is very fast and part of that will be down to eMMC and fast Ethernet – not to mention the 2GB of RAM – well, I don’t have the eMMC module – but I DO have a new, fast Samsung Ovo+ SD. So – I grabbed the DietPi  image.

I ran my new PI script to get the Pi user in there and then the main script – I linked to it in the last post. I can only say the script ran FAST – way faster than a Pi and instead of up to an hour, sometimes more, it was all done in just under 20minutes. Not as fast as the VirtualBox version but faster than my other SBCs.

But I noted – the GPIO routines (WiringOP) didn’t load and I noticed there was no GIT installed – I would not have noticed that in the VirtualBox versions as I didn’t install GPIO.

After the Odroid rebooted – I checked to see if everything worked… and most of it did – VERY quickly.

However – once again – no Webmin, though I’d not noticed any issued – did not load!

I decided to tackle the GPIO first – and installed GIT and tried again.

MAKE not found….

Turns out there was a broken repository – the forum for DietPi had a solution which any time soon should end up on their website.

Then I could not get the time synced  – you could not make this off – the main pool servers were out of action…

All of that will be history by the time you read this I would think. I have another way to grab Webmin and that worked – I’ve altered my script accordingly.

So the upshot of this is that everything appears to work with the Odroid C2 and it is FAST even without eMMC. Now, some of the prices I’ve seen on Ebay are a bit OTT but the price seems reasonable if you go directly to HardKernel at $40 plus postage wherever you are.

In the process of doing the install I noted that there is a specific install of WiringPi for the Odroid C2

git clone https://github.com/hardkernel/wiringPi.git
cd wiringPi
./build
sudo chmod a+s /usr/local/bin/gpio

I’ve included that as an option in my script (I really do need a menu system) and if installed, it is indeed possible for the following to work… taking GPIO 1 as an example

gpio mode  1 out

gpio write 1 1

gpio write 1 0

There are two PWM pins (33 and 19) on the C2 according to this documentation however in the “gpio readall” I’m not actually seeing those numbers appear so at this point – without getting into specific addresses etc. and sticking with the simple GPIO utility you can call from, say, Node-Red, I’m not sure how to access them.  Attempts to do any PWM just return “Unsupport function on on ODROD-C2 model”. Looks as if there are a couple of analog inputs as well, yet to be tested. By the look of it, hardware SPI is not supported.

This could still end up as my main Node-Red controller!

GPIO pinout for Odroid C2

Update August 2017

I put the Odroid to one side – so many other boards to test – and today I decided to take another look. I installed the latest Ubuntu and “the script” – and all of that went well, but no I2C support. That’s really not good as Raspberry Pi and others have I2c out of the box. However,  I followed the instructions on the Odroid site to run apt-get dist-upgrade, that went smoothly then I followed the instructions here. Of course their modprobe instruction failed as they forgot to put SUDO in front of it. That worked…

I did however note that the installed GPIO utility failed to pick up on these additions – so gpio i2cd failed.   However, sudo i2cdetect -y -r 1  worked and spotted my SD1306 board.

OLEDI followed the instructions from the blog where I set up a while ago for another board…  and despite some groans, all of that worked… with my SSD1306 board in place, sudo python sys_info.py worked a treat, displaying info on the SSD1306.

I did notice something odd however.. despite the spec for the Odroid C2 suggesting 2GB – my display showed 1GB – turns out the Python code was rounding this to the nearest GB – a quick rewrite suggested 1,300MB out of 1,800MB available. That’s more like it.

29 thoughts on “ODroid C2”

  1. Which would you recommend for a low-power desktop computer running Ubuntu or Debian, the Odroid C2 or Nano Pi K2? I like the fact that the K2 has built-in wifi, fits any RPi case, and comes with everything I’d need (power cable, heat sink, and case) for substantially less cost than a C2.

    But software support is limited (though it does appear others have gotten Armbian to work on it without much difficulty), and while it has an eMMC socket, I don’t know of any compatible module for it.

    1. The K2 has performed flawlessly as a media centre for months now – however if you look at my update review, I was not so impressed with it’s use outside of that scenario. They provide WiringPi but it does not work and when I contacted FriendlyArm I didn’t get any sense of hope that it ever would. So – it really depends on what you want to do – if you want to use some IO I’d go for the Odroid C2. They have a case, incidentally.

  3. Sorry, a lot of comment after my previous comment – I talked about image for geekbox.
    Btw. another suggestion for your script:

    This line should be also for new version of Debian.

    sudo apt-get $AQUIET -y install apache2 libapache2-mod-php7.0 sqlite3 php-sqlite3 php-xml php-mbstring

    1. it should be the case, as the code is the following, so it is “if the OS found is NOT ubuntu, AND it’s some *BIAN version 9.*” then the script should take the php7 line…
      can you post the output of these lines?

      . /etc/os-release
      OPSYS=${ID^^}
      DISTRO=$(/usr/bin/lsb_release -rs)
      CHECK64=$(uname -m)
      echo -e OPSYS: $OPSYS
      echo -e DISTRO: $DISTRO
      echo -e CHECK64: $CHECK64

          if [[ $OPSYS != *"UBUNTU"* ]]; then
		if [[ $OPSYS == *"BIAN"* ]] && [[ $DISTRO == *"9."* ]]; then
			sudo apt-get $AQUIET -y install apache2 libapache2-mod-php7.0 sqlite3 php-sqlite3 php-xml php-mbstring 2>&1 | tee -a $LOGFILE
		else
			sudo apt-get $AQUIET -y install apache2 libapache2-mod-php5 sqlite3 php5-sqlite 2>&1 | tee -a $LOGFILE
		fi
        [ $? -eq 0 ] && apache=1 # apache installed
    else
        sudo apt-get $AQUIET -y install apache2 libapache2-mod-php7.0 sqlite3 php-sqlite3 php-xml php-mbstring 2>&1 | tee -a $LOGFILE
        [ $? -eq 0 ] && apache=1 # apache installed
    fi

      1. Here you are:

        pi@boxio:~$ . /etc/os-release
        pi@boxio:~$ OPSYS=${ID^^}
        pi@boxio:~$ DISTRO=$(/usr/bin/lsb_release -rs)
        pi@boxio:~$ CHECK64=$(uname -m)
        pi@boxio:~$ echo -e OPSYS: $OPSYS
        OPSYS: DEBIAN
        pi@boxio:~$ echo -e DISTRO: $DISTRO
        DISTRO: 9.1
        pi@boxio:~$ echo -e CHECK64: $CHECK64
        CHECK64: aarch64

  4. I prepared image for Debian 9 and it is working fine, I also install all software via your scripts but part of installation fails because of missing libssl1.0.0 and libwebsockets3_1.2.2 for this version. After installing this debs manually everything seems to work fine.

  5. If I can suggest something, I found quite nice solution for IoT server – geekbox.

    https://www.geekbuying.com/item/GeekBox-Open-Source-Cross–TV-BOX—GeekBox-Landingship-PCBA-369345.html

    It is quite old board but probably because it wasn’t so popular they decrease the price to 62$. Realy good price for 8 cores + 3GB RAM and 16GB eMMC, wifi, BT etc. Works really nice. I installed Debian image, add user pi and run your script to install utils without any problems. The weakest part is SATA over USB… but I don’t need it – build in flash is enough.

    1. Hi Marcin

      Well, that looks interesting though they’re claiming 2GB not 3GB which makes it slightly less enticing. Which Debian did you manage to install? Stretch would be nice?

      1. For now it is Jessie, but I need to find a easy way to prepare firmwares from packages for R-Pi. Should be possible because kernel is on different partition and rootfs on different. Will let you know.

        And sorry -Yes it is 2Gb RAM.

      2. i would look at newer RK3328 boards, like the Rock64… are way faster, are customizable as ram and emmc on board, and linux support is already quite good…
        https://www.cnx-software.com/2017/06/08/rock64-is-a-rockchip-rk3328-development-board-with-up-to-4gb-ram-4k-hdr-gigabit-ethernet-and-usb-3-0/
        https://www.pine64.org/?product_cat=rock64
        https://www.pine64.org/?product_cat=rock64&paged=2

        Peter, i suggest a new blog article: “Availability, failover and disaster recovery of IoT management devices”

        to talk about how to have always a iot system always on, manage failover in case it dies, and how to recover in case of dead systems… to begin to talk about little clustered systems or at least system synched often and that the 2nd one could take the place of the first, if dead…

        1. The only question mark I MIGHT have over the Rock64, it’s predecessor – the Pine64 – is possibly useful as a doorstop.

          Funny you mention disaster recovery – I was up at the crack of dawn this morning recovering sufficient resources to implement a crude heating control system back in the UK because the Raspberry Pi 2 machine over there controlling the heating has given up and died on my – almost definitely due to SD issues. The simplest things – I left a spare SD over there but because case manufacturers insist on that little slot hole for the SD, the chances of the person maintaining the place in our absence being able to take the old card out and replace it are almost zero. Also there is a mains extension with several power supplies plugged in and because it was all fresh in my mind at the time, months ago I didn’t clearly label each output as to what they were for.

          Sometimes the simplest things get missed in planning.

          In my case I have a secondary Pi over there doing nothing but collecting 433Mhz info from a weather station and passing it to the main Pi. I’ve re-tasked that, changing my mac-to-ip mapping to make this the main controller – and right now – the heating is back up and running bar one sensor which refuses to talk – I THINK because I made the mistake of plugging the kitchen temperature sensor into the wall with a sign that says DO NOT TURN OFF – well, my thoughts are that the socket may just have been re-assigned by a guest or the cleaner for something else as my ESP8266 boards otherwise almost never fail.

          The C2 remains a nice machine.

          1. Rock64 is ALL a different device than its predecessor… Read on cnx site, and comments… Mine is here waiting for me to have better connectivity to install it…

            I mentioned disaster recovery just for that, after reading your Skype this morning ☺️

            Add a little tape to msd to make them easier to pull out

            1. It’s getting the new one in that’s the problem – one slip and they end up lying around inside the case or worse, on the floor under the heating system 🙂

  6. One note about the “40 pin RPi compatible header”. On the S905 CPU, SPI is not exposed on the GPIO header, but as a consolation prize, you get 2 ADC inputs. This is the same situation with the NanoPi-K2 because it uses the same CPU.

    1. I’ve put the K2 to one side until FriendlyArm get the WiringNP working on it. Why ANYONE would bring out a board in this day and age without proper GPIO support is beyond me.

        1. Hi

          Pretty much all boards can handle GPIO that way – but I2c is another matter. I could not find any way to expose the I2c. FriendlyArm have a WiringNP which allows for the simple GPIO control and hence I2c but it does not work on that board. Also like some others, I’d rather use Python than compiling code – way faster for experimenting.

  7. I left a comment here and it’s gone missing. There’s something Bermuda triangle-like going on with comments around here. Let’s see if this one survives.

Comments are closed.