Category Archives: embedded linux

Embedded Linux Gems

Serial Port Access for non-sudo User

Working with embedded devices often requires serial access. By default linux tty ports require super user access, so when running an application like a serial communications parser, you will want to give access to the user rather than require your application to have sudo powers.

Once you know which user(s) are to require access, add them to dialout ant tty.

sudo usermod -a -G dialout <serial-user>
sudo usermod -a -G tty <serial-user>

Dialout is a group, so the user changes will take effect after reboot.

Password Hash

Embedded devices will often need a password hash.

Use mkpasswd to generate a hash. First use the -m help option to see what hash algorithms are available.

$ mkpasswd -m help
Available methods:
sha512crypt     SHA-512
sha256crypt     SHA-256
md5crypt        MD5
descrypt        standard 56 bit DES-based crypt(3)

Then generate the hash.

$ mkpasswd -m sha512crypt
Password: 
$6$IPKp8j6a8R$2S1SZigM5x.mupPNX50y0/.mhoJ42LSEe80wszpI6L5jiq4oEUPH9A73zAyT3BqJQm1HIk1p9kI3H.eimTMxY.

Center Ubuntu/Gnome Background

If the image you set as your background does not fit into the screen layout, likely it will be stretched or cropped. To center the image, effectively shrinking it execute on command line

$ gsettings set org.gnome.desktop.background picture-options 'centered'

Explanation and details: https://askubuntu.com/questions/1111201/background-image-resize-in-ubuntu-18-04-1-lts

Serving Flask Apps with NGinx and Uwsgi

Even an embedded system is going to need a web application, be it on the embedded device, or a part of a test system.

We recommend flask applications, and serving them via Nginx and uWSGI.

There are a lot of examples online. The following one outlines most of the possibilities you can choose from: deploy-flask-uwsgi-nginx

We recommend using the apps-available and apps-enabled as the method for starting your uwsgi server flask application. This is less intrusive and requires less custom parts like an additional system specific service.

For additional security you could install your applications somewhere other than /var/www if that is being served as your root for nginx (for example use /srv/uwsgi-apps instead).

To ensure independent application environments, us a python virtual environment for each of your applications. If you do choose to use the system libraries, we touch on some issues you may run into.

For the nginx configuration, the default uwsgi socket location for your application can be used. On Ubuntu at least it has been:

uwsgi_pass unix:/run/uwsgi/app/<your-application>/socket;

Trouble Shooting

To help you trouble shoot during setup, once you have defined <yourapplication>.ini file under /etc/uwsgi/apps-available and symlinked to apps-enable, restart uwsgi and then tail the uwsgi log for your application.

sudo systemctl restart uwsgi
sudo tail -f /var/log/uwsgi/app/<yourapplication>.log

If something goes wrong inside your application on (re)starting uwsgi, that log will show it.

For example

- mapped 654912 bytes (639 KB) for 8 cores
- *** Operational MODE: preforking ***
Traceback (most recent call last):
  File "./wsgi.py", line 1, in <module>
    from app import app as application
  File "./app.py", line 1, in <module>
    from flask import Flask, jsonify, request
ModuleNotFoundError: No module named 'flask'
- unable to load app 0 (mountpoint='') (callable not found or import error)

Module Not Found Error: No module name

In the example above either the system (or your virtual environment) does not have flask installed or you are using the wrong python plugin.

If your python –version is 3.6.x the python plugin in your uwsgi .ini file should be

plugin = python36

When you run uwsgi through its apps-enabled/<yourapp>.ini method, the application will not be run as your user, so even if you have installed flask and other libraries using pip(3), they are attached to your user’s local, rather than the system library.

If you install using pip a library you will see the output.

Requirement already satisfied: flask in /home/user/.local/lib/python3.6/site-packages

Note the /home/user/.local.

If you are not using a virtual environment, you need to ensure libraries are system libraries, either install them using their corresponding distribution package (e.g. in Ubuntu, sudo apt install python3-flask, or using sudo -H pip …)

No Python Application Found

If you see the error

--- no python application found, check your startup logs for errors ---

Then look earlier in the application log (/var/log/uwsgi/app/<yourapplication>.log) to see if your application was started or if their was an exception.

Unable to load app

unable to load app 0 (mountpoint='') (callable not found or import error)
*** no app loaded. going in full dynamic mode ***

To decipher this, look into <yourapplication>.ini file for the module and chdir lines

chdir = /srv/uswgi-apps/yourapplication
module = wsgi:myapp

The wsgi of wsgi:myapp must correspond to the file name wsgi.py in your /srv/uwsgi-apps/yourapplication folder and the myapp must correspond to the import line in your wsgi.py file which imports your flask app as ‘myapp‘. In the example here, the flask app file was called app.py (as many tutorials tend to name their app files).

from app import app as myapp

if __name__ == '__main__':
    myapp.run()

Gracefully Reloading Applications

The uWSGI documentations detail how to manage your applications once deployed.

We recommend using at least the touch reload option and for finer grain control the Master FIFO method.

Touch Reload

The touch reload means that any time you change your ini file, that application will be reloaded.

touch-reload = /etc/uwsgi/apps-available/<yourapplication>.ini

DANGER! If using touch reload, verify your .ini changes on a staging server before deploying to a production server, because your application will be down if there is an error loading it.

Master FIFO

You can have one or more master-fifo lines.

master-fifo = /tmp/<yourapplication>-master-fifo

From the uwsgi docs: Only the uid running the master has write access to the fifo.

