Linux Kernel 4.20 released, our contributions

BayLibre has continued our contribution to the Linux community as seen with this new version of Linux Kernel 4.20, released on Sunday, 23rd December 2018.  An excellent summary of this release can be found at KernelNewbies.

Here is a summary of our contributions, organized by SoC family and a summary graph of contributions by developer.

Amlogic SoC family:

  • Added AXG PDM Input support, with Devicetree Nodes
  • Added common “Canvas” provider for DRM Display and upcoming V4L2 Decoder Driver
  • Added support for Serial Number readout from sysfs
  • Various Pinctrl, DRM, Audio and clock fixes

Ti DaVinci SoC Family:

  • fixed a GPIO-related regression present since v4.19
  • Finally killed davinci_clk_reset_assert/deassert()

Misc:

  • Bartosz Golaszewski became co-maintainer of the GPIO sub-system
  • nvmem: Bartosz fixed problems with the nvmem consumer API
  • Still some cleanups from Corentin in Crypto, Network and various other sub-systems
  • Fabien Parent added support for dedicated power supply in ChromeOS’s charger driver

 

 

The Top 3 Innovative Features of the Automotive Grade Linux UCB

Last month the Automotive Grade Linux (AGL) Unified Code Base (UCB) was listed as a CES Innovation Awards Honouree. AGL is a game-changing project for the automotive industry focused on bringing a fully-open software stack to the connected car, and we’re proud to have recently been named one of the top contributing companies. CES innovation awards 2019

AGL provides an operating system, middleware and application, known as the Unified Code Base (UCB), on top of which its nearly 140 member companies can rapidly build stable products. With all of those companies contributing to the project, there are plenty of innovative software features to talk about. Here, in our opinion, are the top 3:

1. Over-the-air (OTA) Updates

Today’s cars are collections of embedded systems, each running their own software stacks. As security issues are uncovered, updates need to be rolled out across fleets of cars as quickly as possible. Plus, with product life-cycles growing longer, software needs to be supported in production for longer and that often means shipping new features to older vehicles.

OTA updates prevent the need to recall cars simply to apply software updates. The ability to apply updates with cars still on the road is a major advantage because recalls inconvenience customers and can lead to reputational damage for manufacturers. They’re also extremely expensive.

As of the Electric Eel release, the AGL UCB includes a software layer for OTA upgrades. AGL uses the OSTree and Aktualizr projects to provide atomic, full file-system upgrades with rollback capability. As OSTree uses the file system to perform updates, it minimizes the network bandwidth and data storage requirements.

2. A Wide Range of Hardware Board Support

One of AGL’s goals for the UCB is to provide a single software platform for the entire automotive industry, and the UCB provides 70-80% of a finished product out of the box. That obviously includes applications, connectivity, and graphics, but it also includes a wide range of hardware board support for vendors such as Renesas, Qualcomm Technologies, Intel, Texas Instrument, NXP and Raspberry Pi.

And developers continue to contribute new support. Initial 64-bit ARM support was merged for the Electric Eel release earlier this year with the addition of the Renesas R-CAR Generation 3. Now, Renesas is working on contributing support for the ARM big.LITTLE architecture which can provide substantial performance improvements and power savings when combined with Energy-Aware Scheduler (EAS) patch series that’s part of the Renesas BSP.

3. Automated Continuous Integration and Testing

AGL is a “code first” project which means that it favors working code over writing lengthy specifications. All of that code has to be tested, and testing quickly and thoroughly is an important part of accelerating time-to-market with AGL’s shared software platform.

AGL has built extensive infrastructure for testing code changes. Defining the architecture of that testing infrastructure is the job of the Continuous Integration and Test (CIAT) expert group who, like all AGL expert groups, meet regularly to plan and coordinate development efforts.

Within the CIAT infrastructure, open-source software projects such as Fuego, LAVA, and Kernel CI provide comprehensive testing and allow every gerrit submission to be built and smoke tested on a range of hardware. But new changes aren’t just tested in isolation: daily snapshots are built and tested to catch any integration issues as early as possible.

We’ve written previously about how BayLibre contributed changes to both Kernel CI and AGL to harness the power of scalable automated testing, and we even housed a temporary Kernel CI backend in our office while the AGL project transitioned to their own instance. To see AGL’s Kernel CI instance in action visit https://kernelci.automotivelinux.org/.

