Linux 6.6 released, Bootlin contributions

Linux 6.6 was released yesterday, so this is the time for our usual blog post about our contributions to this release. Before that, to get an overall idea of what went into Linux 6.6, we recommend reading the articles from LWN.net covering the Linux 6.6 merge window: part 1 and part 2. The KernelNewbies page is perhaps a little bit less rich than it used to be, but still relevant.

On our side, this time around we contributed 68 changes to this release:

  • Alexandre Belloni, as the RTC subsystem maintainer, submitted a few asorted patches touching various drivers in this subsystem
  • Alexis Lothoré pushed some patches extending the rzn1-a5psw Ethernet switch driver with VLAN support and port_bridge_flags support. These patches were initially written by Clément Léger but had not been accepted until now.
  • Hervé Codina got his audio-iio-aux driver merged, which allows the ASoC subsystem (for audio devices) to use IIO devices, such as a potentiometer. This came together with a number of fixes/improvements in the IIO subsystem. Hervé also fixed some reference counting issues in several I2C mux drivers.
  • Miquèl Raynal pushed to the finish line a patch written several years ago by Bootlin engineer Kamel Bouhara, who hadn’t been accepted until now. This patch adds a sysfs interface that allows to retrieve the reset reason on Microchip ARM platforms
  • Luca Ceresoli fixed some issues in two DRM panel drivers and also fixed a regression in the NVidia Tegra camera interface driver
  • Miquèl Raynal did a number of different, unrelated, contributions:
    • support for the EDT ET028013DMA display panel to the existing sitronix-st7789v driver, which required quite a few preparation changes
    • fix a clock polarity issue in the DRM driver for the display controller used in Microchip ARM platforms
    • improve many small aspects of the qcom NAND controller driver
    • improve the handling of nvmem layouts in the nvmem subsystem
    • fix an issue in the SJA1000 CAN controller driver that would cause the HW to stall after an overrun on some platforms
  • Paul Kocialkowski contributed a few small asorted fixes in the media subsystem documentation

Here are the complete details of our contributions:

Bootlin collaborates with DENT to upstream ONIE NVMEM support in Linux

DENT project logoThe DENT project is a project from the Linux Foundation which aims at utilizing the Linux Kernel, Switchdev, and other Linux based projects as the basis for building a new standardized network operating system without abstractions or overhead.

Recently, Bootlin collaborated with the DENT project to work on a specific topic: extending the Linux kernel NVMEM subsystem to be able to support the ONIE TLV storage format which is used on ONIE-compliant network equipment to store in an EEPROM various information about the device: serial number, model, MAC addresses, and more.

This work, lead by Bootlin engineer Miquèl Raynal has now landed in Linux 6.4 as the drivers/nvmem/layouts/onie-tlv.c driver, together with the underlying new NVMEM layout infrastructure, which Miquèl helped to upstream in collaboration with Michael Walle.

We have written and published a longer blog post on the DENT website to explain the motivation for this effort and the results.

Linux 6.4 released, Bootlin contributions inside

Linux 6.4 was released on June 25, just before the start of the Embedded Open Source Summit in Prague. As usual, lots of changes in Linux 6.4, and we recommend reading LWN coverage of the merge window (part 1, part 2). Sadly, the usual KernelNewbies page hasn’t received a lot of attention, contributions are probably welcome to revive this useful resource.

With 59 commits from Bootlin engineers, Bootlin is ranked as the #28 contributing company by number of commits for this 6.4 release, according to contribution statistics. Our main contributions have been:

  • Alexis Lothoré and Clément Léger contributed a few fixes to the Renesas RZ/N1 A5PSW Ethernet switch driver
  • Hervé Codina contributed a number of new drivers needed to support complex audio setups on some relatively old Freescale PowerPC 32-bit platforms: a driver for the Time Slot Assigner (TSA), a driver for the QUICC Multichannel Controller (QMC), and an ALSA driver that provides audio support over QMC. We have more contributions coming in this area, most notably to support HDLC network traffic over QMC.
  • Kamel Bouhara added support for the TI TAS5733 audio codec in the existing tas571x driver
  • Luca Ceresoli improved the fsl-ldb driver, used on NXP i.MX8MP and i.MX93 for the built-in DPI-to-LVDS encoder. Luca’s improvement allows to use LVDS channel 1 only, while the driver initially supported using either LVDS channel 0, or LVDS channel 0 and 1 combined.
  • Maxime Chevallier contributed an improvement to the regmap code, which allows upshifting register addresses before performing operations
  • Maxime Chevallier also contributed some small fixes to the phylink code related to previous work on QUSGMII support
  • Miquèl Raynal contributed the support for Real-While-Write in the MTD SPI-NOR subsystem. This allows to perform read operations while erase/program operations are on-going, which helps to reduce read latencies. This of course only works on SPI NOR chips that support this feature.
  • Miquèl Raynal contributed several improvements to the NVMEM subsystem. First, a brand new NVMEM driver capable of parsing the ONIE TLV information, as defined by the ONIE spec used on network equipment. Second, he contributed changes that allow NVMEM layout drivers to be compiled as kernel modules rather than being built-in

