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:

 

 

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

Misc:

  • 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

Misc:

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