This means that most likely you need to echo commands to the master fifo as the www-data user (unless you specify a different user using uid in .ini file).

$ sudo -u www-data sh
[sudo] password for user: 
$ echo r > /tmp/<yourapplication>-master-fifo

HUP System Signal

If you already deployed your application and you are not in a position to add touch reload or master fifo, you can use the -HUP signal to reload your application.

sudo kill -HUP $(cat /var/run/uwsgi/app/<yourapplication>/pid)

Introduction to the Yocto Project

The Yocto Project ® is an open source project which provides a software build system, running on a Linux desktop operating system, to produce a Linux distribution primarily targeted at embedded systems, but definitely not limited to that.

In layman’s terms, you use a computer to download a whole bunch of software, compile it all, and collate it into an operating system and file system to go with it. You can then put this collated image/binary onto an SSD card or flash chip on some electronics, power it up and it will boot you a Linux operating system.

There is a lot of documentation on the Yocto Project, much quite detailed and possibly overwhelming. This site attempts to complement that documentation by breaking it down differently, adding value by shining light on the more hidden bits and the gotcha’s, some of which can cost you a lot of time.

What it is not.

It is not a software development system.

Yes, it is often used as a development flow, but it was never intended for this, and it as a result comes as no surprise that it is an inefficient way of developing software.

What it is.

The Yocto Project is a Linux Foundation project and a major driver behind the build system foundation which is Open Embedded.
This site will maintain the distinction between Open Embedded for the technology and Yocto Project for the project or ‘force’ behind it.

Who is the force?

The primary drivers behind the Yocto Project are silicon vendors, and companies providing Embedded Linux services.

This is understandably so, because the project and subsequent Embedded Linux distributions which are created are enablers for the sale of processors and associated Embedded Linux services.

A quick scan through the product showcase and members list will provide you details on who are the main drivers.

Where did it come from?

Open Embedded, the technology, is the successor of the now referred to Open Embedded Classic (or OE-Classic), combined with Poky a fork of it.

The source of OE-Classic is hosted on github still: https://github.com/openembedded/openembedded, and the new Open Embedded site provides insights into the differences.

The most significant change is that metadata is now split into multiple layers rather than being in one repository.

Additionally, OE-Core moves changes to a pull model rather than the push model of OE-classic – instead of all developers having direct commit access, patches are sent to the mailing list for review and if/when satisfactory they are merged by the maintainer

Quoted from https://www.openembedded.org/wiki/OpenEmbedded-Core

What on earth is Poky?

Once you start into the world of the Yocto Project, you will find Poky.

If you search for Poky online you will find it is Yocto Project’s reference distribution, and there is enough information in that link to keep you busy. It’s history though is interesting, and gives some insight into why it is in the Yocto Project in the first place.

Both the Open Embedded site and elinux.org outline its history.

Poky was forked as a cleaner and more supportable version of OE in 2006. Fast forwarding to the present, Poky is now maintained as a reference distribution under the Yocto Project with the support of the Linux Foundation

Quoted from OpenEmbedded-Core

Historically, Poky was a form of parallel evolution of the main OpenEmbedded tree, being smaller/cut down and more focused on specific targets. It was sponsored heavily by OpenedHand with Richard Purdie as its architect and lead developer and has been referrred to as a build system in its own right. To be clear it always used BitBake and the OpenEmbedded architecture so the build system/approach was always OpenEmbedded. With the creation of the Yocto Project and the refactoring of OpenEmbedded into several components such as OpenEmbedded-Core and Meta-OpenEmbedded, Poky became the reference distribution as many of the reasons for the original creation of Poky were addressed by those changes.

Quoted from https://elinux.org/Poky

Why is it a good build system?

Open Embedded is a good build system because it covers all the things that a build system should have.

  • sourcing software (from multiple places)
  • ability to patch released software before building
  • building software packages
  • building final embedded images
  • a built in QA step

Technically Open Embedded does more than what it is listed (e.g. builds toolchains), but those are what we consider the primary needs of a build system.

Also remember that Open Embedded is the technology behind the Yocto Project.

Is it Linux only?

Yes, the Yocto Project is Linux only.

Technically, under the bonnet, the bitbake engine need not be, but in practice its life started for and has become a Linux distribution generation engine.

Not to say that no one will, or has not already forked bitbake for something else.

Is Poky a distribution?

As advertised Poky is a “reference embedded distribution“.

Whether it is a distribution though depends on how one wants to split hairs on the meaning of distribution?

With comparison to Desktop PC distributions like Fedora, Ubuntu and others, these provide binaries, so we could argue the implicit definition of distribution is to provide binaries.

With that definition, the Poky the Yocto Project provides is probably more the build setup for a reference distribution that you can build for your selected target(s).

So what about Ångström?

Those that worked with Classic version of Open Embedded are likely to remember Ångström as a distribution.

Its intent was to provide binaries for a linux distribution targeting some specific embedded devices, using opkg as its package manager.

This made it a ‘real’ distribution.The thing to remember though is that Ångström had targeted hardware and that helps limit the diversity of binaries needing testing. Poky on the other hand ‘solves’ this by just releasing the build setup, even if it does test on some targets.

The last posted binaries on Ångström download page looks to be 2019.06.


Yocto Project ® and all related marks and logos are trademarks of The Linux Foundation. This website is not, in any way, endorsed by the Yocto Project or The Linux Foundation. Linux ® is a registered trademark of Linus Torvalds.