And the full details of our contributions:

Linux 6.2 released, Bootlin contributions inside

Linux 6.2 was released a few days ago, and as usual we point our readers to the LWN coverage of the merge window (part 1 and part 2), or the traditional KernelNewbies page or alternatively the embedded focused CNX Software coverage.

At Bootlin, we contributed a total of 122 patches to this release, making Bootlin the 21st contributing company by number of commits according to statistics. Also Bootlin engineer Paul Kocialkowski appears in the top developers by changed lines in the Linux 6.2 statistics.

Continue reading “Linux 6.2 released, Bootlin contributions inside”

Updated Buildroot support for STM32MP1 platforms, ST BSP v4.1

Back in December 2021, we announced the buildroot-external-st project, which is an extension of the Buildroot build system with ready-to-use configurations for the STMicroelectronics STM32MP1 platforms. Later on, in July 2022, we updated it to the lastest Buildroot LTS 2022.02 and version 4.0 of ST BSP version.

More specifically, this project is a BR2_EXTERNAL repository for Buildroot, with a number of defconfigs that allow to quickly build embedded Linux systems for the STM32MP1 Discovery Kit platforms. It’s a great way to get started with Buildroot on those platforms.

Today, we are happy to announce an updated version of this project, published under the branch st/2022.02.7 at https://github.com/bootlin/buildroot-external-st. This new version brings the following changes:

Continue reading “Updated Buildroot support for STM32MP1 platforms, ST BSP v4.1”

Linux 6.1 released, Bootlin contributions

Linux 6.1 has been released yesterday, a week later than expected. Head over to LWN (part 1, part 2) or KernelNewbies for an overview of the major features merged in this release.

For this release, Bootlin contributed a total of 38 patches, with the following highlights:

  • Maxime Chevallier added initial support for the QUSGMII PHY mode, together with supporting code in the lan966x MAC driver and lan966x PHY driver.
  • Maxime Chevallier added a new PCS driver for the Altera PSE
  • Maxime Chevallier converted the Altera TSE MAC driver to phylink
  • Paul Kocialkowski contributed many improvements to the Allwinner sun6i camera interface driver, which are preparation commits to introduce support for interacting with the Allwinner ISP

Continue reading “Linux 6.1 released, Bootlin contributions”

Linux 6.0 released, Bootlin contributions

Linux 6.0 has been released two weeks ago, and Linux 6.1-rc1 is already out of the door, but we didn’t get the chance to look at the contributions made by Bootlin to the Linux 6.0 release. Before we do that, let’s provide our usual must-read articles on Linux 6.0: the Linux 6.0 merge window part 1 and Linux 6.0 merge window part 2 LWN.net articles and the KernelNewbies.org article.

On Bootlin side, our significant contributions to this release have been:

  • Clément Léger contributed a new driver for the Ethernet switch found in the Renesas RZ/N1 processor, as well as a PCS driver for the MII converter of the same processor. Obviously, this came with the related Device Tree bindings and Device Tree changes, but also with a few small changes in the DSA subsystem.
  • Hervé Codina enabled support for the PCIe controller found in the same Renesas RZ/N1 processor, which in fact does not allow to use PCIe devices, but USB devices: this PCIe controller is only used to connect to an internal USB controller in the chip, which therefore allows to use USB devices.
  • Köry Maincent extended the existing mpc4922 DAC IIO driver to also support the mpc4921 variant, which has only one output channel instead of two.
  • Luca Ceresoli contributed several improvements to the I2C subsystem documentation.
  • Paul Kocialkowski contributed a new DRM driver for the logiCVC-ML display controller IP
  • Paul Kocialkowski contributed two new V4L drivers for the MIPI CSI-2 camera interfaces available in the Allwinner A31 family of processors (sun6i) and the Allwinner A83T family of processors (sun8i).

