FoundriesFactory
The push towards v1.14 continues; MCUboot supports encrypted images.
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.
Jekyll dependencies were updated to fix CVE: https://nvd.nist.gov/vuln/detail/CVE-2018-1000201
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
Not addressed in this update
A brief summary of newly-minted Zephyr support.
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.
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.
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++.
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).
Zephyr has long supported applications defining their own Kconfig options, provided that:
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.
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.
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.
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.
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.
The ILI9340 driver was adjusted to use this new API.
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.
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.
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.
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.
Not addressed in this update
The dm-hawkbit-mqtt sample followed upstream changes to replace the SYS_LOG functionality with the Logger subsystem.
Now that LED data was moved to DTS, specific SoC logic was replaced with a direct check of the BT LED definitions
Introduced a patch to gracefully bring down the Bluetooth connection in an attempt to avoid problems with the host connection (Bluez).
The dm-lwm2m sample followed upstream changes to replace the SYS_LOG functionality with the Logger subsystem.
Now that LED data was moved to DTS, specific SoC logic was replaced with a direct check of the BT LED definitions
Introduced a patch to gracefully bring down the Bluetooth connection in an attempt to avoid problems with the host connection (Bluez).
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.
Not addressed in this update
LXC updated to 3.0.2.
Not addressed in this update
Initial u-boot support for qemuriscv64.
Not addressed in this update
Linux-yocto updated to 4.18.
Not addressed in this 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.
Multiple issues.
Stack-based buffer overflow in psf_memset in common.c in libsndfile 1.0.28.
Multiple issues.
Multiple issues.
Dracut updated to 049. Hwdata updated to 0.316. Udisks2 updated to 2.7.8. Wireshark updated to 2.6.4.
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.
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.
Not addressed in this 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.
Not addressed in this update