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.



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


  • 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:



Linux Kernel 4.16 released, our contributions

Linux Kernel 4.16 released

BayLibre has continued our contribution to the Linux community as seen with this new version of Linux Kernel 4.16, released on April, 1st 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:

This release is important since it’s the first Linux release that can boot an Amlogic SoC with graphics with u-boot mainline, both unchanged !

  • Finally enable the Video Processing Unit power domain and all the missing bit :
    • drm/meson: Add missing VPU init
    • drm/meson: dw_hdmi: Add support for an optional external 5V regulator
    • ARM64: dts: odroid-c2: Add HDMI and CEC Nodes
    • ARM64: dts: meson-gx: grow reset controller memory zone
    • ARM64: dts: meson-gx: Add HDMI_5V regulator on selected boards
    • ARM64: dts: meson-gx: add VPU power domain
    • dt-bindings: display: amlogic, meson-dw-hdmi: Add optional HDMI 5V regulator
    • dt-bindings: display: amlogic, meson-vpu: Add optional power domain property
    • This means you can download Linux v4.16 and U-Boot v2018.01, build them, flash them and you will be able to boot to graphics with HDMI on most Amlogic S905, S905X and S912 supported boards !
  • drm/meson: fix vsync buffer update : fix a long-time issue causing glitches when rendering directly using GBM
  • Jerome improved the Meson S905X/S905D/S912 internal ethernet PHY support by :
    • net: phy: meson-gxl: add interrupt support
    • net: phy: meson-gxl: use genphy_config_init
    • net: phy: meson-gxl: add read and write helpers for banked registers
    • net: phy: meson-gxl: define control registers
    • net: phy: meson-gxl: check phy_write return value
    • ARM64: dts: meson-gxl: add internal ethernet PHY irq
  • Jerome added the “clock protection” feature to the clock framework


  • Add support for the the Variscite DART-MX6 SoM and Carrier board with LVDS display
  • media: uvcvideo: Add a quirk for Generalplus Technology Inc. 808 Camera
  • ARM: davinci: fix the GPIO lookup for omapl138-hawk
  • i2c: davinci: fix the cpufreq transition
  • Corentin did some cleanup in the crypto directory and some overall remove of unused code/documentation



Zephyr 1.11.0 released, BayLibre contributions

A full changelog of this release are available on the project releases page.

For these last 3 Zephyr releases, BayLibre engineer Neil Armstrong worked to add a better support for the STM32F0 SoC family by adding SPI, I2C, and internal Flash support, following his work on the previous Zephyr release on the overall STM32 Microcontrollers.
A hard time was spent adding SPI Slave and I2C Slave support on Zephyr for the whole STM32 Microcontroller family, to align with other RTOS and Linux for the I2C Slave part.

Since Zephyr 1.8, supported in Zephyr :

Along the following STM32 Microcontrollers features :

And ongoing features still in discussions :

The last Pull Request is done in cooperation with Daniel Wagenknecht, and triggered a lot of technical discussions ! Thanks Daniel !


Linux Kernel 4.15 released, our contributions

Linux Kernel 4.15 released

BayLibre has continued our contribution to the Linux community as seen with this new version of Linux Kernel 4.15, released on January, 28th 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:

  • Finally GPIO IRQ Support for Amlogic SoCs
  • Pinctrl cleanup for AXG future support
  • Meson GXL/GXM Internal PHY fixup for reliability
  • Support for new boards :
    • Vega S96
    • Khadas VIM2
  • Driver support for the Video Processing Unit Power Domain for mainline U-Boot support
  • Level Reset support for GX Family


  • Support for the Winbond w25q16dw present on the Khadas VIM2
  • usb: musb: da8xx: Remove duplicated defines



How We Improved AmLogic Support in Mainline Linux

It was a match made in heaven: two years ago AmLogic and BayLibre joined forces to bring top-notch support for AmLogic SoCs into the mainline Linux kernel.

Since that time AmLogic has continued to become one of the most relevant and widely used silicon vendors in the world. Similarly, BayLibre has expanded the variety of SoCs, drivers and frameworks supported upstream all while supporting a growing number of OEMs basing their products off of recent kernel releases.

Along the way Baylibre has collaborated with a great community of product makers, kernel hackers and hobbyists to improve the AmLogic Meson SoC support in mainline Linux. We’ve added support for 64-bit SoCs, new drivers, and we’ve become maintainers for the AmLogic platform in Linux.

Our goal is straightforward: AmLogic system-on-chip processors should be so well-supported in the mainline Linux kernel that OEMs will go to market using the latest stable kernel release.

Last year at Embedded Linux Conference 2017 and this year at Linux Conf Australia, Neil Armstrong gave a well-received talk on our work. This post expands on Neil’s presentation and provides an update on some of the changes we’ve been involved with recently.

The Linux Meson project

The Linux Meson project is an effort to get support for the ARM-based SoCs produced by AmLogic into the upstream Linux kernel and GNU/Linux distributions. AmLogic chips are found in many Android-based multimedia devices such as set-top boxes, smart TVs, projectors, and tablets but are also starting to appear in products in the smart speaker market. Popular consumer products and community boards using the AmLogic Meson SoC include:

  • Amazon Fire TV (gen3)
  • Wetek Play/Hub
  • Nexbox A1/A95
  • Hardkernel ODROID-C2
  • Tronsmart Vega S96
  • R-Box Pro
  • HwaCom AmazeTV
  • Libre Tech CC (a.k.a “Le Potato”)
  • Khadas VIM and VIM2
  • NanoPi K2

