FoundriesFactory

microPlatform update 0.32

Summary

Zephyr microPlatform changes for 0.32

The push towards v1.14 continues; MCUboot supports encrypted images.

Linux microPlatform changes for 0.32

LMP Unified Linux Kernel updated to the 4.18.16 stable release. Core layer updates based on the latest OE/Yocto master/thud changes. Initial support for the 96Boards HiKey960 board.

Zephyr microPlatform

Highlights

Components

MCUboot

Features

Jekyll dependency update

Jekyll dependencies were updated to fix CVE: https://nvd.nist.gov/vuln/detail/CVE-2018-1000201

Encrypted image support

This allows storing encrypted images in slot1, that are automatically decrypted when copying to slot0 and re-encrypted when copying from slot0 to slot1.

For more information: https://github.com/runtimeco/mcuboot/commit/ba829049eac9fd3be72b526d96c4bf4d75bb691d

Bugs

Not addressed in this update

Zephyr

Features

Fresh and New

A brief summary of newly-minted Zephyr support.

Shell Subsystem Reimplementation

Zephyr's shell subsystem has been completely reimplemented. Official docs for the new version claim the following features:

The new features come at a price: during a Technical Steering Committee presentation on the subject, a minimum of 8KB ROM footprint was given. Total footprint and memory usage can, of course, be tuned via Kconfig.

As of now, the Bluetooth shell has been ported to the new shell subsystem.

Wading in the Waters of MISRA-C Compliance

The Motor Industry Software Reliability Organization (MISRA) defines a variety of software standards used in the automotive industry. Among them are the MISRA C guidelines for use of the C programming language. These have gone through three versions, released in 1998, 2004, and 2012; they are proprietary specifications which can be purchased for £15. Zephyr is targeting the most recent (2012) version of the MISRA C standard.

Zephyr has been targeting MISRA-C compliance for some time now, and the first development along these lines is now taking place. A mailing list thread was started introducing the subject and incoming changes to Zephyr, and some commits have been merged which address violations of the standard. So far, these have been fairly wide-ranging changes both in the kernel and across the tree, some scripted using Coccinelle. Initial changes seem focused on somewhat mechanical transformation to address requirements like not ignoring return values or respecting reserved portions of the namespace, which have not been, let's say, universally loved. However, nobody seems to disagree with the idea that Zephyr being certifiable in an automotive context is desirable for the project, even if it implies somewhat baroque and artificial restrictions on the codebase.

Portability and C++

In a slightly orthogonal but somewhat similar set of changes, various patches are going in to make Zephyr usable with C++ applications and non-GNU toolchains. Some examples include avoiding non-standard void pointer arithmetic, C99 rules around semicolons in structures, and making Zephyr's device driver API headers compile in C++.

Out-of-tree SoC Support

Zephyr already has support for integrating with board definitions that aren't part of the Zephyr tree; it now also includes support for out of tree SoCs. The official documentation describes how to integrate such a definition into the Zephyr tree. Internally, this resulted in a top-level soc directory (i.e. parallel to arch), and the movement of existing SoC support there from its previous home in arch.

The remaining code in arch now focuses more narrowly on CPU cores themselves, rather than the SoCs which integrate them with peripherals, other cores, etc. In addition to easing out of tree and proprietary usage of Zephyr, this is arguably a cleaner construction, especially given that some modern "microcontroller" SoCs are complex, multi-core creatures, with cores from different processor subfamilies (or even architectures).

KCONFIG_ROOT by Convention

Zephyr has long supported applications defining their own Kconfig options, provided that:

  1. The application's Kconfig file includes Zephyr's somewhere in its definition.
  2. The application CMakeLists.txt (or the CMake command line) sets the KCONFIG_ROOT variable to point at the application's Kconfig file.

The second requirement has now been partially lifted. If the application's directory contains a file named Kconfig, this is used by default as the KCONFIG_ROOT. Applications are still free to set KCONFIG_ROOT to any value they desire.

These details are now described in the application development primer.

Arm MPU Reorganization

Previously, Zephyr's Memory Protection Unit (MPU) support for Arm cores was split into multiple Kconfig options depending on the target SoC. (Perhaps) needless to say, the story got a bit complicated over time.

For example, users of SoCs with the MPU core provided by Arm Limited could set CONFIG_ARM_CORE_MPU=y, while those with NXP MPUs would use options like CONFIG_NXP_MPU or CONFIG_ARM_MPU_IMX_RT. Nordic nRF52 aficionados would naturally prefer CONFIG_ARM_MPU_NRF52X, and of course lovers of the STM32 line could set CONFIG_STM32_ARM_MPU_ENABLE.

This has been simplified and consolidated under a single CONFIG_ARM_MPU option. If this is set to y, chip-specific build system logic will select and enable the relevant MPU support code for the target SoC. This is in keeping with similar behavioral changes made to Zephyr's device driver support.

More Progress on Power Management

A previous newsletter from the v1.13 RC period celebrated the addition of an "OS-managed" power management framework, which enabled the kernel to handle some aspects of conserving energy depending on system state it was already tracking. This celebration was muted by limitations to nRF devices and hard-coded data structures limiting support to certain peripherals, but looked forward to further improvements.

These improvements are incoming, with the addition of generic arch infrastructure for power state support, which is now used by Arm nRF52, ARC quark_se_c1000_ss, and x86 quark_se SoCs.

The power management core itself now advertises pluggable policies, with an initial example based on CPU residency.

We look forward to further improvements and documentation in this area.

Logger API Changes and Improvements

