added more benchmarks

added linear-algebra benchmarks
Merge branch 'gpgpu' into gpgpu-bench
2026-01-22 13:02:56 +01:00 · 2022-08-26 17:02:32 +02:00 · 2022-08-22 12:23:33 +02:00 · 2022-08-05 13:08:25 +02:00 · 2022-08-05 13:05:28 +02:00 · 2022-08-03 17:35:40 +02:00
1381 changed files with 68391 additions and 30280 deletions
--- a/.gitmodules
+++ b/.gitmodules
@@ -0,0 +1,3 @@
+[submodule "repos/dde_uos-intel-gpgpu/src/uos-intel-gpgpu"]
+	path = repos/dde_uos-intel-gpgpu/src/uos-intel-gpgpu
+	url = https://ess.cs.uos.de/git/software/uos-intel-gpgpu.git
--- a/15
+++ b/15
@@ -13,8 +13,8 @@ the project's official website:
  [https://genode.org/documentation/general-overview]

 The current implementation can be compiled for 8 different kernels: Linux,
-L4ka::Pistachio, L4/Fiasco, OKL4, NOVA, Fiasco.OC, seL4, and a custom
-kernel for running Genode directly on ARM-based hardware. Whereas the Linux
+L4ka::Pistachio, L4/Fiasco, OKL4, NOVA, Fiasco.OC, seL4, and a custom "hw"
+microkernel for running Genode without a 3rd-party kernel. Whereas the Linux
 version serves us as development vehicle and enables us to rapidly develop the
 generic parts of the system, the actual target platforms of the framework are
 microkernels. There is no "perfect" microkernel - and neither should there be
@@ -85,6 +85,17 @@ The source tree is composed of the following subdirectories:
  keys and download locations of software providers.


+Additional hardware support
+###########################
+
+The framework supports a variety of hardware platforms such as different ARM
+SoC families via supplemental repositories.
+
+:Repositories maintained by Genode Labs:
+
+  [https://github.com/orgs/genodelabs/repositories]
+
+
 Additional community-maintained components
 ##########################################

--- a/2
+++ b/2
@@ -1 +1 @@
-22.02
+22.05
--- a/doc/components.txt
+++ b/doc/components.txt
@@ -66,7 +66,13 @@ Device drivers

 Device drivers usually reside in the _src/drivers/_ subdirectory of source-code
 repositories. The most predominant repositories hosting device drivers are
-'os', 'dde_ipxe', 'dde_linux'.
+'os', 'dde_ipxe', 'dde_linux', 'pc'. The main source tree is accompanied
+by a variety of optional source-code repositories, each hosting the support of
+a different SoC family such as NXP's i.MX, Allwinner, Xilinx Zynq, or RISC-V.
+
+:Repositories maintained by Genode Labs:
+
+  [https://github.com/orgs/genodelabs/repositories]


 Platform devices
@@ -138,12 +144,6 @@ capture-session and event-session interfaces respectively.
 :_os/src/drivers/framebuffer/pl11x/_:
  Driver for the PL110/PL111 LCD display.

-:_os/src/drivers/framebuffer/imx53/_:
-  Driver for LCD output on i.MX53 SoCs.
-
-:_os/src/drivers/framebuffer/rpi/_:
-  Driver for the HDMI output of the Raspberry Pi.
-
 :_os/src/drivers/framebuffer/sdl/_:
  Serves as both framebuffer and input driver on Linux using libSDL. This
  driver is only usable on the Linux base platform.
@@ -151,11 +151,11 @@ capture-session and event-session interfaces respectively.
 :_os/src/drivers/gpu/intel/_:
  An experimental Intel Graphics GPU multiplexer for Broadwell and newer.

-:_dde_linux/src/drivers/framebuffer/intel/_:
+:_pc/src/drivers/framebuffer/intel/_:
  Framebuffer driver for Intel i915 compatible graphic cards based on
  the Linux Intel KMS driver.

-:_dde_linux/src/drivers/usb_host/_:
+:_pc/src/drivers/usb_host/_:
  USB host-controller driver that provides an USB session interface to
  USB drivers.

@@ -205,17 +205,14 @@ Block drivers
 All block drivers implement the block-session interface defined at
 _os/include/block_session/_.

-:_os/src/drivers/sd_card/spec/pl180/_:
+:_os/src/drivers/sd_card/pl180/_:
  Driver for SD-cards connected via the PL180 device as found on the PBX-A9
  platform.

-:_os/src/drivers/sd_card/spec/imx53/_:
+:_os/src/drivers/sd_card/imx53/_:
  Driver for SD-cards connected to the Freescale i.MX53 platform like the
  Quick Start Board or the USB armory device.

-:_os/src/drivers/sd_card/spec/rpi/_:
-  Driver for SD-cards connected to the Raspberry Pi.
-
 :_os/src/drivers/ahci/_:
  Driver for SATA disks and CD-ROMs on x86 PCs.

@@ -237,7 +234,7 @@ defined at _os/include/nic_session/_.
  Driver that uses a Linux tap device as back end. It is only useful on the
  Linux base platform.

-:_os/src/drivers/nic/spec/lan9118/_:
+:_os/src/drivers/nic/lan9118/_:
  Native device driver for the LAN9118 network adaptor as featured on the
  PBX-A9 platform.

@@ -245,8 +242,8 @@ defined at _os/include/nic_session/_.
  Device drivers ported from the iPXE project. Supported devices are Intel
  E1000 and pcnet32.

-:_dde_linux/src/drivers/wifi/_:
-  The wifi_drv component is a port of the Linux mac802.11 stack, including the
+:_pc/src/drivers/wifi/_:
+  The wifi driver component is a port of the Linux mac802.11 stack, including the
  iwlwifi driver. It enables the use of Intel Wireless 6xxx and 7xxx cards.

 :_dde_linux/src/drivers/usb_net/_:
@@ -256,16 +253,6 @@ defined at _os/include/nic_session/_.
  Driver for ethernet NICs of the i.MX SoC family.


-General-purpose I/O drivers
-===========================
-
-:_os/src/drivers/gpio/spec/imx53/_:
-  Driver for accessing the GPIO pins of i.MX53 platforms.
-
-:_os/src/drivers/gpio/spec/rpi/_:
-  Driver for accessing the GPIO pins of Raspberry Pi platforms.
-
-
 Resource multiplexers
 #####################

@@ -431,6 +418,9 @@ Separate components
 :_os/src/server/black_hole/_:
  Mockup implementation of Genode session interfaces.

+:_dde_linux/src/app/wireguard/_:
+  Port of the Linux implementation of the WireGuard VPN as Genode component.
+

 VFS plugins
 ===========
@@ -473,6 +463,9 @@ components that use the Genode's VFS library directly.
 :_libports/src/lib/vfs/fatfs/_:
  A VFS plugin that allows for the mounting of FAT-formatted block devices.

+:_os/src/lib/vfs/tap/_:
+  A VFS plugin for the interaction with raw network packets.
+
 :_dde_rump/src/lib/vfs/rump/_:
  A VFS plugin that enables the use of NetBSD's file-system drivers such
  as ext2 or msdos.
--- a/doc/news.txt
+++ b/doc/news.txt
@@ -4,13 +4,141 @@
                               ===========


+Genode OS Framework release 22.05 | 2022-05-31
+##############################################
+
+| The highlights of Genode 22.05 are the new support for WireGuard virtual
+| private networks and a fresh lineup of PC device drivers. Further topics are
+| basic telephony with the PinePhone and dynamic device management on Xilinx
+| Zynq.
+
+Version 22.05 closely adheres the goals as set forth in our
+[https://genode.org/about/road-map - roadmap].
+In particular, the envisioned support of WireGuard VPNs came to fruition
+in the form of a dedicated VPN component based on the Linux implementation of
+the WireGuard protocol. Thanks to this component, the network access of Genode
+systems like [https://genode.org/download/sculpt - Sculpt OS] can now be
+protected using state-of-the-art VPN security.
+
+The second prominent topic is the new lineup of PC device drivers, which had
+been developed using Genode's novel Linux device-driver environment that
+allows the reuse of Linux kernel subsystems as individually sandboxed Genode
+components. The work comprises complex drivers like the wireless LAN stack
+including Intel's Wifi driver and the latest Intel display driver. The
+revamped drivers not only bring the modern feature set of the respective Linux
+5.14.21 subsystems to Genode, but they also validate the efficiency of the new
+porting approach.
+
+The vision of a Genode-based smartphone appears as a recurring topic throughout
+the year, with the current release not being an exception. Three achievements
+stand out. First, Genode gained the principle ability to issue and receive
+voice calls with the PinePhone. Second, in anticipation of sophisticated
+energy-management, the release introduces a Genode-specific custom firmware
+for the PinePhone's system-control processor. And third, it is accompanied
+with the second revision of the
+[https://genode.org/documentation/genode-platforms-22-05.pdf - Genode Platforms]
+document that covers the porting process of Genode to a mobile platform in a
+tutorial of over 200 pages.
+
+Besides those prominent topics, the release comes with numerous framework
+improvements, reaching from a forthcoming new PC platform driver, over
+performance optimizations and usability refinements, to dynamic device
+management on FPGA-based Xilinx Zynq devices.
+
+Discover these and more topics of the new version in the official
+[https:/documentation/release-notes/22.05 - release documentation of version 22.05...]
+
+
+Genode SoC porting guide | 2022-05-25
+#####################################
+
+| In the second revision of the Genode Platforms document, Genode Labs shares
+| its former in-house expertise about moving Genode to new hardware devices.
+
+If you ever wondered how to make sense of highly-complex ARM SoCs without
+accurate public documentation, what it takes to bring a modern microkernel
+from one SoC to another, how to transplant and re-animate individual Linux
+kernel subsystems into sandboxed user-level components, or how to craft a
+custom bare-bones operating system out of Genode's components, the new
+revision of the Genode Platforms document is for you.
+
+[https://genode.org/documentation/genode-platforms-22-05.pdf - Genode Platforms 22.05] (PDF)
+
+During the past two years, Genode developer Norman Feske captured his
+practical experience with enabling Genode on a new hardware platform, namely
+the PinePhone.
+
+The process starts with basics like executing tiny bits of custom code, and
+continues with the porting of the microkernel, creating work flows for testing
+and packaging, and bringing up the Genode user land.
+
+With those fundamentals covered, the main part is concerned with the
+complexities of driving the device hardware of modern SoCs, ranging from
+low-level pin controls, over networking, up to driving sophisticated devices
+like the display and touch screen. For the latter, the ability of reusing
+device drivers from the Linux kernel plays a crucial role. Hence, the guide
+presents Genode's practical methodology and tooling behind the black art of
+transplanting and reanimating unmodified Linux kernel code into Genode
+components. Along the way, there are countless little tips and tricks that
+help to turn low-level grunt work into a fun and worthwhile experience.
+
+The document closes with a glimpse at real-world scenarios, culminating in
+the setup of the modem and the routing of audio signals to issue voice calls.
+
+
+Sculpt OS release 22.04 | 2022-04-28
+####################################
+
+| Sculpt OS version 22.04 introduces the concept of service-level sandboxing
+| and features completely new drivers for wireless, graphics, and USB.
+
+On the user-visible surface, the new version of Sculpt OS looks and feels
+familiar to users of the previous version. Under the hood, however, at the
+nitty-gritty hardware-support level, it features completely revamped device
+drivers for Intel wireless, Intel graphics, and USB.
+
+In a major surgery, the new drivers got transplanted from the Linux kernel
+version 5.14.21 using Genode's unique
+[https://genode.org/documentation/release-notes/21.08#Linux-device-driver_environment_re-imagined - DDE]
+approach.
+In contrast to Linux where the drivers are part of the almighty operating-system
+kernel, Sculpt OS hosts each of the drivers in a dedicated sandbox as plain
+user-level component. So Sculpt users can enjoy the broad hardware support
+of up-to-date Linux drivers without ultimately trusting those staggeringly
+complex driver stacks.
+
+Closely related, the support of hardware-accelerated graphics that we
+introduced with the previous version
+[https://genode.org/news/sculpt-os-release-21.10 - 21.10]
+received substantial optimization and stabilization. With the new version,
+Sculpt users can not only run native OpenGL applications but can even go as far
+as using hardware-accelerated graphics via guest operating systems hosted
+within VirtualBox on top of Sculpt.
+
+Being a component-based operating system following the principle of least
+privilege, Sculpt OS gives users ultimate control over the system resources
+exposed to each component. The new version equips the user with additional
+means to exercise control over the deployed software: A new optional
+component called black hole can now be used as placeholder for various system
+resources when deploying an application. For example, a virtual machine can
+be shielded from the network by connecting its network traffic to the black
+hole. This also works for audio, video capturing, USB, and other commonly used
+system resources. As this mechanism works at the level of individual services,
+the documentation refers to it as _service-level sandboxing_, resembling a
+poster-child for the natural power of capability-based security.
+
+Sculpt OS 22.04 is available as ready-to-use system image at the
+[https://genode.org/download/sculpt - Sculpt download page] and is accompanied
+with updated [https://genode.org/documentation/articles/sculpt-22-04 - documentation].
+
+
 Genode OS Framework release 22.02 | 2022-02-28
 ##############################################

 | With Genode 22.02, 3D acceleration becomes available to guest operating
 | systems running in VirtualBox 6, Sculpt OS evolves into a versatile framework
 | for building special-purpose operating systems, and Genode starts to interact
-| with the modem of the Pinephone.
+| with the modem of the PinePhone.

 The features mentioned above are merely the tip of the iceberg of version
 22.02. In fact, the majority of the development work during the release cycle
@@ -27,7 +155,7 @@ hardware, the current release lifts the potential of Sculpt's architecture for
 the creation of special-purpose operating-system appliances. The gained
 flexibility took even us developers by surprise! Thanks to the new modular
 approach, we were able to demonstrate a bare-bones version of Sculpt OS on
-the Pinephone at FOSDEM, or accelerate our development workflow by routinely
+the PinePhone at FOSDEM, or accelerate our development workflow by routinely
 running Sculpt OS directly on the Linux kernel.

 The intensive device-driver-related developments of the previous releases
@@ -36,7 +164,7 @@ drivers in Genode to PC hardware, starting with a fresh port of the USB host
 controller driver. The Intel GPU driver received numerous performance
 improvements and can now even be combined with guest operating systems running
 in VirtualBox 6. Further notable driver-related improvements are the new
-ability to interact with the modem on the Pinephone and largely streamlined
+ability to interact with the modem on the PinePhone and largely streamlined
 driver infrastructure for the Raspberry Pi.

 All the details of the new version can be found in the
@@ -52,12 +180,12 @@ Road Map for 2022 | 2022-01-18
 Following Genode's major technical breakthroughs in the areas of reusing Linux
 drivers, hardware-accelerated graphics, and the native execution of Chromium
 during 2021, we will pursue _mobile usability_ as overarching theme in 2022.
-Specifically, we aspire the routine use of Genode on the Pinephone as a
+Specifically, we aspire the routine use of Genode on the PinePhone as a
 platform for video chat, using WireGuard to protect the communications.

 This vision motivates a large variety of challenging technical topics.
 To name a few, we have to squeeze good performance out of the
-resource-constrained Pinephone hardware, focus on UI latency and the quality
+resource-constrained PinePhone hardware, focus on UI latency and the quality
 of service of audio streaming, come up with a somewhat usable touch-based
 user interface, and get to the guts of power management.

@@ -76,7 +204,7 @@ Genode OS Framework release 21.11 | 2021-11-30
 ##############################################

 | Genode 21.11 puts the spotlight on device drivers. Interactive Genode
-| scenarios come to the Pinephone, hardware-accelerated graphics becomes
+| scenarios come to the PinePhone, hardware-accelerated graphics becomes
 | available on Intel Gen9+ and Vivante GPUs, and Xilnx Zynq receives
 | new love.

@@ -84,7 +212,7 @@ The previous release presented our new take on porting drivers from Linux, and
 the architectural integration of hardware-accelerated graphics in Genode-based
 systems. The just released version 21.11 is the continuation of both topics.
 Thanks to our streamlined approach for transplanting Linux drivers to Genode, we
-were able to reuse the Pinephone's Linux drivers for the display and
+were able to reuse the PinePhone's Linux drivers for the display and
 touchscreen without modification. But, in contrast to running those drivers in
 the Linux kernel, we are walking on new ground by confining each driver in a
 separate sandbox.
@@ -165,7 +293,7 @@ Genode OS Framework release 21.08 | 2021-08-31
 ##############################################

 | The highlights of Genode 21.08 are revamped GPU support as well as new
-| drivers for the Pinephone and MNT-Reform laptop based on a new streamlined
+| drivers for the PinePhone and MNT-Reform laptop based on a new streamlined
 | approach for porting Linux kernel code. Further topics range from VirtualBox
 | improvements, over media playback in the native web browser, to LTE
 | connectivity in Sculpt OS.
@@ -178,7 +306,7 @@ Linux to Genode used to be a time-intensive affair, which forced a narrow
 focus on very few SoCs on us. With the streamlined porting approach introduced
 with the new release, we become able to dramatically reduce the costs,
 creating the prospect of a much broader hardware support. The first success
-stories of the new way of porting are added graphics drivers for the Pinephone
+stories of the new way of porting are added graphics drivers for the PinePhone
 and the MNT-Reform laptop, a network driver for the Pine-A64-LTS board, and an
 SD-card driver for the MNT-Reform.

@@ -310,7 +438,7 @@ Genode OS Framework release 21.02 | 2021-02-25
 | support for the Pine-A64-LTS board, and revived work on RISC-V.

 Many topics of the current release draw a connection to our overarching goal
-to use Genode on the Pinephone by the end of the year. Besides the obvious
+to use Genode on the PinePhone by the end of the year. Besides the obvious
 steps of enabling the hardware - starting with the Pine-A64-LTS board - the
 release introduces mobile-data connectivity as a Genode feature, and changes
 the network-driver architecture in anticipation of dynamic power-management
@@ -334,7 +462,7 @@ For the full story, please refer to the
 Road Map for 2021 | 2021-01-15
 ##############################

-| In 2021, we plan to bring Genode to the Pinephone, advance the framework's
+| In 2021, we plan to bring Genode to the PinePhone, advance the framework's
 | GPU support, and focus on development workflows.

 During the annual road-map discussion on Genode's public
@@ -342,13 +470,13 @@ During the annual road-map discussion on Genode's public
 the following hot topics for this year emerged.

 First and most inspiring for many Genode developers, we aspire to have
-Genode running on the Pinephone with basic feature-phone functionality by the
+Genode running on the PinePhone with basic feature-phone functionality by the
 end of the year. Since this will involve substantial device-driver-related
 developments, the team will take this line of work as an opportunity to
 advance the tooling and workflows for carrying out such tasks. This, in turn,
 will hopefully ease the on-boarding of new driver developers in the future.

-Closely related to the Pinephone scenario, the project will make optimizations
+Closely related to the PinePhone scenario, the project will make optimizations
 a top priority this year. The opportunities are plenty, ranging from
 micro-optimizations, over API refinements, to architectural changes if
 needed.
--- a/doc/release_notes/18-02.txt
+++ b/doc/release_notes/18-02.txt
@@ -219,8 +219,9 @@ Base framework and OS-level infrastructure
 Increased default warning level
 ===============================

-For building Genode components written in C++, the compiler flags -Wextra,
-Weffc++, and -Werror are now enabled in addition to -Wall by default.
+For building Genode components written in C++, the compiler
+flags -Wextra, -Weffc++, and -Werror are now enabled in addition
+to -Wall by default.

 If this strict warning level is inapplicable for a given component or
 library, it is possible to explicitly disable the strictness in the
--- a/doc/release_notes/21-02.txt
+++ b/doc/release_notes/21-02.txt
@@ -21,7 +21,7 @@ disrupting network-application stacks.

 Second, the release features the infrastructure needed for mobile-data
 communication over LTE, which is a prerequisite for our ambition to use Genode
-on the Pinephone. Section [LTE modem stack] gives insights into the involved
+on the PinePhone. Section [LTE modem stack] gives insights into the involved
 components and the architecture.

 Third, we are happy to feature the initial version of VirtualBox 6 for
@@ -518,7 +518,7 @@ Pine-A64-LTS single board computer
 ==================================

 Our [https://genode.org/about/road-map - road map] envisions
-the use of Genode on the Pinephone by the end of the year. As a first stepping
+the use of Genode on the PinePhone by the end of the year. As a first stepping
 stone, the current release adds basic board support for the
 [https://pine64.com/product-category/pine-a64-ltslong-term-supply/ - Pine-A64-LTS]
 single-board computer. We take this line of work as a welcome opportunity to
--- a/doc/release_notes/21-05.txt
+++ b/doc/release_notes/21-05.txt
@@ -147,7 +147,7 @@ system. The boot time of Sculpt OS has always been relatively quick compared
 to commodity operating systems. E.g., on a 5-years old laptop like a Lenovo
 x260, the system used to boot in about 5 seconds to the graphical user
 interface. However, with the anticipation of Sculpt OS on lower-end platforms
-like the Pinephone and with the vision of instant-on systems, we wondered
+like the PinePhone and with the vision of instant-on systems, we wondered
 about the potential for improvement.

 While gathering a CPU-load profile of the boot process using the top tool, we
--- a/doc/release_notes/21-08.txt
+++ b/doc/release_notes/21-08.txt
@@ -30,7 +30,7 @@ DDE-Linux could be. Section [Linux-device-driver environment re-imagined]
 presents the results of this recent line of development that promises to dwarf
 the costs of driver-porting work compared to our time-tested approach. The
 results have an immediate impact on our ambition to bring Genode to the
-Pinephone as our added network and framebuffer drivers for the Allwinner A64
+PinePhone as our added network and framebuffer drivers for the Allwinner A64
 SoC leverage the new DDE already.

 The challenge of using hardware-accelerated graphics (GPUs) on Genode makes a
@@ -187,7 +187,7 @@ resounding success. The i.MX8MQ repository features drivers for framebuffer
 output and SD-card access,
 [https://genodians.org/skalk/2021-08-02-mnt-reform2-sdcard - targeting the MNT Reform laptop].
 The Allwinner repository contains a network driver for the Pine-A64-LTS board
-and a new framebuffer driver for the Pinephone. No single line of Linux code
+and a new framebuffer driver for the PinePhone. No single line of Linux code
 had to be changed.

 We found that the development of those driver components took only a fraction
@@ -203,7 +203,7 @@ exploratory experience.
 That said, it is not all roses. Components based on Linux drivers have to
 carry substantial Linux-specific bureaucracy along with them. The resulting
 components tend to be somewhat obese given their relatively narrow purpose.
-E.g., the executable binary of the framebuffer driver for the Pinephone is
+E.g., the executable binary of the framebuffer driver for the PinePhone is
 1.5 MiB in size, most of which is presumably dead weight.


@@ -568,7 +568,7 @@ Modular integration of LTE modem stack in Sculpt OS

 In version [https://genode.org/documentation/release-notes/21.02#LTE_modem_stack - 21.02],
 we announced the LTE modem support as a prerequisite for using Genode on the
-Pinephone. Since most of our development laptops also come with LTE modems or
+PinePhone. Since most of our development laptops also come with LTE modems or
 an extension slot for installing one, we explored ways to augment the Sculpt
 scenario with mobile networking on demand, i.e., by the installation of
 additional components. The result is documented by means of an
--- a/doc/release_notes/21-11.txt
+++ b/doc/release_notes/21-11.txt
@@ -11,9 +11,9 @@
 Version 21.11 of the Genode OS Framework puts device drivers into the
 spotlight. Where to begin? Back in
 [https://genode.org/news/road-map-for-2021 - January], we envisioned Genode
-running on the Pinephone. With the current release, the first interactive
+running on the PinePhone. With the current release, the first interactive
 Genode scenarios become alive on this platform. Unlike the regular Linux-based
-systems used on the Pinephone, we are walking on new ground by running each
+systems used on the PinePhone, we are walking on new ground by running each
 individual driver in a dedicated sandbox.

 Speaking of 64-bit ARM platforms, Genode's support for the i.MX8 SoC family
@@ -91,7 +91,7 @@ Kalkowski took the i.MX-related code to his
 Johannes Schlatow took the Xilinx Zynq code to his
 [https://github.com/jschlatow/genode-zynq - genode-zynq] repository,
 Norman Feske
-maintains the Allwinner code for the Pinephone in
+maintains the Allwinner code for the PinePhone in
 his [https://github.com/nfeske/genode-allwinner - genode-allwinner]
 repository, and Sebastian Sumpf gave the RISC-V support a new home
 at his [https://github.com/ssumpf/genode-riscv - genode-riscv] repository.
@@ -173,11 +173,11 @@ corresponding line in your etc/build.conf. Step-by-step instructions for
 individual boards can be found at _repos/zynq/doc/_.


-Allwinner A64 (Pinephone)
+Allwinner A64 (PinePhone)
 =========================

 During the release cycle, Genode's support for the Allwinner A64 SoC, and
-the Pinephone in particular, made big leaps forward. The corresponding code
+the PinePhone in particular, made big leaps forward. The corresponding code
 is hosted in the dedicated
 [https://github.com/nfeske/genode-allwinner - genode-allwinner] repository.

@@ -186,7 +186,7 @@ updated to 5.14.1 in order to support the revision v2 of the Pine-A64-LTS
 board, which features a different Ethernet PHY, namely the Motorcomm YT8511
 PHY. Genode's 'pine_a64lts' board supports both board revisions now.

-To enable touchscreen input on the Pinephone, the corresponding driver for the
+To enable touchscreen input on the PinePhone, the corresponding driver for the
 Goodix touchscreen controller has been ported from the Linux kernel. It
 complements the framebuffer driver that we introduced with the previous
 release. Combined, both drivers enable the use of Genode's regular interactive
@@ -199,10 +199,10 @@ now handled by a new A64-specific version of the platform driver.
  Genode's nano-3D example responding to touch input

 The improved driver support is accompanied with new tooling for booting Genode
-on the Pinephone, either via USB fastboot, or via SD-card. Both options are
+on the PinePhone, either via USB fastboot, or via SD-card. Both options are
 described in the following Genodians article.

-:Booting Genode on the Pinephone:
+:Booting Genode on the PinePhone:

  [https://genodians.org/nfeske/2021-09-20-pine-fun-pinephone-boot]

@@ -291,7 +291,7 @@ input becomes explicit. A client can no longer drive a pin that is an input
 signal unless explicitly permitted.

 The interfaces were created and time-tested in the context of our
-Pinephone-related development, in particular during the work described in the
+PinePhone-related development, in particular during the work described in the
 following two articles.

 :Device access from the user level:
@@ -325,7 +325,7 @@ Time-multiplexed pin direction

 There exist rare use cases for changing the direction of an I/O pin during
 runtime. For example, the Goodix touchscreen controller as found in the
-Pinephone monitors the state of its interrupt signal during reset. During its
+PinePhone monitors the state of its interrupt signal during reset. During its
 normal operation, this signal is driven by the touchscreen controller but
 during reset, it is driven by the host to send one bit of information (I2C
 address selection). We support this time-multiplexed use of one pin as both
@@ -367,7 +367,7 @@ Genode events. The interface is located at
 _repos/os/include/genode_c_api/event.h_ whereas the implementation resides at
 _repos/os/src/lib/genode_c_api/event.cc_.
 The initial version is limited to multitouch events only.
-As of now, it is used by the Goodix touchscreen driver for the Pinephone.
+As of now, it is used by the Goodix touchscreen driver for the PinePhone.


 Event filter for converting touch to pointer input
@@ -399,7 +399,7 @@ as input filter, reworked in
 [https://genode.org/documentation/release-notes/20.08#Replacing_the_input_filter_with_an_event_filter - 20.08]).
 The new filter comes in the form of a new '<touch-click>' node in the filter's
 '<output>' definition. For example, the configuration of the event filter that
-sits in-between the Goodix touchscreen driver for the Pinephone and the
+sits in-between the Goodix touchscreen driver for the PinePhone and the
 nitpicker GUI server looks as follows.

 ! <config>
--- a/doc/release_notes/22-02.txt
+++ b/doc/release_notes/22-02.txt
@@ -27,7 +27,7 @@ driver work for several platforms (Section [Device drivers]). In particular,
 we started to apply our new method of porting Linux driver code to PC drivers
 such as our new USB host controller driver. The Intel GPU driver received
 welcome performance optimizations and became usable for guest operating
-systems running in VirtualBox 6. On the Pinephone, Genode has started
+systems running in VirtualBox 6. On the PinePhone, Genode has started
 interacting with the modem.

 From a functional perspective, the highlight of the release is the
@@ -35,7 +35,7 @@ extension of Sculpt OS towards a highly customizable toolkit for building
 special-purpose operating systems defined at integration time
 (Section [Framework for special-purpose Sculpt-based operating systems]).
 This new level of flexibility cleared the path to running a bare-bones
-version of Sculpt OS on the Pinephone, or directly on a Linux kernel.
+version of Sculpt OS on the PinePhone, or directly on a Linux kernel.


 Framework for special-purpose Sculpt-based operating systems
@@ -212,11 +212,11 @@ redirected to core using the optional 'LOG=core' argument on the command line.
 ! build/x86_64$ make run/sculpt KERNEL=nova BOARD=pc SCULPT=default LOG=core


-Sculpt OS meets the Pinephone
+Sculpt OS meets the PinePhone
 =============================

 Thanks to the greatly modularized new version of Sculpt OS, we have become
-able to run a minimalistic version of Sculpt on the Pinephone, as demonstrated
+able to run a minimalistic version of Sculpt on the PinePhone, as demonstrated
 in our recent presentation at FOSDEM.

 : <video preload="none" controls="controls">
@@ -224,14 +224,14 @@ in our recent presentation at FOSDEM.
 :            type='video/webm; codecs="vp9, opus"' />
 : </video>

-:Genode meets the Pinephone:
+:Genode meets the PinePhone:

  [https://fosdem.org/2022/schedule/event/nfeske/]

  _Microkernel developer room at FOSDEM, 2022-02-05_

 Despite lacking drivers for storage and network connectivity, we are already
-able to put together interesting interactive system images for the Pinephone.
+able to put together interesting interactive system images for the PinePhone.
 To make this possible, a few additional steps had to be taken though.

 First, we had to make Sculpt's administrative GUI able to respond to touch
@@ -878,13 +878,13 @@ configuration (example):
 ! </config>


-Pinephone modem access
+PinePhone modem access
 ======================

 On our way towards a Genode-based phone, we enabled the low-level access of
-the Quectel-EG25 modem as found in the Pinephone. This line of work is hosted
+the Quectel-EG25 modem as found in the PinePhone. This line of work is hosted
 in the [https://github.com/genodelabs/genode-allwinner - genode-allwinner]
-repository and consists of parts. First, the modem driver at
+repository and consists of two parts. First, the modem driver at
 _src/drivers/modem/pinephone/_ takes care of the powering and initialization
 of the modem. It works in tandem with the power and reset controls of the
 A64 platform driver and the GPIO controls of the PIO driver. The second part
@@ -894,12 +894,12 @@ described in
 [https://wiki.pine64.org/wiki/File:Quectel_EC2x%26EG9x%26EG2x-G%26EM05_Series_AT_Commands_Manual_V2.0.pdf - Quectel documentation].

 A first example scenario is provided by the
-[https://github.com/genodelabs/genode-allwinner/blob/22.02/run/modem_pinephone.run modem_pinephone.run]
+[https://github.com/genodelabs/genode-allwinner/blob/22.02/run/modem_pinephone.run - modem_pinephone.run]
 script. It comprises the modem driver and two instances of the UART driver.
 One UART driver is connected to the modem's control channel whereas the other
-is connected to the default serial interface of the Pinephone. By bridging
+is connected to the default serial interface of the PinePhone. By bridging
 both drivers via a terminal-crosslink component, the scenario allows for
-the direct interaction with the modem over the Pinephone's serial channel,
+the direct interaction with the modem over the PinePhone's serial channel,
 e.g., unlocking a SIM card or sending SMS messages via the 'AT+CMGS' command.


--- a/doc/release_notes/22-05.txt
+++ b/doc/release_notes/22-05.txt
@@ -0,0 +1,775 @@
+
+
+              ===============================================
+              Release notes for the Genode OS Framework 22.05
+              ===============================================
+
+                               Genode Labs
+
+
+
+The Genode release 22.05 stays true to this year's
+[https://genode.org/about/road-map - roadmap].
+According to the plan, we continue our tradition of revising the framework's
+documentation as part of the May release. Since last year, the Genode
+Foundations book is accompanied with the Genode Platforms document that
+covers low-level topics. The second revision has just doubled in size
+(Section [Updated and new documentation]).
+
+Functionality-wise, the added support for WireGuard-based virtual private
+networks is certainly the flagship feature of the release.
+Section [WireGuard] briefly introduces the new component while leaving
+in-depth information to a
+[https://genodians.org/m-stein/2022-05-26-wireguard-1 - dedicated article].
+
+Among the other topics of the release, our continued work on device drivers
+stands out. We managed to bring Genode's lineup of PC drivers ported from the
+Linux kernel up to the kernel version 5.14.21 using Genode's unique DDE-Linux
+porting approach.
+As described by Section [New generation of DDE-Linux-based PC drivers], this
+work comprises complex drivers like the wireless LAN stack including Intel's
+Wifi driver and the latest Intel display driver. At the framework's side, the
+modernization of Genode's platform driver for PC hardware is in full swing.
+Even though not yet used by default, the new driver has reached feature parity
+with the original PC-specific platform driver while sharing much of its code
+base with the growing number of ARM platform drivers such as the FPGA-aware
+platform-driver for Xilinx Zynq (Section [Xilinx Zynq]).
+
+Regarding the PinePhone, Genode 22.05 introduces the basic ability to issue
+and receive phone calls, which entails the proper routing of audio signals and
+controlling the LTE modem. Furthermore, in anticipation of implementing
+advanced energy-management strategies, the release features a custom developed
+firmware for the PinePhone's system-control processor. Both topics are
+outlined in Section [PinePhone] while further details and examples are given
+in dedicated articles.
+
+The release is wrapped up by usability improvements of the framework's
+light-weight event-tracing mechanism, low-level optimizations, and API
+refinements.
+
+
+WireGuard
+#########
+
+[https://www.wireguard.com/ - WireGuard] is a protocol for encrypted, virtual
+private networks (VPNs) with the goal of bringing ease-of-use and
+state-of-the-art network security together. Furthermore, it is designed to be
+implemented both light-weighted and highly performant at the same time. For
+years now, we were keen to support WireGuard as a native standard solution for
+peer-to-peer network encryption. With Genode 22.05, we could finally
+accomplish that goal.
+
+After we had considered various implementations as starting point, we chose to
+port the Linux kernel implementation of WireGuard using our modernized
+DDE-Linux tool set. The outcome is a user-land component that acts as client
+to one NIC session and one uplink session. At the uplink session, the
+WireGuard component plays the role of a VPN-internal network device that
+communicates plain-text with the VPN participants. At the NIC session,
+however, the component drives an encrypted UDP tunnel through the public
+network towards other WireGuard instances.
+
+In Genode, a WireGuard instance receives its parameters through the component
+configuration with the peer configuration being re-configurable:
+
+! <config private_key="0CtU34qsl97IGiYKSO4tMaF/SJvy04zzeQkhZEbZSk0="
+!         listen_port="49001">
+!
+!   <peer public_key="GrvyALPZ3PQ2AWM+ovxJqnxSqKpmTyqUui5jH+C8I0E="
+!         endpoint_ip="10.1.2.1"
+!         endpoint_port="49002"
+!         allowed_ip="10.0.9.2/32" />
+!
+! </config>
+
+A typical integration scenario would use two instances of Genode's NIC router.
+One router serves the public network side of WireGuard and connects to the
+internet via the device driver whereas the other router uses the private
+network side of WireGuard as uplink interface. In this scenario, there is no
+way around the WireGuard tunnel towards the Internet even when looking only at
+components and sessions. Alternatively, we could accomplish the same goal with
+only one router instance in contexts that allow us to trust in the integrity
+of the router's own security domains.
+
+[image wireguard_integration]
+  A typical integration scenario for WireGuard
+
+For more details on how to integrate and route WireGuard in Genode, you may
+refer to the new run scripts _wg_ping_inwards.run_, _wg_ping_outwards.run_,
+_wg_lighttpd.run_, and _wg_fetchurl.run_, which are located at
+_repos/dde_linux/run/_.
+
+Please be aware that this is the first official version of the WireGuard
+component. Although we are convinced of the quality of the underlying
+time-tested Linux implementation, we strongly recommend against basing
+security-critical scenarios on Genode's port before it had the time to mature
+through real-world testing as well.
+
+For the whole story behind the new WireGuard support in Genode, have a look at
+the following dedicated article at [https://genodians.org]:
+
+:Bringing WireGuard to Genode:
+
+  [https://genodians.org/m-stein/2022-05-26-wireguard-1]
+
+
+New generation of DDE-Linux-based PC drivers
+############################################
+
+With the
+[https://genode.org/documentation/release-notes/22.02#New_Linux-device-driver_environment_for_PC_drivers - previous release],
+we started to apply the
+[https://genode.org/documentation/release-notes/21.08#Linux-device-driver_environment_re-imagined - new DDE Linux approach]
+to Linux-based PC drivers.
+The first driver to be converted was the USB host-controller driver. In the
+current release, we finished up this line of work. By now, all remaining
+Linux-based PC drivers have been converted and updated. Those drivers now
+share the same kernel version 5.14.21. The ports and configuration reside in
+the _pc_ repository.
+
+Based on the groundwork laid by the USB host-controller driver, we started
+working on the Intel display and Intel wireless drivers. With the stumbling
+blocks already out of the way, namely the x86 support in DDE Linux, we could
+focus entirely on the intricacies of each driver.
+
+In case of the Intel display driver, we could eliminate all our patches to the
+kernel that we previously needed to manage the display connectors. Due to the
+update, we gained support for newer Intel Gen11 and Gen12 graphics generations
+as found in recent Intel CPUs. The old driver has been removed and the new
+driver is now called _pc_intel_fb_drv_. Its configuration, however, remained
+compatible and is documented in detail in the README of the driver.
+
+The Intel wireless driver also profited from the version update as it now
+supports 802.11ax capable devices. In particular, the driver was tested with
+Intel Wi-Fi6 AX201 cards. The driver's unique physique - where the component
+not only incorporates the driver but also the supporting user-land supplicant -
+required changes to the way the Linux emulation environment is initialized.
+We utilize a new VFS 'wifi' plugin that is executed during the component
+start-up to prepare the emulation environment.
+
+The following snippet shows how to configure the driver:
+
+!<start name="pc_wifi_drv" caps="250">
+!  <resource name="RAM" quantum="32M"/>
+!  <provides><service name="Nic"/></provides>
+!  <config>
+!    <libc stdout="/dev/null" stderr="/dev/null" rtc="/dev/rtc"/>
+!    <vfs>
+!      <dir name="dev">
+!        <log/> <null/> <rtc/> <wifi/>
+!        <jitterentropy name="random"/>
+!        <jitterentropy name="urandom"/>
+!      </dir>
+!    </vfs>
+!  </config>
+!  <route>
+!    <service name="Rtc"> <any-child /> </service>
+!    <any-service> <parent/> <any-child /> </any-service>
+!  </route>
+!</start
+
+Apart from the added VFS plugin, the configuration remained unchanged.
+So using the new driver is opaque to the user. The old driver was removed
+and the new driver is now called _pc_wifi_drv_. Instead of preparing the
+'dde_linux' port, the 'libnl' and 'wpa_supplicant' ports are now required for
+building the driver.
+
+! tool/ports/prepare libnl wpa_supplicant
+
+Additionally to both driver updates, we wrapped up working on the USB
+host-controller driver component by enabling the UHCI host-controller driver.
+Support for such controllers was omitted in the previous release and
+supporting the driver required us to add I/O port support to the 'lx_kit' for
+x86. With this remaining feature gap closed, the _legacy_pc_usb_host_drv_
+driver component has been removed in favour of the new one. Furthermore, the
+Genode C-API for USB glue code, which was initially copied from the i.MX8 USB
+host-controller driver, was consolidated and moved into the _dde_linux_
+repository where it now is referenced by all recent USB host-controller
+drivers.
+
+With all updated drivers in place, it was time to make inventory and
+de-duplicate the drivers since each driver accumulated redundant bits and
+pieces of code. This consolidation effort simplified things greatly. We moved
+most of the code shared by all drivers into a separate 'pc_lx_emul' library,
+which is the back bone of those ported drivers. Since not all of them require
+the same sophistication when it comes to the kernel API emulation, we followed
+the same modular pattern already established in the _dde_linux_ repository,
+which allows for mixing and matching of the available dummy implementations
+individually per driver.
+
+
+Updated and new documentation
+#############################
+
+Genode Platforms
+----------------
+
+The second revision of the "Genode Platforms" document condenses two years of
+practical work with enabling Genode on a new hardware platform, taking the
+PinePhone as concrete example. Compared to the first version published one
+year ago, the content has doubled. Among the new topics are
+
+: <div class="visualClear"><!-- --></div>
+: <p>
+:  <div style="clear: both; float: left; margin-right:20px;">
+:   <a class="internal-link" href="https://genode.org">
+:    <img class="image-inline" src="https://genode.org/documentation/genode-platforms-title.png">
+:   </a>
+:  </div>
+: </p>
+
+* Working with bare-bones Linux kernels,
+* Network driver based on DDE-Linux,
+* Display and touchscreen,
+* Clocks, resets, and power controls, and
+* Modem control and telephony.
+
+:Second revision of the Genode Platforms document:
+
+  [https://genode.org/documentation/genode-platforms-22-05.pdf]
+
+
+Genode Foundations
+------------------
+
+The "Genode Foundations" book received its annual update. It is available at
+the [https://genode.org] website as a PDF document and an online version.
+The most noteworthy additions and changes are:
+
+: <div class="visualClear"><!-- --></div>
+: <p>
+:  <div style="clear: both; float: left; margin-right:20px;">
+:   <a class="internal-link" href="https://genode.org">
+:    <img class="image-inline" src="https://genode.org/documentation/genode-foundations-title.png">
+:   </a>
+:  </div>
+: </p>
+
+* Revised under-the-hood section about the base-hw kernel,
+* Adaptation to changed repository structure (pc repository, SoC-specific
+  repositories),
+* Updated API documentation, and
+* Adjusted package-management description.
+
+: <div class="visualClear"><!-- --></div>
+
+To examine the changes in detail, please refer to the book's
+[https://github.com/nfeske/genode-manual/commits/master - revision history].
+
+
+Base framework and OS-level infrastructure
+##########################################
+
+Revised tracing facilities
+==========================
+
+Even though a light-weight event tracing mechanism has been with Genode since
+[https://genode.org/documentation/release-notes/13.08#Light-weight_event_tracing - version 13.08],
+in practice, this powerful tool remains sparingly used because it is arguable
+less convenient than plain old debug instrumentation.
+The trace-logger component introduced later in
+[https://genode.org/documentation/release-notes/18.02#New_trace-logging_component - version 18.02]
+tried to lower the barrier, but tracing remains being an underused feature.
+The current release brings a number of usability improvements that will
+hopefully make the tool more attractive for routine use.
+
+Concise human-oriented output format
+------------------------------------
+
+First, we changed the output format of the trace logger to become better
+suitable for human consumption, reducing syntactic noise and filtering out
+repetitive information. For example, when instrumenting the VFS server in
+Sculpt using the new GENODE_TRACE_TSC utility (see below), the trace logger
+now generates tabular output as follows.
+
+! Report 4
+!
+! PD "init -> runtime -> arch_vbox6 -> vbox -> " ----------------
+!  Thread "vCPU"           at (0,0)  total:12909024 recent:989229
+!  Thread "vCPU"           at (1,0)  total:5643234  recent:786437
+!
+! PD "init -> runtime -> ahci-0.fs" -----------------------------
+!  Thread "ahci-0.fs"      at (0,0)  total:910497   recent:6335
+!  Thread "ep"             at (0,0)  total:0        recent:0
+!   71919692932: TSC process_packets: 8005M (4998 calls, last 4932K)
+!   71921558516: TSC process_packets: 8006M (4999 calls, last 1596K)
+!   71922760220: TSC process_packets: 8007M (5000 calls, last 1006K)
+!   71929853586: TSC process_packets: 8009M (5001 calls, last 1840K)
+!   71931315246: TSC process_packets: 8011M (5002 calls, last 1253K)
+!   72127999920: TSC process_packets: 8016M (5003 calls, last 5606K)
+!   72129568198: TSC process_packets: 8018M (5004 calls, last 1345K)
+!   77161908178: TSC process_packets: 8029M (5005 calls, last 11349K)
+!   77643225736: TSC process_packets: 8029M (5006 calls, last 217K)
+!   89422100594: TSC process_packets: 8035M (5007 calls, last 5656K)
+!   89422123632: TSC process_packets: 8035M (5008 calls, last 1342)
+!  Thread "signal handler" at (0,0)  total:36329    recent:3001
+!  Thread "signal_proxy"   at (0,0)  total:51838    recent:13099
+!  Thread "pdaemon"        at (0,0)  total:97184    recent:332
+!  Thread "vdrain"         at (0,0)  total:1266     recent:286
+!  Thread "vrele"          at (0,0)  total:1904     recent:516
+!
+! PD "init -> runtime -> nic_drv" -------------------------------
+!  Thread "nic_drv"        at (0,0)  total:34044    recent:897
+!  Thread "signal handler" at (0,0)  total:369      recent:142
+!
+! ...
+
+Subjects that belong to the same protection domain are grouped together.
+The formerly optional affinity and activity options have been removed.
+These pieces of information are now unconditionally displayed. The trace
+entries belonging to a thread appear as slightly indented. Trace subjects with
+no activity do not produce any output. This way, the new version can be easily
+used to capture CPU usage of all threads over time, as a possible alternative
+to the top tool, which gives only momentarily sampled information.
+
+
+Straight-forward trace logging with Sculpt OS
+---------------------------------------------
+
+Second, we added the trace-logger utility to the default set of packages along
+with an optional launcher. With this change, only two steps are needed to use
+the tracing mechanism with the
+[https://genode.org/documentation/release-notes/22.02#Framework_for_special-purpose_Sculpt-based_operating_systems - modularized Sculpt]:
+
+# Add 'trace_logger' to the 'launcher:' list of the .sculpt file
+
+# Either manually select the 'trace_logger' from the '+' menu,
+  or add the following entry to the deploy configuration:
+
+  ! <start name="trace_logger"/>
+
+By default, the trace logger is configured to trace all threads executed in
+the runtime subsystem and to print a report every 10 seconds. This default
+policy can be refined in the launcher's '<config>' node. Note that the trace
+logger does not respond to configuration changes during runtime. Changes come
+into effect not before restarting the component.
+
+
+Capturing performance measurements as trace events
+--------------------------------------------------
+
+Finally, to leverage the high efficiency of the tracing mechanism for
+performance analysis, we complement the convenient
+[https://genodians.org/nfeske/2021-04-07-performance - GENODE_LOG_TSC]
+measurement device provided by _base/log.h_ with new versions that target the
+trace buffer. The new macros GENODE_TRACE_TSC and GENODE_TRACE_TSC_NAMED
+thereby simplify the capturing of highly accurate time-stamp-counter-based
+measurements for performance-critical code paths that prohibit the use of
+regular log messages.
+
+
+Memcpy and memset optimization
+==============================
+
+With the improving support for the Zynq-7000 SoC, it was time to collect a few
+basic performance metrics. For the purpose of evaluating memory throughput,
+there exists a test suite in _libports/run/memcpy.run_. It takes a couple of
+measurements for different memcpy and memset implementations. There also
+exists a Makefile in _libports/src/test/memcpy/linux_ to build a similar test
+suite for Linux that serves as a baseline. By comparing the results, we get an
+indicator of whether our board support is setting up the hardware correctly.
+Looking at the numbers for the Zynq-7000 SoC, however, we were puzzled about
+why we achieved significantly less memcpy throughput on Genode than on Linux.
+This eventually sparked an in-depth investigation of memcpy implementations
+and of the Cortex-A9's memory subsystem.
+
+As it turned out, the major difference was caused by our Linux tests hitting
+the kernel's copy-on-write optimization and, therefore, accidentally mimicking
+a memset scenario rather than a memcpy scenario. Nevertheless, in the
+debugging process, we were able to identify a few low-hanging fruits for
+general optimization of Genode's memset and memcpy implementations: Replacing
+the bytewise memset implementation with a wordwise memset yielded a speedup of
+~6 on Cortex-A9 (base-hw) and x86 (base-linux). Similarly, we achieved a
+memcpy speedup of ~3 on x86. On arm_v7, we also experimented with the
+preloading instruction (pld) and L2 prefetching. On Zynq-7000 (Cortex-A9), we
+gained a speedup of ~2-3 by tuning these parameters.
+
+
+Extended black-hole component
+=============================
+
+The black-hole component introduced in
+[https://genode.org/documentation/release-notes/22.02#Black-hole_server_component - version 22.02]
+provides pseudo services for commonly used session interfaces and is thereby
+able to satisfy the resource requirements of a component without handing out
+real resources. This is especially useful for deploying highly flexible
+subsystems like VirtualBox, which supports many host-guest integration
+features, most of which are desired only in a few scenarios. For example, to
+shield a virtual machine from the network, the NIC session requested by the
+VirtualBox instance can simply be assigned to the black-hole server while
+keeping the network configuration of the virtual machine untouched.
+
+The current release extends the black-hole component to cover ROM, GPU, and
+USB services in addition to the already supported NIC, uplink, audio, capture,
+and event services. The ROM service hands out a static '<empty/>' XML node.
+The USB and GPU services accept the creation of new sessions but respond in a
+denying way to any invocation of the session interfaces. The black-hole server
+is located at _os/src/server/black_hole/_.
+
+
+Refined low-level block I/O interfaces
+======================================
+
+In the original version of the 'Block::Connection::Job' API introduced in
+[https://genode.org/documentation/release-notes/19.05#Modernized_block-storage_interfaces - version 19.05],
+split read/write operations were rather difficult to accommodate and remained
+largely unsupported by clients of the block-session interface. In practice,
+this limitation was side-stepped by dimensioning the default I/O buffer sizes
+large enough to avoid splitting. The current release addresses this limitation
+by changing the meaning of the 'offset' parameter of the
+'produce_write_content' and 'consume_read_result' hook functions. The value
+used to reflect the absolute byte position. In the new version, it is relative
+to the job's operation.
+_This API change requires the adaptation of existing block-session clients._
+
+We adapted all block-session clients accordingly, including part_block,
+vfs/rump, vfs/fatfs, and Genode's ARM virtual machine monitor. Those
+components thereby became able to work with arbitrary block I/O buffer sizes.
+
+
+Improved touch-event support
+============================
+
+Until recently, Genode's GUI stack largely relied on the notion of an absolute
+pointer position. For targeting touch-screen devices, our initial approach
+was the translation of touch events to absolute motion events using the
+event-filter component
+([https://genode.org/documentation/release-notes/21.11#Event_filter_for_converting_touch_to_pointer_input - version 21.11]).
+
+However, the event types are subtly different, which creates uncertainties.
+Whereas a pointer has always a defined (most recent) position that can be used
+to infer a hovered UI element in any situation, touch input yields a valid
+position only while touching. Because both event types are different after all,
+the conversion of touch input to pointer motion can only be an intermediate
+solution. The current release enhances several components of Genode's GUI
+stack with the ability to handle touch events directly.
+
+In particular, the nitpicker GUI server has become able to take touch events
+into consideration for steering the keyboard focus and the routing of
+input-event sequences. The window-manager component (wm) has been enhanced to
+transform touch events similarly to motion events by using one virtual
+coordinate system per window. Finally, the menu-view component, which
+implements the rudimentary widget set as used by Sculpt OS' administrative
+user interface, evaluates touch events for generating hover reports now.
+Combined, these changes make the existing GUI stack fit for our anticipated
+touch-screen based usage scenarios such as the user interface for Genode on
+the PinePhone.
+
+
+Platform driver
+===============
+
+The architecture-independent platform driver that unified the platform API since
+[https://genode.org/documentation/release-notes/22.02#Platform_driver - release 22.02],
+still missed some features to replace the deprecated x86-specific variant.
+Most importantly, it was not aware of PCI devices and their special treatment.
+
+PCI decode component
+--------------------
+
+The platform driver is a central resource multiplexer in the system, and
+literally all device drivers depend on it. Therefore, it is crucial to keep it
+as simple as possible to minimize its code complexity. To facilitate
+PCI-device resource handling of the platform driver, we introduce a new
+component called _pci_decode_. It examines information delivered by the ACPI
+driver about the location of the PCI configuration spaces of PCI host bridges,
+as well as additional interrupt re-routing information, and finally probes for
+all available PCI devices, and their functions. Dependent on additional
+kernel-related facilities, e.g., whether the micro-kernel supports
+message-signaled interrupts, it finally publishes a report about all PCI
+devices and their related resources.
+
+An example report looks like the following:
+
+! <devices>
+!   <device name="00:02.0" type="pci">
+!     <pci-config    address="0xf8010000" bus="0x0" device="0x2" function="0x0"
+!                    vendor_id="0x8086" device_id="0x1616" class="0x30000"
+!                    bridge="no"/>
+!     <io_mem        address="0xf0000000" size="0x1000000"/>
+!     <io_mem        address="0xe0000000" size="0x10000000"/>
+!     <io_port_range address="0x3000"     size="0xffff0040"/>
+!     <irq type="msi" number="11"/>
+!   </device>
+! 
+!   ...
+! </devices>
+
+The device and resource description in this report is compatible with the
+device configuration patterns already used by the platform driver before.
+
+Devices ROM
+-----------
+
+To better cope with device information gathered at runtime, like the one
+provided by the PCI decoder, the platform driver no longer retrieves the device
+information from its configuration. Instead, it requests a devices ROM
+explicitly. The policy information about which devices are assigned to which
+client remains an integral part of the platform driver's configuration.
+The devices ROM is requested via the label "devices" by default. If one needs
+to name the ROM differently, one can state the label in the configuration:
+
+! <config devices_rom="config"/>
+
+Using the example above, the former behavior can be emulated. It prompts the
+platform driver to obtain both its policy configuration and device information
+from the same "config" ROM.
+
+Static device information for a specific SoC respectively board does now
+reside in the SoC-specific repositories within the _board/_ directory.
+For instance, the device information for the MNT Reform 2 resides in the
+genode-imx repository under _board/mnt_reform2/devices_. All scenarios and
+test-scripts can refer to this central file.
+
+Report facility
+---------------
+
+The platform driver can report its current view on devices as well as its
+configuration. An external management component might monitor this information
+to dynamically apply policies. With the following configuration switches, one
+can enable the reports "config" and "devices":
+
+! <config>
+!   <report devices="yes" config="yes"/>
+!   ...
+! </config>
+
+Interrupt configuration
+-----------------------
+
+The need for additional information to set up interrupts appropriately led to
+changes in the interrupt resource description consumed by the platform driver.
+It can now parse additional attributes, like mode, type, and polarity. It
+distinguishes "msi" and "legacy" as type, "high" and "low" as polarity,
+"level" and "edge" as mode. Dependent on the stated information in the devices
+ROM, the platform driver will open the IRQ session for the client accordingly.
+
+I/O ports
+---------
+
+A new resource type in the device description interpreted by the platform
+driver is the I/O port range. It looks like the following:
+
+! <devices>
+!   <device name="00:1f.2" type="pci">
+!     ...
+!     <io_port_range address="0x3080" size="0x8"/>
+!     ...
+!   </device>
+!   ...
+! </devices>
+
+The generic platform API's device interface got extended to deliver an IO_PORTS
+session capability for a given index. The index is dependent on which I/O port
+ranges are stated for a given device.
+
+The helper utility 'Platform::Device::Io_port_range' simplifies the usage of
+I/O ports by device driver clients. It can be found in
+_repos/os/include/platform_session/device.h_.
+
+DMA protection
+--------------
+
+The generic platform driver now uses device PDs and attaches all DMA buffers
+requested by a client to it. Moreover, it assigns PCI devices to the device PD
+too. On the NOVA kernel, this information is used to
+configure the IOMMU correspondingly.
+
+PCI device clients
+------------------
+
+The platform API and its utilities no longer differentiate between PCI and
+non-PCI devices. However, under the hood, the platform driver performs
+additional initialization steps once a PCI device gets acquired. Dependent on
+the resources assigned to the device, the platform driver enables I/O and
+memory access in the PCI configuration space of the device. Moreover, it
+enables bus-master access for DMA transfers.
+
+To assign PCI devices to a client, the policy rules in the platform driver can
+refer to it either by a device/vendor ID tuple, or by stating a PCI class.
+The PCI class names are the same supported by the previous x86-specific
+platform driver. Of course, one can still refer to any device via its unique
+name. Here is an example for a policy set:
+
+! <config>
+!   <policy label="usb_drv -> ">
+!     <pci class="USB"/>
+!   </policy>
+!   <policy label="nvme_drv -> ">
+!     <pci vendor_id="0x1987" device_id="0x5007"/>
+!   </policy>
+!   <policy label="ps2_drv -> ">
+!     <device name="ps2"/>
+!   </policy>
+! </config>
+
+Wait for platform device availability
+-------------------------------------
+
+Now that device information can be gathered dynamically at runtime it might
+happen that a client opens a session to the platform driver before the device
+becomes available. As long as a valid policy is defined for the client, the
+platform driver will establish the connection, but deliver an empty devices
+ROM to the client.
+
+To simplify the usage by device drivers, the utilities to acquire a device
+from the platform driver in 'Platform::Device' and 'Platform::Connection' will
+wait for the availability of the device. This is done by implicitly
+registering a signal handler for devices ROM updates at the platform driver
+when the acquisition failed, and waiting for ROM updates until the device is
+available.
+
+Any signal handler that was registered before gets lost in this case.
+The developer of a device driver shall register a devices ROM signal handler
+once its devices were acquired, or shall only acquire devices known to be
+available, after inspecting the devices ROM independently.
+
+
+Platforms
+#########
+
+PinePhone
+=========
+
+Telephony
+~~~~~~~~~
+
+The current release introduces the principle ability to issue and receive
+voice calls with the PinePhone. This work involved two topics. First, we had
+to tackle the integration, configuration, and operation of the LTE modem. The
+second piece of the puzzle was the configuration of the audio paths between
+the mic, the speaker, and the modem. Since the complexity of those topics
+would exceed the scope of the release documentation, the technical details are
+covered in a dedicated article.
+
+:Pine fun - Telephony _(Roger, Roger?)_:
+
+  [https://genodians.org/ssumpf/2022-05-09-telephony]
+
+[image pinephone_telephony]
+
+The image above illustrates a simple system exemplified by the
+[https://github.com/genodelabs/genode-allwinner/blob/master/run/modem_pinephone.run - modem_pinephone.run]
+script. It allows a terminal emulator on a host machine connected to the
+serial connector of the PinePhone to interact with the command interface of
+the modem, e.g., allowing the user to unlock the SIM card via the 'AT+CPIN'
+command, or to issue a call using the 'ATD' command.
+
+
+Custom system-control processor (SCP) firmware
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Battery lifetime is one of the most pressing concerns for mobile phones. While
+exploring the PinePhone hardware, we discovered early on that the key for
+sophisticated energy management lies in the so-called system control processor
+(SCP), which is a low-power companion microcontroller that complements the
+high-performance application processor. The SCP can remain active even if the
+device is visibly switched off.
+Surprisingly, even though its designated purpose is rather narrow, the SCP is
+a freely programmable general-purpose CPU (called AR100) with ultimate access
+to every corner of the SoC. It can control all peripherals including the
+modem, and access the entirety of physical memory.
+
+In contrast to most consumer devices, which operate their SCPs with
+proprietary firmware, the PinePhone gives users the freedom to use an
+open-source firmware called [https://github.com/crust-firmware/crust - Crust].
+Moreover, the Crust developers thoroughly documented their findings of the
+[https://linux-sunxi.org/AR100 - AR100 limitations] and its
+[https://linux-sunxi.org/AR100/HardwareSharing - interplay with the ARM CPU].
+
+Given that the Crust firmware was specifically developed to augment a
+Linux-based OS with suspend-resume functionality, its fixed-function feature
+set is rather constrained. For running Genode on the PinePhone, we'd like to
+move more freely, e.g., letting the SCP interact with the modem while the
+application processor is powered off. To break free from the limitations of a
+fixed-function feature set of an SCP firmware implemented in C, we explored
+the opportunity to deploy a minimal-complexity Forth interpreter as the basis
+for a custom SCP firmware. The story behind this line of development is
+covered by the following dedicated article:
+
+:Darling, I FORTHified my PinePhone!:
+
+  [https://genodians.org/nfeske/2022-03-29-pinephone-forth]
+
+
+Inter-communication between SCP and ARM
+---------------------------------------
+
+To enable a tight interplay of Genode with the SCP, we introduce a new
+[https://github.com/genodelabs/genode-allwinner/tree/master/include/scp_session - interface] and
+[https://github.com/genodelabs/genode-allwinner/tree/master/src/drivers/scp/a64 - driver]
+for supplying and invoking custom functionality to the SCP at runtime.
+The new "Scp" service allows clients to supply snippets of Forth code for
+execution at the SCP and retrieve the result. Both the program and the result
+are constrained to 1000 bytes. Hence, the loading of larger programs may need
+multiple subsequent 'Scp::Connection::execute' calls.
+
+As illustrated by the example
+[https://github.com/genodelabs/genode-allwinner/blob/master/run/a64_scp_drv.run - a64_scp_drv.run]
+script, the mechanism supports multiple clients. Since the SCP's state is
+global, however, all clients are expected to behave cooperatively. Given the
+SCP's ultimate power, SCP clients must be fully trusted anyway.
+
+As a nice tidbit for development, the PinePhone-specific SCP firmware features
+a break-in debug shell for interactive use over UART that can be activated by
+briefly connecting the INT and GND
+[https://wiki.pine64.org/index.php/PinePhone#Pogo_pins - pogo pins].
+Note that this interactive debugging facility works independently from the
+application processor. Hence, it can be invoked at any time, e.g., to inspect
+any hardware register while running a regular Linux distribution on the phone.
+
+
+NXP i.MX8
+=========
+
+Analogously to the PCI decoder introduced in Section [Platform driver], a
+component to retrieve PCI information on the i.MX 8MQ is part of this release.
+It reports all PCI devices found behind the PCI Express host controller(s)
+detected. In contrast to the PCI decoder, it has to initialize the PCI Express
+host controller first, and needs device resources from the platform driver to
+do so before. The component resides in the
+[https://github.com/genodelabs/genode-imx - genode-imx]
+repository and is called _imx8mq_pci_host_drv_.
+
+
+Xilinx Zynq
+===========
+
+For the Zynq-7000 SoCs, we focused on two main topics in this release. First,
+we leveraged the aforementioned improvements on the generic platform driver to
+handle the (dis)appearance of devices in consequence of FPGA reconfiguration.
+Second, we applied our new DDE Linux approach in order to port the SD-card
+driver.
+
+The platform driver for the Xilinx Zynq is now available in the
+[https://github.com/genodelabs/genode-zynq - genode-zynq] repository as
+_src/zynq_platform_drv_. The default devices ROMs are provided by the
+_raw/<board>-devices_ archives. In addition to the generic driver, it features
+the readout of clock frequencies. You can use _zynq_clocks.run_ to dump the
+frequencies of all clocks.
+
+Since the Xilinx Zynq comprises an FPGA that can be reconfigured at run time,
+we also need to handle the appearance and disappearance of devices. For this
+purpose, we added a driver manager that consumes the platform driver's devices
+report and launches respectively kills device drivers accordingly. This
+scenario is accompanied by the _pkg/drivers_fpga-zynq_ archive that assembles
+the _devices_ ROM for the platform driver depending on the FPGA's
+reconfiguration state. The figure below illustrates this scenario: The
+subsystem provided by the _pkg/drivers_fpga-zynq_ archive is a replacement for
+the platform driver. It consumes the _fpga.bit_ ROM that contains the FPGA's
+bitstream. Once the bitstream has been loaded, the _fpga_devices_ ROM is
+merged with the _devices_ ROM provided by the _raw/<board>-devices_ archive.
+The _policy_ ROM contains the config of the internal zynq_platform_driver
+(policies and reporting config). By enabling device reporting, the
+zynq_driver_manager is able to react upon device changes and updates the
+_init.config_ for a drivers subsystem accordingly. An example is available in
+_run/zynq_driver_manager.run_.
+
+[image zynq_driver_manager]
+
+As a prerequisite for porting the first driver for the Zynq following our new
+DDE Linux approach, we added a zynq_linux target that builds a stripped-down
+Linux kernel for the Xilinx Zynq. Although Xilinx provides its own vendor
+kernel, most drivers have been mainlined. To eliminate version mismatch
+issues, we therefore use our mainline Linux port from _repos/dde_linux_
+instead. With this foundation, we were able to port the SD card driver, which
+is now available as _src/zynq_sd_card_drv_.
--- a/doc/road_map.txt
+++ b/doc/road_map.txt
@@ -35,7 +35,7 @@ for Genode with very little friction. On the way, we created new methodology
 and tooling, as well as extensive documentation in the form of the "Genode
 Platforms" document. Thanks to the new drivers ported from the Linux kernel,
 we were able to witness interactive Genode scenarios becoming alive on the
-Pinephone by the end of the year.
+PinePhone by the end of the year.

 The third major topic was the growing sophistication of Genode-native
 workloads, with the media features of the Chromium-based browser on 64-bit ARM
@@ -66,22 +66,22 @@ outcome, which will hopefully propel Genode to new heights in 2022.
 2022 - Mobile Usability
 #######################

-After having enabled the first interactive Genode scenarios on the Pinephone
-last year, we plan to take Genode on the Pinephone to a level where we can
+After having enabled the first interactive Genode scenarios on the PinePhone
+last year, we plan to take Genode on the PinePhone to a level where we can
 routinely use it for advanced applications, in particular video chat. This
 vision confronts us with a multitude of hard technical nuts to crack such as
 power efficiency, UI latency, quality-of-service of audio processing, drivers
 for multi-media devices, WebRTC performance, and usability. This grand theme
-will not only address the Pinephone specifically. The efficiency gains will
+will not only address the PinePhone specifically. The efficiency gains will
 benefit all Genode use cases large and small.

-Our theme of the Genode-based video chat on the Pinephone fuels several
+Our theme of the Genode-based video chat on the PinePhone fuels several
 ambitions in closely related areas. In particular, we aspire using WireGuard
 to secure private communication, and experiment with the operation of
 hardware-based trust anchors as the basis for encrypted storage and
 communication.

-Besides the Pinephone, we will steadily nurture the quality and scope of
+Besides the PinePhone, we will steadily nurture the quality and scope of
 driver support on PC hardware, which remains the primary platform for the
 day-to-day use of Sculpt OS. So you can expect us to keep up with recent
 generations of Intel-based hardware. In this area, we plan to make IOMMU
@@ -102,7 +102,7 @@ February - Release 22.02

 * OpenGL in VirtualBox 6
 * Sculpt OS as tool kit for special-purpose OS images
-* Pinephone
+* PinePhone
  * Modem access
  * Touch-screen compatibility of Sculpt OS

@@ -115,13 +115,13 @@ May - Release 22.05
 * WireGuard VPN
 * Updated drivers for PC hardware (Wifi, Intel framebuffer, USB)
 * New tracing tool with support for CTF and PCAP
-* Pinephone telephony
+* PinePhone telephony


 August - Release 22.08
 ======================

-* Pinephone
+* PinePhone
  * Morph browser
  * Media record and playback capabilities
 * FPGA-powered DMA protection for the Zynq-7000 SoC
@@ -132,7 +132,7 @@ August - Release 22.08
 November - Release 22.11
 ========================

-* Pinephone
+* PinePhone
  * WebRTC-based video chat
  * Power management
 * Base mechanism for suspend-resume on PC hardware
--- a/repos/README
+++ b/repos/README
@@ -26,22 +26,22 @@ but build upon of each other:
  These directories contain platform-specific source-code repositories
  complementing the 'base' repository. The following platforms are supported:

+  :'hw':
+    The hw platform hosts Genode on a custom microkernel specifically
+    developed for Genode. The name "hw" denotes that Genode is executed on
+    bare hardware without a 3rd-party kernel underneath.
+
  :'linux':
    Linux kernel (both x86_32 and x86_64)

  :'nova':
-    NOVA hypervisor developed at University of Technology Dresden
+    NOVA hypervisor ([https://hypervisor.org])

  :'foc':
    Fiasco.OC is a modernized version of the Fiasco microkernel with a
    completely revised kernel interface fostering capability-based
    security. It is not compatible with L4/Fiasco.

-  :'hw':
-    The hw platform allows the execution of Genode on bare ARM and x86 hardware
-    without the need for a separate kernel. The kernel functionality is
-    included in core.
-
  :'okl4':
    OKL4 kernel (x86_32 and ARM) developed at Open-Kernel-Labs.

@@ -52,13 +52,12 @@ but build upon of each other:
    L4/Fiasco kernel developed at University of Technology Dresden.

  :'sel4':
-    seL4 microkernel developed at NICTA/General Dynamics
-    See[https://sel4.systems/]
+    seL4 microkernel ([https://sel4.systems/])

 :'os':

-  This directory contains the non-base OS components such as the init process,
-  device drivers, and basic system services.
+  This directory contains the non-base OS components such as the init
+  component, device drivers, and basic system services.

 :'demo':

@@ -78,18 +77,17 @@ but build upon of each other:
  upstream source code but means to download the code and adapt it to Genode.
  For instructions about how to use this mechanism, please consult the README
  file at the top level of the repository. Among the 3rd-party libraries
-  are Qt5, libSDL, freetype, Python, ncurses, Mesa, and libav.
+  are Qt5, freetype, ncurses, and Mesa.

 :'dde_linux':

  This source-code repository contains the device driver environment for
-  executing Linux device drivers natively on Genode. Currently, this
-  repository hosts the USB stack.
+  executing Linux subsystems as Genode components.

 :'dde_ipxe':

  This source-code repository contains the device-driver environment for
-  executing drivers of the iPXE project.
+  executing network drivers of the iPXE project.

 :'dde_bsd':

--- a/repos/base-fiasco/lib/mk/kernel-fiasco.inc
+++ b/repos/base-fiasco/lib/mk/kernel-fiasco.inc
@@ -10,20 +10,17 @@ KERNEL_CXXFLAGS = -std=gnu++98 -fno-delete-null-pointer-checks $(CXXWARN) \
                  -Wno-address-of-packed-member

 $(FIASCO_BUILD_DIR):
-	$(VERBOSE_MK) set -o pipefail; \
-	              MAKEFLAGS= $(MAKE) SYSTEM_TARGET="$(CROSS_DEV_PREFIX)" \
+	$(VERBOSE_MK) MAKEFLAGS= $(MAKE) SYSTEM_TARGET="$(CROSS_DEV_PREFIX)" \
 	                                 $(VERBOSE_DIR) -C $(FIASCO_SRC) BUILDDIR=$@ \
 	                                 $(KERNEL_BUILD_OUTPUT_FILTER)
 	$(VERBOSE)cp $(KERNEL_CONFIG) $@/globalconfig.out
-	$(VERBOSE_MK) set -o pipefail; \
-	              MAKEFLAGS= $(MAKE) SYSTEM_TARGET="$(CROSS_DEV_PREFIX)" \
+	$(VERBOSE_MK) MAKEFLAGS= $(MAKE) SYSTEM_TARGET="$(CROSS_DEV_PREFIX)" \
 	                                 $(VERBOSE_DIR) -C $@ oldconfig \
 	                                 $(KERNEL_BUILD_OUTPUT_FILTER)
 	$(VERBOSE)cp $(KERNEL_CONFIG) $@/globalconfig.out

 $(FIASCO): $(FIASCO_BUILD_DIR)
-	$(VERBOSE_MK) set -o pipefail; \
-	              MAKEFLAGS= CFLAGS="-std=gnu89 $(CWARN)" \
+	$(VERBOSE_MK) MAKEFLAGS= CFLAGS="-std=gnu89 $(CWARN)" \
 	              CXXFLAGS="$(KERNEL_CXXFLAGS)" \
 	              $(MAKE) SYSTEM_TARGET="$(CROSS_DEV_PREFIX)" \
 	                                 $(VERBOSE_DIR) -C $(FIASCO_BUILD_DIR) \
--- a/repos/base-fiasco/lib/mk/l4_pkg.inc
+++ b/repos/base-fiasco/lib/mk/l4_pkg.inc
@@ -33,6 +33,9 @@ ifeq ($(VERBOSE),)
 L4_VERBOSE = V=1
 endif

+# do not confuse third-party sub-makes
+unexport .SHELLFLAGS
+
 #
 # Execute the rules in this file only at the second build stage when we know
 # about the complete build settings, e.g., 'CROSS_DEV_PREFIX'.
@@ -61,8 +64,7 @@ CXXWARN = $(WARN) -Wno-bool-compare -Wno-c++11-compat -Wno-class-memaccess
 # 'off64_t' type, which is used by bootstrap.
 #
 %.tag:
-	$(VERBOSE_MK) set -o pipefail; \
-	              MAKEFLAGS= CPPFLAGS="$(CC_MARCH)" \
+	$(VERBOSE_MK) MAKEFLAGS= CPPFLAGS="$(CC_MARCH)" \
 	              CFLAGS="$(CC_MARCH) -std=gnu89 $(CWARN)" \
 	              CXXFLAGS="$(CC_MARCH) -D_GNU_SOURCE -std=gnu++98 $(CXXWARN)" \
 	              ASFLAGS="$(CC_MARCH)" LDFLAGS="$(LD_MARCH)" \
--- a/repos/base-fiasco/lib/mk/syscall-fiasco.inc
+++ b/repos/base-fiasco/lib/mk/syscall-fiasco.inc
@@ -15,7 +15,7 @@ L4_BUILD_DIR := $(shell pwd)
 .Makeconf.bid.old:
 	$(VERBOSE)mkdir -p $(dir $@)
 	$(VERBOSE)cp $(L4_CONFIG) $(@:.old=)
-	$(VERBOSE_MK) set -o pipefail; \
+	$(VERBOSE_MK) \
 	   MAKEFLAGS= make $(VERBOSE_DIR) -C $(L4_SRC_DIR)/l4 \
 	   O=$(L4_BUILD_DIR) SYSTEM_TARGET="$(CROSS_DEV_PREFIX)" oldconfig \
 	   2>&1 | sed "s/^/      [l4build]  /"
--- a/repos/base-fiasco/recipes/src/base-fiasco/hash
+++ b/repos/base-fiasco/recipes/src/base-fiasco/hash
@@ -1 +1 @@
-2022-02-27 f339b49bb923456b6ca69bb7abd1a883d31b51fc
+2022-05-24 1790ce242c001ed77aab9695f69923a44d1dc1d1
--- a/repos/base-foc/lib/mk/kernel-foc.inc
+++ b/repos/base-foc/lib/mk/kernel-foc.inc
@@ -8,15 +8,13 @@ MAKEOVERRIDES := $(filter-out KERNEL=%,$(MAKEOVERRIDES))
 unexport KERNEL

 $(FOC_BUILD_DIR):
-	$(VERBOSE_MK) set -o pipefail; \
-	              $(MAKE) CROSS_COMPILE="$(CROSS_DEV_PREFIX)" \
+	$(VERBOSE_MK) $(MAKE) CROSS_COMPILE="$(CROSS_DEV_PREFIX)" \
 	                      $(VERBOSE_DIR) -C $(FOC_SRC) BUILDDIR=$@ \
 	                      $(KERNEL_BUILD_OUTPUT_FILTER)
 	$(VERBOSE)cp $(KERNEL_CONFIG) $@/globalconfig.out

 $(FOC): $(FOC_BUILD_DIR)
-	$(VERBOSE_MK) set -o pipefail; \
-	              $(MAKE) CROSS_COMPILE="$(CROSS_DEV_PREFIX)" \
+	$(VERBOSE_MK) $(MAKE) CROSS_COMPILE="$(CROSS_DEV_PREFIX)" \
 	                      CC="$(CC)" CXX="$(CXX)" \
 	                      $(VERBOSE_DIR) -C $(FOC_BUILD_DIR) \
 	                      $(KERNEL_BUILD_OUTPUT_FILTER)
--- a/repos/base-foc/lib/mk/l4_pkg.inc
+++ b/repos/base-foc/lib/mk/l4_pkg.inc
@@ -39,6 +39,9 @@ PKG_TAGS     = $(addsuffix .tag,$(addsuffix .$(BOARD),$(PKGS)))

 BUILD_OUTPUT_FILTER = 2>&1 | sed "s~^~      [$*]  ~"

+# do not confuse third-party sub-makes
+unexport .SHELLFLAGS
+
 #
 # Execute the rules in this file only at the second build stage when we know
 # about the complete build settings, e.g., 'CROSS_DEV_PREFIX'.
@@ -55,8 +58,7 @@ endif
 .NOTPARALLEL: $(PKG_TAGS)

 %.$(BOARD).tag:
-	$(VERBOSE_MK) set -o pipefail; \
-	              $(MAKE) $(VERBOSE_DIR) O=$(L4_BUILD_DIR) -C $(L4_PKG_DIR)/$* \
+	$(VERBOSE_MK) $(MAKE) $(VERBOSE_DIR) O=$(L4_BUILD_DIR) -C $(L4_PKG_DIR)/$* \
 	                      "$(L4_BUILD_OPT)" WARNINGS=$(WARNINGS) $(BUILD_OUTPUT_FILTER)
 	$(VERBOSE)mkdir -p $(dir $@) && touch $@

--- a/repos/base-foc/lib/mk/syscall-foc.inc
+++ b/repos/base-foc/lib/mk/syscall-foc.inc
@@ -37,7 +37,7 @@ CC_OPT += -DL4SYS_USE_UTCB_WRAP=1 -Wno-unused-function
 # build system will stuble over predefined variables, i.e., 'LIB'
 #
 $(L4_BUILD_DIR)/.kconfig:
-	$(VERBOSE_MK) set -o pipefail; \
+	$(VERBOSE_MK) \
 	     MAKEFLAGS= $(MAKE) $(VERBOSE_DIR) -C $(L4_SRC_DIR)/l4 \
 	     B=$(L4_BUILD_DIR) DROPSCONF_DEFCONFIG="$(L4_CONFIG)" \
 	     VERBOSE="$(VERBOSE)" CROSS_COMPILE="$(CROSS_DEV_PREFIX)" \
--- a/repos/base-foc/recipes/src/base-foc-imx6q_sabrelite/hash
+++ b/repos/base-foc/recipes/src/base-foc-imx6q_sabrelite/hash
@@ -1 +1 @@
-2022-02-27 cf39679df76dd41650f89694fffa660af1c6ee32
+2022-05-24 f7900083623a2009d35234c47d2475dea8f6cf53
--- a/repos/base-foc/recipes/src/base-foc-imx7d_sabre/hash
+++ b/repos/base-foc/recipes/src/base-foc-imx7d_sabre/hash
@@ -1 +1 @@
-2022-02-27 eedec64df2d3b087b1396078b2b8bc6da36bf6ae
+2022-05-24 f7d228f6419c2fc9b1b0faf4ba8d88862ba61e81
--- a/repos/base-foc/recipes/src/base-foc-pbxa9/hash
+++ b/repos/base-foc/recipes/src/base-foc-pbxa9/hash
@@ -1 +1 @@
-2022-02-27 035701a0c05461ee2381447de985f42fab5dbe34
+2022-05-24 391b798b7c1d1b44ff65d855980eb41a8f4a87c1
--- a/repos/base-foc/recipes/src/base-foc-pc/hash
+++ b/repos/base-foc/recipes/src/base-foc-pc/hash
@@ -1 +1 @@
-2022-02-27 bd9cc55e5f41615e5474586a4d10483999545194
+2022-05-24 79eab679e71dd70803b0e1647a23e2ba86c76f50
--- a/repos/base-foc/recipes/src/base-foc-rpi3/hash
+++ b/repos/base-foc/recipes/src/base-foc-rpi3/hash
@@ -1 +1 @@
-2022-02-27 6268532bb738c2d80d7f740ae32a931885bd94e8
+2022-05-24 7a16aeb081d1392c36d83f526936f17cc9560442
--- a/repos/base-hw/recipes/src/base-hw-imx53_qsb/hash
+++ b/repos/base-hw/recipes/src/base-hw-imx53_qsb/hash
@@ -1 +1 @@
-2022-02-27 86fe94edde9d2b89e46a8098af26a1c827a10912
+2022-05-24 ab1cb582165e76bda4abf27870f44ad7d1ae5b6d
--- a/repos/base-hw/recipes/src/base-hw-imx53_qsb_tz/hash
+++ b/repos/base-hw/recipes/src/base-hw-imx53_qsb_tz/hash
@@ -1 +1 @@
-2022-02-27 f19e4c9dc14afd51c14a8f0d87d4f5a34a842b45
+2022-05-24 0fff6ce83b962b3fd54cf6eda0a157cb0cb0c9d5
--- a/repos/base-hw/recipes/src/base-hw-imx6q_sabrelite/hash
+++ b/repos/base-hw/recipes/src/base-hw-imx6q_sabrelite/hash
@@ -1 +1 @@
-2022-02-27 29541794e3f7a29552d0f0000b15e7414d8689a8
+2022-05-24 8c17512664a648eaed876c815ea678770eda3280
--- a/repos/base-hw/recipes/src/base-hw-imx7d_sabre/hash
+++ b/repos/base-hw/recipes/src/base-hw-imx7d_sabre/hash
@@ -1 +1 @@
-2022-02-27 ec09a1dc249e204d0908a4d02cccabde37a8c39a
+2022-05-24 edc396d9bc9a2ebf73590e70c1363020226909be
--- a/repos/base-hw/recipes/src/base-hw-nit6_solox/hash
+++ b/repos/base-hw/recipes/src/base-hw-nit6_solox/hash
@@ -1 +1 @@
-2022-02-27 a1cf4cdd8bb293cd3049ad79ceb0b2d6ae96bc44
+2022-05-24 da90478c4c0b8993041bc59488eedb124e680e78
--- a/repos/base-hw/recipes/src/base-hw-pbxa9/hash
+++ b/repos/base-hw/recipes/src/base-hw-pbxa9/hash
@@ -1 +1 @@
-2022-02-27 fb2fe319193d1867bb9299102c34e5d4c1520952
+2022-05-24 1b34e317209c48bfc88af6118db32be261ce3e0c
--- a/repos/base-hw/recipes/src/base-hw-pc/hash
+++ b/repos/base-hw/recipes/src/base-hw-pc/hash
@@ -1 +1 @@
-2022-02-27 6740dba40d45e35c25b0c14b20a929b391aec073
+2022-05-24 46e9f88209bbc95228d3882cc0831770315402e4
--- a/repos/base-hw/recipes/src/base-hw-virt_qemu/hash
+++ b/repos/base-hw/recipes/src/base-hw-virt_qemu/hash
@@ -1 +1 @@
-2022-02-27 6bb1986efdbfd7d6c27af421f3fbb703028c9328
+2022-05-24 bb6c39c093a24d2ec4ff1d00e397529c51e95fa7
--- a/repos/base-hw/src/core/hw/target.mk
+++ b/repos/base-hw/src/core/hw/target.mk
@@ -3,6 +3,4 @@ TARGET   := core-hw-$(BOARD)
 LIBS     := core-hw-$(BOARD)
 CORE_LIB := core-hw-$(BOARD).a

-BUILD_ARTIFACTS := $(CORE_LIB)
-
 include $(BASE_DIR)/src/core/target.inc
--- a/repos/base-hw/src/include/hw/spec/arm/pl310.h
+++ b/repos/base-hw/src/include/hw/spec/arm/pl310.h
@@ -95,8 +95,9 @@ class Hw::Pl310 : public Genode::Mmio

 		struct Prefetch_ctrl : Register<0xf60, 32>
 		{
-			struct Data_prefetch : Bitfield<28,1> { };
-			struct Inst_prefetch : Bitfield<29,1> { };
+			struct Data_prefetch   : Bitfield<28,1> { };
+			struct Inst_prefetch   : Bitfield<29,1> { };
+			struct Double_linefill : Bitfield<30,1> { };
 		};

 		void _sync() { while (read<Cache_sync>()) ; }
--- a/repos/base-linux/recipes/api/base-linux/hash
+++ b/repos/base-linux/recipes/api/base-linux/hash
@@ -1 +1 @@
-2022-02-14 32d9ab730448e7d3f66752ba6130f6991158fd83
+2022-04-12 dcb2c9200b333adb17f9a8737620cbd84f641408
--- a/repos/base-linux/recipes/src/base-linux/hash
+++ b/repos/base-linux/recipes/src/base-linux/hash
@@ -1 +1 @@
-2022-02-27 02edbf0edb013cb9ca8b96b92f566a365c1d7d7b
+2022-05-24 4aea382035415c79bf5d551642ebfa64d42e4d21
--- a/repos/base-linux/src/core/spec/pc/dataspace_component.cc
+++ b/repos/base-linux/src/core/spec/pc/dataspace_component.cc
@@ -54,7 +54,7 @@ Linux_dataspace::Filename Dataspace_component::_file_name(const char *args)
 Genode::size_t Dataspace_component::_file_size()
 {
 	uint64_t size = 0;
-	if (lx_stat_size(_fname.buf, &size) < 0)
+	if (lx_stat_size(_fname.buf, size) < 0)
 		throw Service_denied();

 	return size;
--- a/repos/base-linux/src/core/spec/pc/io_port_session_component.cc
+++ b/repos/base-linux/src/core/spec/pc/io_port_session_component.cc
@@ -23,8 +23,8 @@ Io_port_session_component::Io_port_session_component(Range_allocator &io_port_al
 	_io_port_alloc(io_port_alloc)
 {
 	/* parse for port properties */
-	_base = Arg_string::find_arg(args, "io_port_base").ulong_value(0);
-	_size = Arg_string::find_arg(args, "io_port_size").ulong_value(0);
+	_base = (unsigned short)Arg_string::find_arg(args, "io_port_base").ulong_value(0);
+	_size = (unsigned short)Arg_string::find_arg(args, "io_port_size").ulong_value(0);
 }

 Io_port_session_component::~Io_port_session_component() { }
--- a/repos/base-linux/src/core/spec/pc/irq_session_component.cc
+++ b/repos/base-linux/src/core/spec/pc/irq_session_component.cc
@@ -26,7 +26,7 @@ using namespace Genode;

 Irq_session_component::Irq_session_component(Range_allocator &, const char *args)
 :
-	_irq_number(Arg_string::find_arg(args, "irq_number").long_value(-1)),
+	_irq_number((unsigned)Arg_string::find_arg(args, "irq_number").long_value(-1)),
 	_irq_object(_irq_number)
 {
 	_irq_object.start();
--- a/repos/base-nova/include/nova/syscall-generic.h
+++ b/repos/base-nova/include/nova/syscall-generic.h
@@ -242,6 +242,14 @@ namespace Nova {
 		EC_DONATE_SC = 2U,
 		EC_RESCHEDULE = 3U,
 		EC_MIGRATE = 4U,
+		EC_TIME = 5U,
+	};
+
+	enum Sc_op {
+		SC_TIME_IDLE   = 0,
+		SC_TIME_CROSS  = 1,
+		SC_TIME_KILLED = 2,
+		SC_EC_TIME     = 3,
 	};

 	/**
--- a/repos/base-nova/include/spec/32bit/nova/syscalls.h
+++ b/repos/base-nova/include/spec/32bit/nova/syscalls.h
@@ -182,6 +182,40 @@ namespace Nova {
 		return (uint8_t)status;
 	}

+
+	ALWAYS_INLINE
+	inline uint8_t syscall_6(Syscall s, uint8_t flags, unsigned sel,
+	                         mword_t &p1, mword_t &p2, mword_t &p3,
+	                         mword_t &p4)
+	{
+		mword_t status = eax(s, flags, sel);
+
+		asm volatile ("  push %%ebp;"
+		              "  push %%ebx;"
+
+		              "  mov %%ecx, %%ebx;"
+		              "  mov %%esp, %%ecx;"
+		              "  mov %%edx, %%ebp;"
+
+		              "  call 0f;"
+		              "0:"
+		              "  addl $(1f-0b), (%%esp);"
+		              "  mov (%%esp), %%edx;"
+		              "sysenter;"
+		              "1:"
+
+		              "  mov %%ebp, %%edx;"
+		              "  mov %%ebx, %%ecx;"
+		              "  pop %%ebx;"
+		              "  pop %%ebp;"
+		              : "+a" (status), "+D" (p1), "+S" (p2), "+c" (p3),
+		                "+d" (p4)
+		              :
+		              : "memory");
+		return (uint8_t)status;
+	}
+
+
 	ALWAYS_INLINE
 	inline uint8_t call(unsigned pt)
 	{
@@ -239,14 +273,51 @@ namespace Nova {
 	}


+	ALWAYS_INLINE
+	inline uint8_t util_time(Syscall const syscall, mword_t const cap,
+	                         uint8_t const op, unsigned long long &time)
+	{
+		mword_t time_h = 0, time_l = 0;
+		uint8_t res = syscall_5(syscall, op, cap, time_h, time_l);
+		time = (uint64_t(time_h) << 32ULL) | uint64_t(time_l);
+		return res;
+	}
+
+
+	ALWAYS_INLINE
+	inline uint8_t sc_ec_time(mword_t const cap_sc, mword_t const cap_ec,
+	                          unsigned long long &time_sc,
+	                          unsigned long long &time_ec)
+	{
+		mword_t time_h_sc = cap_ec, time_l_sc = 0;
+		mword_t time_h_ec = 0,      time_l_ec = 0;
+		uint8_t res = syscall_6(NOVA_SC_CTRL, Sc_op::SC_EC_TIME, cap_sc,
+		                        time_h_sc, time_l_sc, time_h_ec,
+		                        time_l_ec);
+		time_sc = (uint64_t(time_h_sc) << 32ULL) | uint64_t(time_l_sc);
+		time_ec = (uint64_t(time_h_ec) << 32ULL) | uint64_t(time_l_ec);
+		return res;
+	}
+
+
 	ALWAYS_INLINE
 	inline uint8_t ec_ctrl(Ec_op op, mword_t ec = ~0UL, mword_t para = ~0UL,
 	                       Crd crd = 0)
 	{
+		if (op == EC_TIME)
+			return NOVA_INV_HYPERCALL;
+
 		return syscall_2(NOVA_EC_CTRL, op, ec, para, crd.value());
 	}


+	ALWAYS_INLINE
+	inline uint8_t ec_time(mword_t const ec, unsigned long long &time)
+	{
+		return util_time(NOVA_EC_CTRL, ec, Ec_op::EC_TIME, time);
+	}
+
+
 	ALWAYS_INLINE
 	inline uint8_t create_sc(unsigned sc, unsigned pd, unsigned ec, Qpd qpd)
 	{
@@ -396,13 +467,9 @@ namespace Nova {


 	ALWAYS_INLINE
-	inline uint8_t sc_ctrl(unsigned sc, unsigned long long &time, uint8_t op = 0)
+	inline uint8_t sc_ctrl(unsigned const sc, unsigned long long &time, uint8_t op = 0)
 	{
-		mword_t time_h = 0, time_l = 0;
-		uint8_t res = syscall_5(NOVA_SC_CTRL, op, sc, time_h, time_l);
-		time = time_h;
-		time = (time << 32ULL) | time_l;
-		return res;
+		return util_time(NOVA_SC_CTRL, sc, op, time);
 	}
 }
 #endif /* _INCLUDE__SPEC__32BIT__NOVA__SYSCALLS_H_ */
--- a/repos/base-nova/include/spec/64bit/nova/syscalls.h
+++ b/repos/base-nova/include/spec/64bit/nova/syscalls.h
@@ -132,6 +132,24 @@ namespace Nova {
 		return  (uint8_t)status;
 	}

+	ALWAYS_INLINE
+	inline uint8_t syscall_6(Syscall s, uint8_t flags, mword_t sel,
+	                         mword_t &p1, mword_t &p2, mword_t &p3,
+	                         mword_t &p4)
+	{
+		mword_t status = rdi(s, flags, sel);
+
+		register mword_t r8 asm ("r8") = p4;
+
+		asm volatile ("syscall"
+		              : "+D" (status), "+S"(p1), "+d"(p2), "+a"(p3), "+r"(r8)
+		              :
+		              : "rcx", "r11", "memory");
+
+		p4 = r8;
+
+		return  (uint8_t)status;
+	}

 	ALWAYS_INLINE
 	inline uint8_t call(mword_t pt)
@@ -191,14 +209,51 @@ namespace Nova {
 	}


+	ALWAYS_INLINE
+	inline uint8_t util_time(Syscall const syscall, mword_t const cap,
+	                         uint8_t const op, unsigned long long &time)
+	{
+		mword_t time_h = 0, time_l = 0;
+		uint8_t res = syscall_5(syscall, op, cap, time_h, time_l);
+		time = (time_h << 32ULL) | (time_l & 0xFFFFFFFFULL);
+		return res;
+	}
+
+
+	ALWAYS_INLINE
+	inline uint8_t sc_ec_time(mword_t const cap_sc, mword_t const cap_ec,
+	                          unsigned long long &time_sc,
+	                          unsigned long long &time_ec)
+	{
+		mword_t time_h_sc = cap_ec, time_l_sc = 0;
+		mword_t time_h_ec = 0, time_l_ec = 0;
+		uint8_t res = syscall_6(NOVA_SC_CTRL, Sc_op::SC_EC_TIME, cap_sc,
+		                        time_h_sc, time_l_sc, time_h_ec,
+		                        time_l_ec);
+		time_sc = (time_h_sc << 32ULL) | (time_l_sc & 0xFFFFFFFFULL);
+		time_ec = (time_h_ec << 32ULL) | (time_l_ec & 0xFFFFFFFFULL);
+		return res;
+	}
+
+
 	ALWAYS_INLINE
 	inline uint8_t ec_ctrl(Ec_op op, mword_t ec = ~0UL, mword_t para = ~0UL,
 	                       Crd crd = 0)
 	{
+		if (op == EC_TIME)
+			return NOVA_INV_HYPERCALL;
+
 		return syscall_2(NOVA_EC_CTRL, op, ec, para, crd.value());
 	}


+	ALWAYS_INLINE
+	inline uint8_t ec_time(mword_t const ec, unsigned long long &time)
+	{
+		return util_time(NOVA_EC_CTRL, ec, Ec_op::EC_TIME, time);
+	}
+
+
 	ALWAYS_INLINE
 	inline uint8_t create_sc(mword_t sc, mword_t pd, mword_t ec, Qpd qpd)
 	{
@@ -316,13 +371,10 @@ namespace Nova {


 	ALWAYS_INLINE
-	inline uint8_t sc_ctrl(mword_t sm, unsigned long long &time, uint8_t op = 0)
+	inline uint8_t sc_ctrl(mword_t const sc, unsigned long long &time,
+	                       Sc_op const op)
 	{
-		mword_t time_h = 0, time_l = 0;
-		uint8_t res = syscall_5(NOVA_SC_CTRL, op, sm, time_h, time_l);
-		time = time_h;
-		time = (time << 32ULL) | (time_l & 0xFFFFFFFFULL);
-		return res;
+		return util_time(NOVA_SC_CTRL, sc, op, time);
 	}


--- a/repos/base-nova/ports/nova.hash
+++ b/repos/base-nova/ports/nova.hash
@@ -1 +1 @@
-7378ad91b30f517627a14488ff28af2a5c7f3026
+33a2fa953ec52b0f63b921f4d33d68891c0aada0
--- a/repos/base-nova/ports/nova.port
+++ b/repos/base-nova/ports/nova.port
@@ -4,7 +4,7 @@ DOWNLOADS := nova.git

 # r10 branch
 URL(nova) := https://github.com/alex-ab/NOVA.git
-REV(nova) := 5d107ddf9befe2473a80e6c4fa94b1eecae9b268
+REV(nova) := 00dc49bc18e7f72a9c85487e8f94fd859511d89d
 DIR(nova) := src/kernel/nova

 PATCHES   := $(sort $(wildcard $(REP_DIR)/patches/*.patch))
--- a/repos/base-nova/recipes/api/base-nova/hash
+++ b/repos/base-nova/recipes/api/base-nova/hash
@@ -1 +1 @@
-2021-12-16 d00dfe16c059040c919a1357290f72eea835c360
+2022-05-24 91bc8d51bbe703d56f5671019d14e4636f21bf1f
--- a/repos/base-nova/recipes/src/base-nova/hash
+++ b/repos/base-nova/recipes/src/base-nova/hash
@@ -1 +1 @@
-2022-02-27 8f1e69513f1470d57a49fd7e5d35def87fcacc7b
+2022-05-24 8b59a28ade1392bae4aa772bbead1584a2dde1de
--- a/repos/base-nova/src/core/irq_session_component.cc
+++ b/repos/base-nova/src/core/irq_session_component.cc
@@ -107,6 +107,11 @@ void Irq_object::sigh(Signal_context_capability cap)
 	if (!_sigh_cap.valid() && !cap.valid())
 		return;

+	if (_sigh_cap.valid() && _sigh_cap == cap) {
+		/* avoid useless overhead, e.g. with IOMMUs enabled */
+		return;
+	}
+
 	if ((_sigh_cap.valid() && !cap.valid())) {
 		deassociate(irq_sel());
 		_sigh_cap = Signal_context_capability();
--- a/repos/base-nova/src/core/platform.cc
+++ b/repos/base-nova/src/core/platform.cc
@@ -391,23 +391,6 @@ Platform::Platform()
 	              Obj_crd(sc_idle_base, log2cpu), true))
 		nova_die();

-	/* test reading out idle SCs */
-	bool sc_init = true;
-	for (unsigned i = 0; i < hip.cpu_max(); i++) {
-
-		if (!hip.is_cpu_enabled(i))
-			continue;
-
-		uint64_t n_time;
-		uint8_t res = Nova::sc_ctrl(sc_idle_base + i, n_time);
-		if (res != Nova::NOVA_OK) {
-			sc_init = false;
-			error(i, " ", res, " ", n_time, " - failed");
-		}
-	}
-	if (!sc_init)
-		nova_die();
-
 	/* configure virtual address spaces */
 #ifdef __x86_64__
 	_vm_size = 0x7fffc0000000UL - _vm_base;
@@ -865,19 +848,30 @@ Platform::Platform()
 			Info trace_source_info() const override
 			{
 				uint64_t sc_time = 0;
+				uint64_t ec_time = 0;
+				uint8_t  res = 0;

-				enum SYSCALL_OP { IDLE_SC = 0, CROSS_SC = 1,
-				                  KILLED_SC = 2 };
-				uint8_t syscall_op =  (name == "cross")  ? CROSS_SC :
-				                     ((name == "killed") ? KILLED_SC : IDLE_SC);
+				if (name == "killed") {
+					res = Nova::sc_ec_time(sc_sel, sc_sel,
+					                       sc_time, ec_time);
+				} else {
+					auto syscall_op = (name == "cross")
+					                ? Sc_op::SC_TIME_CROSS
+					                : Sc_op::SC_TIME_IDLE;
+
+					res = Nova::sc_ctrl(sc_sel, sc_time,
+					                    syscall_op);
+
+					if (syscall_op == Sc_op::SC_TIME_IDLE)
+						ec_time = sc_time;
+				}

-				uint8_t res = Nova::sc_ctrl(sc_sel, sc_time, syscall_op);
 				if (res != Nova::NOVA_OK)
-					warning("sc_ctrl on idle SC cap, op=", syscall_op,
+					warning("sc_ctrl on ", name, " failed"
 					        ", res=", res);

 				return { Session_label("kernel"), Trace::Thread_name(name),
-				         Trace::Execution_time(sc_time, sc_time), affinity };
+				         Trace::Execution_time(ec_time, sc_time), affinity };
 			}

 			Trace_source(Trace::Source_registry &registry,
@@ -920,16 +914,26 @@ Platform::Platform()
 		 */
 		Info trace_source_info() const override
 		{
+			uint64_t ec_time = 0;
 			uint64_t sc_time = 0;

 			if (name == "root") {
-				uint8_t res = Nova::sc_ctrl(ec_sc_sel + 1, sc_time);
+				uint8_t res = Nova::sc_ec_time(ec_sc_sel + 1,
+				                               ec_sc_sel,
+				                               sc_time,
+				                               ec_time);
 				if (res != Nova::NOVA_OK)
-					warning("sc_ctrl for ", name, " thread failed res=", res);
+					warning("sc_ec_time for root failed "
+					        "res=", res);
+			} else {
+				uint8_t res = Nova::ec_time(ec_sc_sel, ec_time);
+				if (res != Nova::NOVA_OK)
+					warning("ec_time for", name, " thread "
+					        "failed res=", res);
 			}

 			return { Session_label("core"), name,
-			         Trace::Execution_time(sc_time, sc_time), location };
+			         Trace::Execution_time(ec_time, sc_time), location };
 		}

 		Core_trace_source(Trace::Source_registry &registry,
--- a/repos/base-nova/src/core/platform_thread.cc
+++ b/repos/base-nova/src/core/platform_thread.cc
@@ -314,17 +314,22 @@ const char * Platform_thread::pd_name() const {

 Trace::Execution_time Platform_thread::execution_time() const
 {
-	unsigned long long time = 0;
+	uint64_t sc_time = 0;
+	uint64_t ec_time = 0;

-	/* for ECs without a SC we simply return 0 */
-	if (!sc_created())
-		return { time, time, Nova::Qpd::DEFAULT_QUANTUM, _priority };
+	if (!sc_created()) {
+		/* time executed by EC (on whatever SC) */
+		uint8_t res = Nova::ec_time(_sel_ec(), ec_time);
+		if (res != Nova::NOVA_OK)
+			warning("ec_time failed res=", res);
+		return { ec_time, sc_time, Nova::Qpd::DEFAULT_QUANTUM, _priority };
+	}

-	uint8_t res = Nova::sc_ctrl(_sel_sc(), time);
+	uint8_t res = Nova::sc_ec_time(_sel_sc(), _sel_ec(), sc_time, ec_time);
 	if (res != Nova::NOVA_OK)
 		warning("sc_ctrl failed res=", res);

-	return { time, time, Nova::Qpd::DEFAULT_QUANTUM, _priority };
+	return { ec_time, sc_time, Nova::Qpd::DEFAULT_QUANTUM, _priority };
 }


--- a/repos/base-nova/src/core/thread_start.cc
+++ b/repos/base-nova/src/core/thread_start.cc
@@ -127,10 +127,14 @@ void Thread::start()
 		 */
 		Info trace_source_info() const override
 		{
-			uint64_t sc_time = 0;
+			uint64_t ec_time = 0;
+
+			uint8_t res = Nova::ec_time(thread.native_thread().ec_sel, ec_time);
+			if (res != Nova::NOVA_OK)
+				warning("ec_time for core thread failed res=", res);

 			return { Session_label("core"), thread.name(),
-			         Trace::Execution_time(sc_time, sc_time), thread._affinity };
+			         Trace::Execution_time(ec_time, 0), thread._affinity };
 		}

 		Core_trace_source(Trace::Source_registry &registry, Thread &t)
--- a/repos/base-nova/src/core/vm_session_component.cc
+++ b/repos/base-nova/src/core/vm_session_component.cc
@@ -85,14 +85,15 @@ static uint8_t _with_kernel_quota_upgrade(addr_t const pd_target,

 Trace::Source::Info Vm_session_component::Vcpu::trace_source_info() const
 {
+	uint64_t ec_time = 0;
 	uint64_t sc_time = 0;

-	uint8_t res = Nova::sc_ctrl(sc_sel(), sc_time);
+	uint8_t res = Nova::sc_ec_time(sc_sel(), ec_sel(), sc_time, ec_time);
 	if (res != Nova::NOVA_OK)
-		warning("sc_ctrl failed res=", res);
+		warning("vCPU sc_ec_time failed res=", res);

 	return { _label, String<5>("vCPU"),
-	         Trace::Execution_time(sc_time, sc_time,
+	         Trace::Execution_time(ec_time, sc_time,
 	                               Nova::Qpd::DEFAULT_QUANTUM, _priority),
 	         _location };
 }
--- a/repos/base-okl4/recipes/src/base-okl4/hash
+++ b/repos/base-okl4/recipes/src/base-okl4/hash
@@ -1 +1 @@
-2022-02-27 c16146c1aac0bfa04f665b46f3d40809de9eeb13
+2022-05-24 3b2acba4ebd649394e26217802598cf650a4b226
--- a/repos/base-pistachio/lib/mk/syscall-pistachio.mk
+++ b/repos/base-pistachio/lib/mk/syscall-pistachio.mk
@@ -9,6 +9,9 @@ CC_WARN += -Wno-array-bounds -Wno-unused-but-set-variable \
           -Wno-parentheses -Wno-format -Wno-builtin-declaration-mismatch \
           -Wno-unused-function -Wno-pointer-compare

+# do not confuse third-party sub-makes
+unexport .SHELLFLAGS
+
 user_build.tag:
 	LIBGCCFLAGS="$(CC_MARCH)" \
 	LDFLAGS="$(addprefix $(LD_PREFIX),$(LD_MARCH)) -nostdlib" \
--- a/repos/base-pistachio/recipes/src/base-pistachio/hash
+++ b/repos/base-pistachio/recipes/src/base-pistachio/hash
@@ -1 +1 @@
-2022-02-27 4db1a992bb616cbd4ec2f6c6fdedf2934fea3d5f
+2022-05-24 ca2c90ebcbaa61ade7373d6ea48a608912cd2629
--- a/repos/base-pistachio/src/kernel/pistachio/target.mk
+++ b/repos/base-pistachio/src/kernel/pistachio/target.mk
@@ -24,6 +24,9 @@ $(KERNEL_BUILD_DIR)/Makefile:
 #
 unexport CCACHE

+# do not confuse third-party sub-makes
+unexport .SHELLFLAGS
+
 #
 # How to pass custom compiler flags to the Pistachio build system
 #
--- a/repos/base-sel4/recipes/src/base-sel4-imx6q_sabrelite/hash
+++ b/repos/base-sel4/recipes/src/base-sel4-imx6q_sabrelite/hash
@@ -1 +1 @@
-2022-02-27 a1ef9483e83102337f6c85f98e8582c1be47bb42
+2022-05-24 5d9558d34f4bd3f3e34d9b175fe3eb37be3561be
--- a/repos/base-sel4/recipes/src/base-sel4-imx7d_sabre/hash
+++ b/repos/base-sel4/recipes/src/base-sel4-imx7d_sabre/hash
@@ -1 +1 @@
-2022-02-27 16d269330a469d11295e0eaa1296c0182bfdcfe7
+2022-05-24 70a360e5c7b6aed126fb99fc3666cfce030cf53e
--- a/repos/base-sel4/recipes/src/base-sel4-x86/hash
+++ b/repos/base-sel4/recipes/src/base-sel4-x86/hash
@@ -1 +1 @@
-2022-02-27 61bc1e78758915de330f0450c0b005fb8054ac5e
+2022-05-24 fa03ec1bf7ea9b643319d67dbd52e146e0d98189
--- a/repos/base/board/pbxa9/devices
+++ b/repos/base/board/pbxa9/devices
@@ -0,0 +1,25 @@
+<devices>
+	<device name="sp810_syscon0" type="arm,sp810">
+		<io_mem address="0x10001000" size="0x1000"/>
+	</device>
+
+	<device name="clcd" type="arm,pl111">
+		<io_mem address="0x10020000" size="0x1000"/>
+	</device>
+
+	<device name="mmc0" type="arm,pl18x">
+		<io_mem address="0x10005000" size="0x1000"/>
+	</device>
+
+	<device name="pl050" type="arm,pl050">
+		<io_mem address="0x10006000" size="0x1000"/>
+		<io_mem address="0x10007000" size="0x1000"/>
+		<irq    number="52"/>
+		<irq    number="53"/>
+	</device>
+
+	<device name="ethernet" type="smsc,lan9118">
+		<io_mem address="0x4e000000" size="0x1000"/>
+		<irq    number="60"/>
+	</device>
+</devices>
--- a/repos/base/include/base/allocator_avl.h
+++ b/repos/base/include/base/allocator_avl.h
@@ -208,7 +208,7 @@ class Genode::Allocator_avl_base : public Range_allocator
 		void _cut_from_block(Block &b, addr_t cut_addr, size_t cut_size, Two_blocks);

 		template <typename ANY_BLOCK_FN>
-		void _revert_block_ranges(ANY_BLOCK_FN const &);
+		bool _revert_block_ranges(ANY_BLOCK_FN const &);

 		template <typename SEARCH_FN>
 		Alloc_result _allocate(size_t, unsigned, Range, SEARCH_FN const &);
@@ -225,7 +225,7 @@ class Genode::Allocator_avl_base : public Range_allocator
 		 * from the meta-data allocator.
 		 */
 		void _revert_allocations_and_ranges();
-		void _revert_unused_ranges();
+		bool _revert_unused_ranges();

 		/**
 		 * Find block by specified address
@@ -354,7 +354,15 @@ class Genode::Allocator_avl_tpl : public Allocator_avl_base
 		~Allocator_avl_tpl()
 		{
 			_revert_unused_ranges();
-			_metadata.free_empty_blocks();
+
+			/*
+			 * The release of empty blocks may add unused ranges (formerly used
+			 * by metadata). Thus, we loop until all empty blocks are freed and
+			 * no additional unused ranges appear.
+			 */
+			do {
+				_metadata.free_empty_blocks();
+			} while (_revert_unused_ranges());
 			_revert_allocations_and_ranges();
 		}

--- a/repos/base/include/base/log.h
+++ b/repos/base/include/base/log.h
@@ -23,7 +23,7 @@ namespace Genode {
 	class Log;
 	class Raw;
 	class Trace_output;
-	class Log_tsc_probe;
+	template <typename> class Log_tsc_probe;
 }


@@ -76,6 +76,15 @@ class Genode::Log
 		 * Return component-global singleton instance of the 'Log'
 		 */
 		static Log &log();
+
+		/**
+		 * Type for writing a log message, designated use as template argument
+		 */
+		struct Log_fn
+		{
+			template <typename... ARGS>
+			Log_fn(ARGS && ... args) { log().output(LOG, args...); }
+		};
 };


@@ -137,6 +146,18 @@ class Genode::Trace_output
 		 * Return component-global singleton instance of the 'Trace_output'
 		 */
 		static Trace_output &trace_output();
+
+		/**
+		 * Type for writing a trace entry, designated use as template argument
+		 */
+		struct Fn
+		{
+			template <typename... ARGS>
+			Fn(ARGS && ... args)
+			{
+				trace_output().output(Trace::timestamp(), ": ", args...);
+			}
+		};
 };


@@ -146,7 +167,7 @@ namespace Genode {
 	 * Write 'args' as a regular message to the log
 	 */
 	template <typename... ARGS>
-	void log(ARGS &&... args) { Log::log().output(Log::LOG, args...); }
+	void log(ARGS &&... args) { Log::Log_fn(args...); }


 	/**
@@ -187,14 +208,14 @@ namespace Genode {
 	 * The message is prefixed with a timestamp value
 	 */
 	template <typename... ARGS>
-	void trace(ARGS && ... args) {
-		Trace_output::trace_output().output(Trace::timestamp(), ": ", args...); }
+	void trace(ARGS && ... args) { Trace_output::Fn(args...); }
 }


 /*
 * Helper for the 'GENODE_LOG_TSC' utility
 */
+template <typename OUTPUT_FN>
 class Genode::Log_tsc_probe : Noncopyable
 {
 	private:
@@ -263,8 +284,8 @@ class Genode::Log_tsc_probe : Noncopyable
 					if (_cycle_count < _sample_rate)
 						return;

-					log(" TSC ", name, ": ", Pretty_tsc { _tsc_sum }, " "
-					    "(", _calls, " calls, last ", Pretty_tsc { duration }, ")");
+					OUTPUT_FN("TSC ", name, ": ", Pretty_tsc { _tsc_sum }, " "
+					          "(", _calls, " calls, last ", Pretty_tsc { duration }, ")");
 					_cycle_count = 0;
 				}

@@ -314,9 +335,7 @@ class Genode::Log_tsc_probe : Noncopyable
 * are printed. It allows for the tuning of the amount of output depending on
 * the instrumented function.
 */
-#define GENODE_LOG_TSC(n) \
-	static Genode::Log_tsc_probe::Stats genode_log_tsc_stats { n }; \
-	Genode::Log_tsc_probe genode_log_tsc_probe(genode_log_tsc_stats, __func__);
+#define GENODE_LOG_TSC(n) GENODE_LOG_TSC_NAMED(n, __func__)


 /**
@@ -327,8 +346,28 @@ class Genode::Log_tsc_probe : Noncopyable
 * within the same class or same-named methods of different classes.
 */
 #define GENODE_LOG_TSC_NAMED(n, name) \
-	static Genode::Log_tsc_probe::Stats genode_log_tsc_stats { n }; \
-	Genode::Log_tsc_probe genode_log_tsc_probe(genode_log_tsc_stats, name);
+	using Genode_log_tsc_probe = Genode::Log_tsc_probe<Genode::Log::Log_fn>; \
+	static Genode_log_tsc_probe::Stats genode_log_tsc_stats { n }; \
+	Genode_log_tsc_probe genode_log_tsc_probe(genode_log_tsc_stats, name);
+
+
+/**
+ * Trace TSC (time-stamp counter) ticks consumed by the calling function
+ *
+ * See the documentation of 'GENODE_LOG_TSC' for further information.
+ */
+#define GENODE_TRACE_TSC(n) GENODE_TRACE_TSC_NAMED(n, __func__)
+
+
+/**
+ * Variant of 'GENODE_TRACE_TSC' that accepts the name of the probe as argument
+ *
+ * See the documentation of 'GENODE_LOG_TSC_NAMED' for further information.
+ */
+#define GENODE_TRACE_TSC_NAMED(n, name) \
+	using Genode_log_tsc_probe = Genode::Log_tsc_probe<Genode::Trace_output::Fn>; \
+	static Genode_log_tsc_probe::Stats genode_log_tsc_stats { n }; \
+	Genode_log_tsc_probe genode_log_tsc_probe(genode_log_tsc_stats, name);


 #endif /* _INCLUDE__BASE__LOG_H_ */
--- a/repos/base/include/base/trace/buffer.h
+++ b/repos/base/include/base/trace/buffer.h
@@ -1,11 +1,94 @@
 /*
- * \brief  Event tracing infrastructure
+ * \brief  Event tracing buffer
 * \author Norman Feske
+ * \author Johannes Schlatow
 * \date   2013-08-09
+ *
+ * The trace buffer is shared between the traced component (producer) and
+ * the trace monitor (consumer). It basically is a lock-free/wait-free
+ * single-producer single-consumer (spsc) ring buffer. There are a couple of
+ * differences to a a standard spsc ring buffer:
+ *
+ *  - If the buffer is full, we want to overwrite the oldest data.
+ *  - We do not care about the consumer as it might not even exist. Hence,
+ *    the tail pointer shall be managed locally by the consumer.
+ *  - The buffer entries have variable length.
+ *
+ * As a consequence of the variable length, the entry length needs to be stored
+ * in each entry. A zero-length entry marks the head of the buffer (the entry
+ * that is written next). Moreover, we may need some padding at the end of the
+ * buffer if the entry does not fit in the remaing space. To distinguish the
+ * padding from the buffer head, it is marked by a length field with a maximum
+ * unsigned value.
+ *
+ * Let's have a look at the layout of a non-full buffer. The zero-length field
+ * marks the head. The consumer can stop reading when it sees this.
+ *
+ * +------------------------+------------+-------------+-----+-----------------+
+ * | len1             data1 | len2 data2 | len3  data3 |  0  | empty           |
+ * +------------------------+------------+-------------+-----+-----------------+
+ *
+ * Now, when the next entry does not fit into the remaining buffer space, it
+ * wraps around and starts at the beginning. The unused space at the end is
+ * padded:
+ *
+ * +------------------------+------------+-------------+-----+-----------------+
+ * | len4 data4 | 0 | empty | len2 data2 | len3  data3 | MAX | padding         |
+ * +------------------------+------------+-------------+-----+-----------------+
+ *
+ * If the consumer detects the padding it skips it and continues at the
+ * beginning. Note, that the padding is not present if there is less than a
+ * length field left at the end of the buffer.
+ *
+ * A potential consumer is supposed read new buffer entries fast enough as,
+ * otherwise, it will miss some entries. We count the buffer wrap arounds to
+ * detect this.
+ *
+ * Unfortunately, we cannot easily ensure that the producer does not overwrite
+ * entries that are currently read out and, even worse, void the consumer's
+ * tail pointer in the process. Also, it cannot be implicitly detected by
+ * looking at the wrapped count. Imagine the consumer stopped in the middle of
+ * the buffer since there are no more entries and resumes reading when the
+ * producer wrapped once and almost caught up with the consumers position. The
+ * consumer sees that the buffer wrapped only once but can still be corruped
+ * by the producer.
+ *
+ * In order to prevent this, we need a way to determine on the producer side
+ * where the consumer currently resides in the buffer and a) prevent that the
+ * producer overwrites these parts of the buffer and b) still be able to
+ * write the most recent buffer entry to some place.
+ *
+ * One way to approach this could be to store the tail pointer in the buffer
+ * and ensure that the head never overtakes the tail. The producer could
+ * continue writing from the start of the buffer instead. A critical corner
+ * case, however, occurs when the tail pointer resides at the very beginning
+ * of the buffer. In this case, newly produced entries must be dropped.
+ *
+ * Another approach is to split the buffer into two equal
+ * partitions. The foreground partition is the one currently written so that
+ * the background partition can be read without memory corruption. When the
+ * foreground partition is full, the producer switches the partitions and starts
+ * overwriting old entries in the former background partition. By locking the
+ * background partition, the consumer makes sure that the producer does not
+ * switch partitions. This way we assure that the head pointer never overtakes
+ * the tail pointer. In case the background partition is locked when the
+ * producer wants to switch partitions, it starts overwriting the foreground
+ * partition. The producer increments a counter for each partition whenever it
+ * overwrites the very first entry. This way the consumer is able to detect if
+ * it lost some events.
+ *
+ * The consumer is also able to lock the foreground partition so that it does
+ * not need to wait for the producer to fill it and switch partitions. Yet,
+ * it must never lock both partitions as this would stall the producer. We
+ * ensure this making the unlock-background-lock-foreground operation atomic.
+ * In case the consumer crashed when a lock is held, the producer is still able
+ * to use half of the buffer. Care must be taken, however, to eliminate a race
+ * between the producer wrapping and the consumer switching to the foreground
+ * buffer.
 */

 /*
- * Copyright (C) 2013-2017 Genode Labs GmbH
+ * Copyright (C) 2013-2022 Genode Labs GmbH
 *
 * This file is part of the Genode OS framework, which is distributed
 * under the terms of the GNU Affero General Public License version 3.
@@ -16,45 +99,106 @@

 #include <base/stdint.h>
 #include <cpu_session/cpu_session.h>
+#include <util/register.h>

-namespace Genode { namespace Trace { class Buffer; } }
+namespace Genode::Trace {
+	class Simple_buffer;
+
+	class Partitioned_buffer;
+
+	using Buffer = Partitioned_buffer;
+}


 /**
 * Buffer shared between CPU client thread and TRACE client
 */
-class Genode::Trace::Buffer
+class Genode::Trace::Simple_buffer
 {
 	private:

-		size_t   volatile _head_offset;  /* in bytes, relative to 'entries' */
-		size_t   volatile _size;         /* in bytes */
-		unsigned volatile _wrapped;      /* count of buffer wraps */
+		friend class Partitioned_buffer;
+
+		size_t            _head_offset;  /* in bytes, relative to 'entries' */
+		size_t            _size;         /* in bytes */
+		unsigned volatile _num_entries;  /* number of entries currently in buffer */

 		struct _Entry
 		{
+			enum Type : size_t {
+				HEAD     = 0,
+				PADDING  = ~(size_t)0
+			};
+
 			size_t len;
 			char   data[0];
+
+			void mark(Type t)    { len = t; }
+
+			bool head()    const { return len == HEAD; }
+			bool padding() const { return len == PADDING; }
 		};

 		_Entry _entries[0];

-		_Entry *_head_entry() { return (_Entry *)((addr_t)_entries + _head_offset); }
-
-		void _buffer_wrapped()
-		{
-			_head_offset = 0;
-			_wrapped++;
-
-			/* mark first entry with len 0 */
-			_head_entry()->len = 0;
-		}
-
 		/*
 		 * The 'entries' member marks the beginning of the trace buffer
 		 * entries. No other member variables must follow.
 		 */

+		_Entry *_head_entry() { return (_Entry *)((addr_t)_entries + _head_offset); }
+
+		void _buffer_wrapped()
+		{
+			if (_num_entries == 1)
+				error("trace buffer is dangerously small");
+
+			_num_entries = 0;
+			_head_offset = 0;
+
+			/* mark first entry as head */
+			_head_entry()->mark(_Entry::HEAD);
+		}
+
+		template <typename WRAP_FUNC>
+		char *_reserve(size_t len, WRAP_FUNC && wrap)
+		{
+			if (_head_offset + sizeof(_Entry) + len <= _size)
+				return _head_entry()->data;
+
+			/* mark unused space as padding */
+			if (_head_offset + sizeof(_Entry) <= _size)
+				_head_entry()->mark(_Entry::PADDING);
+
+			return wrap();
+		}
+
+		template <typename WRAP_FUNC>
+		void _commit(size_t len, WRAP_FUNC && wrap)
+		{
+			/* omit empty entries */
+			if (len == 0)
+				return;
+
+			/**
+			 * remember current length field so that we can write it after we set
+			 * the new head
+			 */
+			size_t *old_head_len = &_head_entry()->len;
+			_num_entries++;
+
+			/* advance head offset, wrap when next entry does not fit into buffer */
+			_head_offset += sizeof(_Entry) + len;
+			if (_head_offset + sizeof(_Entry) > _size)
+				wrap();
+
+			/* mark entry next to new entry as head */
+			else if (_head_offset + sizeof(_Entry) <= _size)
+				_head_entry()->mark(_Entry::HEAD);
+
+			*old_head_len = len;
+		}
+
 	public:

 		/******************************************
@@ -70,48 +214,23 @@ class Genode::Trace::Buffer

 			_size = size - header_size;

-			_wrapped = 0;
+			/* mark first entry as head */
+			_head_entry()->mark(_Entry::HEAD);
+
+			_num_entries = 0;
 		}

 		char *reserve(size_t len)
 		{
-			if (_head_offset + sizeof(_Entry) + len <= _size)
-				return _head_entry()->data;
-
-			/* mark last entry with len 0 and wrap */
-			if (_head_offset + sizeof(_Entry) <= _size)
-				_head_entry()->len = 0;
-
-			_buffer_wrapped();
-
-			return _head_entry()->data;
-		}
-
-		void commit(size_t len)
-		{
-			/* omit empty entries */
-			if (len == 0)
-				return;
-
-			/**
-			 * remember current length field so that we can write it after we set
-			 * the new head
-			 */
-			size_t *old_head_len = &_head_entry()->len;
-
-			/* advance head offset, wrap when next entry does not fit into buffer */
-			_head_offset += sizeof(_Entry) + len;
-			if (_head_offset + sizeof(_Entry) > _size)
+			return _reserve(len, [&] () -> char* {
 				_buffer_wrapped();

-			/* mark entry next to new entry with len 0 */
-			else if (_head_offset + sizeof(_Entry) <= _size)
-				_head_entry()->len = 0;
-
-			*old_head_len = len;
+				return _head_entry()->data;
+			});
 		}

-		size_t wrapped() const { return _wrapped; }
+		void commit(size_t len) {
+			return _commit(len, [&] () { _buffer_wrapped(); }); }


 		/********************************************
@@ -121,69 +240,183 @@ class Genode::Trace::Buffer
 		class Entry
 		{
 			private:
-
 				_Entry const *_entry;

-				friend class Buffer;
+				friend class Simple_buffer;

 				Entry(_Entry const *entry) : _entry(entry) { }

+				/* entry is padding */
+				bool _padding()  const { return _entry->padding(); }
+
 			public:

-				Entry() : _entry(0) { };
+				/* return invalid entry (checked by last()) */
+				static Entry invalid()     { return Entry(0); }

 				size_t      length() const { return _entry->len; }
 				char const *data()   const { return _entry->data; }

-				/*
-				 * XXX The meaning of this method is irritating.
-				 *
-				 * If it returns 'true', it means either that the entry marks
-				 * the empty padding after the entry with the highest memory
-				 * address or that it actually marks the end of the buffer
-				 * according to commit order. This is an example state of the
-				 * buffer with the two types of "last" entry:
-				 *
-				 * +-------------+------------+---+---------+-------------+------------+---+-------+
-				 * | len3  data3 | len4 data4 | 0 | empty   | len1  data1 | len2 data2 | 0 | empty |
-				 * +-------------+------------+---+---------+-------------+------------+---+-------+
-				 *
-				 * If the entry with the highest memory address fits
-				 * perfectly, the first type of "last" entry is not needed:
-				 *
-				 * +------------+--------------------+---+-------+-------------+-------------------+
-				 * | len3 data3 | len4         data4 | 0 | empty | len1  data1 | len2        data2 |
-				 * +------------+--------------------+---+-------+-------------+-------------------+
-				 *
-				 * If the buffer didn't wrap so far, there is only one "last"
-				 * entry that has both meanings:
-				 *
-				 * +--------------------------+------------+-------------+---+---------------------+
-				 * | len1               data1 | len2 data2 | len3  data3 | 0 | empty               |
-				 * +--------------------------+------------+-------------+---+---------------------+
-				 */
-				bool last() const { return _entry == 0; }
+				/* return whether entry is valid, i.e. length field is present */
+				bool last()     const { return _entry == 0; }
+
+				/* return whether data field is invalid */
+				bool empty()    const { return last() || _padding() || _entry->head(); }
+
+				/* entry is head (zero length) */
+				bool head()     const { return !last() && _entry->head(); }
 		};

+		/* Return whether buffer has been initialized. */
+		bool initialized() const { return _size && _head_offset <= _size; }
+
+		/* Return the very first entry at the start of the buffer. */
 		Entry first() const
 		{
-			return _entries->len ? Entry(_entries) : Entry(0);
+			/* return invalid entry if buffer is uninitialised */
+			if (!initialized())
+				return Entry::invalid();
+
+			return Entry(_entries);
 		}

+		/**
+		 * Return the entry that follows the given entry.
+		 * Returns an invalid entry if the end of the (used) buffer was reached.
+		 * Stops at the head of the buffer.
+		 *
+		 * The reader must check before on a valid entry whether it is the head
+		 * of the buffer (not yet written).
+		 */
 		Entry next(Entry entry) const
 		{
-			if (entry.last())
-				return Entry(0);
+			if (entry.last() || entry._padding())
+				return Entry::invalid();

-			if (entry.length() == 0)
-				return Entry(0);
+			if (entry.head())
+				return entry;

 			addr_t const offset = (addr_t)entry.data() - (addr_t)_entries;
 			if (offset + entry.length() + sizeof(_Entry) > _size)
-				return Entry(0);
+				return Entry::invalid();

 			return Entry((_Entry const *)((addr_t)entry.data() + entry.length()));
 		}
 };

+
+class Genode::Trace::Partitioned_buffer
+{
+	public:
+		using Entry = Simple_buffer::Entry;
+
+	private:
+		enum { PRIMARY = 0, SECONDARY = 1 };
+
+		/* place consumer and producer state into single word to make switches atomic */
+		struct State : Register<32>
+		{
+			struct Producer : Bitfield<0, 1> { };
+			struct Consumer : Bitfield<16,1> { };
+
+			static int toggle_consumer(int old) {
+				return Producer::masked(old) | Consumer::bits(~Consumer::get(old)); }
+
+			static int toggle_producer(int old) {
+				return Consumer::masked(old) | Producer::bits(~Producer::get(old)); }
+		};
+
+		/************
+		 ** Member **
+		 ************/
+
+		unsigned long long volatile _lost_entries;
+		unsigned           volatile _wrapped;
+		int                volatile _state;
+		int                volatile _consumer_lock;
+
+		size_t         _secondary_offset;
+		Simple_buffer  _primary[0];
+
+		/*
+		 * The '_primary' member marks the beginning of the trace buffers.
+		 * No other member variables must follow.
+		 */
+
+		Simple_buffer *_secondary() const {
+			return reinterpret_cast<Simple_buffer*>((addr_t)_primary + _secondary_offset); }
+
+		Simple_buffer &_producer()
+		{
+			if (State::Producer::get(_state) == PRIMARY)
+				return *_primary;
+
+			return *_secondary();
+		}
+
+		Simple_buffer const &_consumer() const
+		{
+			if (State::Consumer::get(_state) == PRIMARY)
+				return *_primary;
+
+			return *_secondary();
+		}
+
+		/**
+		 * Switch consumer's partition
+		 *
+		 * The consumer can always switch but must wait for the producer if the
+		 * latter is currently switching into the same partition.
+		 */
+		Simple_buffer const &_switch_consumer();
+
+		/**
+		 * Switch producer's partition
+		 *
+		 * The producer switches partitions only if the consumer is currently
+		 * in the same partition. Otherwise, it wraps and discards all entries
+		 * in the current partition.
+		 */
+		Simple_buffer &_switch_producer();
+
+	public:
+
+		/******************************************
+		 ** Functions called from the CPU client **
+		 ******************************************/
+
+		void init(size_t len);
+
+		char *reserve(size_t len);
+
+		void commit(size_t len);
+
+		/********************************************
+		 ** Functions called from the TRACE client **
+		 ********************************************/
+
+		unsigned           wrapped()      const { return _wrapped; }
+		unsigned long long lost_entries() const { return _lost_entries; }
+
+		Entry first()       const { return _consumer().first(); }
+		bool  initialized() const { return _secondary_offset > 0 && _consumer().initialized(); }
+
+		/**
+		 * Return the entry that follows the given entry.
+		 * Automatically switches between the partitions if the end of the buffer
+		 * was reached. Stops at the head of the buffer.
+		 *
+		 * The reader must check before on a valid entry whether it is the head
+		 * of the buffer (not yet written).
+		 */
+		Entry next(Entry entry)
+		{
+			Entry e = _consumer().next(entry);
+			if (e.last())
+				return _switch_consumer().first();
+
+			return e;
+		}
+};
+
 #endif /* _INCLUDE__BASE__TRACE__BUFFER_H_ */
--- a/repos/base/include/base/trace/types.h
+++ b/repos/base/include/base/trace/types.h
@@ -107,17 +107,18 @@ class Genode::Trace::Subject_info
 {
 	public:

-		enum State { INVALID, UNTRACED, TRACED, FOREIGN, ERROR, DEAD };
+		enum State { INVALID, UNATTACHED, ATTACHED, TRACED, FOREIGN, ERROR, DEAD };

 		static char const *state_name(State state)
 		{
 			switch (state) {
-			case INVALID:  return "INVALID";
-			case UNTRACED: return "UNTRACED";
-			case TRACED:   return "TRACED";
-			case FOREIGN:  return "FOREIGN";
-			case ERROR:    return "ERROR";
-			case DEAD:     return "DEAD";
+			case INVALID:    return "INVALID";
+			case UNATTACHED: return "UNATTACHED";
+			case ATTACHED:   return "ATTACHED";
+			case TRACED:     return "TRACED";
+			case FOREIGN:    return "FOREIGN";
+			case ERROR:      return "ERROR";
+			case DEAD:       return "DEAD";
 			}
 			return "INVALID";
 		}
--- a/repos/base/include/io_port_session/connection.h
+++ b/repos/base/include/io_port_session/connection.h
@@ -30,8 +30,8 @@ struct Genode::Io_port_connection : Connection<Io_port_session>,
 	 */
 	Capability<Io_port_session> _session(Parent &parent, unsigned base, unsigned size)
 	{
-		return session(parent, "ram_quota=6K, cap_quota=%u, io_port_base=%u, io_port_size=%u",
-		               CAP_QUOTA, base, size);
+		return session(parent, "ram_quota=%u, cap_quota=%u, io_port_base=%u, io_port_size=%u",
+		               RAM_QUOTA, CAP_QUOTA, base, size);
 	}

 	/**
@@ -44,9 +44,9 @@ struct Genode::Io_port_connection : Connection<Io_port_session>,
 	:
 		Connection<Io_port_session>(env,
 		                            session(env.parent(),
-		                                    "ram_quota=6K, cap_quota=%u, "
+		                                    "ram_quota=%u, cap_quota=%u, "
 		                                    "io_port_base=%u, io_port_size=%u",
-		                                    CAP_QUOTA, base, size)),
+		                                    RAM_QUOTA, CAP_QUOTA, base, size)),
 		Io_port_session_client(cap())
 	{ }
 };
--- a/repos/base/include/io_port_session/io_port_session.h
+++ b/repos/base/include/io_port_session/io_port_session.h
@@ -38,7 +38,7 @@ struct Genode::Io_port_session : Session
 	 */
 	static const char *service_name() { return "IO_PORT"; }

-	enum { CAP_QUOTA = 2 };
+	enum { RAM_QUOTA = 6 * 1024, CAP_QUOTA = 2 };

 	virtual ~Io_port_session() { }

--- a/repos/base/include/spec/arm/cpu/string.h
+++ b/repos/base/include/spec/arm/cpu/string.h
@@ -30,21 +30,25 @@ namespace Genode {
 	{
 		unsigned char *d = (unsigned char *)dst, *s = (unsigned char *)src;

-		/* check 4 byte; alignment */
-		size_t d_align = (size_t)d & 0x3;
-		size_t s_align = (size_t)s & 0x3;
+		/* fetch the first cache line */
+		asm volatile ("pld [%0, #0]\n\t" : "+r" (s));

-		/* only same alignments work for the following LDM/STM loop */
-		if (d_align != s_align)
+		/* check 32-byte (cache line) alignment */
+		size_t d_align = (size_t)d & 0x1f;
+		size_t s_align = (size_t)s & 0x1f;
+
+		/* only same word-alignments work for the following LDM/STM loop */
+		if ((d_align & 0x3) != (s_align & 0x3))
 			return size;

-		/* copy to 4 byte alignment */
-		for (; (size > 0) && (s_align > 0) && (s_align < 4);
+		/* copy to 32-byte alignment */
+		for (; (size > 0) && (s_align > 0) && (s_align < 32);
 		     s_align++, *d++ = *s++, size--);

 		/* copy 32 byte chunks */
 		for (; size >= 32; size -= 32) {
 			asm volatile ("ldmia %0!, {r3 - r10} \n\t"
+			              "pld [%0, #160]\n\t"
 			              "stmia %1!, {r3 - r10} \n\t"
 			              : "+r" (s), "+r" (d)
 			              :: "r3","r4","r5","r6","r7","r8","r9","r10");
--- a/repos/base/include/spec/arm/vfp/cpu/string.h
+++ b/repos/base/include/spec/arm/vfp/cpu/string.h
@@ -1,69 +0,0 @@
-/*
- * \brief  ARM-specific memcpy using VFP
- * \author Sebastian Sumpf
- * \date   2013-06-19
- *
- * Should work for VFPv2, VFPv3, and Advanced SIMD.
- */
-
-/*
- * Copyright (C) 2012-2017 Genode Labs GmbH
- *
- * This file is part of the Genode OS framework, which is distributed
- * under the terms of the GNU Affero General Public License version 3.
- */
-
-#ifndef _INCLUDE__SPEC__ARM__VFP__CPU__STRING_H_
-#define _INCLUDE__SPEC__ARM__VFP__CPU__STRING_H_
-
-namespace Genode {
-
-	/**
-	 * Copy memory block
-	 *
-	 * \param dst   destination memory block
-	 * \param src   source memory block
-	 * \param size  number of bytes to copy
-	 *
-	 * \return      Number of bytes not copied
-	 */
-	inline size_t memcpy_cpu(void *dst, const void *src, size_t size)
-	{
-		unsigned char *d = (unsigned char *)dst, *s = (unsigned char *)src;
-		/* check 4 byte; alignment */
-		size_t d_align = (size_t)d & 0x3;
-		size_t s_align = (size_t)s & 0x3;
-
-		/* only same alignments work for the following loops */
-		if (d_align != s_align)
-			return size;
-
-		/* copy to 4 byte alignment */
-		for (; (size > 0) && (s_align > 0) && (s_align < 4);
-		     s_align++, *d++ = *s++, size--);
-
-		/* copy 64 byte chunks using FPU */
-		for (; size >= 64; size -= 64)
-			asm volatile ("pld [%0, #0xc0]  \n\t"
-			              "vldm %0!,{d0-d7} \n\t"
-			              "vstm %1!,{d0-d7} \n\t"
-			              : "+r"(s), "+r" (d)
-                    :: "d0", "d1", "d2", "d3", "d4", "d5", "d6", "d7");
-
-		/* copy left over 32 byte chunk */
-		for (; size >= 32; size -= 32)
-			asm volatile ("ldmia %0!, {r3 - r10} \n\t"
-			              "stmia %1!, {r3 - r10} \n\t"
-			              : "+r" (s), "+r" (d)
-			              :: "r3","r4","r5","r6","r7","r8","r9","r10");
-
-		for(; size >= 4; size -= 4)
-			asm volatile ("ldr r3, [%0], #4 \n\t"
-			              "str r3, [%1], #4 \n\t"
-			              : "+r" (s), "+r" (d)
-			              :: "r3");
-		return size;
-	}
-}
-
-#endif /* _INCLUDE__SPEC__ARM__VFP__CPU__STRING_H_ */
--- a/repos/base/include/spec/x86/cpu/string.h
+++ b/repos/base/include/spec/x86/cpu/string.h
@@ -25,7 +25,37 @@ namespace Genode {
 	 *
 	 * \return      number of bytes not copied
 	 */
-	inline size_t memcpy_cpu(void *, const void *, size_t size) { return size; }
+	inline size_t memcpy_cpu(void * dst, const void * src, size_t size)
+	{
+		typedef unsigned long word_t;
+
+		enum {
+			LEN  = sizeof(word_t),
+			MASK = LEN-1
+		};
+
+		unsigned char *d = (unsigned char *)dst, *s = (unsigned char *)src;
+
+		/* check byte alignment */
+		size_t d_align = (size_t)d & MASK;
+		size_t s_align = (size_t)s & MASK;
+
+		/* only same alignments work */
+		if (d_align != s_align)
+			return size;
+
+		/* copy to word alignment */
+		for (; (size > 0) && (s_align > 0) && (s_align < LEN);
+		     s_align++, *d++ = *s++, size--);
+
+		/* copy words */
+		for (; size >= LEN; size -= LEN,
+		                       d += LEN,
+		                       s += LEN)
+			*(word_t*)d = *(word_t*)s;
+
+		return size;
+	}
 }

 #endif /* _INCLUDE__SPEC__X86__CPU__STRING_H_ */
--- a/repos/base/include/util/string.h
+++ b/repos/base/include/util/string.h
@@ -246,7 +246,47 @@ namespace Genode {
 	 __attribute((optimize("no-tree-loop-distribute-patterns")))
 	inline void *memset(void *dst, uint8_t i, size_t size)
 	{
-		while (size--) ((uint8_t *)dst)[size] = i;
+		typedef unsigned long word_t;
+
+		enum {
+			LEN  = sizeof(word_t),
+			MASK = LEN-1
+		};
+
+		size_t d_align = (size_t)dst & MASK;
+		uint8_t* d = (uint8_t*)dst;
+
+		/* write until word aligned */
+		for (; d_align && d_align < LEN && size;
+		       d_align++, size--, d++)
+			*d = i;
+
+		word_t word = i;
+		word |= word << 8;
+		word |= word << 16;
+		if (LEN == 8)
+			word |= (word << 16) << 16;
+
+		/* write 8-word chunks (likely matches cache line size) */
+		for (; size >= 8*LEN; size -= 8*LEN, d += 8*LEN) {
+			((word_t *)d)[0] = word;
+			((word_t *)d)[1] = word;
+			((word_t *)d)[2] = word;
+			((word_t *)d)[3] = word;
+			((word_t *)d)[4] = word;
+			((word_t *)d)[5] = word;
+			((word_t *)d)[6] = word;
+			((word_t *)d)[7] = word;
+		}
+
+		/* write remaining words */
+		for (; size >= LEN; size -= LEN, d += LEN)
+			((word_t *)d)[0] = word;
+
+		/* write remaining bytes */
+		for (; size; size--, d++)
+			*d = i;
+
 		return dst;
 	}

--- a/repos/base/lib/mk/base-common.inc
+++ b/repos/base/lib/mk/base-common.inc
@@ -29,6 +29,7 @@ SRC_CC += region_map_client.cc
 SRC_CC += rm_session_client.cc
 SRC_CC += stack_allocator.cc
 SRC_CC += trace.cc
+SRC_CC += trace_buffer.cc
 SRC_CC += root_proxy.cc
 SRC_CC += env_session_id_space.cc
 SRC_CC += stack_protector.cc
--- a/repos/base/lib/symbols/ld
+++ b/repos/base/lib/symbols/ld
@@ -247,6 +247,10 @@ _ZN6Genode5Trace6Logger17_evaluate_controlEv T
 _ZN6Genode5Trace6Logger3logEPKcm T
 _ZN6Genode5Trace6LoggerC1Ev T
 _ZN6Genode5Trace6LoggerC2Ev T
+_ZN6Genode5Trace18Partitioned_buffer4initEm T
+_ZN6Genode5Trace18Partitioned_buffer6commitEm T
+_ZN6Genode5Trace18Partitioned_buffer7reserveEm T
+_ZN6Genode5Trace18Partitioned_buffer16_switch_consumerEv T
 _ZN6Genode5printERNS_6OutputEPKc T
 _ZN6Genode5printERNS_6OutputEPKv T
 _ZN6Genode5printERNS_6OutputEd T
--- a/repos/base/recipes/api/base/hash
+++ b/repos/base/recipes/api/base/hash
@@ -1 +1 @@
-2022-02-27 86a3e26a89ef46d69cf328a8b2db57e5d22eccde
+2022-05-24 d4b5b53bc270cebd87bf01a93c6da241077aad42
--- a/repos/base/recipes/pkg/test-ds_ownership/hash
+++ b/repos/base/recipes/pkg/test-ds_ownership/hash
@@ -1 +1 @@
-2022-02-27 cca1d99f9c8fbffbadd18addb14b61df3724a6b4
+2022-05-24 5e486a0f27fdda0a70b9275d62257d98e26589c8
--- a/repos/base/recipes/pkg/test-entrypoint/hash
+++ b/repos/base/recipes/pkg/test-entrypoint/hash
@@ -1 +1 @@
-2022-02-27 46ae9cf8c51959de1768d7a624447967e621fbaf
+2022-05-24 e35abe047c7ec7fe02c0939de16bfc80ed421d38
--- a/repos/base/recipes/pkg/test-log/hash
+++ b/repos/base/recipes/pkg/test-log/hash
@@ -1 +1 @@
-2022-02-27 a1634d441767bb2eafde1948df20e0375511130e
+2022-05-24 79d43c7e33381048618dbd7ba6ca34a3eda23f6c
--- a/repos/base/recipes/pkg/test-mmio/hash
+++ b/repos/base/recipes/pkg/test-mmio/hash
@@ -1 +1 @@
-2022-02-27 f94ddecd58af2e47681f4b4f0bac453a2bafe52b
+2022-05-24 4b2af7d33e8264d080be962d0a4d9a6404ec4bc0
--- a/repos/base/recipes/pkg/test-new_delete/hash
+++ b/repos/base/recipes/pkg/test-new_delete/hash
@@ -1 +1 @@
-2022-02-27 0fee7813cc30ccca7b80ebdb161c4b12f22481e6
+2022-05-24 ed1f37d2213211897d5360c9a8f32404d670722a
--- a/repos/base/recipes/pkg/test-reconstructible/hash
+++ b/repos/base/recipes/pkg/test-reconstructible/hash
@@ -1 +1 @@
-2022-02-27 8e12d8d884f24a3250a3c89d9acfe3c8486d6ba6
+2022-05-24 f09098d18ca36bc8829a673be78dd80460c3d65e
--- a/repos/base/recipes/pkg/test-registry/hash
+++ b/repos/base/recipes/pkg/test-registry/hash
@@ -1 +1 @@
-2022-02-27 707d2bfdadd554018a2d18cab361eec3fca609e8
+2022-05-24 3f91b26dbd239c52bb9af22e8f7713743ee851f4
--- a/repos/base/recipes/pkg/test-rm_fault/hash
+++ b/repos/base/recipes/pkg/test-rm_fault/hash
@@ -1 +1 @@
-2022-02-27 ce272dfe015044927d7c6a7d250fe822bec7829d
+2022-05-24 edbf57617935a054a681e097a611006496ed4c88
--- a/repos/base/recipes/pkg/test-rm_fault_no_nox/hash
+++ b/repos/base/recipes/pkg/test-rm_fault_no_nox/hash
@@ -1 +1 @@
-2022-02-27 d53ccffa0c4f8059dcbc5f4a878ab9dc2140f35d
+2022-05-24 ce2c9008ed6ea0db13999e9c6ab77a098d4f94a0
--- a/repos/base/recipes/pkg/test-rm_nested/hash
+++ b/repos/base/recipes/pkg/test-rm_nested/hash
@@ -1 +1 @@
-2022-02-27 2439a208e7a5d1cde756a32f4881e20897430f0c
+2022-05-24 afd4f2249a2d56bb6b29b6c0d24923ef2ec215c9
--- a/repos/base/recipes/pkg/test-rm_stress/hash
+++ b/repos/base/recipes/pkg/test-rm_stress/hash
@@ -1 +1 @@
-2022-02-27 93e5cf2b24d8b803bd893424b2ff11bade1910ee
+2022-05-24 436a166f1c4371619d7a64bf879dd0ce2dc75429
--- a/repos/base/recipes/pkg/test-sanitizer/hash
+++ b/repos/base/recipes/pkg/test-sanitizer/hash
@@ -1 +1 @@
-2022-02-27 0758f1e8633994538a2640145dc686b31b080b51
+2022-05-24 3877f6f98ff7c3921bdb7b2b83f40a161e9cd5bb
--- a/repos/base/recipes/pkg/test-stack_smash/hash
+++ b/repos/base/recipes/pkg/test-stack_smash/hash
@@ -1 +1 @@
-2022-02-27 dd19cc2e10b51584feecdb1be91660bc084b87f4
+2022-05-24 00a8e3979871b2a0ab67088c3d2b57454ed653f9
--- a/repos/base/recipes/pkg/test-synced_interface/hash
+++ b/repos/base/recipes/pkg/test-synced_interface/hash
@@ -1 +1 @@
-2022-02-27 fe2295f5a8eb45c5c94b0bb49b42f47078639503
+2022-05-24 ab7b5f631d4abf8b01ed6b08c4da83b4164564a8
--- a/repos/base/recipes/pkg/test-timer/hash
+++ b/repos/base/recipes/pkg/test-timer/hash
@@ -1 +1 @@
-2022-02-27 ffd037d7c94288dbab7cb87eac734914c42e3478
+2022-05-24 91ed52185381c38cf7e425fb0c351b46c4548b4f
--- a/repos/base/recipes/pkg/test-tls/hash
+++ b/repos/base/recipes/pkg/test-tls/hash
@@ -1 +1 @@
-2022-02-27 5afcb81f82326dfd3b0278f1d830e0cc31071ca7
+2022-05-24 7ff4d04d0b470eb6974b633bb0dca1212158f625
--- a/repos/base/recipes/pkg/test-token/hash
+++ b/repos/base/recipes/pkg/test-token/hash
@@ -1 +1 @@
-2022-02-27 7a3843087422114ac1e5ad3f93b73e422a6149df
+2022-05-24 b96b88fee3e0946fea12a44cea94963b2b16d173
--- a/repos/base/recipes/pkg/test-xml_generator/hash
+++ b/repos/base/recipes/pkg/test-xml_generator/hash
@@ -1 +1 @@
-2022-02-27 cf436f6c6b0db3bb1dc181b146396c24249ccc48
+2022-05-24 c2d9a2849fe51277372d301c9a46d034c4674ab9
--- a/repos/base/recipes/pkg/test-xml_node/hash
+++ b/repos/base/recipes/pkg/test-xml_node/hash
@@ -1 +1 @@
-2022-02-27 719d135c72fc67d3e6c6c73a17ead4fdae866db1
+2022-05-24 88eb29b90a1e663e1f58de04a6a178f3a035f3f5
--- a/repos/base/recipes/src/test-ds_ownership/hash
+++ b/repos/base/recipes/src/test-ds_ownership/hash
@@ -1 +1 @@
-2022-02-27 4e83453963ac049c6493b2c50c6ffc2c172a360e
+2022-05-24 715bfaa6ea0bff54c0e2477c1bbccf56c0bfc935
--- a/repos/base/recipes/src/test-entrypoint/hash
+++ b/repos/base/recipes/src/test-entrypoint/hash
@@ -1 +1 @@
-2022-02-27 13b55a659bab5a8f0b28a321049b1cca7fb0ea9c
+2022-05-24 05d5db1ec0b7fff36e8526fe701873731fd08660
--- a/repos/base/recipes/src/test-log/hash
+++ b/repos/base/recipes/src/test-log/hash
@@ -1 +1 @@
-2022-02-27 a6faf88e84ef9e63e372428f2ab22c4e635b9ab2
+2022-05-24 7d26fbbb584ab24b8156eda78a8eca5bc9e1122f
--- a/repos/base/recipes/src/test-mmio/hash
+++ b/repos/base/recipes/src/test-mmio/hash
@@ -1 +1 @@
-2022-02-27 a84133c258b7551df99908d9675b55ae546f23dc
+2022-05-24 6542fc1df645f45c9fc71b5c18b458a9e630470d
--- a/repos/base/recipes/src/test-new_delete/hash
+++ b/repos/base/recipes/src/test-new_delete/hash
@@ -1 +1 @@
-2022-02-27 51357ba4aee517296a33c57e97e4d5bf552ac50e
+2022-05-24 67caefb3bbf5926dbd2ca46bbe933882de542db3
--- a/repos/base/recipes/src/test-reconstructible/hash
+++ b/repos/base/recipes/src/test-reconstructible/hash
@@ -1 +1 @@
-2022-02-27 cdc4f34872927d31633c7afc11bedb3163157ea3
+2022-05-24 915f8bebfcdbfe4ef499ea94985303bacebeb8e8
--- a/repos/base/recipes/src/test-registry/hash
+++ b/repos/base/recipes/src/test-registry/hash
@@ -1 +1 @@
-2022-02-27 95cb122959fa2c2288e3226eee5e6e0dc27f655d
+2022-05-24 e1e3559b2f3010d96d19e81cbaa6abbeb07c6251
--- a/Show More
+++ b/Show More
@@ -1 +1 @@
 .02
 .05