Check out the AGL Booth at CES 2019

These are just some of the technical highlights of the AGL UCB. With over 2000 commits so far in 2018, new features and bug fixes are shipped in every release. If you’re attending CES 2019, January 8-11 in Las Vegas, be sure to check out the AGL Demo Showcase (Westgate Hotel Pavilion, booth 1614) to see the UCB on display.

Hardware Accelerated Video Decoding and System Load Monitoring Demos

In the past few months, BayLibre engineers Maxime Jourdan, Alexandre Bailon and Neil Armstrong showcased two demos to illustrate some of their recent work: fully hardware-accelerated video decoding which was linked to non-intrusive System Load monitoring via JTAG.

While these two demos seem unrelated, the non-intrusive System Load monitoring via JTAG developed by Alexandre Bailon was a good way to prove that the Amlogic Video Decoder driver from Maxime Jourdan and the Amlogic Video Processing Unit graphics output work well together, and that it’s possible to monitor system load without causing video frames to be dropped.

First of all, Maxime Jourdan did a talk at Embedded Recipes 2018 in Paris about his work on developing and upstreaming the Amlogic Video Decoder driver for the Amlogic S905, S905X, S9095D and S9012 SoCs.

You can access the talk here :

And slides at: https://www.slideshare.net/ennael/embedded-recipes-2018-upstream-multimedia-on-amlogic-so-cs-from-fiction-to-reality-maxime-jourdan

Then, Alexandre Bailon and Patrick Titiano spoke about their “libSoCCA” project which gets the real-time statistics of a running system via the well-known JTAG interface without interfering with the system’s execution or requiring any modifications to the code.

The ultimate demonstration was to show, in real-time, the CPU Load and CPU Bus accesses of a Libre Computer AML-S905X-CC system (running the LibreELEC Kodi distribution) with a steady 10% load decoding 50mbps 4K H.264 and 4K H.265 10-bit video samples from the JellyFish Video Bitrate test files http://jell.yfish.us/. And all without changing a single byte of the Linux filesystem or Kodi binaries.

The most interesting fact of this demo is that Kodi doesn’t have any platform-specific code to handle Accelerated Hardware Video decoding, nor does FFmpeg which speaks to the decoder driver.

All of this is made possible thanks to the Linux DRM (Direct Rendering Manager) KMS (Kernel Mode Setting) GBM (Graphics Buffer Management) display support handled in Kodi, and the V4L2 (Video For Linux 2) Memory2Memory Hardware Decoder support from FFmpeg.

With these two graphics subsystems combined, decoded frames from the V4L2 interface can be passed to the DRM Video driver and scaled, blended and displayed. And thanks to the Linux DMA-BUF framework, none of the frames need to be copied.

Linux Kernel 4.19 released, our contributions

BayLibre has continued our contribution to the Linux community as seen with this new version of Linux Kernel 4.19, released on Sunday, 21th October 2018.  An excellent summary of this release can be found at KernelNewbies.

Here is a summary of our contributions, organized by SoC family and a summary graph of contributions by developer.

Amlogic SoC family:

  • Initial support of the audio hardware on the Amlogic AXG SoC : A113D
    • Audio clock controller
    • Audio reset controller
    • Pinctrl missing configurations
    • ALSA SoC card
    • TDM input/output
    • SPDIF output
    • HW FIFOs handling
    • es7134 codec support
    • tas517x support
    • DT audio and pinctrl nodes
  • Add S805X based P241 board
  • Finally enable graphics output on the FriendlyElec Nanopi-K2
  • Enable DMT (Display Monitor Timing) HDMI output to support generic, non-HDMI monitors (DVI, VGA via HDMI->VGA dongle or monitors with custom timings in EDID)

Ti DaVinci SoC Family:

  • switch davinci SoCs to use the ti-aemif driver
  • switch to the reset framework for the DSP remoteproc

Misc:

  • Lots of cleanup and some code removal from Corentin
  • Various Clock & ALSA SoC fixups to make AXG Audio work
  • Add support for the CEC functionality on the upcoming Asus ChromeBox via the Embedded Controller interface and the Linux CEC Framework maintained by Hans Verkuil

 

 