In the Logger blog series (https://foundries.io/insights/2018/08/14/zephyr-logging-part-2/), we deep-dived into the initial version of the Logger API merged into Zephyr. This subsystem has since seen some changes and improvements, both to its core implementation and usage within the tree.

Here's a quick recap:

(Experimental) Socket Offload API

As we've discussed at some length in previous newsletters, Zephyr's networking stack is in the process of being rearchitected so that all network access, including use of TLS and DTLS, is via its sockets API.

One of the main reasons this is happening is to enable offloading of network support to external chips. The idea behind this is that if the user relies only on standard socket APIs (plus some nonstandard setsockopt() calls to handle the TLS state machine), then the networking implementation can be a software stack on the same chip or a driver for an external chip with a "sockets-ish" wire protocol, with nobody above the sockets API being the wiser.

One important missing piece needed to make this vision a reality is a socket-based API for writing such "offload" drivers. Experimental work was merged rectifying this with the addition of a new CONFIG_NET_SOCKETS_OFFLOAD option. When this is enabled, a new API in <net/socket_offload.h> will be substituted for the usual software implementation, providing its own socket API declarations which call into a struct socket_offload vtable. The TI SimpleLink WiFi driver is the first in-tree user of this option and API.

Support at present seems limited to installing a single socket_offload structure at a time, so mixing use of multiple network interfaces with this feature doesn't seem possible at the moment.

New Display API added

The ILI9340 driver was adjusted to use this new API.

Logger Subsystem Migration

As the Logger subsystem continues receive bug-fixes and back-end implementations, more of Zephyr was migrated to it or adjusted to use its new logging level nomenclature. This would include: the core kernel, arch and SoC trees, several drivers and sections of the network subsystem -- the related sample applications were migrated as well.

Shell Subsystem Migration

Not to be outdone by the Logger subsystem changes, several more shell features were added and the continuing effort to switch shell implementation continues with the filesystem subsystem, sections of the bluetooth stack, networking subsystem sections for ieee802154, openthread, wifi and the generic net shell, as well as several samples: http_server, rpl_border_router, wpanusb and zperf.

Of LEDs, buttons and DTS

Several arches and SoCs shifted the configuration of LED and button defines into DTS: arc, atmel, hifive1, nrf, silabs, sam4s_xplained, sam_e70_xplained, x86, zedboard_pulpino.

External HAL changes
MCUMGR project updated in Zephyr

It was possible to erase slot 1 while it was storing the confirmed image during ongoing tests. This is unwanted behavior which allows for bricking the remote device accidentally. Added a check for this case which aligns the conditions required for erase command execution similar to upload command.

Bugs

Not addressed in this update

hawkBit and MQTT sample application

Features

Conversion from SYS_LOG to LOG

The dm-hawkbit-mqtt sample followed upstream changes to replace the SYS_LOG functionality with the Logger subsystem.

Bluetooth LED changes

Now that LED data was moved to DTS, specific SoC logic was replaced with a direct check of the BT LED definitions

Bugs

Dealing with Bluetooth disconnect woes

Introduced a patch to gracefully bring down the Bluetooth connection in an attempt to avoid problems with the host connection (Bluez).

LWM2M sample application

Features

Conversion from SYS_LOG to LOG

The dm-lwm2m sample followed upstream changes to replace the SYS_LOG functionality with the Logger subsystem.

Bluetooth LED changes

Now that LED data was moved to DTS, specific SoC logic was replaced with a direct check of the BT LED definitions

Bugs

Dealing with Bluetooth disconnect woes

Introduced a patch to gracefully bring down the Bluetooth connection in an attempt to avoid problems with the host connection (Bluez).

Linux microPlatform

Highlights

Components

Meta Freescale

Features

Layer Update

Linux-fslc updated to 4.18. NXP BSP updated to L4.9.123-2.3.0_8mm_ga. New machine definition for for imx8mmevk. Qoriq BSP updated to LSK v18.09. U-boot-fslc updated to the 2018.09-based fork.

Bugs

Not addressed in this update

Meta Virtualization

Features

Layer Update

LXC updated to 3.0.2.

Bugs

Not addressed in this update

Meta RISC-V

Features

Layer Update

Initial u-boot support for qemuriscv64.

Bugs

Not addressed in this update

Meta Yocto

Features

Layer Update

Linux-yocto updated to 4.18.

Bugs

Not addressed in this update

OpenEmbedded-Core Layer

Features

Layer Update

Bash updated to 4.4.23. Go 1.10 recipes removed in favor of 1.11.1. Glibc updated to the 2.8-044c96f0d5 revision. Valgrind updated to 3.14.0.

Bugs

elfutils

Multiple issues.

libsndfile1

Stack-based buffer overflow in psf_memset in common.c in libsndfile 1.0.28.

qemu

Multiple issues.

binutils

Multiple issues.

Meta OpenEmbedded Layer

Features

Layer Update

Dracut updated to 049. Hwdata updated to 0.316. Udisks2 updated to 2.7.8. Wireshark updated to 2.6.4.

Bugs

python3-requests

The Requests package before 2.20.0 for Python sends an HTTP Authorization header to an http URI upon receiving a same-hostname https-to-http redirect, which makes it easier for remote attackers to discover credentials by sniffing the network.

Meta Updater Layer

Features

Layer Update

Added support for setting custom OSTree commit subject and body. Aktualizr updated to the 39acfec48d revision. Otaimg image renamed to ota-ext4 in order to simplify the image build process.

Bugs

Not addressed in this update

Meta LMP Layer

Features

Layer Update

Added initial support for the HiKey960 board. LMP Unified Linux Kernel updated to 4.18.16. OE-Core security flags are now enabled by default in LMP.

Bugs

Not addressed in this update

Related posts

Keep up to date with Foundries.io