PTXdist: Did you know? Today: Just a reboot

While the development on an embedded system I need to reboot it quite often. Doing so I appreciate to keep the required steps as less as possible and be sure the embedded system uses the recently changed data in a consistent manner.

I never want to be a disk jockey, moving around an SD card, writing it here, using it there, just to test a litte change in my root filesystem. It needs too much time and its boring.

That's why I want to run my embedded system via network only. And here "only" means, it includes the kernel and its devicetree as well. I presume the bootloader of the embedded system supports the NFS protocol and also the BootLoaderSpec (if you are using the bootloader barebox you are already in a nice position). Both features in addition to an NFS service support the possibility to run the embedded system solely and in a consisten manner via network. The NFS service possibilities I already discussed here.

I'm using the bootloader barebox on all of mine embedded systems, so it will be a prerequisite for this example.

The NFS service must export the BSP subdirectory platform-<name>/root. It is the root filesystem dedicated for the embedded system and the embedded system must use a path to this directory from its point of view. The BSP subdirectory is created when the command ptxdist go has run.

Initially the bootloader barebox must configure its network interface. Its possible to configure it statically or via DHCP.

To load the Linux kernel and its devicetree via network, I need to define an additional automount entry in the barebox environment. On my embedded system I'm using the eth0 interface for the network, so my automount entry looks like that:

barebox:/ edit /env/init/automount
 mkdir -p /mnt/nfs
 automount /mnt/nfs 'ifup eth0 && mount -t nfs ${eth0.serverip}:/<path> /mnt/nfs'

The <path> component is just a placeholder here and it must be replaced by the path to the NFS export of the BSP's root filesystem directory.

Now the bootloader barebox is already using the network, but the Linux kernel needs an additional parameter as well to make use of the network and NFS for its root filesystem. barebox will add this required parameter automatically if the BootLoaderSpec config file contains the line linux-appendroot true. More about this detail will follow. That's all to be done at the embedded system.

At the PTXdist side (my development host) its sufficient to enable the entry default bootloader spec entry in the submenu bootloader spec entries in the platform configuration. Due to PTXdist does not automatically add the linux-appendroot true line mentioned above, I have to add it by my own. In order to, I copy the file default.conf from the path projectroot/loader/entries in the PTXdist installation directory to my local BSP into the projectroot/loader/entries directory and add the required linux-appendroot true line to it. It now should look like this:

title             @TITLE@
version           @VERSION@
options           @CMDLINE@
linux-appendroot  true
linux             @KERNEL@

Now I run the ptxdist go command to create the root filesystem directory on my local harddisk, start the NFS service (if not already done) and switch on my embedded system. I can now boot my embedded system simply by typing the command:

barebox:/ boot /mnt/nfs

Doing so looks like this at my side:

barebox 2017.09.0 #2 Mon Sep 04 11:55:04 CEST 2017

Board: jb's board
detected i.MX53 revision 2.1
running /env/bin/init...

Hit any key to stop autoboot:    3
barebox:/ boot /mnt/nfs
booting 'PTXdist - jb's board'
blspec: booting PTXdist - jb's board from none
Adding "root=/dev/nfs nfsroot=<path>,v3,tcp ip=dhcp" to Kernel commandline

Loading ARM Linux zImage '/mnt/nfs//boot/zImage'
Loading devicetree from '/mnt/nfs//boot/imx53-board.dtb'
commandline: root=/dev/nfs nfsroot=nfsroot=<path>,v3,tcp ip=dhcp

My embedded system is DHCP configured and thus barebox automatically adds this method to the kernel command line (ip=dhcp). Here the <path> component mentioned above appears as well. barebox has extracted this parameter automatically from the automount entry and appended it in a suitable way to the kernel command line.

To avoid to re-type the mentioned boot command after each start or reset, I can configure it as the default:

barebox:/ nv boot.default=/mnt/nfs
barebox:/ saveenv

As for me, I am already relaxed at work and let the high pressure do its work in my coffee maker instead...

Further Readings

labgrid Tutorials

This week, we started our series of YouTube labgrid tutorials. In the next few weeks we will publish more video tutorials showing you labgrid's features and giving you handy tips and tricks.

Showcase: Fail-Safe (OTA) Field Updating

Enrico Jörns | | didyouknow, rauc

Being able to robustly and securely update embedded systems and IoT devices in the field is a key requirement of every product today. The update framework RAUC is the basis for a modern and future-proof solution. In this showcase we present the basic principles of a fail-safe update system and how Pengutronix can support you with implement this for your platform.

Showcase: Graphics on i.MX8MP

Enabling the graphics output pipeline on the i.MX8M Plus (i.MX8MP for short), is the most recent example on how open-source and upstream driver support for GPU and display engines can reduce effort and risk in a new project.

License management with the ptxdist make license-report

PTXdist comes with a tool to make license management more simple, namely the command: ptxdist make license-report. This tool generates a license report in pdf format, which filters the used BSP for all known licenses. To generate and comply with the license report should be seen as minimum standard, exceeding efforts should, if possible, be done.

Static Filesystem

Jürgen Borleis | | PTXdist

Whenever it is a requirement to be able to switch off an embedded device without any previous preparation, the next question is about the consistence of the used filesystem. If this filesystem is used to be written with new content and this new/changed data hasn't done it's way to the persistent media when the power is cut, this new/changed data is lost.

Jump Start your BSP using DistroKit and PTXdist Layers

A BSP (Board Support Package) in Embedded Software is the layer of software that lets you run your application on a specific hardware. For Pengutronix a BSP usually contains a bootloader, Linux Kernel and a userspace. DistroKit is our Demo-BSP that supports a variety of common evaluation boards. DistroKit gives you a head start if you want to develop an application on top of such an evaluation board with most of the hard problems already solved.