U-Boot v2018.07 released, our contributions

BayLibre has continued contribution to the open-source community as seen with this new version of U-Boot v2018.07, released on 27th July 2018.

This release permits booting over an USB Mass Storage (USB Stick or Hard Drive) with EFI on the Libre Computer AML-S905X-CC board !

With U-Boot 2018.07, you can download the nighly Debian-Installer or OpenSuse  TumbleTweed, copy U-boot to a blank SDCard, copy the installer to an USB, plug USB and SDCard, boot and install !

Here is a summary of our contributions:

Amlogic SoC family:

  • Add support for the USB PHY and Controller on the Meson GXL (S905X, S905D) SoC based on the Linux version done by Martin Blumenstingl
  • Add Analog-to-Digital (ADC) driver based on the Linux version done by Martin Blumenstingl
  • Add Amlogic Reset Controller
  • Add ADC cli command
  • Sync DT with Linux 4.17

Misc :

  • Add “bulk” commands for Reset and Clocks + tests
  • Add dwc3-of-simple USB DWC3 simple Glue driver based on the Linux version
  • Add support for any number of PHYs for the DWC3 controller

Linux Kernel 4.18 released, our contributions

BayLibre has continued our contribution to the Linux community as seen with this new version of Linux Kernel 4.18, released on Sunday, 12th August 2018.  An excellent summary of this release can be found at KernelNewbies.

Here is a summary of our contributions, organized by SoC family and a summary graph of contributions by developer.

Amlogic SoC family:

  • Multiple fixups/enhancements for the AXG A113D SoC (I2C, TDM)
  • Add write support for NVMEM
  • MMC/SDCard Fixups
  • Boot fixup with SCPI

Ti DaVinci SoC Family:

  • Fixup for NAND support
  • Fixups for RemoteProc support
  • Fixups for AEMIF support

Misc:

  • Lots of cleanup and some code removal

 

 

Announcing the ACME Firmware Beta 3 Release

On 8th June 2018, BayLibre released a new version of the ACME Firmware, Beta 3. This important release contains a fix for a critical issue that can cause incorrect reporting of current and voltage data.

We recommend that everyone upgrade to this latest release right away.

A high-level summary of the changes can be found in the changelog, but in the rest of this article we’ll look at them in more detail.

 

Fix for Incorrect Shunt Resistor Values

The Beta 3 release includes a fix for a major bug that can manifest as incorrect current and voltage data being reported at the application level.

The issue is that shunt resistor values are incorrectly copied from the probe EEPROM when creating entries in the Linux sysfs file system. Depending on the configuration of inserted probes, the value from the probe in the first slot may actually be copied to the sysfs entry for the second slot, the value from the probe in the second slot may be copied to the sysfs entry for the third slot, and so on. In other words, it’s possible for all sysfs entries to contain incorrect shunt resistor values.

The bug is caused by a mismatch between the way probes are numbered by ‘dut-dump-probe’ (starting at 1) and the way the OS enumerates devices in sysfs (starting at 0). Because of this off-by-one bug, it’s impossible to initialize the shunt resistor value for the first slot on the ACME cape, and the default value of 10mohm is always used. Note that users of JACK probes may not be affected by this issue since the shunt resistor value for this probe happens to be identical to the default value.

 

An Upgrade to the Latest Yocto Krogoth Release

We’ve also upgraded to the latest version of the community-maintained Yocto Krogoth release (2.1.3), which includes both functional and security fixes, bringing the latest software updates to ACME users.

You can find instructions for downloading the ACME Firmware Beta 3 release here.

An Overview of Generic Power Domains (genpd) on Linux

The saying goes that most programming problems can be solved with another layer of abstraction. Generic Power domains (genpd) are a (relatively) new Linux kernel power management abstraction that model the way power is controlled for components on SoCs. In other words, genpd describes the relationship between devices and power controllers. Generic power domains allow these relationships to be declared outside of device drivers, which means these device groups can be updated at runtime.

Static versus Dynamic power management

Linux supports two types of idle power management: static and dynamic. Static power management is the term for suspend and resume operations; it controls system-wide power. This is the traditional way to suspend a system and comes from the original support for laptop PCs where the whole system would be suspended at once. A good example of this is closing the laptop lid.

