Intel Clear Linux on Udoo X86 How-To

The Intel Clear Linux Project is a Linux distribution built for cloud and IoT use cases.

The aim is to showcase the best of Intel architecture technology and performance, from low-level kernel features to complex applications that span across the entire OS stack. The focus is on Power and Performance optimizations throughout the operating system as a whole.

The distribution is quite recent and Intel is also focusing on docker containers.

The Clear Linux Distro is slickkkkk AF. Simple and minimal just the way I ❤️ it. Nice work Intel!https://t.co/JQ7SxkgjlK

— jessie frazelle (@jessfraz) October 26, 2017

Phoronix website already highlighted the improvements it can carry over other common distributions (see also here).

How do we start? The Intel website offers a light tutorial you can find at this page.

The first step is to verify the Udoo X86 is equipped as a compatible processor.
You can validate it with the script clear-linux-check-config.sh.

You'll get this output:

luca@udoox86 ~ $ ./clear-linux-check-config.sh host
Checking if host is capable of running Clear Linux* OS for Intel® Architecture

SUCCESS: Intel CPU
SUCCESS: 64-bit CPU (lm)
SUCCESS: Streaming SIMD Extensions v4.1 (sse4_1)
SUCCESS: EFI firmware

Follow the tutorial to prepare the USB drive. Nothing uncommon compared to other distros.

But...
You'll get a surprise when rebooting and selecting the USB drive as primary boot. You will be able to proceed and get to the partitioning setup page... A wild Python backtrace will appear!
An error saying the command "fdisk -l on /dev/mmcblk0rpmb" returned an error.

The device is a Replay Protected Memory Block. I am not an expert and I could be totally wrong, but it should be a way to provide a separate trusted store, which usually an OEM could store IP to protect. The access is enforced by a secure API. This document about TEE OS should clarify some detail.

We're lucky the installer is written in Python.
Reboot and plug the USB drive on your favorite device running Linux.

Identify the following file /usr/bin/ister_gui.py and open it for editing.
We need to modify the function get_list_of_disks().
The function consists in running a lsblk and extracting all the devices which are not the current root device, generating a list.

In order to exclude the unwanted devices, add the following line:

    for part in parts:
        part = part.strip()
        if 'boot' in part or 'rpm' in part:
            continue
        if 'disk' in part:
            disks.append(part.split()[0])
        elif part.endswith('/'):
            root_disk = part.split()[0]

There are more elegant ways to do so, but it just works™.

Once done, you can unmount the USB drive and reboot. If everything is fine, you'll be able to get past the partition setup page and you'll be able to properly finalize the installation.
It's a network installation, so be patient (even on a Gigabit fiber connection, if you're writing to the emmc).

In case you do not want to install on the emmc, it should be possible to even disable the device through the UEFI and this "fix" should not be necessary. I'll update once I can confim that.

After rebooting and selecting the internal emmc as boot device, you should be able to boot for the first time on the Clear Linux distro!

You'll notice an error at kernel boot, still related to the RPMB device. It should be something like:

systemd-gpt-auto-generator[1765]: Failed to dissect: Input/output error

As the distribution is quite recent, it includes the workaround detailed at this issue on systemd. A fix has been integrated in master, but probably not yet released. The workaround is to pass the following kernel boot parameter:

systemd.gpt_auto=0

Clear Linux uses clr-boot-manager. It is a Kernel & Boot loader manager.
It has been also integrated in Solus OS.
It's actually thanks to the Solus OS webpage that I understood how to add the flag no matter the kernel in use.

Become root and create a new file /etc/kernel/cmdline and add the previous systemd boot parameter. Save the file, clr-boot-manager update and reboot. The message at boot should disappear!

Remember, if you choose to install Linux on the emmc, disable the swap as the device will probably suffer from intense usage.

Feel free to comment and suggest corrections!

Have a nice day!

Udoo X86 Power On / Off via BLE on Arduino 101

I finally received my UDOO X86, I backed on Kickstarter on April 2016!

To give a little of context, it is a board designed by UDOO sporting an Intel x86 CPU (64bit, different depending if you have a BASIC, ADVANCED or ULTRA), 2/4/8GB or RAM (soldered) and a LOT of peripherals and I/O.
To mention some of them:

