Dafna Hirschfeld
August 05, 2020
Share this post:
Reading time:
Earlier this week, the Linux 5.8 kernel was released. It is one of the biggest releases of all time, as if developers started to code more during the recent lockdowns across the globe. As usual, you can the find the most important changes for this release in the always great LWN.net articles - part 1 and part 2.
According to Linus himself, the 5.8 release is big. While Collabora modestly contributed to this massive release, Linux 5.8 marks our biggest and most significant contributions yet. Everyone at Collabora has been impressed by the efforts put together by our kernel developers. Working directly upstream, contributing to the Linux kernel has long been a key objective of Collabora as an organization. Over the past decade we have been growing our participation in this essential effort that Linux is.
The ability for a relatively small software consultancy such as Collabora to contribute at this level demonstrates a fantastic improvement in vendors' mindset when it comes to working Open First (hence Collabora's tagline). Providing mainline support out-of-box as early as possible is really becoming a priority for all our customers and we appreciate them all the more for it.
So a big thank you to all our clients for the continued trust they are placing in Collabora. We look forward to continuing to contribute on their behalf of years to come.
Collabora is a very active contributor to Rockchip SoC which is used in devices such as Chromebooks, Laptops, several development boards and other devices. We've been contributing especially with graphics (Mali drivers, Panfrost) and multimedia. Here is the list of contributions to this platform:
AFBC (Arm Frame Buffer Compression) is a hardware feature, available on several ARM SoCs, which reduces memory bandwidth used by compressing buffers sent to the display. This feature is very important for better power usage and allows user-space drivers to perform more efficient rendering by reducing the number of copies of the display buffer. For this version, Andrzej Pietrasiewicz added support for AFBC on Rockchip. See his blog post for detailed explanation.
Continuing our work on codec accelerators, Boris Brezillon contributed a series to upstream the Rockchip Video Decoder driver (rkvdec). Part of this work includes moving the H.264 DPB handling to the core, so it can be reused by other drivers.
This driver supports a Rockchip-specific codec IP block that can be found on Rockchip SoCs such as RK3399, RK3326 and PX30.
For now, only H.264 is supported in the rkvdec driver. Support for H.264 High-10 profile is currently being discussed by the community. In addition, VP9 and HEVC are planned to be added soon.
This accelerator driver implements the newly introduced Memory-to-memory Stateless Video Decoder Interface. Being a new interface, some support from the application side is needed. Nicolas Dufresne has recently added support for this in GStreamer. He recently presented the history of codecs support in the kernel at ELCE 2020.
The RK3399 Camera ISP driver (rkisp1) reached the mainline kernel's staging area in v5.6. With the goal to improve code quality and provide a stable driver for users, a continuing joint effort between Helen Koike and myself (Dafna Hirschfeld) is being made to destage the rkisp1 driver and the correspondent dphy driver phy-rockchip-dphy-rx0. For this kernel release, we moved a number of steps forward and are getting closer to the goal.
Some major patch(set)s:
The driver is already supported by the libcamera project, which enables applications to work on top of a myriad of different devices without worrying about the underlining hardware.
The rkisp1 driver exports an API which allows user space to implement image enhancement algorithms such as 3A. An Open Source implementation was recently added in libcamera for the Raspberry Pi. It will hopefully be made generic in the future, supporting Rockchip devices and several others.
The DRM subsystem provides the means to manage and utilise display outputs (modeset) and rendering devices. To prevent malicious applications from changing a display's resolution, or disabling it all together, the concept of DRM_MASTER exists. This enables a single program to manage which processes are allowed to perform such tasks.
On platforms with systemd, the systemd-logind service is the one with the DRM_MASTER role, orchestrating which processes are allowed to do modeset operations. Yet there are cases where systemd isn't available, or the graphics server (Xorg or a Wayland compositor) cannot make use it for various reasons.
Emil Velikov reworked the SET/DROP_MASTER ioctls, allowing a user space process which has DRM_MASTER privilege to revoke its privilege and regain it easily. Previously, the program had to be run as root or have its setuid bit set (as seen with, Xorg and weston-launch) solely for that purpose. With the patch this artificial requirement has been lifted. Effectively, this makes Xorg work (instead of outright crashing) in a few corner-cases, while allowing distributions to drop the setuid flag from Xorg, weston-launch and others. This improves security by reducing the number of programs running with root privileges.
Linux has long been known for its good support of old hardware, the policy being "if there is still one user caring about a specific hardware, support should not be dropped". This is a great thing for users, but it sometimes gets in the way of subsystems refactoring, leaving maintainers with two choices:
MTD is pretty old, and as a result, carries a lot of history with no less than three different interfaces exposed to drivers. This is the result of repeatedly going for option #1 without ever pushing driver maintainers to convert their drivers to the latest API. This policy has led to a situation where every evolution of the subsystem internals is a painful operation requiring extra care to not break one of the APIs. Sometimes the amount of work is so big that maintainers/developers just give up, thus leaving new features or potential performance improvement for new hardware unimplemented.
During the last release cycle Boris Brezillon tried to address that problem by converting some of these old drivers to the most recent API called exec_op. Given the number of drivers still using the old APIs, we still have a long way to go before things are unified, but any progress, even small, is better than the status-quo we were in.
MediaTek has a family of SoCs that are used in (among other devices) several Chromebooks, such as the MT8173 used in the Lenovo N23 Chromebook and Acer Chromebook R13, plus the MT8183 in the Lenovo IdeaPad Duet Chromebook. We are working hard to have better upstream support for these devices, especially Enric Balletbo, who has been involved in kernel and Chromebook upstream support for a long time. The displays on MT8173 based devices were not functional when using the mainline kernel, this has been rectified with this kernel release.
The cause of this defect was a conflict between the clock and DRM drivers. He found that two different drivers - the MT8173 clocks controller driver, and the MT8173 DRM driver were using the same compatible string mediatek,mt8173-mmsys. This is a problem since in such cases only the first matched driver will be probed. The other one, in this case the DRM driver, never gets probed and so the display was not made available for use. In a collaborative effort between Enric Balletbo and the MediaTek SoC maintainer Matthias Brugger, a top level mmsys driver (Multi-Media subsystem) was introduced to register the clock and DRM drivers. See 1, 2.
Better compression can be achieved with JPEG images when the Huffman tables they contain are optimized specifically for their individual content, however the Coda driver only supported decoding JPEGs which used standard / non-optimized tables. Adrian Ratiu, with the help of Andrzej Pietrasiewicz, added support to the Coda driver for decoding a wider range of JPEG images with optimized Huffman tables. The Chips&Media CODA960 video decoder is most notably used on NXP i.MX 6 series of SoCs.
In a continuation of the work we have been doing for several kernel releases now, as part of the effort to improve the iSCSI driver, Gabriel Krisman Bertazi authored a fix for a deadlock issue that plagued iSCSI drivers in low memory conditions. This bug, which could be triggered by a memory reclaim, stopped the iSCSI daemon from recovering the device and completing the reclaim. This could, in effect, deadlock the system. Gabriel's solution prevents the issue from happening, while hardening the iSCSI driver against several other possible issues that arise from all the iSCSI commands sharing the same execution lock.
Smart Battery System (SBS) is a specification for managing a 'smart battery'. Such batteries can be found on the Novena board, and several Chroombook devices such as Scarlet Chromebooks, veyron-jerry and others. Sebastian Reichel sent a patch set to improve the SBS battery driver. A lot more information (e.g. manufacturer date, max. charge current/voltage requested by battery, ...) from the smart battery controller is now exposed to user space via sysfs and uevents variables 1. It is interesting to mention that the number of uevents variables passed the maximum of 32 defined, and so it had to be updated to 64. Two patches from the series, adding Packet Error and Correction (PEC) support, didn't make it into the release and instead are expected for 5.9.
Kernel developers use the printk function as their primary tool for logging. It is such a fundamental part of the kernel that it deserved some documentation improvements. Ricardo Cañuelo enhanced the documentation of printk and the pr_* macros with this patch.
Supporting Linux distributions such as Debian and its derivatives is one of the many ways Collabora fulfills its mission and helps Open Source end users. Debian's armhf kernel needs to support a variety of different boards so it doesn't use the standard Linux defconfigs. With the Debian's customized defconfig for armhf, the cpufreq failed to probe on i.MX 6 boards. A set of patches were developed to Linux mainline and Linux Debian, the first of them, authored by Walter Lozano is already included in this release.
While working with several Open Source projects, very often our Engineers stumble upon minor issues or things worthy improving such as documentation or cleanups.
We try to contribute upstream on a continuous basis. For 5.8 we had various contributions to areas including fixes to the V4L2 core, Device Mapping, I3C, power, clocks , MTD, ASoC and more.
We enjoy and take great pride in being an active part of the community, helping and improving the projects we use. This also includes providing help with reviewing and testing patches from other community members.
Adrian Ratiu:
Andrzej Pietrasiewicz:
André Almeida:
Boris Brezillon:
Dafna Hirschfeld:
Emil Velikov:
Enric Balletbo i Serra:
Ezequiel Garcia:
Gabriel Krisman Bertazi:
Guillaume Tucker:
Helen Koike:
Ricardo Cañuelo:
Sebastian Reichel:
Walter Lozano:
Boris Brezillon:
Enric Balletbo i Serra:
Sebastian Reichel:
Enric Balletbo i Serra:
Gabriel Krisman Bertazi:
Helen Koike:
Sebastian Reichel:
Andy Shevchenko:
ChenTao:
Christophe JAILLET:
Dan Carpenter:
Dan Murphy:
Hongbo Yao:
Jason Yan:
Jean-Francois Dagenais:
Kejia Hu:
Khazhismel Kumykov:
Mathew King:
Matthias Brugger:
Matti Vaittinen:
Michał Mirosław:
Niklas Söderlund:
Qiushi Wu:
Rafael Gandolfi:
Samuel Zou:
Sebastian Reichel:
Serge Semin:
Tang Bin:
Tobias Schramm:
Boris Brezillon:
Daniel Stone:
Emil Velikov:
Enric Balletbo i Serra:
Ezequiel Garcia:
Helen Koike:
Sebastian Reichel:
Andrzej Pietrasiewicz:
Helen Koike:
Enric Balletbo i Serra:
Nicolas Dufresne:
Sebastian Reichel:
Gabriel Krisman Bertazi:
Nicolas Dufresne:
17/04/2024
Monado, the cross-platform open source XR runtime, has recently received significant updates to align with the features and specifications…
11/04/2024
Adhering to the fundamentals of open source, the Atari VCS OS is based on Debian using the Apertis infrastructure, and the graphics rely…
10/04/2024
Using TensorFlow Lite models optimized for the STM3MP2 NPU along with an upstream-ready H.264 encoder (Video4Linux2), this demo showcases…
Whether writing a line of code or shaping a longer-term strategic software development plan, we'll help you navigate the ever-evolving world of Open Source.
한국어 버전의 Collabora.com 보기
Acesse Collabora.com em Português
Comments (7)
Salvador:
Aug 28, 2020 at 12:45 AM
Congrats!!!
Reply to this comment
Reply to this comment
Colin Williams:
Jun 25, 2021 at 08:30 PM
Any way the enthusiast community might get some more information on deploying a custom kernel or OS on the chromebook duet?
Reply to this comment
Reply to this comment
Enric Balletbò i Serra:
Jun 30, 2021 at 04:51 PM
We have a developer tool that can help you to create a bootable media and boot a Debian distribution on the Lenovo IdeaPad Duet. The problem with the IdeaPad Duet is that display is not working yet with a bare kernel mainline version, so after just creating the image and boot it, you will be able only to log via serial port or ssh. To get display working you should add some patches that are not upstream yet, but they can be found in the following branch:
- https://gitlab.collabora.com/eballetbo/linux/-/commits/topic/chromeos/somewhat-stable-5.13
And the tool to create a bootable image can be found here:
- https://gitlab.collabora.com/eballetbo/chromebooks
Reply to this comment
Reply to this comment
Colin Williams:
Jul 09, 2021 at 12:00 PM
Thanks for sharing. I looked to see if there were other interested parties in building linux against the duet via reddit. https://www.reddit.com/r/LenovoDuet/comments/ogseys/anyone_interested_in_collaborating_to_document/
Perhaps I will try to build a patched kernel today. It looks like 5.13 has been released, then I assume I can patch against the release kernel. Is there any easy way to track the features against mainline to mitigate patching? Would it be of any value to start building against 5.14?
Reply to this comment
Reply to this comment
Colin Williams:
Aug 20, 2021 at 11:05 PM
I have had luck deploying the chromeOS 5.14 kernel. Thanks for sharing!
Reply to this comment
Reply to this comment
Colin Williams:
Aug 22, 2021 at 10:40 PM
I dropped your ChromeOS kernel 5.14 on top of Cadmium in this branch also adding an ArchLinuxARM root FS. I'm excited to be running GNOME 40 on the device. I'm curious regarding testing video acceleration. I see
```
[ 9476.006401] remoteproc remoteproc0: request_firmware failed: -2
[ 9476.006406] [MTK_V4L2][ERROR] fops_vcodec_open:184: vpu_load_firmware failed!
[ 9481.005543] remoteproc remoteproc0: powering up scp
[ 9481.005599] remoteproc remoteproc0: Direct firmware load for scp.img failed with error -2
[ 9481.005609] remoteproc remoteproc0: request_firmware failed: -2
[ 9481.005617] [MTK_V4L2][ERROR] fops_vcodec_open:134: failed to load firmware!
[ 9481.005670] remoteproc remoteproc0: powering up scp
[ 9481.005693] remoteproc remoteproc0: Direct firmware load for scp.img failed with error -2
[ 9481.005699] remoteproc remoteproc0: request_firmware failed: -2
```
in the logs. Then I assume I need to do something to load the firmware.
https://github.com/drocsid/Cadmium/tree/feature/ArchOnCollaboraKernelGNOME40
Reply to this comment
Reply to this comment
Dafna Hirschfeld:
Aug 23, 2021 at 02:46 PM
Hi, It seems that you don't have the firmware files.
You can get them from: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git under mediatek/mt8173 or mediatek/mt8183.
The files should reside in /lib/firmware in the FS.
Reply to this comment
Reply to this comment
Add a Comment