Here is the full details of our contributions, commit by commit:

A journey in the RTC subsystem

As part of a team effort to improve the upstream Linux kernel support for the Renesas RZ/N1 ARM processor, we had to write from scratch a new RTC driver for this SoC. The RTC subsystem API is rather straightforward but, as most kernel subsystems, the documentation about it is rather sparse. So what are the steps to write a basic RTC driver? Here are some pointers.

The registration

The core expects drivers to allocate, initialize and then register a struct rtc_device with the device managed helpers: devm_rtc_allocate_device() and devm_rtc_register_device(). Between these two function calls, one will be required to provide at least a set of struct rtc_class_ops which contains the various callbacks used to access the device from the core, as well as setting a few information about the device.

The kind of information expected is the support for various features (rtcdev->features bitmap) as well as the maximum continuous time range supported by your RTC. If you do not know the actual date after which your device stops being reliable, you can use the rtc-range test tool from rtc-tools, available at https://git.kernel.org/pub/scm/linux/kernel/git/abelloni/rtc-tools.git (also available as a Buildroot package). It will check the consistency of your driver against a number of common known-to-be-failing situations.

Time handling

The most basic operations to provide are ->read_time() and ->set_time(). Both functions should play with a struct rtc_time which describes time and date with members for the year, month, day of the month, hours (in 24-hour mode), minutes and seconds. The week day member is ignored by userspace and is not expected to be set properly, unless it is actively used by the RTC, for example to set alarms. There are then three popular ways of storing time in the RTC world:

  1. either using the binary values of each of these fields
  2. or using a Binary Coded Decimal (BCD) version of these fields
  3. or, finally, by storing a timestamp in seconds since the epoch

In BCD, each decimal digit is encoded using four bits, eg. the number 12 could either be coded by 0x0C in hexadecimal, or 0x12 in BCD, which is easier to read with a human eye.

The three representations are absolutely equivalent and you are free to convert the time from one system to another when needed:

  • #1 <-> #2 conversions are done with bcd2bin() and bin2bcd() (from linux/bcd.h)
  • #1 <-> #3 conversions are done with rtc_time64_to_tm() and rtc_tm_to_time64() (from linux/rtc.h)

While debugging, it is likely that you will end up dumping these time structures. Note that struct rtc_time is aligned on struct tm, this means that the year field is the number of years since 1900 and the month field is the number of months since January, in the range 0 to 11. Anyway, dumping these fields manually is a loss of time, it is advised instead to use the dedicated RTC printk specifiers which will handle the conversion for you: %ptR for a struct rtc_time, %ptT for a time64_t.

Of course, when reading the actual time from multiple registers on the device and filling those fields, be aware that you should handle possible wrapping situations. Either the device has an internal latching mechanism for that (eg. the front-end of the registers that you must read are all frozen upon a specific action) or you need to verify this manually by, for instance, monitoring the seconds register and try another read if it changed between the beginning and the end of the retrieval.

If your device continuous time range ended before 2000 you may want to shift the default hardware range further by providing the start-year device tree property. The core will then shift the Epoch further for you.

Finally, once done, you can verify your implementation by playing with the rtc test tool (also from rtc-tools).

Supporting alarms

One common RTC feature is the ability to trigger alarms at specific times. Of course it’s even better if your RTC can wake-up the system.

If the device or the way it is integrated doesn’t support alarms, this should be advertised at registration time by clearing the relevant bit (RTC_FEATURE_ALARM, RTC_FEATURE_UPDATE_INTERRUPT). In the other situations, it is relevant to indicate whether the RTC has a second, 2-seconds or minute resolution by setting the appropriate flag (RTC_FEATURE_ALARM_RES_2S, RTC_FEATURE_ALARM_RES_MINUTE). Mind when testing that querying an alarm time below this resolution will return a -ETIME error.

When implementing the ->read_alarm(), ->set_alarm() and ->alarm_irq_enable() hooks, be aware that the update and periodic alarms are now implemented in the core, using HR timers rather than with the RTC so you should focus on the regular alarm. The read/set hooks naturally allow to read and change the alarm settings. A struct rtc_wkalrm *alrm is passed as parameter, alrm->time is the struct rtc_time and alrm->enabled the state of the alarm (which must be set in ->set_alarm()). The third hook is an asynchronous way to enable/disable the alarm IRQ.

