Linux Kernel v5.3 released, our contributions

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

If you check out LWN.net’s 5.3 Kernel development cycle statistics article, you’ll see that BayLibre made it onto the top 20 contributors list, showing that we were one of the most active companies (when measured by changes) this development cycle.

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

AmLogic SoCs

This release we contributed heavily to Amlogic Meson SoCs mainline support with lots of work from Neil Armstrong, Jerome Brunet, and Maxime Jourdan for the G12A (S905X2/S905D2) and G12B SoCs including:

  • Initial support for new G12B Soc family 
  • Enabling the IR controller on the SEI510, u200, and X96 Max boards
  • Fixups for the AXG TDM formatter driver
  • Adding support for dynamic OTG switching with the ID change interrupt
  • Enabling the sound card on the Hardkernel Odroid-N2
  • Increasing the Bluetooth bus speed to 2Mbaud/s
  • Enabling the WiFi SDIO module
  • Adding gigabit ethernet support for the X96 Max board
  • Enabling the hwrng module for the next generation SM1 SoC family
  • Enabling SD and eMMC on the g12a u200 board
  • A V4L2 m2m video decoder driver
  • Support for the XBGR8888 and ABGR8888 formats to the graphics controller

GPIO subsystem

Bartosz Golaszewski contributed changes for the GPIO subsystem including:

  • Fixes for warnings when the gpiolib is disabled
  • A fix for a use-after-free bug 
  • Various other cleanups and fixes

RISC-V

With the continued interest and adoption of RISC-V, we wanted an easy way to build an upstream kernel for the SiFive Unleashed board. Loys Ollivier submitted a patch that enables support in the default RISC-V kernel config.

DaVinci SoC

We’ve talked about updating the existing TI DaVinci SoC timer driver in the past, and this release Bartosz Golaszewski implemented a much simpler — and more modern — version with clockevents and clocksource support. He also enabled cpufreq support.

Misc

Beyond the above, we’ve also contributed patches to various subsystems and drivers.

  • Jerome Brunet contributed miscellaneous fixes and cleanups for the ASoC subsystem
  • Fabien Parent added AUDSYS clock support for MediaTek’s MT8516 SoC
  • Neil Armstorng enabled the Lima driver (ARM Mali 400/450 GPU) for arm64 and ARMv7 boards because it will be useful for KernelCI boot and runtime testing. 
  • Bartosz Golaszewski contributed cleanup patches for the at24 EEPROM driver and a new selector stepping option for voltage regulators.

BayLibre Linux 5.3 contributions

When 32 bits isn’t enough — Porting Zephyr to RISCV64

Conventional wisdom says you should normally apply small microcontrollers to dedicated applications with constrained resources. 8-bit microcontrollers with a few kilobytes of memory are still plentiful today. 32-bit microcontrollers with a couple of dozen kilobytes of memory are also very popular. In the latter case, it is typical to rely on a small RTOS to provide basic software interfaces and services.

The Zephyr Project provides such an RTOS. Many ARM-based microcontrollers are supported, but other architectures including ARC, XTENSA, RISC-V (32-bit) and X86 (32-bit) are also supported.

Yet some people are designing products with computing needs that are simple enough to be fulfilled by a small RTOS like Zephyr, but with memory addressing needs that cannot be described by kilobytes or megabytes, but that actually require gigabytes! So it was quite a surprise when BayLibre was asked to port Zephyr to the 64-bit RISC-V architecture.

Where to start

The 64-bit port required a lot of cleanups. Initially, we were far from concerned by the actual RISCV64 support. Zephyr supports a virtual “board” configuration faking basic hardware on one side and interfacing with a POSIX environment on the other side which allows for compiling a Zephyr application into a standard Linux process. This has enormous benefits such as the ability to use native Linux development tools. For example, it allows you to use gdb to look at core dumps without fiddling with a remote debugging setup or emulators such as QEMU.

Until this point, this “POSIX” architecture only created 32-bit executables. We started by only testing the generic Zephyr code in 64-bit mode. It was only a matter of flipping some compiler arguments to attempt a 64-bit build. But unsurprisingly, it failed.

The 32-bit legacy

Since its inception, the Zephyr RTOS targeted 32-bit architectures. The assumption that everything can be represented by an int32_t variable was everywhere. Code patterns like the following were ubiquitous:

static inline void mbox_async_free(struct k_mbox_async *async)
{
        k_stack_push(&async_msg_free, (u32_t)async);
}

Here the async pointer gets truncated on a 64-bit build. Fortunately, the compiler does flag those occurrences:

In function ‘mbox_async_free’:
warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
k_stack_push(&async_msg_free, (u32_t)async);
^

Therefore the actual work started with a simple task: converting all u32_t variables and parameters that may carry pointers into uintptr_t. After several days of work, the Hello_world demo application could finally be built successfully. Yay!

But attempting to execute it resulted in a segmentation fault. The investigation phase began.

Chasing bugs

While the compiler could identify bad u32_t usage when a cast to or from a pointer was involved, some other cases could be found only by manual code inspection. Still, Zephyr is a significant body of code to review and catching all issues, especially the subtle ones, couldn’t happen without some code execution tracing in gdb.

A much more complicated issue involved linked list pointers that ended up referring to non-existent list nodes for no obvious reason, and the bug only occurred after another item was removed from the list. This issue was only noticeable with a subsequent list search that followed the rogue pointer into Lalaland. And it didn’t trigger every time.

The header file for list operations starts with this:

#ifdef __LP64__
typedef u64_t unative_t;
#else
typedef u32_t unative_t;
#endif