Dynamic power management, on the other hand, controls power to individual devices, allowing flexible power management based on activity in different parts of the SoC/platform.

Dynamic power management for device drivers is implemented inside of the kernel with the runtime PM framework (dynamic power management for CPUs is handled differently, via the CPUfreq and CPUidle subsystems). Device drivers use the struct dev_pm_ops data object to hook up their callbacks:

These callbacks allow devices to be powered up or down, or enter a low-power idle state when they go idle, such as when a transaction is finished. Each individual driver decides when the device is idle.

Device drivers can inform the PM core when devices are going idle. Idleness is controlled using the pm_runtime_get() and pm_runtime_put() functions. This API maintains a reference counter for each device to track whether the device is in-use at any time. pm_runtime_get() blocks the device from entering a low-power mode until the last pm_runtime_put().

But controlling power on a per-device level, while better than system-wide, isn’t the most efficient way to save power. Instead, hardware vendors have long provided a way to control power to groups of devices through power islands, or power domains.

 

What are power domains?

Devices and SoCs have separate power rails with devices connected to them. Power domains are a hardware concept for managing devices sharing power rails. Their power voltages are correlated. While the hardware power islands have existed for many years, the kernel has only recently added support for them.

Linux power domain drivers sit above devices in the PM hierarchy, at the same level as bus_type.

Power management core hierarchy diagram

These relationships need to be modeled inside of the kernel because the same IP blocks and chip families might have different groups depending on the hardware. For example, the same ARM IP can be used in different SoC vendor products and they might group things differently. So you need a way to describe this fixed relationship. Some examples are whether all CPUs/clusters share a power rail or have independent rails, or whether video-centric IP shares a power rail with the display IP.

A solution is needed that abstracts this so that the driver doesn’t need to care. And these power domain relationships need to be described in a way that does not require updating drivers for every new platform and configuration.

Crucially, we don’t want a driver to care whether it’s running on an AmLogic or Qualcomm chip — it should work on both, independent of how the power rails are configured on those platforms.

 

Generic Power Domains (genpd)

Generic power domains are an abstraction on top of Linux kernel power domains. They provide a number of benefits over regular power domains because they support:

  • Domain hierarchies
  • Adding and removing devices from domains at runtime
  • Power governors
  • Device Tree support

Generic power domain drivers control the entire domain’s power when an entire group of devices goes idle. A typical action is sending a command to a microcontroller or writing to a register to disable a voltage rail. The genpd framework takes care of running the callbacks for every genpd driver in a hierarchy, a feature that makes it possible to control the nested power domains available on some SoCs.

genpd drivers can be both IRQ-safe and always-on. The former (enabled with the GENPD_FLAG_IRQ_SAFE) is useful for domains that can be powered on/off in atomic context. This feature is particularly useful for devices that have low suspend and resume latency, and can be powered on or off quickly.

Always-on genpd drivers make sense if you have devices that must not be powered off. For example, CPUs that are behind a power microcontroller. Whether or not genpd drivers set the GENPD_FLAG_ALWAYS_ON flag can be platform-dependent.

In addition, there are optional driver callbacks that can be used if drivers want to know when new devices are attached or detached from a generic power domain. These callbacks are used to execute power domain-specific actions.

Generic power domains are described in the device tree, so the configuration can be described on a per-platform basis. Storing the configuration data inside device tree also makes it easy to update since the genpd driver requires no changes when new SoCs are released; a single driver can support all platform configurations.

Here’s a simple genpd example:

Here’s how it would be used by a device:

genpd also provides governors which add another level of control in between the PM core and the device drivers. Every generic power domain can have its own governor. Governors decide whether power should be gated to a generic power domain, and their decisions are based on simple heuristics. There are two available in the kernel: the simple QoS governor and the always-on governor.

As the name implies, the always-on governor prevents devices from being powered off. The simple QoS governor is more interesting — it considers the time it takes to power devices on and off, known as suspend and resume latency. If a power domain is predicted to be resumed before power can be turned off to all devices, the simple QoS governor will prevent the power domain from suspending.