• M.2 Key E port
• Gigabit Ethernet
• 3x USB 3 Ports
• 1 HDMI and 2x DisplayPort
• GPIO
• 2x COM ports
• RTC
• I2C

In addition, they managed to put on the same board a Genuino/Arduino 101 board (Intel Curie), with BLE and 6 axis accelerometer & gyroscope.
Everything on a board more or less twice the size of the RaspberryPi.

More details can be checked on the official documentation page on the UDOO site.

I am writing this tutorial from the board itself and I can tell it can be used as desktop/HTPC without any major issues.

One cool feature of the Arduino 101 is it is able to Power On/Off the main CPU via Interrupt!

I am going to tell you how to be able to remotely power on and off the main CPU via BLE.

I am using LUbuntu 16.04 as OS, but those instructions should work pretty well on any operating system, even MS Windows.

Grant Power management to Intel Curie

Verify the BIOS/EFI settings are as shown in this page.

Prepare the Arduino environment

Install the Arduino IDE from the official site and install the Intel Curie Arduino 101 Libraries & Tools. You could do the same with PlatformIO, but I am not quite sure about the Intel Curie support.

Check you select the correct board type, programmer and serial port in the Tools menu.


Remember to give your user the rights to write to the serial port executing:

sudo usermod -a -G dialout

You have to logout to make those changes taken into account.

In addition to that, it could be necessary to execute the following script:

wget -O - https://raw.githubusercontent.com/01org/corelibs-arduino101/master/scripts/create_dfu_udev_rule | sudo bash

This is required to make the Arduino capable of resetting the board to put it in programming mode.

Check everything works fine uploading a simple example sketch (pick the Basic/Blink one).

The blinking led is the one close to the HDMI port

Upload the sketch to receive commands from BLE

Let's start with a skeleton sketch Intel prepared for us.

Choose the example from CurieBLE/Peripheral/CallbackLED.

Upload it to the board.

Follow the instructions shown on this page to configure the Android application.

All you need to do is to pair to the Arduino101 BLE device, which will be shown as LEDCB.
Once you're connected, you'll be able to write 0 or 1 to a variable exposed by the service implemented in the sketch.
The variable will power on and off the LED depending on the value of the variable.

Adapt the sketch to send a Power signal to the main board

We need to add a simple function to send a LOW digital signal for 20ms on the PIN number 9, followed by a HIGH digital level.
This generated wave will be caught by an intermediary SMT32, which will send the power interrupt to the Intel Atom/Celeron/Pentium.



The whole board will react on the interrupt, including the Arduino 101, which will be restarted, losing any unsaved state.
It means everything which follows the execution of the function sendPowerSignal is actually useless, as the Arduino 101 will reboot.

Issues (2 May 2017)

I am unable to fully verify it is working since on shutdown the board actually gets powered on.
Possible root cause:

• BLE is interacting with the PIN number 9
• When the Arduino 101 is reset, the PIN 9 goes again low triggering a power on

Those facts seem not impacting just my board, as I found a forum post you can check here where another user faced the same problem.

I can also confirm that if I suspend the system, the Arduino 101 is no more visible on Bluetooth, so it means it gets powered off.

UPDATE (3 May 2017)!

I've been in touch with UDOO team and they provided a revision of the BIOS for testing purposes only.

The problem is partially fixed and I'll keep you posted to let you know when we will have this example fully working.

UPDATE (18 July 2017)!

I've received a BIOS 1.03 RC version to test if the mentioned issues are fixed.

And we have good news! Everything works as expected!

I let UDOO send the changelog of the latest BIOS as soon as it is officially out, but I can confirm you'll be able to use the Arduino 101 to properly power up and shutdown the main board.

The power management via Intel Curie can be now left enabled and flashing the Arduino 101 or rebooting will no more generate issues (reboots).

The problem has been solved making the power signal trigger sequence more complex (5 HIGH to LOW transitions within 100 ms, instead of a single transition).

If you're using a desktop linux distribution (e.g. Ubuntu), please check the power management rules and set "When power button is pressed" to "Shutdown" or "Suspend", depending on what you prefer).

Otherwise, you will get a dialog, as in the following video...