Hardkernel Odroid-C2

The Odroid-C2 low-cost development platform, see the specifications on the hardkernel website.

The Odroid-C2 has multiple components. The development board itself contains a system-on-chip (SOC), the Amlogic S905, 2GiB RAM, and other devices including ethernet, SD card reader, eMMC module socket, infrared (IR) sensor, USB ports and LEDs.

The SOC itself, the Amlogic S905, contains an quad-core ARMv8, Cortex-A53 CPU and other devices including timers, watchdog timers, GPU, DMA controllers etc.

Finally, the CPU, a Corex-A53, has four cores, caches, and other architectural features including the coprocessor and arm generic timers.

Manuals

The boot process

The ODROID-c2 kits are brand new, and need configuring. By default, when plugged in the board will boot into Linux, which is loaded onto an eMMC Flash storage card by U-Boot, a popular, open-source first-stage boot loader. U-Boot's primary role is to enable peripherals and secondary storage in order to load and boot a complete operating system from a variety storage media.

Once U-Boot has loaded, it will wait a few seconds before executing the default boot command. This is your chance to stop the boot process and enter the U-Boot prompt. Once at the U-Boot prompt, type help to view a list of commands or print to display a list of environment variables.

Key environment variables:

If in doubt, you can restore the default environment by typing run clearenv.

Key U-Boot commands:

Once you have finished, you can resume the auto boot process by running run bootcmd

Kit contents

The kit given out for COMP9242 contains the following items:

Setting up your host

The CSE lab machines already have the required software installed. See milestone 0 for details.

Your host machine will require certain software and drivers to talk to the Odroid-C2. This is mostly machine specific:

Setting up an Odroid-C2

Use the USB-microusb to connect to the UART adapter (the wires poking out the hole int the case), which allows output over serial device.

You will also need a network connection between the host computer and the Odroid-C2 for downloading OS images, communicating with NFS file systems and to provide a console over LAN. If you are in a CSE lab or do not have a spare Ethernet port, you will need to use the provided USB/Ethernet dongle. Connect the Ethernet cable cable from the Odroid-C2 to the USB/Ethernet dongle and then connect the dongle to your computer.

Once the Odroid-C2 is connected to your development machine you should launch the two consoles that connect you to its output. Run picocom -b 115200 /dev/ttyUSB0 in one console window and nc -up 26719 192.168.168.2 26719 in the other.

You may be required to change the arguments for picocom. On Linux, use dmesg to work out which port the USB to serial converter has been attached to (its usually /dev/ttyUSB0). Then pass that to picocom.

Plug in the power cable for the Odroid-C2 to reboot. When picocom is connected to the serial port, you should see some output from U-Boot.

How to use - what is really happening

A brief description of the development cycle can be found in Milestone 0. A lot is happening under the covers to allow you to easily develop an operating system:

  1. Plug in the Odroid-C2 and power it on.

    On CSE machines this generates a hotplug event on the host's USB bus and results in the creation of the tty device. A cse script runs at this time and customises the tftpd and nfs server to your login sessions user name.

  2. In a terminal, launch picocom

    when picocom launches it opens the tty device.

  3. In another terminal, launch netcat, nc -up 26719 192.168.168.2 26719.

    Not magical, nothing will happen though until you send something with libserial.

  4. Make your changes, (hint: learn cscope).
  5. Build and run using build$ ninja && ../reset.sh.

    A lot is happening here under the covers, ninja will first build your OS, generating a binary boot image. Once the build is complete, make copies the images/sos-image-arm-odroidc2 file to your tftpboot directory. Then, a reset signal is sent over serial, which causes the kernel to reboot the device. When the device reboots, tftp will fetch the newly built image over tftp and execute the image.