Governors have a standard plugin-architecture, so you can write custom versions for specific platforms as well.

 

Performance states

A recent addition to the kernel, in v4.15, is support for power domain performance states. This new feature makes it possible to finely tune the power consumption of devices by varying the voltage to power rails. genpd drivers implement this with the (*set_performance_state) callback. Sadly, there are no upstream users of this API yet, but one is currently being reviewed on the kernel mailing lists.

 

Resources

The genpd framework provides an extremely flexible API for finely controlling power domains. If you want to learn more, here is a list of resources:

And here’s the video of Kevin’s talk on generic power domains at Kernel Recipes 2017.

Linux Kernel 4.17 released, our contributions

BayLibre has continued our contribution to the Linux community as seen with this new version of Linux Kernel 4.17, released on June, 3rd 2018.  An excellent summary of this release can be found at KernelNewbies.

We’re happy to report BayLibre is once again featured in the LWN stats for this release. Corentin Labbe from our team is a Top 10 developer and BayLibre is a Top 20 employer, both by Lines Changed.

Here is a summary of our contributions, organized by SoC family and a summary graph of contributions by developer.

Amlogic SoC family:

  • clocks: major rework to switch to regmap; misc. cleanups
  • improve DT support for WeTek hub and play2
  • MMC: reduce max speed for Odroid-C2 boards after multiple problems reported
  • AXG family: enable hardware RNG
  • HDMI: Add support for DMT modes

Misc:

  • Lots of cleanup and dead code removal (see Lines removed by Corentin)

 

 

Shipping the Zephyr RTOS in Consumer Electronics Products

Baylibre collaborates with manufacturers of consumer electronics, providing custom firmware solutions and specializing in Linux-based IoT devices. We’ve worked on several embedded consumer products using the Zephyr Project, including the Sensor Hub in the Blocks modular smartwatch and Ellcie Healthy glasses, and the Embedded Controller for the Gnarbox.

When choosing our Real Time Operating System (RTOS) for these projects, we had quite a few options because the RTOS market is increasingly fragmented. Top of our priority list was a project using a permissive license, and providing a free solution. This eliminated FreeRTOS from consideration since it was still under a GPL or proprietary license at the time. Mbed OS was another contender, but we felt it was too dependant on the Mbed ecosystem. We considered using NuttX or building a bespoke OS, but ultimately decided that Zephyr best met our needs.

Zephyr is an RTOS hosted by the Linux Foundation. It is scalable, supports multiple hardware architectures, is optimized for resource-constrained devices (everything is statically allocated), and built with security in mind. Collaboration is also actively encouraged, from individual coders to major companies contributing. We liked that it is similar in many ways to Linux (in its coding style and build process), has a strong community focus, and fantastic documentation. The permissive Apache 2.0 license was also an advantage.

Zephyr’s release cycle is three to four months, with (approximately) an 11-week merge window and 3-week stabilization period. Each release is a combination of planned new features and community contributions.

Those community contributions meant that Zephyr gave us a lot of what we wanted out of the box, and made it easy for us to upstream the elements we added for our customers’ products: support for the STMicroelectronics STM32L4 and STM32F0 MCUs. STM32F1 was already supported, so we were able to copy that example, simplifying our development work. That also made porting very fast. We completed a basic port in a day and a half, and a fully-tested port in less than one week.

Overall, we found Zephyr to be well-structured and simple to use. Most of the port time was spent on I2C/SPI testing. Once porting was complete, the Zephyr upstreaming process was straightforward. We

  • Read the contribution guidelines
  • Cleaned up our patch to follow Zephyr’s coding standards (with help from uncrustify)
  • Verified that the patch met the coding standards using checkpatch
  • Committed our changes to github
  • Awaited reviews

Fortunately, the Zephyr project provides a community of reviewers and we were able to contact the maintainers on the Zephyr IRC channel to assist with getting patches merged.

Despite challenges during the review process, overall we found Zephyr easy to get started with thanks to its similarities to Linux, thorough documentation, and an active community. This RTOS’s design is good for low memory usage, and as the software and development processes evolve with growing community input and support, flaws are quickly fixed.

If you’d like to hear more about our experience with Zephyr to power consumer electronics products, check out our presentation from Embedded Linux Conference 2017: