Now that you’ve learned about how Linux came to be, let’s delve into how a few simple decisions by the man who created Linux, Linus Torvolds, changed the course of Linux and its role in the internet of things (IoT).
Embedded Linux has been used since the mid 1990s. But it wasn’t until 2011, when Linux 3.1 arrived, that Linux was stable enough for use in embedded systems. Unlike the desktop or server, embedding any operating system into a machine, car or appliance introduces a complication that doesn’t exist on the desktop or server machine: Upgradability. For numerous reasons that are mostly security related, updating an embedded Linux system isn’t common. When you buy an appliance or car, either a board is replaced or the car dealer handles software patches and updates.
Between 2011 and 2015, embedded Linux grew rapidly. And it was under the radar until a few companies sprouted up that developed embedded Linux systems. But they were anything but open source. As the number of proprietary embedded Linux systems grew, Linus Torvolds realized he had to address the issue head on.
Each embedded Linux system was custom built, and there were no processes or standards in place to guide the development process. So, Linus mandated some rules for embedded developers that had to be met if they wanted to call their creation Linux, use the Linux logo and have rights to use the Linux trademarks. At the time, his decision was not only unpopular, but most developers were convinced his mandate was impossible to meet.
Standardizing Embedded Linux Development
Embedded Linux has a slightly different development cycle and tool set. A credit-card-sized computer does not have the same resources as a server or desktop machine, and they don’t have a basic input/output system (BIOS).
The Embedded Linux Boot Process:
- A boot loader, u-boot, loads the hardware abstraction layer (HAL), which is called a device tree.
- Then the boot loader validates the hardware, locks the driver area and passes control to the Linux Kernel.
- The Linux Kernel initializes the hardware and completes the boot process to a fully running Linux system.
U-boot is not maintained by the Linux kernel team – it is designed for embedded systems. While the device tree is nothing like a BIOS, combined with u-boot, it replaces the BIOS in embedded Linux systems.
The device tree is a high-level editor and compiler that creates the binary image that replaces the BIOS. These are steps that exist in building an embedded Linux system that are not necessary or even understood by server and desktop Linux developers.
3 Steps to Comply with Embedded Linux Standardization
Torvolds required a few simple steps by developers to comply with his mandates. First, he required embedded Linux OS and Kernel source code to be migrated into the main Linux OS and Kernel source trees. This would force embedded Linux developers to use existing source code and make modifications for embedded Linux that would be handled at compile time.
In short, the same source code used for servers and desktop would now be the foundation for the embedded Linux devices as well. This standardized how embedded Linux systems were built and complied with open source standards. Now, when a Linux system build was customized, the source code would be migrated into the standard Linux source tree, making it available to all future embedded Linux systems built, which is exactly what open source compliance is all about: Sharing innovations with everyone.
Second, he forced embedded Linux developers to use a version of the device tree compiler that would utilize a master database of hardware components and that could be expanded easily when new components with new features were released. This standardized the hardware interface and abstraction layers.
Finally, he forced the kernel and OS maintainers to add support for new processor architectures in the source tree, and all of the embedded-specific compiler flags would now be handled in the same place as all other processor-dependent options, in the make files for the source code.
These three mandates were simple in the end, and standardizing embedded Linux customization and builds with the existing Linux source tree allowed embedded Linux systems to take off like a rocket.
How Linux Won the Embedded Systems Development Race
Up until this time, Windows had touted their embedded development kit. But Windows had a problem to face that Linux developers had already conquered. Windows had to be ported to support non-Intel architectures, whereas Linux and its compilers already had conquered that hurdle. There was no race. Windows was still at the gate as Linux had completed several laps around the track.
As it would play out, about the same time that embedded Linux development was standardized, an important patent expired and became available in the public domain. That patent was on the processes that made the Linux kernel operate in real-time mode, something critical for embedded operating systems to properly handle input and output from devices other than keyboards and monitors.
How Linux Clinched the IoT Device Market
While I talk about the portability of the Linux operating system, once the compilers are available for a new architecture, they can generate the applications from source as a byproduct. So, if you use one of the graphic layers, GTK or KDE, you can build almost any application that runs on them once the Linux OS is running. Build a new Linux system for a new architecture, and then build all your applications as a bonus. Windows can’t compete with that!
But once you can build the OS for one or more architectures, you can use the same source code from your applications on multiple platforms and architectures with little or no code changes. So, you develop your IoT interface to your sensors, and you can then use the same source code to communicate from the server to the embedded Linux device server, and from the embedded Linux device to the sensors. It’s that simple.
Write once, use on many and use often.
When you look at the big picture, the ability to build embedded Linux for multiple architectures at the same time, gives Linux an advantage that just can’t be beat. Being able to provide the same network tools, graphics tools, sensor interfaces and encrypted tunnel protocols that can be used out of the box on the server, desktop and embedded Linux at the same time is truly amazing and a benefit that provides quality while reducing delivery time, using the same source code base. And Linux debuggers can do source-level debugging on any supported target architecture from any supported host development environment, again with no change.
But Linux went even further than support for cross-platform embedded Linux development and debugging on servers and desktops. It allows full processor emulation, even allowing the host Linux system to dedicate hardware to the embedded Linux target via a virtual processor emulator. This allows for full transparency of the host system to the target’s architecture virtual emulator. In the past, this was a feature dedicated to external hardware in-circuit-emulator units (ICE).
Emulating the Target Architecture
The final difference between Linux and Windows in embedded Linux support is virtual machine processor emulation. If you have used a virtual machine manager or virtual machine, you are probably familiar with VirtualBox or VMWare. The official virtual machine for Linux is QEMU. QEMU is short for quick emulator and was originally released in July 2009.
While you may never have heard of QEMU, the project is intertwined with a number of other Linux projects and is tied directly to the Linux kernel through the Linux hypervisor, XEN. Together these two technologies allow QEMU to perform at near-native processor execution speeds due to the virtual machine being tied to the Linux kernel and VirtIo, the Linux virtual network interface.
Combined, these technologies can allow you to emulate a complete client–server network of different architectures on a single host at near execution speeds. This is a Linux-only suite of software, making it one of the reasons that Linux is the operating system of choice for IoT. This mature and advanced virtual machine (VM) and emulation technology is the biggest reason that Linux drives 80% of the world’s web servers.
QEMU allows for advanced IotT development techniques:
- Allocating dedicated hardware to virtual machine
- Allocating dedicated hardware to emulated architectures
- Debugging a VM operating system for an emulated architecture
- Remote debugging via TCP/IP
- Remote debugging a VM with emulated processor.
- Source code debugging any of the above
One added non-Linux related feature is the ability to virtualize, develop and debug for non-Linux embedded targets that support IoT sensors. These are advanced features that go way beyond the abilities of third-party-based virtual machine managers.
All Development Together
And finally, you can pull project management together using the eclipse workbench in editing, building, debugging and even deploying the executable programs to multiple computers on a network for testing and debugging without leaving the comfort of your desk.
You can design, code, build, test and debug any supported IoT sensor interfaces, device drivers and embedded servers to encrypted server tunnels or virtual private networks (VPNs). You can even trace your data on multiple architectures without any custom hardware or debuggers, using existing host cards for embedded Linux development for any architecture supported by QEMU.
The reason this appears so simple is because Linux was designed with portability and cross-development in mind. After all, Linux was designed to run on multiple processors. These long-term goals have been there since the beginning and are well maintained from one version to the next.
In closing, UNIX was developed by BELL LABS and chartered for these purposes. Linux carries on the traditional goals of UNIX that were initially developed to support the computer research and development lab to a degree not experienced prior.
Work on many popular embedded non-Linux-based processors is also in development to allow IoT sensor development on standard microcontrollers via a Linux VM host, completing the circle of support from the largest IBM (s390x) to the smallest embedded sensors (ESP8266-01) networking chips.
Show employers that you have the skills needed to work with Linux with CompTIA Linux+. Download the exam objectives today.