So one would quickly presume that the code is already 64-bit ready. From a quick glance, it does use unative_t everywhere. What is easily missed is this:

#define SYS_SFLIST_FLAGS_MASK 0x3U

static inline sys_sfnode_t *z_sfnode_next_peek(sys_sfnode_t *node)
{
        return (sys_sfnode_t *)(node->next_and_flags & ~SYS_SFLIST_FLAGS_MASK);
}

Here we return the next pointer after masking out the bottom 2 flag bits. But 0x3U is interpreted by the compiler as an unsigned int and therefore a 32-bit value, meaning that ~0x3U is equal to 0xFFFFFFFC. Because node->next_and_flags is an u64_t, our (unsigned) 0xFFFFFFFC is promoted to 0x00000000FFFFFFFC, effectively truncating the returned pointer to its 32 bottom bits. So everything worked when the next node in the list was allocated in heap memory which is typically below the 4GB mark, but not for nodes allocated on the stack which is typically located towards the top of the address space on Linux.

The fix? Turning 0x3U into 0x3UL. The addition of that single character required many hours of debugging, and this is only one example. Other equally difficult bugs were also found.

The unsuspecting C library

One major change with most 64-bit targets is the width of pointers, but another issue is the change in width of long integer variables. This means that the printf() family of functions have to behave differently when the “l” conversion modifier is provided, as in “%ld”. On a 32-bit only target, all the printf() modifiers can be ignored as they all refer to a 32-bit integer (except for “%lld” but that isn’t supported by Zephyr). For 64-bit, this shortcut can no longer be used.

Alignment considerations are different too. For example, memory allocators must return pointers that are naturally aligned to 64-bit boundaries on 64-bit targets which has implications for the actual allocator design. The memcpy() implementation can exploit larger memory words to optimize data transfer but a larger align is necessary. Structure unions may need adjustments to remain space efficient in the presence of wider pointers and longs.

Test, test and test

One great thing about Zephyr is its extensive test suite. Once all the above was dealt with, it was time to find out if the test suite was happy. And of course it wasn’t. In fact, the majority of the tests failed. At least the Hello_world demo application worked at that point.

Writing good tests is difficult. The goal is to exercise code paths that ought to work, but it is even better when tests try to simulate normal failure conditions to make sure the core code returns with proper error codes. That often requires some programming trickery (read: type casting) within test code that is less portable than regular application code. This means that many tests had to be fixed to be compatible with a 64-bit build. And when core code bugs only affecting 64-bit builds were found, fixing them typically improved results in large portions of the tests all at once.

OK, but where does RV64 fit in this story?

We wrote the RV64 support at the very end of this project. In fact, it represented less than 10% of the whole development effort. Once Zephyr reached 64-bit maturity, it was quite easy to abstract register save/restore and pointer accesses in the assembly code to support RV64 within the existing RV32 code thanks to RISC-V’s highly symmetric architecture. Testing was also easy with QEMU since it can be instructed to use either an RV32 or an RV64 core with the same machine model.

Taking full advantage of 64-bit RISC-V cores on Zephyr may require additional work depending on the actual target where it would be deployed. For example, Zephyr doesn’t support hardware floating point context switching or SMP with either 32-bit or 64-bit RISC-V flavors yet.

But the groundwork is now done and merged into the mainline Zephyr project repository. Our RV64 port makes Zephyr RTOS 2.0.0 a milestone release — it’s the first Zephyr version to support both 32-bit and 64-bit architectures.

Linux Kernel 5.0 released, our contributions

BayLibre has continued our contribution to the Linux community as seen with this new version of Linux Kernel 5.0, released on Sunday, March 3rd 2019.  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:

  • new board: S805X-based “La Frite” from Libre Computer
  • audio: support S/PDIF input on AXG SoC family
  • audio: enable sound modules for S400 board
  • clocks: added new clock measure driver
  • display: support HDMI 1.4 4K modes

Ti DaVinci SoC Family:

  • fix label names in GPIO lookup entries
  • use nvmem to lookup MAC address

Misc:

  • Corentin Labbe: several fixes and cleanups in the crypto subsystem
  • Carlo Caione: fix boot from eMMC on i.MX8MQ
  • Bartosz Golaszewski: nexted IRQ fixes in GPIO subsystem

U-Boot v2019.01 released, our contributions

BayLibre has continued contribution to the open-source community as seen with this new version of U-Boot v2019.01, released on 14th January 2019.

This release introduces a big rework for Amlogic Meson SoC support in order to:

  • Add support for the new AXG platform and ease support for G12A/G12B platforms
  • Ease support for new boards based on Amlogic Reference Design

Starting with this release, Neil Armstrong now maintains the Amlogic SoC support with an U-Boot Custodian tree, similar to a kernel.org maintainer tree, now collecting patches for the Amlogic SoC support (board, arch, clock, pinctrl, …) and sending pull-requests to Tom Rini, the U-Boot maintainer.

Since U-Boot v2017.11, BayLibre engineers have pushed:

  • 75 patches
  • 14804 line changes
  • 292 files changes

Here is a summary of our contributions for this release:

Amlogic SoC family:

  • Add boot device mode, usable with pyamlboot
  • Add support for AXG family
    • pinctrl
    • dts
    • clock
    • network
    • mmc
  • Rework GX support by:
    • moving all P212 boards variants under the P212 board code
    • moving Khadas VIM2 support under the Q200 board code
    • moving Nanopi-K2 support under the Odroid-C2 board code
  • Add SPIFC flash controller for the upcoming “La Frite” board
  • Add VPU Power domain and VPU clocks support for upcoming video support

 

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