AmLogic provides a kernel release and SDK that supports their hardware but it’s a heavily-modified 3.10-based or 3.14-based kernel for Android. Thankfully, most of the changes are confined to the `drivers/amlogic` directory and it has been possible to use them as a starting point to write the upstream support.

Carlo Caione added the initial support for the 32-bit Meson6 SoC in Linux 3.18, with Beniamino Galvani adding support for Ethernet and Andreas Färber contributing code for the GXBB platform. Since then, support has been added for Meson8, Meson8b, and the 64-bit ARM Meson GXBB, Meson GXL and GXM SoCs and a whole host of hardware. Codenames for the 64-bit SoCs are used in the kernel source and the following table shows how they map to their respective product names:


Codename Product name
GXL S905X, S905D
GXM S912
AXG A111, A112, A113


Here’s How We Helped

Our efforts have mainly been focused on adding support for the 64-bit Meson SoCs. Kevin Hilman generalized the boot and serial console code for the 64-bit AmLogic family of SoCs so that more boards could be supported, starting with the Hardkernel ODROID-C2).

Michael Turquette reworked the Meson SoC clock driver to move to the `platform_driver` API and replaced the dynamic configuration code with statically initialized data. That was in preparation for adding clock driver support for the S905 SoC. We’ve also added S905 AO (Always-On) clock and reset controller drivers and support for PWM, RNG, Watchdog, IR, I2C, SPIFC devices.

Because some of AmLogic SoCs use a legacy version of the System Control and Power Interface (SCPI) protocol (pre-v1.0), we pushed changes to the upstream SCPI driver to support it. The SCPI driver is used for Dynamic Voltage and Frequency Scaling (DVFS) with the CPUFreq subsystem to dynamically alter the processor’s speed.

We’ve added a driver for the AmLogic SPI Communication Controller (SPICC) that’s capable of full-duplex transfers up to 30MHz. And in v4.10 Kevin added a brand new SD/eMMC driver that supports the host controller found on the AmLogic S905/GX* family of SoCs.

Neil wrote the AmLogic Meson DRM driver and has added HDMI support since his last update during his talk at Embedded Linux Conference 2017.

As the following graph shows, the number of Meson patches merged into the kernel has risen steadily over the last few kernel releases, and Baylibre is responsible for hundreds of them.

AmLogic kernel commits and BayLibre contributions
And because of our knowledge of the Meson code, we’ve had the honour of becoming (co-)maintainers for the majority of it.

  • Meson SoC code (Kevin Hilman)
  • DRM display driver (Neil Armstrong)
  • AO-CEC driver (Neil Armstrong)
  • Meson SoC clock framework (Neil Armstrong and Jerome Brunet)

As the number of supported boards has grown, it’s become increasingly important to maintain quality across all devices. For that, we’ve leaned heavily on Baylibre is a founding member of kCI and you can expect more details in an upcoming blog post. has been extremely useful for our AmLogic work. Part of our lab is made up of 8 AmLogic Meson boards which we use to check for regressions across 6 kernel trees. The infrastructure recently caught a kernel regression in the SCPI code which resulted in CPUFreq failures on boot. Thanks to and our collection of Meson boards, we were able to get the offending patch reverted before the final v4.15 release.


Links to Community Resources

AmLogic Meson support has come a long way in the last two years. That progress has been possible thanks to the supportive Linux Meson community and the kernel hackers (shout out to Martin Blumenstringl for his contributions as well as Carlo Caione and Andreas Färber for their early work and ongoing reviews) helping to improve the upstream AmLogic code. There’s lots more to come and we are currently working on support for the new AXG SoC (including audio) which is targeted at the smart speaker market.

If you want to know more about Linux Meson development you can subscribe to the linux-amlogic mailing list or join the #linux-amlogic IRC channel on Also, the Linux Meson wiki is updated as support for new devices and SoCs lands in mainline Linux.


Post header image by Hardkernel –, CC BY-SA 3.0, Link

U-Boot v2018.01 released, our contributions

BayLibre has continued contribution to the open-source community as seen with this new version of U-Boot v2018.01, released on 9 Jan 2018.

Here is a summary of our contributions:

Amlogic SoC family:

Add support for the Meson GXL Family by :

  • Adding pinctrl support, based on excellent work of Beniamino Galvani
  • Adding Internal PHY Support + fixups for reliability
  • Add support for dynamic reserved memory
  • Adding support for S905X Based boards :
    • P212 reference board
    • Khadas VIM
    • LibreTech-CC
  • Neil Armstrong becomes maintainer of these freshly added boards

This version of U-Boot for Amlogic GXL SoCs will need to wait for Linux 4.16 to be released, or is compatible with the LibreTech-cc 4.14 stable linux tree for the LibreTech-CC board.

Khadas has released an image with this version of U-Boot and Linux Mainline for the Khadas VIM board here.

Misc :

  • fat: Use cache aligned buffers for fat_opendir