The interrupt handler for the alarm is required to call rtc_update_irq() to signal the core that an alarm happened, providing the RTC device, the number of alarms reported (usually one), and the RTC_IRQF flag OR’ed with the relevant alarm flag (likely, RTC_AF for the main alarm).

Oscillator offset compensation

RTC counters rely on very precise clock sources to deliver accurate times. To handle the situation where the source is not matching the expected precision, which is the case with most cheap oscillators on the market, some RTCs have a mechanism allowing to compensate for the frequency variation by incrementing or skipping the RTC counters at a regular interval in order to get closer to the reality.

The RTC subsystem offers a set of callbacks, ->read_offset() and a ->set_offset(), where a signed offset is passed in ppb (parts per billion).

As an example, if an oscillator is below its targeted frequency of 32768 Hz and is measured to run at 32767.7 Hz, we need to offset the counter by 1 - (32767.7/32768) = 9155 ppb. If the RTC is capable of offsetting the main counter once every 20s it means that every 20s, this counter (which gets decremented at the frequency of the oscillator to produce the “seconds”) will start at a different value than 32768. Adding 1 to this counter every 20s would basically mean earning 1 / (32768 * 20) = 1526 ppb. Our target being 9155 ppb, we must offset the counter by 9155 / 1526 = 6 every 20s to get a compensated rate of 32767.7 + (6 / 20) = 32768 Hz.

Upstreaming status of the RZ/N1 RTC driver

The RZ/N1 RTC driver has all the features listed above and made its way into the v5.18 Linux kernel release. Hopefully this little reference sheet will encourage others to finalize and send new RTC drivers upstream!

Bootlin at Linux Plumbers conference 2022

Next week, almost the entire Bootlin team will be at the Embedded Linux Conference Europe in Dublin, see our previous blog post on this topic. We will give four talks at this event, on a variety of Linux kernel and embedded Linux topics.

During the same week, also in Dublin albeit in a different location, will take place the Linux Plumbers conference. Bootlin engineer Miquèl Raynal will give a talk at Linux Plumbers, as part of the IoTs a 4-Letter Word micro-conference. Miquèl’s talk will discuss Linux IEEE 802.15.4 MLME improvements, as Miquèl has been working for several months on bringing improvements to the 802.15.4 stack in the Linux kernel.

Linux 5.19 released, Bootlin contributions inside

Linux 5.19 has been released yesterday. We recommend the usual resources of LWN (part 1 and part 2) as well as KernelNewbies to get some high-level overview of the major additions. CNX-Software also has an article focused on the ARM/RISC-V/MIPS improvements.

At Bootlin, we contributed 68 patches to this release, the main highlights being:

  • Clément Léger contributed patches for the Microchip SAMA5 platform to support suspend operation while running in non-secure mode, with OP-TEE handling the necessary PCSI calls. This is related to our work to port OP-TEE on Microchip SAMA5D2, which we have covered in several blog posts before.
  • Hervé Codina contributed device Tree updates to enable the PCI controller of the Renesas RZ/N1 platform, which allows to access the USB host controller that sits on an internal PCI bus. Some driver updates for the PCI driver are needed, and they will land in 5.206.0 kernel.
  • Miquèl Raynal contributed several improvements to the IIO subsystem, following his work on several IIO drivers and his related blog post. These improvements either touch the core IIO, or fix some incorrect API use in IIO drivers.
  • Miquèl Raynal contributed a new driver for the Renesas RZ/N1 DMA router (in drivers/dmaengine) as well as a new driver for the Renesas RZ/N1 Real Time Clock (in drivers/rtc). In addition, Miquèl modified the 8250 UART controller driver to be able to use the DMA capabilities available on the RZ/N1 processor.
  • Miquèl Raynal also contributed a number of improvements to the IEEE 802.15.4 stack in the Linux kernel.
  • Paul Kocialkowski contributed support for MIPI CSI-2 in the Allwinner phy-sun6i-mipi-dphy driver.
  • Paul Kocialkowski and Luca Ceresoli contributed a few misc fixes, touching the SPI core and SPI Rockchip driver and the dmaengine documentation.

The complete details of our contributions are: