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

• Zephyr v1.14 development snapshot
• MCUboot with encrypted images support
• Sample applications converted to Logger and improved Bluetooth robustness

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.

• ARCHES: Initial support for big-endian architectures.
• BOARDS: Cypress PSoC6 Cortex-M0 and Cortex-M4 (cy8ckit_062_wifi_bt_m0 and cy8ckit_062_wifi_bt_m4), Atmel SAMD21 XPlained (atsamd21_xpro), NXP i.MXRT1062 Cortex-M7 (mimxrt1060_evk), nrf52_bsim adds a simulated board which models the NRF52832 SoC, ST support for the stm32l4r5xx parts
• DRIVERS: RTC support for STM32L4, -F3, -F4; slave devices and 10-bit addressing mode for I2C; SPI for NXP LPSPI; GPIO for Intel Apollo Lake; UART for Cypress PSoC6 and POSIX; LED strip WS2812 with defaults for using it with nRF52 SoC; nRF52840 USBD; Intel PRO/1000 Ethernet controller; LIS2MDL Mag sensor; MS5837 pressure sensor; lsm303dlhc accel; lsm303dlhc magnetometer; SSD1306 display controller; SSD1673 EPD controller drivers added
• DEVICE TREE: RISC-V DTS enabled for Pulpino.
• SAMPLES: demonstration applications for the newly merged shields in samples/shields, MS5837 sensor
• SHIELDS: The first mainline shields were merged, with support for STMicro X-NUCLEO-IKS01A1 and X-NUCLEO-IKS01A2 (x-nucleo-iks01a1 and x-nucleo-iks01a2).
• SOCS: Cypress PSoC6, i.MX RT1060

Shell Subsystem Reimplementation

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

• Multiple backends (though it's not clear what the future holds for interaction with the nascent TTY layer)
• Integration with the new Logger subsystem
• Tab completion
• Built-in shell support for clear, shell, colors, echo, history and resize.
• Command history with arrow key (↑ and ↓) support, as well as editing with arrow key (← and →), Backspace, Delete, End, Home, and Insert key support
• Support for ANSI escape codes, multi-line commands, wildcards (* and ?), and meta keys
• Built-in command help handling

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:

• The LOG_MODULE_REGISTER() and LOG_MODULE_DECLARE() macros now take the name of the module being registered (or declared), so the old way:

  LOG_MODULE_REGISTER();

  Must now be:

  LOG_MODULE_REGISTER(your_module_name_goes_here);

  If you want to continue defining LOG_MODULE_NAME as before, you can simply pass that as a parameter to the relevant macro.

• A template file, subsys/logging/Kconfig.template.log_config, was added, which provides a standard way to define log level configuration Kconfig options for a module. This uses the new macro substitution feature that is part of recent Kconfig implementations.

• The UART-backend specific color and timestamp options were made generic and renamed CONFIG_LOG_BACKEND_SHOW_COLOR and CONFIG_LOG_BACKEND_FORMAT_TIMESTAMP.

• A new logger backend was added for the POSIX pseudo-architecture; it is configurable using CONFIG_LOG_BACKEND_NATIVE_POSIX.

• Logging control commands were added to Zephyr's new shell subsystem; they can be enabled with CONFIG_LOG_CMDS.

• Flags were added to control whether the log level and timestamp are printed.

(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

• Turning on/off display blanking
• Writing/Reading a bit map towards/from the display
• Requesting framebuffer pointer
• Setting display contrast and brightness
• Querying display capabilities
• Changing pixel format
• Changing display orientation

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

• Added the Gecko SDK files to support EFM32HG SoCs
• STM32Cube stm32f3 package from v1.9.0 to v1.10.0
• STM32Cube stm32f7 package from v1.11.0 to v1.12.0

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

• LMP Unified Linux Kernel updated to 4.18.16.
• Core layer series now compatible with the OE/Yocto thud release.
• OE-Core build security flags are now enabled by default in LMP.
• Initial support for the HiKey960 board.

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.

• CVE-2018-16402
• CVE-2018-16403

libsndfile1

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

• CVE-2018-13139

qemu

Multiple issues.

• CVE-2018-17958
• CVE-2018-17962
• CVE-2018-17963

binutils

Multiple issues.

• CVE-2018-17358
• CVE-2018-17359
• CVE-2018-17360

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.

• CVE-2018-16402

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