diff --git a/README b/README
index c68e549481..99cf34ecc0 100644
--- a/README
+++ b/README
@@ -4,15 +4,17 @@
=================================
-This is the source tree of the reference implementation of the Genode OS
-architecture. For a general overview about the architecture, please refer to
-the project's official website:
+This is the source code of Genode, which is a framework for creating
+component-based operating systems. It combines capability-based security,
+microkernel technology, sandboxed device drivers, and virtualization with
+a novel operating system architecture. For a general overview about the
+architecture, please refer to the project's official website:
-:Official project website for the Genode OS Framework:
+:Website for the Genode OS Framework:
[https://genode.org/documentation/general-overview]
-The current implementation can be compiled for 8 different kernels: Linux,
+Genode-based operating systems can be compiled for a variety of kernels: 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
@@ -22,7 +24,7 @@ one. If a microkernel pretended to be fit for all use cases, it wouldn't be
"micro". Hence, all microkernels differ in terms of their respective features,
complexity, and supported hardware architectures.
-Genode allows the use of each of the kernels listed above with a rich set of
+Genode allows for the use of each of the supported kernels with a rich set of
device drivers, protocol stacks, libraries, and applications in a uniform way.
For developers, the framework provides an easy way to target multiple different
kernels instead of tying the development to a particular kernel technology. For
@@ -37,7 +39,7 @@ Documentation
#############
The primary documentation is the book "Genode Foundations", which is available
-on the front page of Genode website:
+on the front page of the Genode website:
:Download the book "Genode Foundations":
@@ -79,11 +81,6 @@ The source tree is composed of the following subdirectories:
Source-code management tools and scripts. Please refer to the README file
contained in the directory.
-:'depot':
-
- Directory used by Genode's package-management tools. It contains the public
- keys and download locations of software providers.
-
Additional hardware support
###########################
@@ -108,13 +105,32 @@ system scenarios.
[https://github.com/genodelabs/genode-world]
+Community blog
+##############
+
+Genodians.org presents ideas, announcements, experience stories, and tutorials
+around Genode, informally written by Genode users and developers.
+
+:Genodians.org:
+
+ [https://genodians.org]
+
+
Contact
#######
-The best way to get in touch with Genode developers and users is the project's
-mailing list. Please feel welcome to join in!
+The community forum is organized by Genode users to help newcomers, share ideas
+and experiences, and discuss Genode-related projects.
-:Genode Mailing Lists:
+:Community forum:
+
+ [https://genode.discourse.group]
+
+The mailing list is the primary way for reaching out to Genode's core
+developers, for receiving announcements, and for the project's annual road-map
+discussion.
+
+:Genode Mailing List:
[https://genode.org/community/mailing-lists]
diff --git a/VERSION b/VERSION
index 54de1e741d..3dce2e921c 100644
--- a/VERSION
+++ b/VERSION
@@ -1 +1 @@
-22.08
+24.08
diff --git a/doc/challenges.txt b/doc/challenges.txt
index 623953303f..5b138bf771 100644
--- a/doc/challenges.txt
+++ b/doc/challenges.txt
@@ -16,17 +16,24 @@ research projects on Genode.
Applications and library infrastructure
#######################################
-:VNC server implementing Genode's framebuffer session interface:
+:Port of the Ladybird web browser:
- With 'Input' and 'Framebuffer', Genode provides two low-level interfaces
- used by interactive applications. For example, the Nitpicker GUI server uses
- these interfaces as a client and, in turn, exports multiple virtual
- 'Framebuffer' and 'Input' interfaces to its clients. This enables a
- highly modular use of applications such as the nesting of GUIs. By
- implementing the 'Framebuffer' and 'Input' interfaces with a VNC server
- implementation, all graphical workloads of Genode would become available over
- the network. One immediate application of this implementation is the remote
- testing of graphical Genode applications running on a headless server.
+ [https://ladybird.org/ - Ladybird] is a new web browser developed
+ independently from the large browser-engine vendors. It is designed to
+ be light-weight and portable. Among the supported platforms is Qt,
+ which is available for Genode. This makes the porting of Ladybird a
+ tempting application of the Goa SDK.
+
+:Goa SDK running on Sculpt OS:
+
+ Genode's [https://github.com/genodelabs/goa - Goa SDK] is currently used
+ in Linux-based development environments, facilitating cross-compilation
+ to Genode. The goal of this project is the ability to use Goa directly on
+ Sculpt OS without the need for a Linux VM. This entails a number of
+ challenges, ranging from running the Goa tool itself by porting the expect
+ interpreter, over running the Genode tool chain, adjusting the
+ network-facing Goa commands to Genode's environment, to crafting custom
+ support for executing 'goa run' as a sandboxed Genode subsystem.
:Interfacing with the SAFE network:
@@ -39,25 +46,6 @@ Applications and library infrastructure
integrated in the operating system, i.e., in the form of Genode components
or a set of Genode VFS plugins.
-:Interactive sound switchbox based on Genode's Audio_out session interface:
-
- Since version 10.05, Genode features a highly flexible configuration concept
- that allows the arbitrary routing of session requests throughout the
- hierarchic process structure. Even though primarily designed for expressing
- mandatory-access control rules, the concept scales far beyond this use case.
- For example, it can be used to run an arbitrary number of processes
- implementing the same interface and connecting the different interface
- implementations. One special case of this scenario is a chain of audio
- filters with each using the 'Audio_out' session interface for both roles
- client and server. Combined with the Nitpicker GUI server and Genode's
- support for real-time priorities, this base techniques enable the creation of
- flexible audio mixer / switchboard applications, which require dedicated
- frameworks (e.g., Jack audio) on traditional operating systems. The goal of
- this project is to create a showcase implementation demonstrating the
- feasibility for creating high-quality audio applications on Genode.
- Furthermore, we wish for feedback regarding the current design of our bulk
- streaming interface when used for low-latency applications.
-
:Graphical on-target IPC tracing tool using Qt:
Analysing the interaction of components of a multi-server operating system
@@ -94,31 +82,39 @@ Applications and library infrastructure
:Ports of popular software:
- Genode features a ports mechanism to cleanly integrate 3rd-party software.
+ The [https://github.com/genodelabs/goa - Goa SDK] streamlines the process
+ of developing, porting, packaging, and publishing software for Genode,
+ and Sculpt OS in particular.
Thanks to the C runtime, the flexible per-component VFS, the standard
- C++ library, and the Noux runtime (for UNIX software), porting software
- to Genode is relatively straight forward. The
- [https://genode.org/documentation/developer-resources/porting - porting guide]
- explains the typical steps. A wish list of software that we'd like to
- have available on Genode is available at
+ C++ library, and a variety of supported 3rd-party libraries, porting
+ software to Genode is relatively straight forward.
+ A wish list of software that we'd like to have available on Genode is
+ available at
[https://usr.sysret.de/jws/genode/porting_wishlist.html].
:Native Open-Street-Maps (OSM) client:
- When using Sculpt OS, we regularly need to spawn a fully fledged web
- browser in a virtual machine for using OSM or Google maps. The goal
- of this project would be a native component that makes maps functionality
- directly available on Genode, alleviating the urge to reach for a SaaS
- product. The work would include a review of existing OSM clients regarding
- their feature sets and the feasibility of porting them to Genode.
- Depending on the outcome of this review, an existing application could
- be ported or a new component could be developed, e.g., leveraging Genode's
- Qt support.
+ When using Sculpt OS, we regularly need to spawn a fully fledged web browser
+ for using OSM or Google maps. The goal of this project would be a native
+ component that makes maps functionality directly available on Genode,
+ alleviating the urge to reach for a SaaS product. The work would include a
+ review of existing OSM clients regarding their feature sets and the
+ feasibility of porting them to Genode. Depending on the outcome of this
+ review, an existing application could be ported or a new component could be
+ developed, e.g., leveraging Genode's Qt support.
Application frameworks and runtime environments
###############################################
+:GTK:
+
+ Genode supports Qt as a native toolkit. But many popular applications
+ are built upon [https://www.gtk.org/ - GTK]. A port of GTK to Genode would
+ allow for the use of these applications on Sculpt OS without the need
+ of a Linux VM. A tangible goal for this line of work could be the port
+ of [https://mtpaint.sourceforge.net/ - mtPaint] to Sculpt OS.
+
:OpenJDK:
[https://openjdk.java.net/ - OpenJDK] is the reference implementation of the
@@ -143,31 +139,6 @@ Application frameworks and runtime environments
removed from the trusted computing base of Android, facilitating the use of
this mobile OS in high-assurance settings.
-:Go language runtime:
-
- Go is a popular language in particular for web applications. In the past,
- there were numerous attempts to make the Go runtime available on Genode
- but so far, none of those undertakings have landed in the official
- Genode source tree. To goal of this project is the hosting of
- Go-written applications - in particular networking applications - as
- Genode components. The topic comprises work on the tool-chain
- and build-system integration, the porting the runtime libraries, and
- the glue between the Go and Genode environments.
-
-:Combination of CAmkES with Genode:
-
- [https://wiki.sel4.systems/CAmkES - CAmkES] is a component framework for
- seL4. In contrast to Genode, which is a dynamic system, CAmkES-based systems
- are defined at design time and remain fixed at runtime. Hence, CAmkES and
- Genode can be seen as the opposite ends of component-based used-land
- architectures. The goal of this project is to build a bridge between
- both projects with the potential to cross-pollinate the respective communities.
- Among the principal approaches are embedding of a single CAmkES
- component as a Genode component (e.g., an individual device driver),
- the hosting of a dynamic Genode system as a component within a
- CAmkES system, or the hosting of a CAmkES system composition as a Genode
- subsystem.
-
:Runtime for the D programming language:
The D systems programming language was designed to overcome many gripes that
@@ -181,19 +152,6 @@ Application frameworks and runtime environments
programs, and interfacing D programs with other Genode components written in
C++.
-:Using Haskell as systems-development language:
-
- The goal of this project is the application of functional programming
- i.e., Haskell, for the implementation of low-level Genode components.
- Implementing critical functionalities in such a high-level language instead
- of a classical systems language such as C or C++ would pave the way towards
- analyzing such components with formal methods.
-
- The use of Haskell for systems development was pioneered by the
- [https://programatica.cs.pdx.edu/House/ - House Project]. A more recent
- development is [https://halvm.org - HalVM] - a light-weight OS runtime for
- Xen that is based on Haskell.
-
:Xlib compatibility:
Developments like Wayland notwithstanding, most application software on
@@ -214,45 +172,44 @@ Application frameworks and runtime environments
requests issued by a block-session client to a block-device driver,
such a bump-in-the-wire component could visualize
the access patterns of a block device. Similar ideas could be pursued for
- other session interfaces, like the audio-out (sound visualization) or NIC
+ other session interfaces, like record/play (sound visualization) or NIC
session (live visualization of network communication).
The visualization of system behavior would offer valuable insights,
e.g., new opportunities for optimization. But more importantly, they
- would be extremely fun to play with.
+ would be fun to play with.
+
+
+Platforms
+#########
+
+:Support for additional ARM SoCs:
+
+ Genode's ARM support has been focused on NXP's i.MX family, Allwinner A64
+ (used by the PinePhone), and to a lesser degree the Raspberry Pi. To make
+ Genode compatible with a larger variety of devices, the support for further
+ chip families calls for exploration. For example,
+ [https://en.wikipedia.org/wiki/Rockchip - Rockchip] SoCs are getting
+ popular in products by open-source hardware vendors such as
+ [https://pine64.com/ - Pine64] and [https://mntre.com/ - MNT].
+ The first steps have been [https://github.com/mickenx/genode-rockchip - already taken]
+ by [https://genodians.org/mickenx/index - Michael Grunditz]!
+ Another example is the Mediatek SoC family, which is popular in
+ affordable consumer smartphones.
+ Another example is the Mediatek SoC family, which is popular in
+ affordable consumer smartphones.
+
+ The process of bringing an OS like Genode to a new SoC is full of technical
+ challenges and labor-intensive, yet extremely gratifying.
+ As a guide through this process, the
+ [https://genode.org/documentation/genode-platforms-23-05.pdf - Genode Platforms]
+ book breaks the challenge down to a sequence of manageable steps, where
+ each step can be celebrated as a success.
Virtualization
##############
-:VirtualBox on top of KVM on Linux:
-
- Genode's version of VirtualBox replaces the original in-kernel VirtualBox
- hypervisor by the virtualization mechanism of the NOVA hypervisor or the
- Muen separation kernel. Those mechanisms look very similar the KVM
- interface of the Linux kernel. It should in principle be possible to
- re-target Genode's version of VirtualBox to KVM. This way, VirtualBox and
- Qemu/KVM-based virtual machines could co-exist on the same system, which
- is normally not possible. Also, complex Genode scenarios (like Turmvilla)
- could be prototyped on GNU/Linux.
-
-:Xen as kernel for Genode:
-
- Using Xen as kernel for Genode would clear the way to remove the
- overly complex Linux OS from the trusted computing base of Xen
- guests OSes.
-
- Xen is a hypervisor that can host multiple virtual machines on one physical
- machine. For driving physical devices and for virtual-machine management, Xen
- relies on a privileged guest OS called Dom0. Currently, Linux is the
- predominant choice to be used as Dom0, which implicates a trusted computing
- base of millions of lines of code for the other guest OSes.
-
- Even though Xen was designed as hypervisor, a thorough analysis done by Julian
- Stecklina concludes that Xen qualifies well as a kernel for Genode. For
- example, Julian implemented a version of Genode's IPC framework that utilizes
- Xen's communication mechanisms (event channels and shared memory).
-
:Genode as virtualization layer for Qubes OS:
[https://www.qubes-os.org/ - Qubes OS] is a desktop operating system
@@ -278,121 +235,37 @@ Virtualization
the project bears the opportunity to explore the provisioning of the
KVM interface based on Genode's VFS plugin concept.
-:Hardware-accelerated graphics for virtual machines:
- In
- [https://genode.org/documentation/release-notes/17.08#Hardware-accelerated_graphics_for_Intel_Gen-8_GPUs - Genode 17.08],
- we introduced a GPU multiplexer for Intel Broadwell along with support
- for Mesa-based 3D-accelerated applications.
- While designing Genode's GPU-session interface, we also aimed at supporting
- the hardware-accelerated graphics for Genode's virtual machine monitors like
- VirtualBox or Seoul, but until now, we did not took the practical steps of
- implementing a virtual GPU device model.
+System management and tools
+###########################
- The goal of this project is the offering of a virtual GPU to a Linux guest
- OS running on top of Genode's existing virtualization and driver
- infrastructure.
+:Virtual network-boot infrastructure as Sculpt component:
+ Network-based development work flows for PCs require a variety of tools and
+ network-configuration peculiarities. Think of a development network with a
+ custom configured DHCP server, a TFTP or HTTP server on the development
+ machine, the provisioning of a PXE boot loader, tooling for obtaining serial
+ output over AMT, or tooling for remote power control via AMT.
-Device drivers
-##############
+ The goal of this project would be the hosting of all those functions in a
+ Sculpt OS component "devnet" that is exclusively in charge of a dedicated
+ LAN port of the developer's Sculpt machine. By connecting a test machine to
+ this LAN port, the test machine becomes immediately available as development
+ target without any manual installation or configuration steps needed. The
+ devnet component would interface with the rest of the Sculpt system as a
+ client of a file-system session (containing the boot payloads) and a
+ terminal session (for the virtual serial connection).
-:Sound on the Raspberry Pi:
+:Statistical profiler using Sculpt's GDB monitor:
- The goal of this project is a component that uses the Raspberry Pi's
- PWM device to implement Genode's audio-out-session interface. Since
- Genode's version of libSDL already supports this interface as audio
- backend, the new driver will make the sound of all SDL-based games
- available on the Raspberry Pi.
-
-:Data Plane Development Kit (DPDK):
-
- Genode utilizes the network device drivers of the iPXE project, which
- perform reasonably well for everyday use cases but are obviously not
- designated for high-performance networking.
- The [https://dpdk.org/ - DPDK] is a vendor-supported suite of network device
- drivers that is specifically developed for high-performance applications.
- It presents an attractive alternative to iPXE-based drivers. This project
- has the goal to make DPDK drivers available as a Genode component.
-
-
-Platforms
-#########
-
-:Microkernelizing Linux:
-
- Thanks to Genode's generic interfaces for I/O access as provided by core, all
- Genode device drivers including drivers ported from Linux and gPXE can be
- executed as user-level components on all supported microkernels. However, so
- far, we have not enabled the use of these device drivers on Linux as base
- platform. The goal of this project is the systematic replacement of in-kernel
- Linux device drivers by Genode processes running in user space, effectively
- reducing the Linux kernel to a runtime for Genode's core process. But moving
- drivers to Genode processes is just the beginning. By employing further
- Genode functionality such as its native GUI, lwIP, and Noux, many protocol
- stacks can effectively be removed from the Linux kernel.
-
- In 2018, Johannes Kliemann pursued this topic to a state where Genode
- could be used as init process atop a customized Linux kernel.
- [https://lists.genode.org/pipermail/users/2018-May/006066.html - His work]
- included the execution of Genode's regular device drivers for VESA and
- PS/2 as regular Genode components so that Genode's interactive demo
- scenario ran happily on a laptop. At this time, however, only parts of
- his results were merged into Genode's mainline.
-
- The goal of this project is to follow up on Johannes' work, bring the
- [https://github.com/genodelabs/genode/pull/2829 - remaining parts] into
- shape for the inclusion into Genode, and address outstanding topics, in
- particular the handling of DMA by user-level device drivers. Further down
- the road, it would be tempting to explore the use of
- [https://en.wikipedia.org/wiki/Seccomp - seccomp] as sandboxing mechanism
- for Genode on Linux and the improvement of the Linux-specific implementation
- of Genode's object-capability model.
-
-:Support for the HelenOS/SPARTAN kernel:
-
- [http://www.helenos.org - HelenOS] is a microkernel-based multi-server OS
- developed at the university of Prague. It is based on the SPARTAN microkernel,
- which runs on a wide variety of CPU architectures including Sparc, MIPS, and
- PowerPC. This broad platform support makes SPARTAN an interesting kernel to
- look at alone. But a further motivation is the fact that SPARTAN does not
- follow the classical L4 road, providing a kernel API that comes with an own
- terminology and different kernel primitives. This makes the mapping of
- SPARTAN's kernel API to Genode a challenging endeavour and would provide us
- with feedback regarding the universality of Genode's internal interfaces.
- Finally, this project has the potential to ignite a further collaboration
- between the HelenOS and Genode communities.
-
-:Support for the XNU kernel (Darwin):
-
- XNU is the kernel used by Darwin and Mac OS X. It is derived from the
- MACH microkernel and extended with a UNIX-like syscall API. Because the
- kernel is used for Mac OS X, it could represent an industry-strength
- base platform for Genode supporting all CPU features as used by Mac OS X.
-
-:Genode on the Librem5 phone hardware:
-
- Even though there exists a great variety of ARM-based SoCs, Genode
- primarily focuses on the NXP i.MX family because it is - in contrast
- to most SoCs in the consumer space - very liberal in terms of
- good-quality public documentation and reference code, and it scales
- from industrial to end-user-facing use cases (multi-media).
-
- The [https://puri.sm/products/librem-5/ - Librem5] project - with its
- mission to build a trustworthy mobile phone - has chosen the i.MX family as
- the basis for their product for likely the same reasons that attract us.
-
- To goal of this work is bringing Genode to the Librem5 hardware.
- For the Librem5 project, Genode could pave the ground towards new use cases
- like high-security markets where a regular Linux-based OS would not be
- accepted. For the Genode community, the Librem5 hardware could become an
- attractive mobile platform for everyday use, similar to how we developers
- use our Genode-based [https://genode.org/download/sculpt - Sculpt OS] on our
- laptops.
-
-
-System management
-#################
+ Starting with version 24.04, Sculpt OS provides the ability to supervise
+ selected components
+ [https://genodians.org/chelmuth/2024-05-17-on-target-debugging - using the GDB protocol].
+ The underlying mechanism and infrastructure could be leveraged for
+ implementing a statistical profiler that monitors components live.
+ Using the on-target information obtained via Sculpt's "download debug info"
+ option, the tool could display a sorted list of the most executed
+ functions, facilitating interactive on-target analysis and experimentation.
:Remote management of Sculpt OS via Puppet:
@@ -406,18 +279,3 @@ System management
The project would explore the application of the Puppet approach and tools
to Sculpt OS.
-
-Optimizations
-#############
-
-:De-privileging the VESA graphics driver:
-
- The VESA graphics driver executes the graphics initialization code provided
- by the graphics card via an x86 emulator. To initialize a graphics mode, this
- code needs to access device hardware. Currently, we permit access to all
- device registers requested by the graphics-card's code. These devices include
- the system timer, the PCI configuration registers, and the interrupt
- controller, which are critical for the proper operating of the kernel. The
- goal of this work is to restrict the permissions of the VESA driver to a
- minimum by virtualizing all devices but the actual graphics card.
-
diff --git a/doc/components.txt b/doc/components.txt
index 7fe7f350e5..b4cedc24c5 100644
--- a/doc/components.txt
+++ b/doc/components.txt
@@ -34,10 +34,11 @@ of them is briefly characterized as follows:
the driver is made available to other system components via
one of Genode's device-independent session interfaces, which are
'platform_session', 'capture_session', 'event_session', 'block_session',
- 'audio_out_session', 'log_session', 'nic_session', and 'timer_session'
- (see _os/include/_ for the interface definitions). Those interfaces are
- uniform across hardware platforms and kernel base platforms. Usually,
- each device driver can accommodate only one client at a time.
+ 'record_session', 'play_session', 'log_session', 'uplink_session', and
+ 'timer_session' (see _os/include/_ for the interface definitions).
+ Those interfaces are uniform across hardware platforms and kernel base
+ platforms. Usually, each device driver accommodates one client at a
+ time.
:Resource multiplexers: provide mechanisms to multiplex device resources
to multiple clients. A typical resource multiplexer requests one
@@ -64,7 +65,7 @@ of them is briefly characterized as follows:
Device drivers
##############
-Device drivers usually reside in the _src/drivers/_ subdirectory of source-code
+Device drivers usually reside in the _src/driver/_ subdirectory of source-code
repositories. The most predominant repositories hosting device drivers are
'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
@@ -78,18 +79,23 @@ a different SoC family such as NXP's i.MX, Allwinner, Xilinx Zynq, or RISC-V.
Platform devices
================
-:_os/src/drivers/platform/_: Platform drivers for various platforms.
+:_os/src/driver/platform/_: Platform drivers for various platforms.
On x86, the platform driver uses the PCI controller as found on x86 PC
hardware. A client can probe for a particular device and request information
about physical device resources (using the 'platform_device' interface). I/O
resources for MMIO regions, I/O ports, and interrupts can be requested by the
provided device abstraction.
-:_os/src/drivers/acpi/_:
+:_os/src/driver/acpi/_:
On x86 platforms that use the APIC (namely Fiasco.OC, NOVA, and hw_x86_64)
this simple ACPI parser traverses the ACPI tables and reports device-resource
information (e.g., interrupt lines of PCI devices).
+:_os/src/app/pci_decode/_:
+ A component that reports the physical information about PCI devices after
+ parsing and initializing the PCI bus. The reported information is usually
+ consumed by the platform driver.
+
:_os/src/app/smbios_decoder/_:
A component that parses SMBIOS information on x86 platforms and makes the
result available as a report.
@@ -108,10 +114,10 @@ UART devices
The UART device drivers implement the UART-session interface.
-:_os/src/drivers/uart/spec/pbxa9/_:
+:_os/src/driver/uart/spec/pbxa9/_:
Driver for the PL011 UART as found on many ARM-based platforms.
-:_os/src/drivers/uart/spec/x86/_:
+:_os/src/driver/uart/spec/x86/_:
Driver for the i8250 UART as found on PC hardware.
@@ -121,11 +127,11 @@ Framebuffer and input drivers
Framebuffer and input drivers are implemented as clients of the
capture-session and event-session interfaces respectively.
-:_os/src/drivers/ps2/x86/_:
+:_os/src/driver/ps2/x86/_:
Driver for the 'i8042' PS/2 controller as found in x86 PCs. It supports both
mouse (including ImPS/2, ExPS/2) and keyboard.
-:_os/src/drivers/ps2/pl050/_:
+:_os/src/driver/ps2/pl050/_:
Driver for the PL050 PS/2 controller as found on ARM platforms such as
VersatilePB. The physical base address used by the driver is obtained at
compile time from a header file called _pl050_defs.h_. The version of the
@@ -133,33 +139,36 @@ capture-session and event-session interfaces respectively.
is made available to the driver via the SPECS machinery of the Genode build
system.
-:_libports/src/drivers/framebuffer/vesa/_:
+:_libports/src/driver/framebuffer/vesa/_:
Driver using VESA mode setting on x86 PCs. For more information, please refer
to the README file in the driver directory.
-:_libports/src/drivers/framebuffer/boot/_:
+:_libports/src/driver/framebuffer/boot/_:
Driver for boot-time initialized framebuffers (e.g., UEFI GOP)
discovered from the 'platform_info' ROM
-:_os/src/drivers/framebuffer/pl11x/_:
+:_os/src/driver/framebuffer/pl11x/_:
Driver for the PL110/PL111 LCD display.
-:_os/src/drivers/framebuffer/sdl/_:
+:_os/src/driver/framebuffer/sdl/_:
Serves as both framebuffer and input driver on Linux using libSDL. This
driver is only usable on the Linux base platform.
-:_os/src/drivers/gpu/intel/_:
- An experimental Intel Graphics GPU multiplexer for Broadwell and newer.
+:_os/src/driver/framebuffer/virtio/_:
+ Driver for the Virtio virtual graphics device as supported by Qemu.
-:_pc/src/drivers/framebuffer/intel/_:
+:_os/src/driver/gpu/intel/_:
+ An Intel Graphics GPU multiplexer for Broadwell and newer.
+
+:_pc/src/driver/framebuffer/intel/_:
Framebuffer driver for Intel i915 compatible graphic cards based on
the Linux Intel KMS driver.
-:_pc/src/drivers/usb_host/_:
+:_pc/src/driver/usb_host/_:
USB host-controller driver that provides an USB session interface to
USB drivers.
-:_dde_linux/src/drivers/usb_hid/_:
+:_dde_linux/src/driver/usb_hid/_:
USB Human Interface Device driver using the USB session interface.
@@ -186,14 +195,14 @@ provided by the kernel, or a pseudo time source (busy):
Audio drivers
=============
-Audio drivers implement the Audio_out session interface defined at
-_os/include/audio_out_session/_ for playback and optionally the audio_in
-interface for recording.
+Audio drivers use the audio mixer's record session interface defined at
+_os/include/record_session/_ for audio output and optionally the play
+session interface _os/include/play_session/_ for audio input.
-:_os/src/drivers/audio/spec/linux/_:
+:_os/src/driver/audio/spec/linux/_:
Uses ALSA as back-end on the Linux base platform and supports only playback.
-:_dde_bsd/src/drivers/audio/_:
+:_dde_bsd/src/driver/audio/_:
Sound drivers ported from OpenBSD. Currently, the repository
includes support for Intel HD Audio as well as for Ensoniq AudioPCI
(ES1370) compatible sound cards.
@@ -205,21 +214,17 @@ Block drivers
All block drivers implement the block-session interface defined at
_os/include/block_session/_.
-:_os/src/drivers/sd_card/pl180/_:
+:_os/src/driver/sd_card/pl180/_:
Driver for SD-cards connected via the PL180 device as found on the PBX-A9
platform.
-:_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/ahci/_:
+:_os/src/driver/ahci/_:
Driver for SATA disks and CD-ROMs on x86 PCs.
-:_os/src/drivers/nvme/_:
+:_os/src/driver/nvme/_:
Driver for NVMe block devices on x86 PCs.
-:_os/src/drivers/usb_block/_:
+:_os/src/driver/usb_block/_:
USB Mass Storage Bulk-Only driver using the USB session interface and provides
a block-session interface.
@@ -230,28 +235,29 @@ Network interface drivers
All network interface drivers implement the NIC session interface
defined at _os/include/nic_session/_.
-:_os/src/drivers/nic/spec/linux/_:
+:_os/src/driver/nic/spec/linux/_:
Driver that uses a Linux tap device as back end. It is only useful on the
Linux base platform.
-:_os/src/drivers/nic/lan9118/_:
+:_os/src/driver/nic/lan9118/_:
Native device driver for the LAN9118 network adaptor as featured on the
PBX-A9 platform.
-:_dde_ipxe/src/drivers/nic/_:
+:_dde_ipxe/src/driver/nic/_:
Device drivers ported from the iPXE project. Supported devices are Intel
E1000 and pcnet32.
-:_pc/src/drivers/wifi/_:
+:_pc/src/driver/nic/pc/_:
+ The PC NIC-driver component uses network driver code of the Linux kernel
+ to drive common network cards as found in commodity PC hardware.
+
+:_pc/src/driver/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/_:
+:_dde_linux/src/driver/usb_net/_:
USB network driver using the USB session interface.
-:_dde_linux/src/drivers/nic/fec/_:
- Driver for ethernet NICs of the i.MX SoC family.
-
Resource multiplexers
#####################
@@ -268,9 +274,9 @@ subdirectory of a source repository.
framebuffer and a virtual input interface. Nitpicker (including a README
file) is located at _os/src/server/nitpicker/_.
-:Audio output: The audio mixer located at _os/src/server/mixer/_ enables
- multiple clients to use the audio-out interface. The mixing is done by simply
- adding and clamping the signals of all present clients.
+:Audio output: The audio mixer located at _os/src/server/record_play_mixer/_
+ allows for the routing and mixing of audio signals from play-session clients
+ to record-session clients.
:Networking: The NIC bridge located at _os/src/server/nic_bridge/_ multiplexes
one NIC session to multiple virtual NIC sessions using a proxy-ARP
@@ -282,6 +288,9 @@ subdirectory of a source repository.
session to multiple virtual NIC sessions by applying network address
translation (NAT).
+ The NIC-uplink component located at _os/src/server/nic_uplink/_ connects
+ a NIC client directly to a network driver (as uplink client) without routing.
+
:Block: The block-device partition server at _os/src/server/part_block/_ reads
the partition table of a block session and exports each partition found as
separate block session. For using this server, please refer to the run
@@ -491,8 +500,8 @@ Libraries
Library for implementing pseudo-graphical applications (i.e., VIM) that
run on a text terminal.
-:_libports/lib/mk/qt5_*/_:
- Qt5 framework, using GUI session and NIC session as back end.
+:_libports/qt6/_:
+ Qt6 application framework.
:_libports/lib/mk/vfs_jitterentropy.mk_:
A VFS plugin that makes a jitter-based random-number generator available
@@ -530,14 +539,14 @@ located in their respective directory.
:_demo/src/app/scout/_:
Graphical hypertext browser used for Genode's default demonstration scenario.
-:_ports/src/app/gdb_monitor/_:
- Application that allows the debugging of a process via GDB over a remote
- connection.
+:_os/src/monitor/_:
+ Variant of init that allows for the debugging of components via GDB over a
+ remote connection.
-:_libports/src/app/qt5/qt_launchpad/_:
+:_libports/src/app/qt6/qt_launchpad/_:
Graphical application starter implemented using Qt.
-:_libports/src/app/qt5/examples/_:
+:_libports/src/app/qt6/examples/_:
Several example applications that come with Qt.
:_os/src/app/sequence/_:
@@ -577,6 +586,9 @@ Package-management components
:_gems/src/app/depot_deploy/_:
Subsystem init configuration generator based on blueprints.
+:_gems/src/app/depot_remove/_:
+ Tool for the orderly removal of depot content.
+
:_libports/src/app/fetchurl/_:
A runtime-configurable frontend to the libcURL library for
downloading content.
diff --git a/doc/depot.txt b/doc/depot.txt
index 7fcab5ff49..abd9196a13 100644
--- a/doc/depot.txt
+++ b/doc/depot.txt
@@ -228,7 +228,7 @@ subdirectory. Within this directory, there is a 'pubkey' file with the
user's public key that is used to verify the integrity of archives downloaded
from the user. The file 'download' specifies the download location as an URL.
-Subsuming archives in a subdirectory that correspond to their the origin
+Subsuming archives in a subdirectory that correspond to their origin
(user) serves two purposes. First, it provides a user-local name space for
versioning archives. E.g., there might be two versions of a
'nitpicker/2017-04-15' source archive, one by "genodelabs" and one by
@@ -290,7 +290,7 @@ archive is downloaded as well. All archive types are accepted as arguments
including binary and package archives. Furthermore, it is possible to download
all binary archives referenced by a package archive. For example, the
following command downloads the window-manager (wm) package archive including
-all binary archives for the 32-bit x86 architecture. Downloaded binary
+all binary archives for the 64-bit x86 architecture. Downloaded binary
archives are always accompanied with their corresponding source and used API
archives.
diff --git a/doc/getting_started.txt b/doc/getting_started.txt
index 70569c418d..e9679cd351 100644
--- a/doc/getting_started.txt
+++ b/doc/getting_started.txt
@@ -22,7 +22,8 @@ The best starting point for exploring Genode is to run it on Linux. Make sure
that your system satisfies the following requirements:
* GNU Make version 3.81 or newer
-* 'libSDL-dev'
+* 'libsdl2-dev', 'libdrm-dev', and 'libgbm-dev' (needed to run interactive
+ system scenarios directly on Linux)
* 'tclsh' and 'expect'
* 'byacc' (only needed for the L4/Fiasco kernel)
* 'qemu' and 'xorriso' (for testing non-Linux platforms via Qemu)
diff --git a/doc/news.txt b/doc/news.txt
index 46f5b2cd18..69ca452c64 100644
--- a/doc/news.txt
+++ b/doc/news.txt
@@ -4,6 +4,516 @@
===========
+Genode OS Framework release 24.08 | 2024-08-29
+##############################################
+
+| Genode 24.08 introduces the Qt6 application framework, updates all
+| Linux-based components and PC device drivers to Linux version 6.6.47,
+| equips the Goa SDK with remote debugging support, modernizes the base
+| and GUI interfaces of the framework, extends the board support for
+| i.MX-based devices, and explores AVX on x86.
+
+The highlights of Genode 24.08 are the addition of the Qt6 application
+framework in addition to the time-tested Qt5 and the major update of all
+Linux-based components and PC device drivers. So Genode users can enjoy
+current-generation commodity software and drivers across all kernels supported
+by the framework.
+
+For developers, the new combination of Genode's recent advances in
+on-target debugging with the Goa SDK enables seamless remote debugging.
+
+Regarding hardware support, the new version broadens the driver landscape for
+NXP i.MX-based devices, paving the way for Sculpt OS on the
+[https://shop.mntre.com/products/mnt-pocket-reform - MNT Pocket Reform]
+open-source hardware laptop.
+
+For the full picture, please refer to the
+[https:/documentation/release-notes/24.08 - release documentation of version 24.08...]
+
+
+New community forum at Discourse | 2024-08-13
+#############################################
+
+| Our new community forum is organized by Genode users to share ideas
+| and experiences, help newcomers, and discuss Genode-related projects.
+
+The new forum complements the existing
+[http:/community/mailing-lists - mailing list] and
+[https://github.com/genodelabs/genode - issue tracker]
+with a place for casual conversation among newcomers, seasoned users,
+and developers.
+
+[https://genode.discourse.group]
+
+As the forum is a place for users, it is moderated by users. Thanks a lot
+to Spencer and Cedric for constituting the initial moderation team!
+
+
+Meet us at FroSCon during August 17-18 | 2024-07-30
+###################################################
+
+| The Genode project will host a booth at this year's Free
+| and Open-Source Software Conference in Sankt Augustin.
+
+Besides FOSDEM, public appearances of Genode are rather rare.
+All the more delighted we are about the opportunity to host
+a booth at the upcoming FrOScon conference.
+
+*FrOScon Free and Open-Source Software Conference*
+
+*August 18 and 17 in Sankt Augustin*
+
+[https://froscon.org]
+
+The Genode stand will be maintained by the Genode team members
+Stefan Kalkowski, Johannes Schlatow, Christian Helmuth, and
+Norman Feske. It goes without saying that we will have Sculpt
+OS in various forms and flavors with us to showcase. Whether
+you like to get acquainted with our project or touch base with
+us developers in person, FrOScon might present the perfect
+opportunity!
+
+
+Genode OS Framework release 24.05 | 2024-05-30
+##############################################
+
+| The highlights of Genode 24.05 are the new ability to run Sculpt OS on
+| our custom kernel, GDB on Sculpt OS, suspend/resume, the redesign of
+| the framework's USB infrastructure, and the completed transition to
+| the new audio interfaces. The release is accompanied with the annual
+| update of the "Genode Foundations" book.
+
+With Genode 24.05, the underpinnings of the many usability improvements
+of the [https://genode.org/news/sculpt-os-release-24.04 - latest] Sculpt OS
+release found their way into the framework. Among them are a completely
+redesigned USB infrastructure that allows for fine-grained and dynamic
+assignment of USB devices to components and virtual machines, the consistent
+use of the audio facilities introduced in February, and the driver life-cycle
+management for suspend/resume.
+
+Beside those usability-related topics, two mile-stone achievements stand out.
+First, we have realized our long-time vision of running Sculpt OS on our
+custom kernel specifically designed for Genode. With Intel virtualization
+support, the release delivers the final missing piece of this puzzle.
+Second, our long-hedged dream of natural on-target debugging via the GNU
+debugger running directly on Sculpt OS has become true. This feature, which
+has been in the works for more than a year, enables Sculpt OS users to
+leverage GDB for the development of applications, services, and even device
+drivers.
+
+The release is accompanied by a new version of the "Genode Foundations" book,
+which is the go-to documentation of the framework.
+Further topics of the current release range from timing and network-throughput
+optimizations, over updated 3rd-party software like Mesa, libSDL2, and cURL,
+to developer tooling. Find these among many more topics covered in the detailed
+[https:/documentation/release-notes/24.05 - release documentation of version 24.05...]
+
+
+Sculpt OS release 24.04 | 2024-04-26
+####################################
+
+| Sculpt OS 24.04 is rich of new user-visible features.
+| It now supports 4K displays and I2C touchpads out of the box,
+| brings experimental support for suspend/resume,
+| allows the fine-grained assignment of USB devices to applications and VMs,
+| and introduces new audio-mixing capabilities.
+
+The release of version 24.04 adheres to
+our [https://genode.org/about/road-map - declared] focus on Sculpt OS usability
+during this year. Seasoned users will immediately recognize the new power of the
+component-management UI, offering easy control over optional features,
+software providers, and software installation. Among many little
+user-interface improvements, the component graph and configuration interface
+have become scrollable, boosting the interactive user experience.
+
+When looking closely at the components, users will recognize a whole new set
+of drivers neatly grouped under hardware. In contrast to earlier versions,
+which operated these drivers hidden from the user, the new version manages the
+drivers dynamically and fully transparent for the user. The change makes the
+user interface more logical and simpler. However, the driving force behind this
+approach
+was our aspired support for suspend/resume, which requires the dynamic
+life-cycle management of drivers. This brings us to the technical highlight of
+the release: After on-and-off development for more than a year, we are more
+than happy offering suspend/resume as an experimental feature.
+
+As culmination of a second long-term development, version 24.04 employs a new
+and much more flexible interplay between the USB-host driver and components
+accessing USB devices. The dynamic assignment of devices to virtual machines
+and other components has become a breeze.
+
+Just in time for the release, Sculpt OS has received a completely overhauled
+audio stack that supports pluggable drivers, arbitrary sample rates, and the
+flexible routing and mixing of audio signals. We are eager to stress and
+refine the taken approach over the upcoming release cycle to make low-latency
+audio a commodity on Sculpt OS.
+
+Thanks to our routine with running Sculpt OS on modern laptops day to day,
+version 24.04 bumps the range of supported hardware. Displays up to 4K are
+supported out of the box now, and touchpads of laptops like the Gen13 Framework
+have become operational.
+
+Speaking of developers, the release offers two bold new features targeted at
+this specific demography, namely the support for on-target debugging via GDB,
+and the ability to use Sculpt OS as a remote test target of Genode's Goa SDK.
+Look out for more information about these features in the upcoming weeks
+at [https://genodians.org].
+
+Sculpt OS 24.04 is available as ready-to-use system image at the
+[https://genode.org/download/sculpt - Sculpt download page] accompanied
+with updated [https://genode.org/documentation/articles/sculpt-24-04 - documentation].
+
+
+Genode OS Framework release 24.02 | 2024-02-29
+##############################################
+
+| Version 24.02 revisits Genode's audio support for latency-sensitive
+| scenarios, flexible sample rates, and pluggable drivers. It also introduces
+| the new ability of the Goa SDK to use Sculpt OS as remote test target,
+| comes with a new TCP/IP stack based on Linux 6.1.20, makes drivers aware
+| of suspend/resume, and improves HID event handling.
+
+Genode 24.02 kicks off the year with a profound redesign of the framework's
+audio infrastructure, addressing the routing and mixing of multi-channel audio
+streams at flexible sample rates, the dynamic starting and removal of audio
+sources and sinks, and latency optimization.
+
+Besides audio, the second infrastructural rework is a new TCP/IP stack based
+on DDE-Linux 6.1.20. It wraps up our long-year transition from a fairly
+fragmented landscape of ported driver code to the consistent use of our modern
+Linux device-driver environment across all Linux-based drivers and protocol
+stacks.
+
+The feature highlight of the release is the new ability of using Sculpt OS as
+a remote test target for the Goa SDK during application development. Thanks
+to this new feature, Genode applications can be developed and tested in a
+quick and uniform way, whether testing directly on a Linux-based development
+environment, or on a Sculpt PC reachable via a local network, or a PinePhone
+connected to the same wireless access point.
+
+Further highlights of the release are the versatile handling of human-interface
+devices including the calibration of motion events, the use of Vivante GPUs by
+multiple clients, and the driver-related preparatory steps needed for
+implementing suspend/resume for Sculpt OS.
+
+You can find the changes presented in full detail in the
+[https:/documentation/release-notes/24.02 - release documentation of version 24.02...]
+
+
+Road Map for 2024 | 2024-01-18
+##############################
+
+| After intensively concentrating on deeply technical topics below the surface
+| in 2023, we are going to reap user-visible rewards in 2024 by focussing on
+| Sculpt OS usability.
+
+Thanks to the input gathered from our annual road-map discussion on Genode's
+[https://genode.org/community/mailing-lists - mailing list], we have updated
+the project [https://genode.org/about/road-map - road map] for 2024.
+
+Without hesitation, our developer community quickly rallied behind the topic
+"Sculpt OS usability", desiring to boost the user experience with respect to
+multi-monitor usage, convenient interactive UIs for common tasks,
+profound support for touchpads and touchscreens, tearing-free graphics,
+low-latency audio, casual on-target debugging, and suspend/resume.
+
+The focus on usability notwithstanding, we will steadily continue with the
+gardening of Genode's driver landscape, fostering the consistent use of drivers
+ported from up-to-date Linux kernels, clear-cut ACPI support, and making
+drivers pluggable.
+In 2024, we will also promote Genode's custom (base-hw) microkernel to become
+the default kernel for Sculpt OS, which is the culmination of a multi-year
+effort.
+
+Please find our reflection of the past year and the complete plan for 2024
+presented on Genode's official [https:/about/road-map - road-map page].
+
+
+Genode OS Framework release 23.11 | 2023-11-30
+##############################################
+
+| Genode 23.11 moves the IOMMU driver from the kernel to the user land,
+| introduces CPU power/temperature/frequency monitoring and steering,
+| comes with a new API for low-complexity GUI applications, and
+| streamlines the framework's virtualization interface. It also improves
+| developer ergonomics and showcases the port of the Linphone VoIP stack.
+
+Version 23.11 of the Genode OS Framework introduces DMA protection as
+kernel-agnostic feature, parting with the tradition of driving I/O protection
+units from the kernel. This radical move is accompanied by a sweeping
+modernization of the framework's virtualization interface across kernels and
+instruction-set architectures. In other words, the release is dominated by
+deeply technical topics.
+
+That said, it is not void of user-facing features either, as illustrated by
+the new port of the Linphone VoIP stack using the Goa tool, the extension of
+the Seoul virtual machine monitor to 64-bit guests, and the support for CPU
+power/temperature/frequency monitoring and steering on PC platforms.
+Furthermore, developers receive better tooling for the use and distribution of
+debug builds, and will observe a welcomed boost of their development-test
+cycles thanks to a largely streamlined build-system.
+
+These and more topics are covered in full detail by the
+[https:/documentation/release-notes/23.11 - release documentation of version 23.11...]
+
+
+Sculpt OS release 23.10 | 2023-10-26
+####################################
+
+| Modern PCs provide plenty of metering and power-management options.
+| Version 23.10 of the Genode-based Sculpt operating system makes these features
+| available via an interactive user interface. One can watch the temperature
+| of each CPU core, monitor the individual CPU frequencies, switch between
+| power profiles, and reveal details about power draw.
+
+Our official
+[https://genode.org/documentation/articles/sculpt-23-10 - documentation]
+introduces Sculpt as an operating system that puts the user in the position
+of full control. With the new release, this promise is taken to the precise
+control and monitoring of physical CPU parameters.
+
+Besides restricting workloads to specific CPU cores, each individual core can
+be interactively parametrized, e.g., by balancing performance against power
+efficiency. The effects of changing these parameters become immediately
+visible by the monitored frequencies, temperature, and power draw. The new
+knobs add plenty of play value and an entirely new sense of control to the
+user experience. You can find the new power-control feature described in a
+[https://genodians.org/alex-ab/2023-10-23-msr - dedicated article].
+
+The advanced power-control abilities are accompanied with generally improved
+support for modern laptops. E.g., on the Framework Gen 12 laptop,
+features like battery monitoring, keyboard backlight control, and external
+displays just work now.
+
+Like the previous release, Sculpt OS is available for both PCs and the
+PinePhone. The PinePhone version received several usability improvements
+motivated by the feedback we got from the Pine64 community. Most importantly,
+a new screensaver reduces the power draw to less than 40%, making the device
+more viable in practice.
+Under the hood, Sculpt completely removes the drivers for the display and the
+touchscreen while the screen is blanked. Those drivers are restarted when
+pressing the power button. Furthermore, the volume buttons have become
+functional, and the dial pad has become more flexible.
+
+Beside the user-visible improvements, the underpinnings of Sculpt OS
+received a number of improvements. The entire software is now consistently
+built with GCC 12.3. The former iPXE-based network driver has been replaced
+by driver code of the Linux kernel 6.1.20, which works nicely on modern
+machines. The new version also introduces the principle mechanisms needed
+for on-target debugging, switches to a much revised virtualization interface,
+and replaces the block-encryption engine of the file vault. Users of the latter
+should follow the documented
+[https://genodians.org/m-stein/2023-10-25-file-vault-migration-1 - migration steps].
+
+Sculpt OS 23.10 for PC and PinePhone is available as ready-to-use system image
+at the [https://genode.org/download/sculpt - Sculpt download page] accompanied
+with updated [https://genode.org/documentation/articles/sculpt-23-10 - documentation].
+Seasoned Sculpt users can conveniently switch to the new version via the
+system-update dialog.
+
+
+Genode OS Framework release 23.08 | 2023-08-24
+##############################################
+
+| The main theme of the current release is tooling for developing, debugging,
+| porting, and publishing Genode components. Beyond that, the release improves
+| driver support and the internals of core and the base-framework.
+
+The headline features of this release introduce a new multi-component debug
+monitor and extend the Goa tool with support for working with multiple
+projects.
+
+The new debug monitor reapproaches Genode's GDB debugging support and sets
+smooth on-target debugging in Sculpt OS as its final goal. The monitor can
+transparently replace the Init component and is equipped with support for
+multi-component debugging by GDB inferiors. The Goa tool evolves into an
+all-encompassing alternative to Genode's traditional work flows for developing,
+porting, and publishing applications. With this release, runtime testing with
+Goa gets extremely flexible and handling of multiple Goa projects becomes a no
+brainer.
+
+Beside the tooling topics, we round out the release with a new PC NIC driver
+based on Linux, new RaspberryPi/i.MX6 USB host-controller drivers,
+hardware-button and screensaver support on the PinePhone, improved Intel
+GPU/display, WiFi, and audio drivers.
+
+Find all details of changes and improvements in the
+[https:/documentation/release-notes/23.08 - release documentation of version 23.08...]
+
+
+Genode OS Framework release 23.05 | 2023-05-31
+##############################################
+
+| Besides the annual documentation update, the scheduled tool-chain update,
+| and the switch to C++20, the release puts the spotlight on the Goa tool,
+| which enables the use of existing SDKs like Lomiri or Rust's cargo for
+| targeting Genode.
+
+By now, the dedication of Genode's May releases to housekeeping tasks has
+become a fine tradition, and this year is no different. With version 23.05,
+the framework consistently switches from the C++ standard C++17 to C++20,
+thanks to our new tool chain based on GCC 12.3, which will serve us for the
+next two years. Speaking of consistency, both Genode books "Foundations" and
+"Platforms" have been updated to the most recent version of the framework. You
+can find the PDFs at the [https://genode.org - genode.org front page].
+
+Following the recent release of Sculpt OS 23.04 targeting both PC and mobile
+platforms, Genode 23.05 brings good news for application developers interested
+in targeting Genode and Sculpt OS in particular. The release introduces the
+ability to use existing SDKs, in particular the Lomiri UI toolkit as well as
+Rust's cargo for crafting Genode applications.
+
+A prominent topic among the previous releases is our Linux device-driver
+environment (DDE), which allows for the use of Linux drivers as Genode
+components. The current release continues this line of work by upgrading DDE
+to Linux 6.1.20 and by using DDE as enabler of our cross-platform Wifi stack
+that works for the PC and ARM platforms like the PinePhone. This way, Genode
+users can benefit from the enormous efforts of the Linux kernel community
+targeting modern hardware.
+
+Further highlights of the new version are the initial use of our custom
+base-hw microkernel as x86 hypervisor, a profoundly reworked block-encryption
+stack, and updates of supported 3rd-party software like the seL4 kernel and
+VirtualBox.
+
+All changes are covered in detail by the official
+[https:/documentation/release-notes/23.05 - release documentation of version 23.05...]
+
+
+Sculpt OS release 23.04 | 2023-04-28
+####################################
+
+| Sculpt OS 23.04 marks the first-time PinePhone support in addition to the PC
+| version. With this release, the system supports live upgrades of the boot
+| image, rendering Sculpt updates and the switching between versions a matter of
+| some easy steps. The new preset feature brings entire application scenarios to
+| your screen after just one click/tap.
+
+With the fresh release 23.04, the Sculpt operating system boards the PinePhone
+to explore the mobile world and, thereby, adds a second platform to its
+year-long support for Intel PCs. In preparation, we added two key features to
+Genode during the past months, which are the phone-oriented Sculpt
+user-interface variant and the system-update functionality. Now, Sculpt
+versions can be switched by three easy steps directly in the integrated user
+interface: downloading system images to the software depot, install the
+desired version on the boot medium, and reboot the device.
+
+Further, the release supports so-called presets in the system menu UI, which
+are entire runtime scenarios. The user can load and switch between presets by
+just one click. Presets currently available in Sculpt are a simple GUI demo
+(nano3d), a simple desktop including background picture and window manager,
+and a ready to use Falkon web browser. Still, components can be integrated
+into the system (or the currently running preset) by the + menu of the
+component graph.
+
+Sculpt OS 23.04 for PC and PinePhone is available as ready-to-use system image
+at the [https://genode.org/download/sculpt - Sculpt download page] accompanied
+with updated [https://genode.org/documentation/articles/sculpt-23-04 - documentation].
+
+
+Genode OS Framework release 23.02 | 2023-02-28
+##############################################
+
+| Version 23.02 introduces system-update functionality to the mobile version
+| of Sculpt OS, enhances our ARM VMM for interactive guest OSes, adds DMA
+| protection to Xilinx Zynq via a custom IP core, extends suspend/resume
+| support, and makes Intel's P&E cores explicitly manageable.
+
+For the first time, Genode has become easily installable on the PinePhone.
+The first system image is not merely a re-targeted PC version of Sculpt OS but
+it comes with a novel user interface, a new mechanism for rapidly switching
+between different application scenarios, and system-update functionality. This
+is everything we need to kick off the first public field test of Genode on the
+phone. This line of development motivated plenty of optimizations - from
+kernel scheduling, over the I/O throughput of the VFS, to the interfacing of
+GPU drivers - that made it into version 23.02.
+
+Besides the focus on the phone, the release continues the hardware-software
+co-design story of the previous version by adding DMA protection to Xilinx
+Zynq SoCs using custom FPGA fabric, which is especially tailored for Genode.
+But also stationary platforms like PCs and ARM laptops received attention.
+On ARM, we enabled the use of interactive virtual machines by adding
+device models for the GPU and input events. For the PC, the principle support
+for suspend/resume has become available to Genode's custom microkernel in
+addition to NOVA, and Genode learned to distinguish Intel's performance cores
+from energy-efficient cores.
+
+Regarding application workloads, the new release is accompanied by a
+substantially improved version of the Goa tool, which streamlines the
+creation, packaging, and publishing of Genode components using commodity
+build systems. With the new version, Goa largely automates the
+porting of CMake-based 3rd-party libraries for Genode.
+
+Find these among many more topics covered by the official
+[https:/documentation/release-notes/23.02 - release documentation of version 23.02...]
+
+
+Road Map for 2023 | 2023-01-17
+##############################
+
+| In 2023, we will make the mobile version of Sculpt OS fit for end users,
+| unleash advanced hardware features of Intel platforms,
+| switch to C++20 by default, and run the feature-complete PC version
+| of Sculpt OS on Genode's custom-tailored microkernel.
+
+After having enabled all hardware features of the PinePhone that are
+fundamental for a mobile phone over the course of the past year, the
+project now aims at getting the mobile version of Sculpt OS into the hands of
+end users. Throughout the year, there will be multiple rounds of field tests
+within the community, allowing us to reach the desired state of maturity and
+usefulness in an iterative way.
+
+On PC platforms, Genode will increasingly address advanced platform features
+like the distinction between power-efficient and high-performance cores, the
+management of temperatures and frequencies, or the practical use of
+suspend/resume. By the end of the year, we envision the PC version of Sculpt
+OS running on Genode's custom-tailored microkernel leveraging all those
+aspects of modern PC hardware.
+
+Along the planned timeline of the project, one can spot plenty of additional
+topics of interest such as the continued line of work of combining Genode
+with FPGAs, applications implemented in Rust, the integration of IPv6, the
+use of C++20 by default, or completed driver support for the MNT Reform laptop.
+An exciting year lies ahead of us!
+
+More details including our reflections of the past year, this year's focus,
+and a rough schedule are presented at our official
+[https:/about/road-map - road-map page].
+
+
+Genode OS Framework release 22.11 | 2022-11-30
+##############################################
+
+| Genode 22.11 enables hardware-accelerated graphics on up-to-date Intel
+| GEN12+ hardware, introduces work flows for hardware-software co-design,
+| wraps up the framework's unified device-driver infrastructure across PC and
+| ARM, and pushes forward the use of Genode on the PinePhone.
+
+The Genode OS framework is both a dependable foundation for custom operating
+systems - like Sculpt OS - and at the same time a playground for new ideas.
+The just released version 22.11 pays tribute to both facets. On the one hand,
+it features the results of our year-long effort of unifying and simplifying
+the framework's device-driver infrastructure across all base platforms, which
+subjects the interaction of driver components with device hardware to an
+unprecedentedly rigid regime of least privilege. This makes Genode-based
+systems ever more dependable and clear.
+
+The role of Genode as a playground for innovation is embodied by the
+combination of the framework with reconfigurable hardware. The release
+introduces new work flows for designing hardware IP cores and Genode
+components in tandem, which allows for low-complexity software-hardware
+co-designs that fit like a glove.
+
+Feature-wise, the new version covers a vast area of topics. The enhancement of
+our Intel GPU multiplexer to current GEN12+ hardware stands out most. Further
+topics range from the emerging user interface for Genode on the PinePhone,
+over plenty of device-driver work, to virtualization improvements on ARM and
+PC hardware.
+
+These and many more topics of the new version are covered by the official
+[https:/documentation/release-notes/22.11 - release documentation of version 22.11...]
+
+
Sculpt OS release 22.10 | 2022-10-13
####################################
diff --git a/doc/release_notes/22-08.txt b/doc/release_notes/22-08.txt
index 6b501b28f2..224cb4a750 100644
--- a/doc/release_notes/22-08.txt
+++ b/doc/release_notes/22-08.txt
@@ -400,7 +400,7 @@ We invite seasoned developers - especially those who are following the
[https://genodians.org/nfeske/index - Pine-fun article series] - to experiment
with the new phone variant. It can be built via the following command:
-! built/arm_v8a$ make run/sculpt KERNEL=hw BOARD=pinephone SCULPT=phone
+! build/arm_v8a$ make run/sculpt KERNEL=hw BOARD=pinephone SCULPT=phone
For a broader audience, we plan to provide a ready-to-use SD-card image for
the PinePhone in tandem with the next release of Sculpt OS.
diff --git a/doc/release_notes/22-11.txt b/doc/release_notes/22-11.txt
new file mode 100644
index 0000000000..06e54b3794
--- /dev/null
+++ b/doc/release_notes/22-11.txt
@@ -0,0 +1,1015 @@
+
+
+ ===============================================
+ Release notes for the Genode OS Framework 22.11
+ ===============================================
+
+ Genode Labs
+
+
+
+With version 22.11, we pursued two new exploratory topics as we envisioned on
+the project's [https://genode.org/about/road-map - road map] for this year,
+namely the use of the framework for hardware-software co-design work,
+and principally enabling suspend/resume functionality on PCs.
+
+A decade ago, we
+[https://genode.org/documentation/release-notes/11.02#Approaching_platform_support_for_Xilinx_MicroBlaze - explored the combination]
+of Genode with FPGA technology for the first time.
+Our interest in this direction got reignited two years ago when we started
+enabling Genode on a board based on the Xilinx Zynq, which combines an ARMv7
+SoC with FPGA fabric. This line of work eventually culminated in new
+development work flows for creating hardware IP cores and Genode components in
+tandem. Section [Hardware-software co-design with Genode on Xilinx Zynq] covers
+the results of this line of work.
+
+The second largely exploratory topic is the practical use of sleep states
+on PC hardware, which - until this point - remained rather mysterious to us.
+Section [Low-level mechanism for suspend/resume on PC platforms] reports
+on our findings and the forthcoming integration of this feature into Genode.
+
+Besides the exploration work, the profound enhancement of our Intel GPU
+multiplexer stands out. As detailed in Section
+[Hardware-accelerated graphics with Intel GEN12+ GPUs], the new version
+supports up-to-date GEN12+ GPUs, comes with numerous robustness and
+performance improvements, and got adapted to Genode's new uniform driver
+infrastructure.
+
+The latter point brings us to the most elaborate development under the hood
+of the framework, which is the great unification of the device-driver
+interfaces across all supported architectures.
+Section [Uniform use of new platform-driver interface] wraps up this
+intensive line of work, which left no PC-related driver unturned.
+
+A recurring theme throughout this year is the use of Genode on the PinePhone.
+The current release is no exception.
+Sections [Emerging Sculpt OS variant for the PinePhone] and
+[PinePhone drivers for audio, camera, and power control] report on the
+progress at the user-facing side as well as the driver-related achievements
+digging deep into the realms of power management, audio, and the camera.
+
+Among the many further topics of the current release are virtualization on PC
+and ARM (Sections [ARM virtual machine monitor] and [Seoul VMM]), plenty
+of device-driver improvements, and enhanced tooling that makes the framework
+ever more enjoyable to use (Section [Build system and tools]).
+
+
+Hardware-software co-design with Genode on Xilinx Zynq
+######################################################
+
+A distinct feature of the Xilinx Zynq-7000 SoC is the combination of its
+Cortex-A9 CPU with an FPGA, which is also referred to as _programmable logic_.
+As the name suggests, the FPGA can be programmed with custom hardware designs
+and thus act as an accelerator, DSP, or an arbitrary peripheral device. The
+Zynq platform thereby accommodates a playground for hardware-software co-design
+for a comparably low budget.
+
+While extending the platform support for the Zynq in general, we have
+particularly been working towards establishing the required infrastructure
+for supporting hardware-software co-design in Genode. With this release, we
+can draw an almost complete picture of such a co-design workflow in Genode.
+Our achievements culminate in a beginner-level tutorial for the Zybo Z7 board.
+
+
+Runtime reconfiguration of the FPGA
+===================================
+
+A key component to FPGA runtime reconfiguration in Genode is the
+_drivers_fpga-zynq_ subsystem that we already
+[https://genode.org/documentation/release-notes/22.05#Xilinx_Zynq - introduced with release 22.05].
+
+This subsystem enabled bitstream loading at runtime in order to reprogram the
+FPGA. In conjunction with the _Zynq Driver Manager_, it allowed
+launching/stopping of device drivers in accordance with the availability of the
+devices implemented on the FPGA.
+
+For this release, we reworked this subsystem in order to support switching
+between several bitstreams. In particular, we added a _devices manager_ to
+merge the static 'devices' ROM with a bitstream-dependent set of devices. The
+latter is specified by the component's configuration as follows:
+
+!
+!
+!
+!
+!
+!
+!
+!
+!
+
+The configuration comprises an arbitrary number of _bitstream_ nodes with a
+mandatory _name_ attribute. Each _bitstream_ node may contain a set of device
+specifications as expected by the platform driver. The _devices manager_ merges
+the static 'devices' ROM with the devices of the currently loaded bitstream,
+which is reported by the _fpga_drv_ component. The result is then consumed
+by the platform driver. The bitstream to be loaded is specified by the
+configuration of the _fpga_drv_ as follows:
+
+!
+!
+!
+
+These changes are bundled into the new _drivers_fpga-zynq_ subsystem.
+The figure below illustrates how this subsystem is used as a replacement for
+the platform driver.
+
+[image zynq_driver_manager_22_11]
+
+Just as the standard platform driver, the subsystem expects a 'policy' and
+'devices' ROM. In addition, we must provide it with a _devices_manager.config_
+ROM as shown above. The bitstreams as well as the configuration for the internal
+_fpga_drv_ component must be provided via a file system session.
+
+In addition to these changes to the _drivers_fpga-zynq_ subsystem, we added
+configurability of the four FPGA clocks ("fpga0" to "fpga3") to the Zynq
+platform driver. Moreover, we added four equally named reset domains.
+
+All changes are found in the
+[https://github.com/genodelabs/genode-zynq - genode-zynq]
+repository.
+
+
+Packaging of bitstreams with Goa
+================================
+
+Custom hardware designs for the Zynq SoC are created with Xilinx Vivado.
+In order to simplify reproducing a bitstream from its sources and creating
+corresponding depot archives, we added Vivado as a supported build system to
+[https://github.com/nfeske/goa - Goa]. In particular, we leveraged the fact
+that a hardware project can be exported from Vivado as a tcl script that
+reproduces the project. With this approach, we only need to keep the custom
+source files and omit any generated glue code.
+
+In addition, we added support for auto-generating a _devices_manager.config_
+from a hardware design. When provided with a sparse _devices_ file (mentioning
+the name or type of each device), Goa tries to extract the corresponding MMIO
+addresses and clock rates from the design and adds a corresponding
+_devices_manager.config_ to the depot archive.
+
+Please find detailed instructions in the Goa documentation via
+
+! $ goa help build-systems
+
+
+Pin driver and co-design tutorial
+=================================
+
+Following the lead of the Allwinner SoC, we implemented a pin driver for the
+Zynq platform. Since GPIO on the Zynq may require loading of a custom bitstream
+in case the FPGA's I/O pins are used, we developed and published a tutorial
+for the Zybo Z7 board. This tutorial showcases a co-design workflow
+demonstrating the use of the pin driver, custom hardware design with Xilinx
+Vivado, bitstream generation and packaging with Goa as well as bitstream
+switching at runtime.
+You can find the tutorial on the new
+[https://www.hackster.io/genode/ - Genode channel on hackster.io].
+
+
+Hardware-accelerated graphics with Intel GEN12+ GPUs
+####################################################
+
+With our big [https://mesa3d.org - Mesa 3D] library update from version 11.2.2
+to version [https://genode.org/documentation/release-notes/21.08 - 21.0.0],
+we also switched the Intel graphics back end from the dated DRI2/i965 to the
+Gallium/Iris based graphics driver. The reason for doing so is becoming
+apparent with the current Genode release. The old i965 driver does not support
+newer Intel Graphics hardware and is limited to (U)HD graphics devices found,
+for example, on Broadwell, Skylake, or Kabylake platforms. The new
+[https://en.wikipedia.org/wiki/Intel_Xe - Intel Xe] (eXascale for
+everyone = GEN12) hardware is only supported by the Iris driver and can be
+found on current architectures like Tigerlake or Alderlake. Intel Xe comes
+with a completely new instruction set architecture (ISA). Thanks to our switch
+to Iris, most of these ISA changes are handled transparently by the Mesa
+library for us. The main task for Genode was to adjust our Intel GPU
+multiplexer to the new graphics-device generation.
+
+
+Intel GPU-GEN12 multiplexer adjustments
+=======================================
+
+Genode's GPU multiplexer is a very low level component within the 3D graphics
+stack. Technically, it handles the GPU resources (like graphics memory) and the
+scheduling and execution of compiled GPU code (i.e., batch buffers) of the
+graphics device. It is also responsible for providing separation of different
+GPU clients, which is achieved by GPU contexts with a separate page table per
+client in hardware. Also, it serves interrupts and informs the clients,
+respectively the 3D applications, about progress so a client can submit the
+next rendering request. For Intel Xe, there are only two changes within this
+low level ISA. First, the interrupt handling registers have been improved.
+It has become easier to distinguish, for example, between a display-engine
+interrupt and a rendering interrupt. Since graphics cards can have many
+interrupt causes, this is a useful and welcome change. Second, it is now
+possible to schedule 16 instead of 4 jobs onto the GPU. While we don't take
+advantage of this feature yet - we schedule one job at a time - this may come
+in handy for use cases like 3D compositing. Additionally, the multiplexer has
+to provide information about slices, subslices, and EUs (Execution Units) to
+Mesa clients.
+
+
+Stability and resource improvements
+===================================
+
+Resources need to be traded on Genode, and it is essential that the GPU
+multiplexer does not pay for memory allocations or capability upgrades from
+its own budget. The client has to donate these resources beforehand.
+If this rule is violated, the multiplexer might run out of budget and stall
+all clients. Because 3D applications can require a huge amount of resources,
+this has been a challenging topic during the last release cycle, and we are
+glad to announce that even sophisticated workloads are now running well on
+Genode. There is still room for improvement, but the current situation is
+already reassuring. Stability-wise, we have tested the updated 3D stack with
+various workloads (games, browsers, VirtualBox6-3D) and did fix all issues
+that we came across.
+
+
+Base framework and OS-level infrastructure
+##########################################
+
+Base API changes
+================
+
+New 'Dictionary' utility
+------------------------
+
+Throughout the Genode code base, there are several places where objects are
+accessed by using a name as key. To avoid the repeated manual crafting of such
+data structures, we introduced a basic 'Dictionary' data structure located at
+_base/include/util/dictionary.h_.
+
+It follows the patterns of the existing 'Id_space' and 'Registry'. That is,
+elements are automatically added to the dictionary at construction time,
+respectively removed at destruction time. There exists a 'with_element' method
+for applying a functor to one element by specifying a name as key, and a
+'with_any_element' method that can be used to destruct all dictionary items.
+
+
+Tightening the 'Xml_node' interface
+-----------------------------------
+
+The former 'with_sub_node' method has been renamed to 'with_optional_sub_node'
+to better reflect the intention of the caller. If no sub node of the specified
+type exists, the specified functor is not executed.
+
+Use cases where a sub node is mandatory are best covered by the new
+'with_sub_node' method that takes two functors as arguments, one called with
+the matching sub node, and one that is called if no such sub node exists.
+
+
+NIC router
+==========
+
+The NIC router now generates reports triggered by internal events
+(re-configuration, link state change, etc.) asynchronously. This has the
+benefit that the potentially expensive report update does not delay the event
+processing that triggered the update and that a report is guaranteed to reflect
+a consistent state of the router's internals.
+
+Furthermore, if the '' attribute 'link_state_triggers' is set, the
+router now updates the report also whenever a network session gets constructed
+or destructed. This is definitely necessary with sessions whose link state is
+"up" because we should consider a non-existent session to be "down". However,
+in real-world scenarios, a subscriber might want to know about the
+construction and destruction of sessions that are "down" as well because one
+has to be able to synchronize the lifetime of local objects that keep track of
+the link states.
+
+Besides the polishing of the report functionality, there are some improvements
+related to the DHCP processing in the router. First, the router is now robust
+against invalid DNS addresses in DHCP ACK packets. Next, the DHCP client
+doesn't produce oversized Ethernet packets anymore. This is important in
+networks with a low bandwidth. Then, the link state of a session that is bound
+to the state of another domain via the '' attribute
+'dns_config_from' is now correctly synchronized to whether that domain has an
+IP configuration or not. And, last but not least, the DHCP server now accepts
+the optimized startup sequence of clients like Debian that store their lease
+persistently and directly try re-requesting it on boot-up (no DHCP DISCOVER).
+These last two changes both prevent DHCP re-attempts that could cause a
+significantly delayed network boot-up at applications behind the router.
+
+
+Improved support for time-multiplexed GPIO pins
+===============================================
+
+Prompted by the need to enable a bit-banging I2C driver on the PinePhone,
+we extended Genode's pin-driver framework introduced in version
+[https://genode.org/documentation/release-notes/21.11#Pin_I_O_session_interfaces - 21.11]
+with support for the time-multiplexed operation of a pin as output or input.
+
+To operate a pin in both directions, a driver obtains both a pin-state and a
+pin-control session for the same pin. The pin-state session can be used to
+sense the current pin state. The control session allows the client to set the
+pin to high or low (using the 'state' method), or to set it to high-impedance
+via the 'yield' method. Once switched to high-impedance, the pin can be used
+as input.
+
+
+Libraries and applications
+##########################
+
+Emerging Sculpt OS variant for the PinePhone
+============================================
+
+Genode on the PinePhone has come a long way, most of which is covered by the
+[https://genode.org/documentation/genode-platforms-22-05.pdf - Genode Platforms]
+document. Device-driver work accounts for the majority of the effort, which is
+nicely wrapped up with the current release as described in
+Section [PinePhone drivers for audio, camera, and power control].
+With the fundamental device drivers for the PinePhone covered, we can now turn
+our attention to system-integration work, ultimately raising the question of
+how a Genode-based phone should best present itself to the user.
+
+[image sculpt_pinephone_22_11]
+ The forthcoming phone variant of the user interface of Sculpt OS.
+
+We take this question as an opportunity for exploration. Similarly to
+how the so-called Leitzentrale of [https://genode.org/download/sculpt - Sculpt OS]
+provides the user with an administrative view on the system that is separate
+from the user-defined desktop runtime, we pursued the division of the phone's
+UI into two faces that can be toggled with a simple touch gesture. The first
+one accommodates the role of the device as a fixed-function appliance similar
+to the functionality of a feature phone whereas the second one can be shaped
+entirely by the user. The screenshots above give a glimpse of the user
+interface of the appliance side. It covers low-level device parameters, voice
+calls, establishing network connectivity, and the installation and management
+of the software running on the user-defined side. One can see several cues
+from Sculpt OS such as the component graph.
+
+The clear-cut separation of the two roles of the device opens up new ways to
+leverage Genode's component architecture. For example, observing that the
+appliance role needs only a subset of components, we can orchestrate the
+startup of the system such that those components are started first. This way,
+the device's basic functions like voice calls become available in under 7
+seconds when powering-on the device.
+
+Regarding the built-in feature set, we implemented the fundamental device
+functions that everyone takes for granted, like displaying the battery state,
+triggering the charging when a charger gets connected, controlling the
+brightness of the display, or powering down the device.
+
+The phone variant of Sculpt OS evolves in the
+[https://github.com/nfeske/genode-allwinner - genode-allwinner] repository,
+specifically within the _sculpt/_ and _src/app/phone_manager/_ directories.
+It can be built via the following command:
+
+! build/arm_v8a$ make run/sculpt KERNEL=hw BOARD=pinephone SCULPT=phone
+
+For loading the system on the PinePhone, please follow the instructions given
+in the following article.
+
+:Booting Genode on the PinePhone:
+
+ [https://genodians.org/nfeske/2021-09-20-pine-fun-pinephone-boot]
+
+Note that the current version is still at a rather developer-focused stage.
+To avoid testimonies of a prematurely released version, we decided to postpone
+the release of a ready-to-use image until the feature set generally expected
+from a phone is complete and well tested.
+
+
+ARM virtual machine monitor
+===========================
+
+The hardware-assisted virtual machine monitor (VMM) for ARM developed for
+Genode is part of the framework since release
+[https://genode.org/documentation/release-notes/15.02#Virtualization_on_ARM - 15.02].
+Over the years, it got extended to support recent ARMv8 hardware, VirtIO
+device models for console, network, block, and so on. Nevertheless, the given
+device models, memory dimensions, and Linux specifics like initramfs size
+remained hard-coded within the VMM component, and not easily configurable.
+
+Now, the VMM accepts a configuration that enables one to define various
+aspects of the virtual machine and guest OS. The VMM is still focused on Linux
+OS guests though. Formerly, a pre-compiled flattened device-tree binary (DTB)
+was used by the VMM to boot the Linux guest. The new version of the VMM
+generates the DTB based on its own configuration.
+
+An example configuration looks like the following:
+
+!
+!
+!
+!
+!
+
+The RAM size and CPU count attributes are mandatory. All other attributes are
+optional and use default values. However, it is noteworthy that you should use
+the correct values for the CPU type and the Generic Interrupt Controller (GIC)
+version that matches your underlying hardware. Due to the usage of
+hardware-dependent virtualization extensions, the VMM and guest OS should see
+the correct hardware description for CPU and interrupt controller.
+
+
+Seoul VMM
+=========
+
+The Seoul/Vancouver VMM - introduced to Genode with release 11.11 - is an
+x86 based VMM which runs on Genode@NOVA, Genode@seL4, and Genode@Fiasco.OC on
+Intel and on AMD hardware. It is used with 32-bit Linux VMs typically.
+
+Over the last and this year, the VMM got VirtIO support with the goal to
+improve the usability when used day-to-day, e.g., on Sculpt OS. Given the
+observation that most Linux guests come readily (or easy to install) equipped
+with VirtIO driver support, we can avoid fiddling with building or integrating
+guest drivers manually. The Seoul VMM got extended by implementations for the
+VirtIO input device model, VirtIO GPU device model (2D by now) and VirtIO
+audio device model.
+
+With the new input model, absolute mouse positions are supported, so that the
+mouse pointer positions in Genode's Sculpt OS and in the guest VM can be kept
+in sync. Beforehand, it was hardly possible when solely using the PS/2 model
+using relative motion vectors.
+With the new 2D GPU model, the mouse pointer shape of the guest VM can be
+exported and shown by Genode's GUI multiplexer instead of the native mouse
+pointer, which improves the visual impression and avoids confusion.
+Additionally, with the new GPU model, resizeable and arbitrary resolution
+dimension are possible, which was not feasible with the former VGA/VESA model.
+The overall painting overhead is more manageable since partial updates are
+supported by the device model.
+The VirtIO audio model enables playback of music when streaming & surfing in
+the VM, which was beforehand not possible because no audio model was
+available. The new VirtIO models of the Seoul VMM were finally mapped to
+Genode's GUI, input and audio-out session interfaces.
+
+Combined, the new device models improve the overall usability when using Seoul
+on Sculpt OS. Several packages of alex-ab's depot are available to get
+started, ranging from a full on target Debian installation over pre-packed and
+ready to use VMs to up-to-date Firefox and Thunderbird VMs based on Tiny Core
+Linux. Whereas the Firefox VM is entirely disposable - as mentioned in
+[https://genodians.org/alex-ab/2019-03-06-disposal-browser-vm] -
+the Thunderbird VM relies on persistent storage.
+
+
+Device drivers
+##############
+
+Uniform use of new platform-driver interface
+============================================
+
+In release
+[https://genode.org/documentation/release-notes/22.02#Platform_driver - 22.02],
+Genode's generic platform API for all architectures got introduced and the
+x86-specific platform API got deprecated. However, at that point, all
+x86-based device drivers still used the deprecated API and the deprecated
+platform driver. With this release, all device drivers are now reworked to use
+the generic platform API, and driver. The deprecated platform driver and API
+have been removed.
+
+To make all previous scenarios work again, several changes were necessary. The
+changes - especially concerning the _pci_decode_ and _platform_drv_
+components - are described in the following.
+
+PCI decoder
+-----------
+
+The PCI decoder, introduced in release
+[https://genode.org/documentation/release-notes/22.05#Platform_driver - 22.05],
+consumes ACPI information delivered by the ACPI driver and additional platform
+information from the core component. It uses this information to find and scan
+PCI buses for devices and their capabilities. Finally, it creates a report
+about all PCI devices found.
+
+While using more and more device drivers with the generic platform driver and
+PCI decoder, we realized that on some platforms, not all PCI bridges are
+necessarily enabled, which leaves the devices behind such a bridge unusable.
+This is now fixed by enabling all PCI bridges.
+
+The information about reserved memory regions for PCI devices is already used
+in the boot process, e.g., memory for video graphic cards is discovered by the
+ACPI driver. However, the PCI decoder did not yet offer this information in
+its devices report. Therefore, the platform driver did not know about the
+reserved memory, and could not set up an IOMMU appropriately. From now on,
+the PCI decoder reports such memory regions as follows.
+
+!
+! ...
+!
+!
+
+The PCI memory _Base Address Registers_ (BARs) provide information about
+pre-fetchable memory. This information is now additionally exported by the PCI
+decoder and can be used by the platform driver (see the next section for
+details). The information is presented in the following form:
+
+!
+! ...
+!
+!
+
+Currently, the PCI decoder decides about the type of interrupt which can be
+used for a PCI device. The background is that several kernels, like OKL4,
+do not support the use of _Message-Signaled-Interrupts_ (MSI) or MSI-X. Older
+kernels, like Pistachio, do not even support the I/O _Advanced Programmable_
+_Interrupt Controller_ (IOAPIC), and are even more limited regarding available
+interrupt pins.
+On kernels that support all kinds of interrupts, devices with support for MSI
+or MSI-X were reported to prefer MSI-X. However, in rare cases we observed
+problems with the WiFi driver on MSI-X capable hardware. Therefore, we switch
+the priority of reporting MSI over MSI-X if both are available.
+In addition, we experienced problems with some Intel HDAUDIO cards and MSIs.
+Therefore, we do not report the MSI capability on those devices for the
+time being.
+
+
+Platform driver
+---------------
+
+The generic platform driver got re-worked to support the newly provided
+information from the PCI decoder. The given reserved memory regions of a
+device are used to add corresponding entries in the IOMMU.
+
+The new "prefetchable" attribute for corresponding I/O memory regions -
+typically only "stolen memory" of the video graphics card - is used to decide
+when I/O memory can be mapped as write-combined into the address space of the
+client. Now that the platform driver decides for which I/O memory these
+special paging attributes are sensible to use, the actual driver no longer
+needs to distinguish special paging attributes for I/O memory.
+Therefore, we removed those details from the 'io_mem' call.
+
+PCI devices on x86 without MSI or MSI-X support may still share the same
+interrupt line. To make the generic platform driver functional on these
+platforms, we had to add shared interrupt support. When the platform driver
+receives its devices report, it iterates over all devices and their interrupt
+resources, and detects any shared interrupts. For those interrupts, the
+platform driver provides a custom IRQ service, thereby realizing the sharing.
+For all other interrupts, it hands out the IRQ capability as obtained from
+core directly.
+
+The generic platform driver can now set up MSI-X within the PCI configuration
+space of a device, if the devices ROM instructs it to do so.
+
+The ability to power and reset PCI devices was also missing in the generic
+platform driver so far. We caught up on implementing this feature.
+
+Several PCI enablement quirks are needed for correctly running devices and
+drivers. Especially the hand-off of devices in between BIOS/UEFI and OS are an
+example for this. We encountered problems when doing this too late. Therefore,
+we moved the PCI quirks from the moment of first usage to the startup of the
+platform driver. Moreover, PCI quirks for EHCI and HDAUDIO were added.
+
+VirtIO PCI devices hide several important information about their queues inside
+the PCI configuration space. Now that we do not provide direct access to the
+PCI configuration space to device drivers, the platform driver needs to
+identify VirtIO devices, and provide the necessary information via the devices
+ROM to the driver. It does so in the following way:
+
+!
+!
+! ...
+!
+!
+!
+
+Sometimes a device driver is needed to set up a device but doesn't necessarily
+need to stay present while the device is active. The PCIe host controller for
+the i.MX 8MQ SoC described in
+Section [New PCI and network drivers for NXP i.MX] is such an example.
+To be able to destruct a platform resp. single device session at the platform
+driver without automatically powering it off or resetting it, we introduced
+the "leave_operational" attribute. As the name suggests, it leaves a device
+untouched when its session gets closed. The attribute is part of the policy
+node for the client within the platform driver's configuration.
+
+Platform driver for PC hardware
+-------------------------------
+
+The vanished and deprecated x86-specific platform driver was able to reset a
+machine via I/O port access. It did so upon observing the 'state' attribute of
+the system ROM having the value "reset".
+This feature is mainly used within Sculpt OS. To not lose this ability,
+a platform driver specific to PCs is now part of the _repos/pc_ repository.
+It shares all code and semantics with the generic platform driver, but adds
+this single functionality.
+
+Platform API clients
+--------------------
+
+All remaining x86-centered device drivers got reworked to use the generic
+platform API and its helper utilities in _platform_session/device.h_ and
+_platform_session/dma_buffer.h_.
+
+The lx_kit and lx_emul layers within the _repos/dde_linux_ repository now use
+one and the same generic layer too. While reworking these libraries, we
+addressed a performance penalty in the interrupt handling. The multiple
+opening and closing of interrupt sessions is now eliminated.
+Moreover, we removed the legacy_pc_usb_host_drv from _repos/dde_linux_.
+
+All run-scripts and packages were revised to use the new drivers.
+
+
+PinePhone drivers for audio, camera, and power control
+======================================================
+
+Over the past 18 months, we have steadily expanded the base of device drivers
+for the PinePhone, initially addressing the
+[https://genodians.org/nfeske/2021-12-21-pine-fun-display - display] and
+[https://genodians.org/nfeske/2022-03-16-pine-fun-touchscreen - touchscreen],
+later covering the
+[https://genode.org/documentation/release-notes/22.02#PinePhone_modem_access - modem],
+[https://genode.org/documentation/release-notes/22.05#Custom_system-control_processor__SCP__firmware - system control],
+[https://genode.org/documentation/release-notes/22.08#GPU_and_Mesa_driver_for_Mali-400 - GPU], and
+[https://genode.org/documentation/release-notes/22.08#SD-card_driver_for_the_PinePhone - SD-card].
+With the current release, we wrap up this line of work with drivers for
+audio, camera, and power control.
+
+As a prerequisite step for enabling the camera, we changed the version of the
+Linux kernel that we use as donor of the driver code. Up to now, we relied on
+the vanilla Linux kernel for the Allwinner SoC. However, the camera support
+still resides on [https://xnux.eu - Ondrej Jirman's] custom kernel
+(orange-pi-5.14), which is apparently the kernel of choice for most Linux
+distributions for the PinePhone. We follow suit.
+
+
+Audio
+-----
+
+The added audio support consists of two separate components, namely an
+audio-control driver and audio in/out driver. The former controls the audio
+routing and mixing on the hardware level. It is responsible to route the mic
+to the modem during voice call, control the gain, or enable/disable the
+speaker. The privacy-sensitive audio-control driver is meant to be part of the
+base system of Sculpt. It operates according to its configuration, which can
+be updated dynamically.
+
+Volumes can be configured by nodes within the '' node using a volume
+attribute (range 0-100) where 0 implies turning off the input or output
+device. Supported nodes are '', '', and ''.
+Furthermore, a '' node can be used to switch the audio path between the
+modem and the ARM application processor (SoC). Its 'target' attribute can be
+set to either "soc" (default) or "modem". The "soc" mode implicitly sets the
+codec's sample rate to 44.1 KHz whereas "modem" mode sets the sample rate to
+48 KHz. This distinction is required because the modem is compatible with 8
+KHz only. The modem's 8 KHz can be cleanly converted to 48 KHz.
+
+In contrast to the audio-control driver, the audio in/out driver is concerned
+with streaming PCM audio data to/from the ARM application processor. It allows
+audio applications hosted in the user-defined runtime of Sculpt OS to record
+and play audio via Genode's audio-in and audio-out session interfaces.
+The combination of both drivers can be exercised via the
+[https://github.com/genodelabs/genode-allwinner/blob/master/run/audio_pinephone.run - audio_pinephone.run]
+script.
+
+
+Power control
+-------------
+
+The new power-control driver is based on our custom firmware for the A64's
+system-control processor (SCP) in combination with Genode's dedicated
+scp-session interface that allows Genode components to interact with the SCP.
+
+To properly arbitrate the access to the power-management IC (PMIC) between the
+SCP firmware and the ARM application processor, the PMIC driver has been moved
+entirely to the SCP side. This way, both the SCP firmware and Genode-based SCP
+clients become able to safely access the PMIC without stepping on each other's
+toes. In particular, the platform driver acts as an SCP client to toggle power
+controls. Since the platform driver now depends on the SCP, we co-located the
+formerly separate SCP driver component with the platform driver.
+
+Built upon this infrastructure, a new power driver exercises control over
+several low-level aspects of the PinePhone hardware such as:
+
+* Platform reboot (via the PMIC),
+* Powering down the system (via the PMIC),
+* Switching between the power profiles "performance" and "economic",
+ which clock the ARM CPU at 1296 MHz and 816 MHz respectively,
+* Reporting the remaining battery capacity, power draw, or charge current,
+* Triggering the charging when connecting a charger, and
+* Adjusting the backlight brightness.
+
+Besides being integrated in Sculpt OS, the driver can be exercised in
+isolation using the
+[https://github.com/genodelabs/genode-allwinner/blob/master/run/power_pinephone.run - power_pinephone.run]
+script.
+
+
+Camera
+------
+
+The added camera driver component consists of a port of the Linux SUN6I-CSI as
+well as OV5640 and GC2145 drivers. It renders the captured camera image data
+into a GUI session according to the following configuration attributes.
+
+The 'camera' attribute selects the camera. Supported values as "front" and
+"rear". The 'width' and 'height' attributes select the horizontal and vertical
+resolution. Valid configurations are 640x480 as well as 1280x720. The 'fps'
+attribute selects the capture rate of the camera. Valid values are "15" and
+"30". The 'format' attribute selects the capture format. The only valid value
+is "yuv", which selects YUV420. The 'convert' attribute specifies if the
+captured image data is converted to the pixel format suitable for the GUI
+display. Default is "true". The 'rotate' attribute specifies if the capture
+image data is rotated counter-clockwise and flipped. Default is 'true'.
+
+The integration of the driver is exemplified by the
+[https://github.com/genodelabs/genode-allwinner/blob/master/run/camera_pinephone.run - camera_pinephone.run] script.
+The test scenario displays the camera image on the framebuffer. It repeatedly
+switches between front and rear camera.
+
+
+New PCI and network drivers for NXP i.MX
+========================================
+
+PCIe host controller for i.MX 8MQ
+---------------------------------
+
+The i.MX 8MQ SoC includes two PCI-express host controllers. The MNT Reform 2
+laptop for example exposes both via one M.2 and one miniPCIe socket, e.g., to
+drive an NVMe card and a WiFi card. In contrast to x86-based PCs, those PCIe
+controllers are not set up by boot-firmware like BIOS or UEFI, but need to be
+driven by the OS first. Therefore, this release contains a new PCIe driver for
+the mentioned SoC. This driver does not provide a special API. It uses the
+platform driver to obtain the device resources of the PCIe controller, and
+enables and configures it appropriately. It then parses the PCI configuration
+space of the device behind the controller, which in fact acts as PCI host
+bridge. The collected device and PCI information is then exposed via the
+report service analogously to the PCI decode component available for x86.
+Finally, the platform driver resp. another incarnation of the platform driver
+can consume this report as devices ROM, and provide the device resources to a
+driver of the PCI device.
+
+In practice, we have tested the PCIe host controller driver in combination
+with an NVMe card used in the MNT Reform 2 laptop only. Moreover, it got
+integrated in Sculpt OS for the MNT Reform 2. Therefore, we had to add an
+i.MX 8MQ specific driver manager. This management component is able to check
+for the availability of an NVMe device, controls the driver's lifetime, and
+assembles a block-device report that covers both SD-card and NVMe devices.
+
+
+FEC Network driver
+------------------
+
+There is long-standing support for the _Freescale Ethernet Controller_ (FEC)
+within Genode available, supporting a broad range of SoCs from i.MX 53 up to
+i.MX 8.
+But the existing driver port taken from Linux 4.16.3 was running shakily on
+the i.MX 8MQ SoC and the i.MX 6 Sabrelite board. Instead of trying to
+investigate potentially violated semantics in the legacy DDE Linux emulation
+code, we ported the Linux device driver for FEC from scratch. Thereby, we've
+used the recent DDE Linux porting approach, first described in the
+[https://genode.org/documentation/release-notes/21.08#Linux-device-driver_environment_re-imagined - 21.08]
+release.
+The new driver is based on the vanilla Linux kernel 5.11 plus the MNT Reform 2
+patches provided by Lukas Hartmann, which we already use for other drivers
+available in the genode-imx repository.
+
+To enable the driver to work correctly, it needs information about its clock
+frequencies. Therefore, we have extended the platform driver for i.MX 53, and
+introduced new rudimentary platform drivers specific to i.MX 6 and 7, which
+expose the needed clock frequencies.
+
+
+USB-C on i.MX 8MQ EVK
+---------------------
+
+The USB host controller driver for the i.MX 8MQ EVK board did not enable the
+second USB host controller yet, which is connected to the USB-C socket of the
+board. Now this host controller gets driven too.
+
+
+Intel graphics
+==============
+
+The Intel display driver was enabled to run on Intel Alderlake graphics PCs,
+tested on the 12th Gen
+[https://frame.work/de/en/products/laptop-12-gen-intel - Framework Laptop].
+Furthermore, the driver now supports 4K displays, tested specifically on Dell
+Ultrasharp and LG 27MU67 hardware. Additionally, the driver may now be
+configured to set up an upper resolution bound to avoid out-of-service
+exceptions due to unexpectedly high memory needs. This feature is used by
+default on Sculpt to limit resolutions to WQHD aka 1440p aka 2560x1440 pixels
+and can be changed in _repos/gems/sculpt/fb_drv/default_.
+
+
+Audio driver updated to OpenBSD 7.1
+===================================
+
+We updated the audio-driver component to OpenBSD version 7.1 that brings in
+support for playback on more recent 12th Gen Intel machines. Besides the
+update, we remedied a long-standing shortcoming when handling multiple
+HD-Audio devices and removed the support for old audio devices.
+
+The component contained a simple check to exclude known non-working devices
+but depending on the machine's configuration, this check was incomplete. Rather
+than extending the check, we took a step back and changed the probing
+behavior of the component:
+
+![init -> audio_drv] azalia0 [8086:160c]
+![init -> audio_drv] :
+![init -> audio_drv] azalia0: no supported codecs
+![init -> audio_drv] azalia1 [8086:9ca0]
+![init -> audio_drv] :
+![init -> audio_drv] azalia1: codecs: Realtek ALC292
+![init -> audio_drv] audio0 at azalia1
+
+It now checks all available devices and picks the first one it can use. This
+comes in handy in configurations where the virtual PCI-bus is populated with
+all audio devices found in a machine and some of them contain unsupported
+codecs as, among others, found on GPUs.
+
+Furthermore, we decided to remove the _eap_ and _auich_ drivers as these
+drivers rely on I/O port access, which still had to be enabled in the
+component after the switch to the new platform driver and due to being of
+minor importance in daily use. The first one was mainly used to initially
+develop the component and later on for testing in QEMU. The second one on the
+other hand was merely enabled to provide a shot at getting audio in VirtualBox
+VMs where the component did not work with the HDA device model at the time.
+
+
+Improved ACPICA driver
+======================
+
+The ACPICA driver got improved support for Thinkpad notebooks to report ACPI
+events and in particular battery state changes. The frequency of checking of
+state changes, which are not triggered by an ACPI event, can now be configured
+explicitly, which is documented in the README file of the component.
+
+Additionally, the ACPICA component got extended to support ACPI suspend &
+resume functionality. On the one hand the component can be configured to
+determine and report the supported ACPI sleep states (S1-S5) of a PC machine.
+On the other hand, the component can now react on 'system' ROM changes and
+participate on sleep state preparation and the subsequent wakeup procedure
+using the ACPICA library, e.g., AcpiEnterSleepStatePrep,
+AcpiLeaveSleepStatePrep and AcpiLeaveSleepState.
+
+
+Wireless-networking improvements
+================================
+
+In the process of enabling the Intel AX211 WiFi card, DDE-Linux and the WiFi
+driver were enhanced to support loading PNVM firmware files. Ultimately, a
+[https://github.com/QubesOS/qubes-linux-kernel/commit/5fcfe0f19ed5ff2bd3514644afce0af642c326c6 - workaround]
+from QubesOS was needed to make the card work, highlighting shared challenges
+that both our projects face when using Linux drivers in unconventional ways to
+improve system security.
+
+
+Platforms
+#########
+
+Low-level mechanism for suspend/resume on PC platforms
+======================================================
+
+On modern PC platforms, suspend and resume is realized by using a mechanism
+provided by ACPI. The Advanced Configuration and Power Interface defines
+(besides many other things) several global states (Gx) and six sleep states (Sx)
+an operating system (OS) can choose. Oversimplified, the S0 state is the
+normal working state, S1-S2 are light sleeping states, S3 is known as
+"suspend to RAM" state, S4 is called "suspend to disk" and S5 is mostly "off".
+See [https://en.wikipedia.org/wiki/ACPI#OSPM_responsibilities] for a basic
+overview and further pointers for reading.
+
+The supported sleep states vary between PCs, some of which do not even support
+all states. An operating system has to look up and determine the supported Sx
+states, which are part of ACPI tables and ACPI AML code. Beginning with this
+Genode release, we can use the ACPICA driver to lookup the supported Sx
+states. The sleep states themselves are represented as two values (TYP_SLPa
+and TYP_SLPb in ACPI specification) and are reported by the ACPICA driver.
+
+In order to trigger/program the intended sleep state, an OS like Genode + used
+kernel has to look up and set up several ACPI tables, e.g., FACS & FADT. Via
+the tables, the OS deposits a wakeup vector, which is called by the UEFI
+firmware on wakeup. Before actually going to sleep, the OS has to take care to
+flush all kinds of hardware cached state either to memory or persistence
+storage, depending on the Sx state.
+
+With this release, we added principal support for S3 "suspend to RAM" in
+Genode using the NOVA kernel. The kernel now supports a privileged suspend
+syscall, which is solely available to Genode's core roottask. The invocation
+is triggered and guarded by Genode's 'Pd::managing_system' RPC function, which
+takes both TYP_SLPa and TYP_SLPb values as parameters representing the
+intended Sx state. On invocation, Genode's core will check that the component
+holds Genode's managing-system capability. On success, the suspend syscall of
+the NOVA kernel is invoked and will lead to holding all CPUs, depositing the
+wakeup vector in the ACPI tables, flushing cached state of Genode's components
+to memory, like CPU registers, FPU state, IO-APIC state and virtualization
+state of Intel' VMX or AMD's SVM. Finally, both TYP_SLP values will be used to
+trigger the sleep state.
+
+On ACPI wakeup, the UEFI/BIOS firmware wakes up the NOVA kernel via the
+deposited wakeup vector. The kernel re-initializes the CPU and wakes up all
+other CPUs. Finally, control will be transferred to Genode's roottask (core),
+which can thereby return from the 'Pd::managing_system' RPC call.
+
+Before and after the actual suspend and resume, the ACPICA driver should
+be used to run ACPI AML methods to prepare and post-process the system state
+change, which may affect the success of the Sx state transfer depending on the
+used PC platform. Additionally, after resume, all hardware and their drivers
+must be considered to be re-initialized. The re-initialization and re-starting
+of drivers and hardware, e.g., PCI, is not finished currently.
+
+An early prototype for exercising this scenario is available in the form of
+the _acpi_suspend.run_ script in the _libports_ repository. This test scenario
+periodically suspends and resumes the hardware and also restarts the used
+display driver. The low level ACPI suspend and resume can be observed to work
+quite reliable, which we could validate across several generations of Intel
+notebooks and some AMD desktop machines. However, the re-starting of the
+display driver is not always reliable. Restarting the Intel display driver
+worked notably well on older Thinkpad notebooks, e.g., X201 and T420.
+
+Note that the suspend/resume feature is still work in progress. The next
+potential work items are the addition of suspend/resume support to the base-hw
+kernel, ways to power-off and power-on (PCI) hardware, e.g.,via the new
+platform driver, and re-initializing and/or re-starting drivers. Additionally,
+a convenient way to debug resume issues is desired when no serial output is
+working anymore after resume.
+
+
+Base-HW microkernel
+===================
+
+The base-hw kernel, which was specifically developed for Genode, did not
+provide the use of _Message-Signaled-Interrupts_ (MSI), and MSI-X yet. With
+this release, x86 architectural support for MSI and MSI-X entered the base-hw
+kernel. The usage of MSI or legacy interrupts is transparent to the user. It
+gets determined in the interplay of the PCI decode component, platform driver,
+and core.
+
+
+NOVA microhypervisor
+====================
+
+Besides the added ACPI suspend/resume support described in
+Section [Low-level mechanism for suspend/resume on PC platforms], the kernel
+received principal support to run on more than 32 CPUs. By default, Genode's
+and the kernel's CPU limit is set to 64, configurable by the constants
+MAX_SUPPORTED_CPUS in Genode's core respectively NUM_CPU in the kernel.
+In our tests, up to 250 CPUs were usable in Qemu.
+
+
+Build system and tools
+######################
+
+Streamlined building of libraries
+=================================
+
+The release adds special handling for 'lib/' arguments to the build
+system, which supersedes the former 'LIB=' mechanism. Whereas the old
+mechanism was limited to a single library, the new convention allows multiple
+library arguments, similar to regular targets.
+
+The change brings two immediate benefits. First, the streamlining of library
+and target arguments allows for the building of libraries via the 'build'
+command of the run tool. Second, it alleviates the need for pseudo _target.mk_
+files for building shared libraries that have no direct dependencies, in
+particular VFS plugins.
+
+Note that _target.mk_ files located under _src/lib/_ are no longer reachable.
+Therefore, all run scripts that used to trigger the build of a shared library
+via a pseudo target must be adapted. E.g., 'build lib/vfs/tap' must be
+replaced by 'build lib/vfs_tap'.
+
+The former 'LIB=' option is no longer supported.
+
+
+Boot-loading over HTTP
+======================
+
+The standard network-boot approach for x86 at Genode Labs has been a
+combination of the PC-integrated Preboot Execution Environment (PXE), the
+Pulsar boot loader, and the TFTP protocol for years. Because Pulsar is tied
+to legacy BIOS interfaces, UEFI-only hardware demands for alternatives. iPXE
+is a field-tested, UEFI-compatible alternative that is already supported in
+Genode's run tool via _load/ipxe_.
+
+One of the prominent features of iPXE is the support for additional network
+(boot) protocols beyond TFTP with HTTP as a tempting option to improve boot
+performance. This release enhances the _load/ipxe_ run module to optionally
+configure and spawn the lightweight HTTP server _lighttpd_ to serve the boot
+image to iPXE using the following declarations in _etc/build.conf_.
+
+! RUN_OPT += --include load/ipxe
+! RUN_OPT += --load-ipxe-base-dir /tftpboot
+! RUN_OPT += --load-ipxe-boot-dir /ipxe
+! RUN_OPT += --load-ipxe-lighttpd
+! RUN_OPT += --load-ipxe-lighttpd-port 2209
+
+The HTTP server is run only while the run tool is executed, killed on exit,
+and limited to serve the contents of the test-specific directory under
+_var/run/_ in your build directory. Your iPXE boot loader should be configured
+to chain the automatically generated _boot.cfg_ file as follows.
+
+! #!ipxe
+! chain http://:2209/boot.cfg
+
+For more details, please refer to the dedicated Genodians.org article.
+
+:Getting Fujitsu U7411 up and running - Network Boot:
+
+ [https://genodians.org/chelmuth/2022-11-24-u7411-up-and-running]
+
+
+Configurable Intel HWP mode
+===========================
+
+We updated our version of the Bender chain-boot loader to be configurable
+regarding the mode in which to run Intel's Hardware P-States (HWP). When
+running Genode on NOVA, the HWP mode can now be controlled via the new run
+option '--bender-intel-hwp-mode'. The option responds to the values 'off',
+'performance', 'balanced', and 'power_saving'. The default value is
+'performance' in order to stay backwards compatible. On kernels other than
+NOVA, HWP remains turned off in general.
diff --git a/doc/release_notes/23-02.txt b/doc/release_notes/23-02.txt
new file mode 100644
index 0000000000..8d655639cb
--- /dev/null
+++ b/doc/release_notes/23-02.txt
@@ -0,0 +1,887 @@
+
+
+ ===============================================
+ Release notes for the Genode OS Framework 23.02
+ ===============================================
+
+ Genode Labs
+
+
+
+With Genode's February release, almost everything goes
+[https://genode.org/about/road-map - according to plan].
+As envisioned on our road map, it features the first ready-to-install
+system image of Sculpt OS for the PinePhone, which is not merely a re-targeted
+version of the PC version but comes with a novel user interface, a new
+mechanism for rapidly switching between different application scenarios, and
+system-update functionality.
+Section [First system image of mobile Sculpt OS (PinePhone)] gives an
+overview and further links about running Genode on your PinePhone.
+
+While enabling substantial application workloads on devices as constrained as
+the PinePhone, we engaged in holistic performance optimizations, ranging from
+kernel scheduling (Section [Base-HW microkernel]), over the framework's VFS
+infrastructure (Section [VFS optimization and simplification]), to the
+interfacing of GPU drivers (Section [GPU performance optimizations]).
+
+For stationary ARM-based platforms like the MNT-Reform laptop,
+interactive graphical virtual machines have become available now, which
+brings us close to mirror the experience of the PC version of Sculpt OS on
+such devices (Section [Interactive graphical VMs on ARM]). This development
+is accompanied by several device-driver improvements for NXP's i.MX family.
+
+For embedded devices based on Xilinx Zynq, the release introduces custom
+FPGA fabric for implementing DMA protection that is normally not covered by
+Zynq SoCs. This line of work - as outlined in
+Section [Custom IP block for DMA protection on AMD/Xilinx Zynq] - exemplifies
+how well Genode and reconfigurable hardware can go hand in hand.
+
+Also, PC platforms got their share of attention, benefiting from the
+new distinction between Intel's P&E cores, or the principle support of
+suspend/resume on both NOVA and Genode's custom base-hw microkernel.
+
+When it comes to running applications on top of Genode, the release brings
+good news as well. Our custom Goa tool for streamlining
+application-development work flows received the ability to largely automate
+the porting and packaging of 3rd-party libraries using CMake
+(Section [Build system and tools]).
+
+
+First system image of mobile Sculpt OS (PinePhone)
+##################################################
+
+Just in time for our
+[https://fosdem.org/2023/schedule/event/genode_on_the_pinephone/ - public presentation]
+of Genode on the PinePhone at FOSDEM in the beginning of February,
+we published a first ready-to-use system image:
+
+:First system image of mobile Sculpt OS:
+
+ [https://genodians.org/nfeske/2023-02-01-mobile-sculpt]
+
+It features a
+[https://genodians.org/nfeske/2023-01-05-mobile-user-interface - custom user interface],
+voice calls and mobile-data connectivity, on-target software installation and
+system update, device controls (battery, brightness, volume, mic, reset,
+shutdown), and a variety of installable software. Among the installable
+applications, there is the Chromium-based Morph web browser, an OpenGL demo
+using the GPU, tests for the camera and microphone, as well as a light-weight
+Unix-like system shell.
+
+The underpinnings of the Genode system image for the PinePhone are nearly
+identical to Sculpt OS on the PC. However, besides the new user interface
+specifically designed for the touch screen of the phone, two noteworthy
+differences set it apart from the regular version of Sculpt OS.
+
+[image pinephone_presets]
+
+First, the phone variant allows the user to rapidly switch between different
+runtime configurations, called presets. This way, the limited resources of the
+phone can be accounted and fully leveraged for each preset individually, while
+making the system extremely versatile. The loading of a preset can be imagined
+as the boot into a separate operating system, but it takes only a fraction of
+a second. The structure of the running system is made fully transparent to the
+user by the component graph known from Sculpt OS.
+
+[image pinephone_scenarios]
+ The variety of presets includes the Morph browser, GLMark2, a system shell,
+ a simple oscilloscope, and camera test.
+
+Second, the system is equipped with an on-target system update mechanism that
+allows the user to install new versions of the system image when they become
+available. System updates are secured by cryptographic signatures. The
+mechanism does not only allow for updating the system but also for the
+rollback to any previously downloaded version. This way, the user can try
+out a new version while being able to fall back to the previous one in the
+case of a regression. This reinforces the end user's ultimate control.
+
+[image pinephone_update]
+
+
+Interactive graphical VMs on ARM
+################################
+
+The virtual-machine monitor (VMM) using hardware-assisted virtualization on
+ARM started as a case study eight years ago for Samsung's Exynos 5250 SoC.
+Originally, it supported virtualization of CPU, timer, interrupt-controller,
+and a UART-device only. Since then, it received several extensions like
+support for 64-bit ARMv8 systems, VirtIO devices for network, console, and
+block access. With release 22.11, the VMM's I/O device access, RAM
+consumption, and CPU count have come configurable.
+
+With the current release, we further enhance the VMM for ARM devices to
+provide all the means necessary to become a useful virtualization solution for
+interactive scenarios.
+
+[image mnt_interactive_debian_vm]
+ Sculpt OS running Debian in a virtual machine on the MNT Reform laptop
+
+Two additional VirtIO device models are available now: A GPU model and one for
+input. Both models are mapped to Genode's GUI service under the hood. One can
+extend the configuration of the VMM accordingly:
+
+!
+!
+!
+! ...
+!
+
+For now, only one GPU and one input device can be declared. Both devices get
+mapped to the very same GUI service, according to the service routing of the
+VMM.
+
+Caution: the GPU and input model are still in an experimental state, and there
+are known corner cases, e.g., when the graphical window size of the VMM gets
+changed dynamically.
+
+Formerly, the VMM always expected an initial RAM file system to be provided as
+ROM dataspace, which got loaded together with the Linux kernel into the VM's
+memory. Now, it is possible to omit the "initrd_rom" configuration option.
+If omitted, no initrd is provided to the Linux guest.
+
+
+Custom IP block for DMA protection on AMD/Xilinx Zynq
+#####################################################
+
+As a continuation of the hardware-software co-design efforts presented in the
+[https://genode.org/documentation/release-notes/22.11#Hardware-software_co-design_with_Genode_on_Xilinx_Zynq - previous release],
+we turned towards enabling bulk-data transfer between the Zynq's CPU and its
+FPGA. In a first step, we built a custom hardware design that implements a DMA
+loopback device based on Xilinx' AXI DMA IP. Since we were particularly
+interested in testing out the Zynq's accelerator coherency port (ACP), we
+implemented two loopback devices: one attached to the ACP and one to the
+high-performance (HP) AXI port of the Zynq. In order to test the design in
+Genode, we added a port of Xilinx' embeddedsw repository that hosts standalone
+driver code for the Xilinx IP cores. Based on this port, we implemented the
+xilinx_axidma library as a Genode wrapper in order to simplify development of
+custom drivers using Xilinx' AXI DMA IP. A newly written test component takes
+throughput measurements for varying transfer sizes. A more detailed account of
+this story is published in an
+[https://www.hackster.io/johannes-schlatow/using-axi-dma-on-genode-6482d2 - article on hackster.io].
+
+Knowing that DMA bypasses any memory protection on the Zynq as it does not
+feature an IOMMU, we further spent some development efforts on implementing a
+custom IP block, called DMA Guard, for protecting against unintended DMA
+transfers from/to the FPGA. The DMA Guard is configured with a limited set of
+address ranges for which DMA transfers will be granted. Any out-of-range
+transfer will be denied. The configuration of the DMA Guard is conducted by
+the Zynq's platform driver based on the allocated DMA buffers. For the time
+being, we applied several changes to the platform driver. These modifications
+are currently hosted in the genode-zynq repository but are going to find their
+way into the generic platform driver for the next release.
+
+More details about the DMA Guard are covered by the dedicated article:
+[https://www.hackster.io/johannes-schlatow/taking-control-over-dma-transactions-on-zynq-with-genode-fd60b6 - Taking control over DMA transactions on Zynq with Genode].
+To follow this line of work, keep watching our
+[https://www.hackster.io/genode - hackster.io channel].
+
+
+Base framework and OS-level infrastructure
+##########################################
+
+VFS optimization and simplification
+===================================
+
+For regular applications executed on Genode, input and output involves the
+virtual file system (VFS). In contrast to traditional monolithic operating
+systems (which host the VFS in the kernel) or traditional microkernel-based
+operating systems (which host the VFS in a dedicated server component),
+Genode's VFS has the form of a library, giving each component an individual
+virtual file system. The feature set of the VFS library is not fixed
+but extensible by so-called VFS plugins that come in the form of optional
+shared libraries. These plugins can implement new file-system types, but also
+expose other I/O facilities as pseudo files. For example, TCP/IP stacks like
+lwIP and lxIP (IP stack ported from Linux) have the form of VFS plugins.
+The extensibility of the VFS gives us extreme flexibility without compromising
+Genode's simplicity.
+
+On the other hand, the pervasiveness of the VFS - being embedded in Genode's C
+runtime - puts it on the performance-critical path whenever application I/O is
+involved. The ever-growing sophistication of application workloads like
+running a Chromium-based web browser on the PinePhone puts merciless pressure
+on the VFS, which motivated the following I/O-throughput optimizations.
+
+Even though the VFS and various VFS plugins work asynchronously, the batching
+of I/O operations is not consistently effective across different kernels. It
+particularly depends on the kernel's scheduling decision upon the delivery of
+asynchronous notifications. Kernels that eagerly switch to the signal receiver
+may thereby prevent the batching of consecutive write operations. We could
+observe variances of more than an order of magnitude of TCP throughput,
+depending on the used kernel. In the worst case, when executing a kernel that
+eagerly schedules the recipient of each asynchronous notification, the
+application performance is largely dominated by context-switching costs.
+
+Based on these observations, we concluded that the influence of the kernel's
+scheduler should better be mitigated by scheduling asynchronous notifications
+less eagerly at the application level. By waking up a remote peer not before
+the application stalls for I/O, all scheduled operations would appear at the
+remote side as one batch.
+
+The implementation of this idea required a slight redesign of the VFS,
+replacing the former implicit wakeup of remote peers by explicit wakeup
+signalling. The wakeup signalling is triggered not before the VFS user settles
+down. E.g., for libc-based applications, this is the case when the libc goes
+idle, waiting for external I/O. In the case of a busy writer to a non-blocking
+file descriptor or socket (e.g., lighttpd), the remote peers are woken up once
+a write operation yields an out-count of 0. The deferring of wakeup signals is
+accommodated by the new 'Remote_io' mechanism (_vfs/remote_io.h_) that is
+designated to be used by all VFS plugins that interact with asynchronous
+Genode services for I/O.
+
+Combined with additional adjustments of I/O buffer sizes - like the request
+queue of the file-system session, the TCP send buffer of the lwIP stack, or
+the packet buffer of the NIC session - the VFS optimization almost eliminated
+the variance of the I/O throughput among the different kernels and generally
+improved the performance. On kernels that suffered most from the eager context
+switching, netperf
+[https://github.com/genodelabs/genode/issues/4697#issuecomment-1342542399 - shows a 10x]
+improvement. But even on kernels with more balanced scheduling, the effect is
+impressive.
+
+While we were at it, and since this structural change affected all VFS plugins
+and users anyway, we took the opportunity to simplify and modernize other
+aspects of the VFS-related code as well.
+
+In particular, the new interface 'Vfs::Env::User' replaces the former
+'Vfs::Io_response_handler'. In contrast to the 'Io_response_handler', which
+had to be called on a 'Vfs_handle', the new interface does not require any
+specific handle. It is merely meant to prompt the VFS user (like the libc) to
+re-attempt stalled I/O operations but it does not provide any immediate hint
+about which of the handles have become ready for reading/writing. This
+decoupling led to welcome simplifications of asynchronously working VFS
+plugins.
+
+Furthermore, we removed the 'file_size' type from read/write interfaces. The
+former C-style pair of (pointer, size) arguments to those operations have been
+replaced by 'Byte_range_ptr' and 'Const_byte_range_ptr' argument types, which
+make the code safer and easier to follow. Also, the VFS utilities offered by
+_os/vfs.h_ benefit from this safety improvement.
+
+
+GPU performance optimizations
+=============================
+
+Session interface changes
+-------------------------
+
+The GPU session interface was originally developed along the first version of
+our GPU multiplexer for Intel devices. For this reason, the interface
+contained Intel specific nomenclature, like GTT and PPGTT for memory map and
+unmap operations. With the introduction of new GPU drivers with different
+architectures (e.g., Mali and Vivante), the Intel specifics should have gone
+away. With the current Genode release, we streamlined the map and unmap
+functions to semantically be more correct on all supported hardware. There are
+two map functions now: First, _map_cpu_ which maps GPU graphics memory to be
+accessed by the CPU. And second, _map_gpu_ which establishes a mapping of
+graphics memory within the GPU.
+
+Additionally, we removed the concept of buffers (as used by Mesa and Linux
+drivers) to manage graphics memory and replaced it by the notion of video
+memory (VRAM) where VRAM stands for the actual graphics memory used by a GPU -
+may it be dedicated on-card memory or system RAM. The change makes it possible
+to separate the graphics-memory management from the buffer management as
+required by the Mesa library.
+
+
+Intel graphics
+--------------
+
+When porting 3D applications using Mesa's OpenGL, we found that Mesa allocates
+and frees a lot of small GPU buffer objects (data in GPU memory) during
+operation. This is sub optimal for component-based systems because the Mesa
+library has to perform an RPC to the GPU multiplexer for each buffer
+allocation and for each buffer mapping. As mentioned above, we changed the
+session semantics from buffer object to video memory and implemented this
+feature within Intel's GPU multiplexer, which now only hands out VRAM. This
+made it possible to move the buffer handling completely to the Mesa client
+side (libdrm). Libdrm now allocates large chunks of video memory (i.e., 16MB)
+and hands out memory for buffer objects from this pool. This brings two
+advantages: First, the client-side VRAM pool acts as cache, which reduces the
+number of RPCs required for memory management significantly. Second, because
+of the larger VRAM allocations (compared to many 4K or 16K allocations before)
+fewer capabilities for the actual dataspaces that back the memory are
+required. Measurements showed that almost an order of magnitude of
+capabilities can be saved at Mesa or the client side this way.
+
+
+Mali graphics
+-------------
+
+The 22.08 release introduced a
+[https://genode.org/documentation/release-notes/22.08#GPU_and_Mesa_driver_for_Mali-400 - driver]
+for the GPU found in the PinePhone. Since it was merely a rapid prototype, it
+was limited to one client at a time, and was normally started and stopped
+together with its client. With this release, we remedied these limitations and
+enabled support for multiple concurrent clients and also revised our libdrm
+backend for Mesa's Lima driver.
+
+We have not yet explored applying the same VRAM optimizations that are employed
+by our Intel graphics stack. One VRAM allocation still correlates to one
+buffer-object.
+
+
+More flexible ACPI-event handling
+=================================
+
+The _acpica_ component uses the Intel ACPICA library to parse and interpret
+ACPI tables and AML code. One designated feature is the monitoring of several
+ACPI event sources including optional reporting of information about state
+changes. The supported event sources are:
+
+* Lid, which can be open or closed
+* Smart battery (SB), information about battery parameters (e.g., capacity)
+ and charging/discharging status
+* ACPI fixed events, e.g., power buttons
+* AC adapters, which reflect power cable plug/unplug
+* Embedded controller (EC), events like Fn-* keys, Lid, AC, SB changes
+* Vendor-specific hardware events, e.g., Fujitsu FUJ02E3 key events
+
+Acpica optionally reports information about state changes. These reports can
+be monitored by other components as ROMs. The following configuration
+illustrates the feature:
+
+!
+!
+!
+!
+!
+!
+!
+!
+!
+!
+!
+!
+!
+!
+!
+!
+!
+!
+! ...
+!
+!
+
+One such ACPI monitor component is _acpi_event_ that maps ACPI events to key
+events of a requested Event session based on its configuration. This way, ACPI
+state changes can be processed like ordinary key press-release events via, for
+example, the _event_filter_. The following configuration illustrates how to
+map the ACPI event types to key events:
+
+!
+!
+!
+!
+!
+!
+!
+!
+!
+!
+!
+!
+!
+!
+!
+!
+!
+!
+! ...
+!
+!
+
+In the current release, we replaced the limited list of supported key names by
+a general mechanism, which supports the use of all key names declared in
+_repos/os/include/input/keycodes.h_.
+
+
+Base API changes
+================
+
+As part of our continuous motive to streamline and simplify the framework's
+base API as much as possible, the current release removes the interfaces
+_base/blocking.h_, _base/debug.h_, and _base/lock_guard.h_ as those headers
+contained parts of the API that have become obsolete by now. As a further
+minor change, the 'abs' function of _util/misc_math.h_ got removed.
+
+The string utilities _util/string.h_ received the new 'Const_byte_range_ptr'
+type complementing the existing 'Byte_range_ptr'. Both types are designated
+for passing arguments that refer to a byte buffer, e.g., the source buffer of
+a write operation.
+
+
+On-target system-update and rollback mechanism
+##############################################
+
+For the mobile version of Sculpt OS as covered in
+Section [First system image of mobile Sculpt OS (PinePhone)],
+we envisioned easy-to-use system updates that would enable us to quickly
+iterate based on the feedback of early field testers.
+
+This topic confronted us with a variety of concerns. Just to name a few,
+conventions for booting that would not require changes in the future,
+equipping (system) images with self-reflecting version information, tools for
+generating and publishing digitally-signed images, on-target discovery of new
+image versions, secure downloading and cryptographic checking of new images,
+directing the machine's boot loader to use the new version, and possibly
+reverting to an earlier version.
+
+Fortunately, most of these concerns have a lot in common with the problems
+we had to address for Genode's
+[https://genode.org/documentation/release-notes/18.02#On-target_package_installation_and_deployment - package management].
+For example, the off-target and on-target tooling for digital signatures,
+the notion of a depot, and the concept of federated software providers
+(depot users) are established and time-tested by now.
+
+
+Self-reflecting version information
+-----------------------------------
+
+To allow a running Sculpt system to know its own version, the sculpt.run
+script generates an artificial boot module named "build_info", which can be
+evaluated at runtime by the sculpt-manager component.
+
+!
+
+
+Formalism for generating images and image metadata
+--------------------------------------------------
+
+To enable the Sculpt system to easily detect new versions, system images must
+be accompanied by metadata discoverable at a known location. This information
+is provided by a so-called image-index file located at
+_depot//image/index_. The image index of a depot user lists the
+available images in XML form, e.g.,
+
+!
+!
+!
+!
+! ...
+!
+
+The 'os', 'board', and 'version' attributes can be used to infer the file name
+of the corresponding image file. The '' nodes contain a summary of
+changes as information for the end user.
+
+The new _gems/run/sculpt_image.run_ script provides assistance with generating
+appropriately named images, placing them into the depot, and presenting a
+template for the manually curated image index.
+
+
+Signing and publishing
+----------------------
+
+For signing and publishing system images and image indices, we extended the
+existing _tool/depot/publish_ tool. To publish a new version of an image
+index:
+
+! ./tool/depot/publish /image/index
+
+Each system image comes in two forms, a bootable disk image and an archive of
+the boot directory. The bootable disk image can be used to install a new
+system from scratch by copying the image directly to a block device. It
+contains raw block data. The archive of the boot directory contains the
+content needed for an on-target system update to this version. Within the
+depot, this archive has the form of a directory - named after the image - that
+contains the designated content of the boot directory on target. Depending on
+the board, it may contain only a single file loaded by the boot loader (e.g.,
+uImage), or several boot modules, or even the boot-loader configuration. The
+following command publishes both forms:
+
+! ./tool/depot/publish /image/
+
+This results in the following - accompanied by their respective .sig
+files - in the public directory:
+
+! /image/.img.xz (disk image)
+! /image/.tar.xz (boot archive)
+! /image/.zip (disk image)
+
+The .zip file contains the .img file. It is provided for users who download
+the image on a system with no support for .xz.
+
+
+On-target image discovery, download, and verification
+-----------------------------------------------------
+
+To enable a running Sculpt system to fetch image index files and images, the
+existing depot-download component accepts the following two new download
+types:
+
+!
+!
+
+Internally, the depot-download subsystem employs the depot-query component to
+determine the missing depot content. This component accepts the following two
+new queries:
+
+!
+!
+
+If present in the query, depot_query generates reports labeled as "images" and
+"image_index" respectively. These reports are picked up by the depot-download
+component to track the completion of each job. The reported information is
+also used by the system updater to get hold of the images that are ready to
+install.
+
+
+On-target image installation and rollback
+-----------------------------------------
+
+Once downloaded into the local depot of a Sculpt system, the content of the
+boot directory for a given image version is readily available, e.g.,
+
+! depot/nfeske/image/sculpt-pinephone-2023-02-02/uImage
+
+The installation comes down to copying this content to the _/boot/_ directory.
+On the next reboot, the new image is executed.
+
+When subsequently downloading new image versions, the old versions stay
+available in the depot as sibling directories. This allows for an easy
+rollback by copying the boot content of an old version to the _/boot/_
+directory.
+
+
+Device drivers
+##############
+
+NXP i.MX Ethernet & USB
+=======================
+
+The Ethernet driver for i.MX53, i.MX6, and i.MX7 got updated to use a more
+recent Linux kernel version (5.11). These drivers got aligned with the
+source-code base originally ported for the i.MX8 SoC.
+
+Using the recent approach to port Linux device drivers, trying to preserve the
+original semantic, it is necessary to provide the correct clock rates to the
+driver. Therefore, specific platform drivers for i.MX6 and i.MX7 were created
+that enable the network related clocks and export their rate values.
+The i.MX53 related platform driver got extended to support these clocks.
+
+The USB host-controller driver for the i.MX 8MQ EVK is now able to drive the
+USB-C connector of this board too.
+
+
+Realtek Wifi
+============
+
+As a welcoming side effect of switching to the new DDE-Linux approach,
+enabling other drivers that are part of the same subsystem has become less
+involved. In the past, we mostly focused on getting wireless devices supported
+by the iwlwifi driver to work as those are the devices predominantly found in
+commodity laptops. That being said, every now and then, one comes across a
+different vendor and especially with the shifting focus on ARM-based systems
+covering those as well became necessary.
+
+As a first experiment, we enabled the rtlwifi driver that provides support
+for Realtek-based wireless devices. Due to lacking access to other hardware,
+the driver has been so far tested only with a specific RTL8188EE based device
+(10ec:8179 rev 01). Of course, some trade-offs were made as power-management
+is currently not available. But getting it to work, nevertheless, took barely
+half a day of work, which is promising.
+
+
+Platforms
+#########
+
+Base-HW microkernel
+===================
+
+Cache-maintenance optimization
+------------------------------
+
+On ARM systems, the memory view on instructions and data of the CPUs, as well
+as between CPUs and other devices is not necessarily consistent. When dealing
+with DMA transfers of devices, developers of related drivers need to ensure
+that corresponding cache lines are cleaned before a DMA transfer gets
+acknowledged. When dealing with just-in-time compilation, where instructions
+are generated on demand, the data and instruction caches have to be aligned
+too.
+
+Until now, the base-API functions for such cache-maintenance operations were
+mapped to kernel system calls specific to base-hw. Only the kernel was allowed
+to execute cache maintenance related instructions. On ARMv8 however, it is
+possible to allow unprivileged components to execute most of these
+instructions.
+
+With this release, we have implemented the cache maintenance functions outside
+the kernel on ARMv8 where possible. Thereby, several device drivers with a lot
+of DMA transactions, e.g. the GPU driver, benefit from this optimization
+enormously. The JavaScript engine used in the Morph and Falkon browsers
+profits as well.
+
+
+ACPI suspend & resume
+---------------------
+
+In the previous release, we started to support the low-level
+[https://genode.org/documentation/release-notes/22.11#Low-level_mechanism_for_suspend_resume_on_PC_platforms - ACPI suspend and resume]
+mechanism with Genode for the NOVA kernel. With the current release, we added
+the required low-level support to Genode's base-hw kernel for x86 64bit
+platforms. Similar to the base-nova version, on base-hw the
+'Pd::managing_system' RPC function of Genode's core roottask is used to
+transfer the required ACPI values representing the S3 sleep state to the
+kernel. The kernel then takes care to halt all CPUs and flush its state to
+memory, before finally suspending the PC using the ACPI mechanism. On resume,
+the kernel re-initializes necessary hardware used by the kernel, e.g., all
+CPUs, interrupt controller, timer device, and serial device. One can test
+drive the new feature using the _run/acpi_suspend_ scenario introduced by the
+former release.
+
+
+Scheduling improvements for interactive workloads
+-------------------------------------------------
+
+As Genode conquers the PinePhone, the base-hw kernel, for the first time, has
+to perform real-life multimedia on a daily basis given a resource-limited
+mobile target. One particularly important and ambitious use case has become
+video conferencing in the Morph browser. A combination of an already demanding
+browser engine with an application that not only streams video and audio in
+both directions over network but also handles video and audio I/O at the
+device, and all that fluently and at the same time.
+
+A lot of thinking went into how to optimize this scenario on each level of
+abstraction and one rather low-level lever was the scheduling scheme of the
+base-hw kernel. The base-hw scheduling scheme consists of a combination of
+absolute priority bands with execution-time quotas that prevent higher
+prioritized subjects from starving lower ones. There is the notion of a super
+period and each subject owns only a fraction of that super period as quota
+together with its priority. Once a subject has depleted its quota, it can't
+use its priority until the end of the current super period where its quota
+will be re-filled. However, during that time, the subject is not blocked - It
+can become active whenever there is no subject with priority and remaining
+quota present.
+
+So, this "zero" band below all the priority bands temporarily accommodates all
+subjects that have a priority but that are out of quota. It contains, however,
+also subjects that have no priority in general. These might be tasks like a GCC
+compilation or a ray tracer. While prioritized tasks would be user input
+handlers or the display driver. Now, one difficult problem that arises with
+this scheduling scheme is that system integration has to decide how much quota
+is required by a prioritized task. The perfect value can't be determined as it
+depends on many factors including the target platform. Therefore, we have to
+consider that an important task like the audio driver in the video-conference
+scenario runs out of quota shortly before finishing its work.
+
+This is already bad as is as the audio driver now has to share the CPU with
+many unimportant tasks until the next super period. But it became even worse
+because, in the past implementation, subjects always entered the zero band at
+the tail position. It meant that, e.g., the remaining audio handling had to
+wait at least until all the unprioritized tasks (e.g. long-taking computations)
+had used up their zero-band time slice. In order to mitigate this situation, we
+decided that prioritized tasks when depleting their quota become head of the
+zero-band, so, they will be scheduled first whenever the higher bands become
+idle.
+
+This change relaxes the consequences of quota-depletion events for
+time-critical tasks in a typical system with many unprioritized tasks.
+At the same time, it should not have a significant impact on the overall
+schedule because depletion events are rare and zero-band time-slices short.
+
+
+NOVA microhypervisor
+====================
+
+ACPI suspend & resume
+---------------------
+
+As an extension to the principal
+[https://genode.org/documentation/release-notes/22.11#Low-level_mechanism_for_suspend_resume_on_PC_platforms - ACPI suspend and resume]
+support introduced with the Genode 22.11 release, the NOVA kernel now supports
+also the re-enablement of the IOMMU after ACPI resume. The IOMMU as a hardware
+feature has been supported by Genode since
+[https://genode.org/documentation/release-notes/13.02#DMA_protection_via_IOMMU - release 13.02]
+and extended in
+[https://genode.org/documentation/release-notes/20.11#NOVA_microhypervisor - release 20.11],
+which sandboxed device hardware and (malicious/faulty) drivers to avoid
+arbitrary DMA transactions.
+
+Intel P/E cores
+---------------
+
+Starting with [https://en.wikipedia.org/wiki/Intel_Core#12th_generation - Intel CPU generation 12],
+Intel introduced CPUs with heterogeneous cores, similar to
+[https://en.wikipedia.org/wiki/ARM_big.LITTLE - ARM's big/LITTLE] concept.
+The new CPUs have a number of so called P-cores (performance) and E-cores
+(efficient), which differ in their performance and power characteristics.
+The CPU cores
+([https://en.wikipedia.org/wiki/Alder_Lake#CPUID_incoherence - should be])
+instruction compatible and are reported as identical via x86's CPUID
+instruction nowadays. However, an operating system such as Genode must be able
+to differentiate the cores in order to take informed decisions about the
+placement and scheduling of Genode components.
+
+With the current release, we added support to the NOVA kernel to propagate the
+information about P/E cores to Genode's 'core' roottask. In Genode's core,
+this information is used to group the CPU cores into Genode's
+[https://genode.org/documentation/release-notes/13.08#Management_of_CPU_affinities - affinity space].
+With
+[https://genode.org/documentation/release-notes/20.05#NOVA_microhypervisor - release 20.05],
+we introduced the grouping of hyperthreads on the y-axis, which we keep in
+case the P-cores have the feature enabled. Following the P-cores and
+hyperthreads, all remaining E-cores are placed in the affinity space.
+
+The following examples showcase the grouping in the affinity-space on x/y axis:
+
+Core i7 1270P - 4 P-cores (hyperthreading enabled) and 8 E-cores:
+
+! x-axis 1 2 3 4 5 6 7 8
+! ----------------------------------
+! y-axis 1 | P\ P\ P\ P\ E E E E
+! 2 | P/ P/ P/ P/ E E E E
+!
+! hyperthreads \ / of same core
+
+Core i7 1280P - 6 P-cores (hyperthreading enabled) and 8 E-cores:
+
+! x-axis 1 2 3 4 5 6 7 8 9 10
+! -----------------------------------------
+! y-axis 1 | P\ P\ P\ P\ P\ P\ E E E E
+! 2 | P/ P/ P/ P/ P/ P/ E E E E
+!
+! hyperthreads \ / of same core
+
+The information about the P/E cores is visible in the kernel and Genode's
+log output and is reported in the 'platform_info' ROM, e.g.
+
+! kernel:
+!
+! [ 0] CORE:00:00:0 6:9a:3:7 [415] P 12th Gen Intel(R) Core(TM) i7-1270P
+! ...
+! [15] CORE:00:17:0 6:9a:3:7 [415] E 12th Gen Intel(R) Core(TM) i7-1270P
+! ...
+
+! Genode's core:
+!
+! mapping: affinity space -> kernel cpu id - package:core:thread
+! remap (0x0) -> 0 - 0: 0:0 P boot cpu
+! remap (0x1) -> 1 - 0: 0:1 P
+! remap (1x0) -> 2 - 0: 4:0 P
+! remap (1x1) -> 3 - 0: 4:1 P
+! remap (2x0) -> 4 - 0: 8:0 P
+! remap (2x1) -> 5 - 0: 8:1 P
+! remap (3x0) -> 6 - 0:12:0 P
+! remap (3x1) -> 7 - 0:12:1 P
+! remap (4x0) -> 8 - 0:16:0 E
+! remap (4x1) -> 9 - 0:17:0 E
+! remap (5x0) -> 10 - 0:18:0 E
+! remap (5x1) -> 11 - 0:19:0 E
+! remap (6x0) -> 12 - 0:20:0 E
+! remap (6x1) -> 13 - 0:21:0 E
+! remap (7x0) -> 14 - 0:22:0 E
+! remap (7x1) -> 15 - 0:23:0 E
+! ...
+
+! platform_info ROM:
+!
+! ...
+!
+!
+! ...
+!
+! ...
+!
+! ...
+
+
+Build system and tools
+######################
+
+Building and packaging CMake-based shared libraries (via Goa)
+=============================================================
+
+The [https://github.com/nfeske/goa - Goa] tool streamlines the work of
+cross-developing, testing, and publishing Genode application software
+using commodity build tools like CMake. The tool is particularly suited for
+porting existing 3rd-party software to Sculpt OS.
+
+Until recently, Goa was solely focused on applications whereas the porting of
+3rd-party libraries required the use of the traditional approach of hand
+crafting build rules for Genode's build system. This limitation of Goa got
+lifted now.
+
+In the new version, a Goa project can host an _api_ file indicating that
+the project is a library project. The file contains the list of headers that
+comprise the library's public interface. The build artifact of a library
+is declared in the _artifacts_ file and is expected to have the form
+_.lib.so_. The ABI symbols of such a library must be listed
+in the file _symbols/_. With these bits of information supplied
+to Goa, the tool is able to build and publish both the library and the API as
+depot archives - ready to use by Genode applications linking to the library.
+The way how all those little pieces work together is best illustrated by the
+accompanied
+[https://github.com/nfeske/goa/tree/master/examples/cmake_library - example].
+For further details, please consult Goa's builtin documentation via 'goa help'
+(overview of Goa's sub commands and files) and 'goa help api' (specifics of
+the _api_ declaration file).
+
+When porting a library to Genode, one manual step remains, which is the
+declaration of the ABI symbols exported by the library. The new sub command
+'goa extract-abi-symbols' eases this manual step. It automatically generates a
+template for the _symbols/_ file from the library's built shared
+object. Note, however, that the generated symbols file is expected to be
+manually reviewed and tidied up, e.g., by removing library-internal symbols.
+
+_Thanks to Pirmin Duss for having contributed this welcomed new feature, which_
+_makes Goa much more versatile!_
+
+
+New tool for querying metadata of ports
+=======================================
+
+The integration of third-party software into Genode is implemented via _ports_
+that specify how to retrieve, verify, and patch the source code in preparation
+for use with our build system. Ports are managed by tools residing in the
+_tool/ports_ directory. For example, _tool/ports/prepare_port_ is used to
+execute all required preparation steps.
+
+Currently, the base Genode sources support 90 ports (you may try
+_tool/ports/list_ yourself) and, thus, it's not trivial to keep track of all
+the ports in the repo directories. Therefore, we introduce the
+_tool/ports/metadata_ tool to extract information about license, upstream
+version, and source URLs of individual ports. The tool can be used as follows:
+
+!./tool/ports/metadata virtualbox6
+!
+!PORT: virtualbox6
+!LICENSE: GPLv2
+!VERSION: 6.1.26
+!SOURCE: http://download.virtualbox.org/virtualbox/6.1.26/VirtualBox-6.1.26.tar.bz2 (virtualbox)
+!SOURCE: http://download.virtualbox.org/virtualbox/6.1.26/VirtualBoxSDK-6.1.26-145957.zip (virtualbox_sdk)
+
+
+Harmonization of the boot concepts across ARM and PC platforms
+==============================================================
+
+To make the system-update functionality covered in
+Section [On-target system-update and rollback mechanism] equally usable across
+PC and ARM platforms, the conventions of booting the platforms had to be
+unified.
+
+Traditionally, a bootable disk image for the PC contains a _boot/_ directory.
+E.g., when using NOVA, it contains the GRUB boot-loader config + the hypervisor +
+the bender pre-boot loader + the banner image + the Genode system image.
+This structure corresponds 1:1 to the _boot/_ directory as found on the 3rd
+partition of the Sculpt system, which is very nice. A manual system update of
+Sculpt comes down to replacing these files. However, on ARM platforms, SD-card
+images used to host a _uImage_ file and a U-Boot environment configuration
+file in the root directory. The distinction of these differences complicates
+both the build-time tooling and the on-target handling of system updates.
+
+The current release unifies the boot convention by hosting a _boot/_ directory
+on all platforms and reinforces the consistent naming of files. On ARM, the
+_uImage_ and _uboot.env_ files now always reside under _boot/_. Thanks to this
+uniform convention, Genode's new system update mechanism can now equally
+expect that a system update corresponds to the mere replacement of the content
+of the _boot/_ directory.
+
+
+Minor run-tool changes
+======================
+
+The functionality of the _image/uboot_fit_ plugin has been integrated into the
+regular _image/uboot_ plugin as both plugins were quite similar.
+FIT images can now be produced by adding the run option '--image-uboot-fit'.
+
diff --git a/doc/release_notes/23-05.txt b/doc/release_notes/23-05.txt
new file mode 100644
index 0000000000..6253f0f116
--- /dev/null
+++ b/doc/release_notes/23-05.txt
@@ -0,0 +1,861 @@
+
+
+ ===============================================
+ Release notes for the Genode OS Framework 23.05
+ ===============================================
+
+ Genode Labs
+
+
+
+Besides our annual documentation update, our major tool-chain update as
+scheduled every two years, and the switch to C++20, version 23.05 puts the
+spotlight on the Goa tool, which allows us to leverage existing SDKs like
+Lomiri and Rust's cargo for Genode applications. In line with the previous
+versions, DDE-Linux is prominently featured as enabler of our cross-platform
+Wifi stack and the updated (6.1.20) drivers for Intel graphics and USB.
+
+:
+:
+:
+
+Before getting to the technical achievements, we'd like to draw your attention
+to the books "Genode Foundations" and "Genode Platforms", which have been
+updated to reflect the most recent state of the framework. Whereas the
+"Foundations" cover Genode's architecture, developer work flows, and reference
+material, the "Platforms" document is focused on low-level hardware topics and
+provides plenty of practical guidance.
+
+:
+
+Every two years, we update Genode's tool chain to the latest stable releases
+of GCC and binutils. This time, we took the update as opportunity to switch
+Genode's default from C++17 to C++20 so that modern C++ niceties can be used
+for regular Genode components. The new tool chain is covered by
+Section [New tool chain based on GCC 12.3, C++20 enabled by default].
+
+For application developers, the evolving Goa tool is certainly the most
+interesting feature of the current release. As detailed in
+Section [Goa tool updated to Sculpt OS 23.04, initial support for Rust],
+this tool enables us to reuse existing SDKs to target Genode. In particular,
+we enabled the use of the Lomiri mobile UI toolkit (formerly known as Ubuntu
+Touch UI toolkit) for targeting the PinePhone, and Rust's cargo.
+
+System integrators may appreciate our continued development of the Linux
+device-driver environment, which received an update to Linux 6.1.20
+(Section [Device drivers]) and ultimately enabled us to use the same Wifi
+stack across PC and ARM platforms
+(Section [Uniform Wifi stack across PC and ARM platforms]).
+
+Even though not end-user facing yet, two noteworthy development milestones of
+the current release are the new use of our custom base-hw microkernel as x86
+hypervisor (Section [Base-HW microkernel]) and the profound work on storage
+encryption covered in
+Section [Revision of Genode's custom block-encryption infrastructure].
+Further topics making an appearance in version 23.05 range from RISC-V, over
+WireGuard, VirtualBox, to seL4.
+
+
+Goa tool updated to Sculpt OS 23.04, initial support for Rust
+#############################################################
+
+Last month, we [https://genode.org/news/sculpt-os-release-23.04 - released]
+Sculpt OS 23.04 for PC and PinePhone. The new release comes with various
+[https://genodians.org/nfeske/2023-05-11-sculpt-os - usability improvements]
+such as presets and on-target system updates.
+
+[image mobile_sculpt_23_04]
+ Interactive software management on the mobile variant of Sculpt OS
+
+In particular, with Sculpt OS 23.04 running on the PinePhone, we have carved
+out the base for hosting mobile apps on a Genode-based system. Yet, there are
+only very few apps available right now. Since an OS is of no practical use
+without apps, this urgently called for an SDK to simplify (mobile) app
+development. After careful investigation, we opted for porting the
+Ubuntu-Touch-UI toolkit to Genode and integrate it into Goa (Section
+[Using Goa for bringing apps based on the Ubuntu-Touch-UI toolkit to Genode]),
+our streamlined workflow tool for application development. In addition, we
+integrated initial support for Rust's _cargo_ to make Goa palatable to a
+broader developer audience (Section [Initial Rust support]).
+
+The growing attention of the Goa tool prompted us to move it under the
+[https://genodians.org/nfeske/2023-05-02-goa-genode-labs - umbrella of Genode Labs]
+as we are increasing our development and maintenance efforts for the tool.
+Aligned with the Sculpt release, the Goa tool has been updated with the
+corresponding depot archive versions. With this Genode release, we put a
+cherry on top and added bash completion to improve the user experience even
+further. Having Goa installed, bash completion is enabled by the following
+commands:
+
+! goa update-goa master
+! GOA_DIR=$(realpath $(which goa) | sed s#bin/goa##)
+! echo "source ${GOA_DIR}/share/bash-completion/goa" >> ~/.bashrc
+
+:Goa tool:
+
+ [https://github.com/genodelabs/goa/]
+
+
+Using Goa for bringing apps based on the Ubuntu-Touch-UI toolkit to Genode
+==========================================================================
+
+While writing mobile apps might be fun, it is outside our core expertise.
+Therefore, we have looked into ways of supporting established open-source SDKs
+for app development on Genode. We investigated two possible options in depth,
+namely Ubuntu Touch's UI toolkit now called [https://lomiri.com - Lomiri] and
+the [https://docs.sailfishos.org/Tools/Sailfish_SDK - Sailfish SDK]. We have
+tried to port applications for both stacks and after many iterations settled
+with the Ubuntu UI toolkit. The full story can be read
+[https://genodians.org/ssumpf/2023-05-06-ubunutu_ui - here]. Therefore, a port
+of the Ubuntu UI toolkit is available on Genode right now and support for it
+has been added to the Goa tool.
+
+The workflow for crafting an app for the PinePhone using the Goa tool is a
+fairly streamlined experience now:
+
+# Since the UI toolkit depends on Qt5, add "genodelabs/api/qt5" to your
+ [https://genodians.org/nfeske/2019-11-25-goa - _used_apis_ file]
+
+# Add "ssumpf/pkg/ubuntu_ui_toolkit" to your _archives_
+ [https://genodians.org/nfeske/2019-11-25-goa - file] to have the UI toolkit
+ available within your package
+
+# In order to have your QML code within your packet installed, add
+ ".tar: install/" to your
+ [https://genodians.org/nfeske/2019-11-25-goa - _artifacts_ file]
+
+# Configure your
+ [https://genodians.org/nfeske/2019-12-19-goa-unix-terminal - _runtime_ file]
+
+# Execute your scenario on Linux for development
+ ! goa run
+
+# Build for the PinePhone
+ ! goa build --arch arm_v8a
+
+# [https://genodians.org/nfeske/2020-01-16-goa-publish - Publish] your package
+ ! goa publish --depot-user john --depot-overwrite
+
+Examples using QML, Qt5, and C++ can be found
+[https://github.com/ssumpf/goa-projects - here]
+
+
+Initial Rust support
+====================
+
+The Rust programming language has grown in popularity in the recent years.
+The Genode OS Framework had support for the Rust programming language
+before, contributed to Genode release 16.05 by Waylon Cude. However, as an
+on-off contribution it never got traction and the support was eventually
+removed with release 20.05.
+While the original support focused on some low-level runtime libraries and
+integration into the Genode build system, our new attempt has a somewhat
+different objective, which is to facilitate the use of the existing Rust
+ecosystem on the Genode OS Framework. The removal note already envisioned a
+possible comeback using the Goa tool and Rust's cargo build system, for which
+we have added initial support with this release.
+
+Our objective led to the following guidelines for Rust integration:
+
+# Make use of the native build system, cargo, to make the existing ecosystem
+ accessible.
+# Aim for a seamless integration into the Genode OS Framework using the Goa
+ build tool.
+# Instead of introducing our own Genode
+ [https://doc.rust-lang.org/nightly/rustc/platform-support.html - target triples],
+ leverage Genode's FreeBSD-based C library interface to use existing
+ supported standard library targets like 'x86_64-unknown-freebsd'.
+# Strive to use the upstream tool chain, or at least stay as close to upstream
+ as possible.
+
+While we largely succeeded in following these guidelines, our initial
+proof-of-concept implementation relies on a marginally adapted tool chain to
+work around missing support for versioned library symbols in our linker.
+We are exploring avenues to overcome these limitations and expand the support
+to cover more complex use cases in the next release.
+
+To learn more about our Rust support, head over to the
+[https://genodians.org/atopia/2023-05-30-bringing-rust-back-to-genode - article on Genodians.org].
+
+
+Uniform Wifi stack across PC and ARM platforms
+##############################################
+
+Support for wireless LAN was mostly focused on the
+[https://genode.org/documentation/release-notes/14.11#Intel_wireless_stack - PC platform]
+as it was the platform predominately used for using Genode and, in extension,
+Sculpt on a daily basis. In the last couple of years, however, we started to
+embrace ARM-based platforms like the MNT Reform 2 and the PinePhone as well,
+longing for thorough support of Sculpt OS on such systems. Thanks to our Linux
+device-driver environment, we have now taken the opportunity to reuse the
+existing wireless stack on vastly different platforms.
+
+
+Making the wireless stack globally accessible
+---------------------------------------------
+
+The
+[https://genode.org/documentation/release-notes/23.02#Realtek_Wifi - previous release]
+already featured additional support for a different wireless LAN device driver -
+the rtlwifi driver that supports Realtek-based devices - giving us a good
+intuition on how easy it has become to extend even a complex Linux-based
+driver component stack such as our wifi-driver component ('wifi_drv').
+
+The first step was making it less x86-centric. We started by making the various
+ingredients of the driver available on the ARM platforms.
+
+On the one hand, that includes the WPA supplicant and its dependencies like
+the 'nl80211' driver that in turn depends on 'libnl'. Enabling them was
+straight-forward because they are already pretty platform independent and
+the platform-dependent portions, e.g. libcrypto, are readily available for ARM.
+
+On the other hand, the wireless stack was slightly more complicated because
+the hardware integration of wireless networking devices on ARM platforms
+varies from platform to platform. In case of the MNT Reform 2 and PC, the
+integrated wireless devices are normally connected via PCIe. In contrast, the
+PinePhone relies on SDIO. We separated the code to allow for a "mix-and-match"
+way of selecting the necessary compilation units as the used Linux
+configuration might differ between each target and could result in compilation
+issues otherwise.
+
+The next step was to make the wireless stack globally accessible by moving it
+from the _pc_ to the _dde_linux_ repository. This move was motivated by the
+fact that the _dde_linux_ repository is already available in all platform or
+rather board-specific repositories while the _pc_ repository is not. It is
+in itself a board-specific repository and therefore having it appear as
+dependency for other such repositories feels unnatural.
+
+So the bulk of the driver code now lives in the _dde_linux_ repository from
+where it can be referenced by other repositories.
+
+While moving the code, we noticed that in contrast to all other Linux-based
+drivers the 'wifi_drv' is special. Since the binary itself is a libc component,
+care was taken to isolate the application code, the 'wpa_supplicant', from
+the driver code, the library containing the Linux wireless stack and drivers.
+On all platforms, the binary stays the same while the driver library contains
+all the platform-specific code. For this reason, the 'wifi_drv' binary is now
+delegated to be a generic harness that includes all configuration and
+management functionality shared by all wireless device driver components,
+e.g., the WPA supplicant. The code of the device driver emulation environment
+is located in _repos/dde_linux/src/lib/wifi_. It is referenced by the
+platform-specific driver library that resides in the corresponding platform
+repository. The runtime configuration needs to point the driver to a proper
+driver library.
+
+The platform-specific library is in charge of orchestrating the 3rd-party
+sources utilized by the driver as well as providing the _source.list_ and
+_dep.list_ files. It must include the generic library snippet
+_repos/dde_linux/lib/wifi.inc_ that deals with managing the emulation
+environment code. The amount of code added by the platform-specific libraries
+is unimposing as it mostly consists of the dummy implementations needed by
+the Linux configuration.
+
+[image wifi_drv_architecture]
+ Composition of the wireless LAN driver component
+
+All recipes for the depot archives are prefixed to the specific driver, for
+example 'pkg/pc_wifi' contains a reference to 'src/pc_wifi_drv' as well as to
+'raw/pc_wifi_firmware'.
+
+Thanks to the steps outlined above, we now have three different wireless LAN
+drivers, one for the PinePhone, one for the MNT Reform 2, and one for the PC
+that nicely follow the same approach.
+
+
+New firmware loading mechanism
+------------------------------
+
+Additionally to making it easier to enable and use the driver for new
+platforms, we also refined how the driver loads its firmware images. In the
+past, the driver contained a list of well-known working firmware images that
+needed to be updated every now and then when new devices where enabled or the
+firmware version changed due to a Linux update. In particular using the driver
+with new devices was cumbersome as the driver itself already supported the
+device most of the time, but it solely missed the corresponding entry in the
+firmware list and adding that required recompiling the driver.
+
+[image wifi_firmware_loading]
+ Firmware image loading sequence
+
+So instead, the driver now loads the firmware images via its local VFS rather
+than requesting a predetermined ROM module. Since the platform-specific driver
+library has no direct access to the VFS - after all both worlds are
+intentionally isolated from each other - a request/response interface was
+added. The library submits a request to the _wifi_drv_ binary and will suspend
+its execution waiting for the completion of the request. The binary will
+acquire the firmware image and notify the driver library in return.
+Streamlining the firmware acquisition in such a manner allows for using the
+original probing mechanism available in Linux. Rather than following the
+firmware list the actual driver code is now free to probe as it sees fit,
+exactly pointing to the required uAPI revision in case the firmware is
+missing.
+
+The following snippet illustrates the configuration of the driver on the
+PinePhone (omitting any integration-related routes for the config ROM as well
+as state and scan reports):
+
+!
+!
+!
+!
+!
+!
+!
+!
+!
+!
+!
+!
+!
+!
+!
+!
+!
+!
+!
+!
+!
+!
+!
+!
+!
+!
+! […]
+! child/>
+!
+!
+
+In this configuration, the firmware images are provided as a _.tar_ archive
+that itself is requested via a ROM connection. The driver will always look
+into the _/firmware_ directory to access any firmware related files. How the
+directory is populated is up to the integrator of the driver.
+
+As a further simplification step, we removed the need for the firmware library
+used to contain firmware images. It is superseded by the use of a plain data
+depot archive, e.g., _raw/pc_wifi_firmware_.
+
+
+Additional device support and updates
+-------------------------------------
+
+We updated the firmware images to the most recent ones supported by
+Linux version 6.1.20.
+
+We enabled the ath9k PCIe driver that can be used on the MNT Reform 2 and the
+PC. As the ath9k device (168c:0034) used to test the driver on the PC exhibited
+problems when using MSIs, we disable their usage in the 'pci_decoder'. Similar
+treatment might be necessary if other ath9k-based devices are used.
+
+The device support in the 'rtlwifi' driver got extended by additionally
+enabling support for RTL8192CE devices.
+
+Furthermore, we updated the WPA supplicant to its latest v2.10 release and
+introduce preliminary support for joining networks secured by WPA3.
+
+
+Base framework and OS-level infrastructure
+##########################################
+
+New tool chain based on GCC 12.3, C++20 enabled by default
+==========================================================
+
+Following a regular cycle of two years, we updated our tool chain to recent
+versions again, this time in particular to GCC 12.3.0, binutils 2.40, and GDB
+13.1 while taking the opportunity to enable C++20 by default.
+
+A noticeable change with GCC 12 is that auto-vectorization with the
+'-ftree-vectorize' option is now enabled by default when building with the
+'-O2' optimization level. This has the effect that more SIMD instructions are
+generated, which required adaptations throughout our code base, for example by
+making sure that memory allocations in ported Linux drivers adhere a suitable
+address alignment and by saving and restoring ARMv8 FPU registers in the
+dynamic linker.
+
+In addition to that, GCC 12 reports new warnings and errors, which we had to
+rectify at various places, the most common ones being:
+
+* Deprecated arithmetics between different enumeration types,
+
+* Deprecated use of '++' and '--' operators with volatile variables, and
+
+* Undefined references to 'strlen' inside custom implementations
+ of 'strlen'-like functions, related to the
+ '-ftree-loop-distribute-patterns' option.
+
+As an extra feature, we added Genode's library name patterns to the linker so
+that the '-l' option has become able to find the corresponding libraries.
+This is useful while porting 3rd-party software based on Autoconf, whenever a
+'configure' script checks for a library dependency by linking a test program
+with this option. This change thereby removes the need for dummy libraries
+that were formerly used to satisfy the probing.
+
+
+API changes
+===========
+
+As part of Genode's
+[https://genode.org/documentation/release-notes/16.08#Cultivation_of_the_new_text-output_API - great API revision]
+in 2016, we largely *abolished* the use of *format strings* throughout the
+framework. This is desirable because a code base without format strings cannot
+have format-string vulnerabilities. Still, a few occurrences, specifically the
+interface for passing session-construction arguments, remained untouched since
+then. With version 23.05, we finally attained our initial goal by wrapping up
+the transition.
+
+In particular, we revised 'Genode::Connection', which now accepts the session
+label, affinity, and session-specific parameters as constructor arguments,
+whereas the parameters are passed as a 'Genode::String'. This eliminates the
+need for rendering a format string. Given this new interface, we were able to
+remove format strings from all connection types, updated all components that
+still happened to rely on format strings, and ultimately removed format
+strings from Genode's base API.
+
+Format strings still play a role to accommodate 3rd-party code ported
+to Genode. Whenever the 3rd-party code targets the C runtime, format
+strings are readily available via the libc. For free-standing ports that
+avoid the dependency from the full C runtime, e.g., ported device drivers,
+a new 'format' library based on Genode's former _base/snprintf.h_ and
+_base/console.h_ provides rudimentary format-string support. The library
+is hosted in the libports repository.
+
+As another matter of housekeeping, we removed the _util/avl_string.h_ utility.
+The use case of organizing objects by using strings as keys is covered by the
+_util/dictionary.h_ now.
+
+
+Towards kernel-agnostic DMA protection
+======================================
+
+As sketched in our [https://genode.org/about/road-map - road map], we plan
+having a feature-complete PC version of Sculpt OS based on base-hw by the end
+of this year. One of the reasons why we are still sticking to base-nova for
+the PC version is the fact that we are relying on NOVA's IOMMU support. One
+necessary step to decouple Sculpt OS from base-nova is to integrate the IOMMU
+handling into the platform driver.
+
+Motivated by our
+[https://genode.org/documentation/release-notes/23.02#Custom_IP_block_for_DMA_protection_on_AMD_Xilinx_Zynq - custom IP block for DMA protection on AMD/Xilinx Zynq],
+we integrated the notion of IOMMU-like devices into the platform driver with
+this release as a preparatory step. The platform driver automatically acquires
+known IOMMU-like devices for itself by looking at the device types. Other
+devices can then reference these devices by using '' nodes. This is
+best illustrated by looking at the devices ROM for the Zynq's dma_guard IP
+block:
+
+!
+!
+!
+!
+!
+!
+!
+!
+!
+!
+!
+!
+
+This tells the platform driver that, whenever a DMA buffer is allocated/freed
+for the session owning the 'axi_dma_0' device, the 'dma_guard_0' must be
+configured accordingly in order to allow/deny access to the corresponding
+memory ranges. With the structural changes to the platform driver, the support
+for dma_guard devices is simply added by implementing specific 'Io_mmu' and
+'Io_mmu_factory' objects. You can find the code in the _dma_guard.h_ within
+the
+[https://github.com/genodelabs/genode-zynq/blob/master/src/drivers/platform/zynq/dma_guard.h - genode-zynq repo].
+
+For the PC version of the platform driver, we implemented a _kernel_iommu_
+device that still uses device PDs to pass IOMMU configuration to the NOVA
+kernel. The _kernel_iommu_ is automatically instantiated and used as a default
+for each device until we replaced this by a kernel-agnostic implementation in
+a future release.
+
+With these preparations, we paved the way for implementing configuration logic
+for arbitrary IOMMU-like devices within the platform driver. In particular,
+the platform driver has been made capable of managing multiple IOMMU-like
+devices at the same time. However, there is one limitation that comes from the
+fact that DMA buffers are not device-specific but allocated per session: All
+IOMMU-like devices must either operate as MMU (virtual addressing) or as MPU
+(physical addressing).
+
+
+Revision of Genode's custom block-encryption infrastructure
+===========================================================
+
+Tresor library
+~~~~~~~~~~~~~~
+
+For about two years, our Ada/SPARK-based CBE block encryption and its GUI
+front-end, the file vault, served us well with rather manageable workloads
+such as configuration and credential files in Sculpt OS on the PC. However,
+with the rise of mobile Sculpt on the PinePhone, the CBE ecosystem was
+suddenly confronted with new challenges and requirements.
+
+First, mobile platforms are usually less forgiving when it comes to
+performance and the CBE still exhibited a lot of potential for optimization.
+Second, we envision encrypted storage to become an integral part of the base
+system - the "appliance role" of mobile Sculpt OS - which shifts the role of
+the component from an optional feature to a foundational mechanism. With this
+role shift, however, maintainability becomes increasingly important. Third,
+now that we decided to settle on this block-encryption approach and to
+increasingly expose it to real workloads, we can expect new requirements to
+pop up more frequently and with higher priority. Last but not least, our
+Ada/SPARK runtime, so far, lacks ARM support.
+
+This prospect forced us to carefully reconsider our relation to the existing
+CBE approach, and especially to the fact that its core logic and crypto
+back-end were entirely written in Ada/SPARK. When we started developing the
+CBE in Ada/SPARK, we were positive that the language might become popular
+among the core developers of Genode and that, eventually, other, especially
+critical parts of the framework could benefit from it as well. But this idea
+didn't come to fruition. Only a few of us came in touch with the new language
+and, of those, even fewer acquired profound experience with it. We ultimately
+realized that the friction caused by the added language boundary that emerged
+with the CBE approach became a bottleneck, inhibiting the further evolution of
+our block-encryption stack with a strong sense of collective code ownership.
+
+This observation in mind, and the above-mentioned challenges in sight, we
+decided to drop the CBE library and create a new implementation strongly
+inspired by the CBE design but in C++, our "mother tongue". The new library is
+called tresor, brings the same feature set as the CBE and is compatible with
+containers created with the CBE. The file vault has been adapted to run with
+the tresor library. So file-vault users can continue using their containers as
+usual without further ado. The entire tresor-based ecosystem is
+architecture-agnostic, which lifts the former restriction to x86.
+
+
+File Vault
+~~~~~~~~~~
+
+Some new features have been added to the file vault. For instance, the
+component can now be driven with one of two available user interfaces: The
+usual graphical front-end or the new non-interactive interface that is driven
+by a textual configuration and provides feedback through a report. This allows
+for the integration of the file vault with automated controls respectively
+lower or higher-level UIs. The interactive interface remains the default, but
+one can replace it with the text-based variant using the new "user_interface"
+configuration attribute. An example of operating the text-based interface is
+provided by the new _file_vault_config_report.run_ script.
+
+As another rather small but handy feature, a file vault can now be locked and
+unlocked without having to restart the component. In the locked state, all key
+material is removed from the cryptographic back end and the block-encryption
+driver is shut down. The user is then prompted to provide the correct
+credentials in order to re-establish access to the container.
+
+
+Custom virtual machine monitor on ARM
+=====================================
+
+The
+[https://genode.org/documentation/release-notes/23.02#Interactive_graphical_VMs_on_ARM - previous release], introduced interactive graphical VMs on ARM systems.
+Genode's custom virtual machine monitor was enhanced by VirtIO device models
+for input events and GPU. However, dynamic changes of the virtual GPU's
+framebuffer resolution weren't yet handled by the initial version. With the
+current release, these restrictions got removed. Now, the user is able to
+resize the window of a virtual machine as expected.
+
+
+NetBSD rump kernel on RISC-V
+============================
+
+We have added RISC-V to our port of the
+[https://wiki.netbsd.org/rumpkernel - rump kernel].
+This enables Genode to access commodity file-systems on RISC-V based devices.
+
+
+Strengthened fault tolerance of on-target package management
+============================================================
+
+Genode's way of safely installing and deploying packages on-target - as
+introduced in
+[https://genode.org/documentation/release-notes/18.02#On-target_package_installation_and_deployment - version 18.02] -
+is a corner stone of Sculpt OS. The recent move of Sculpt OS to mobile
+devices, however, revealed a couple of limitations that we address with the
+current release.
+
+First, in contrast to the PC version of Sculpt OS that allows for the
+straight-forward management and editing of files using a regular command-line
+interface, a touch-based user interface as present on the phone is far more
+constrained. Problems that can be solved by manual intervention on the PC
+without second thought can become insurmountable showstoppers on the phone.
+The most prominent problem is recovery from the situation where package
+dependencies remain incomplete due to an interruption of the installation
+process or due to packaging mistakes. On the PC, such a situation can be
+resolved by simply clearing the depot using a single terminal command,
+followed by a reinstall of the package. On the phone, the user was left out in
+the cold with the message "package installed but incomplete" but with no
+obvious or non-obvious way of recovery. The new version gracefully handles
+this failure state by offering the retry of the package installation.
+
+Second, network connectivity is far more fluctuating on mobile devices, which
+increases the likelihood for download errors. The previous version that
+regarded download errors as rare and sporadic issues, responded to such errors
+by repeated and silent retries. We found that a mobile phone demands a more
+graceful way to reflect such failure situations to the user, and to limit the
+rate of futile download attempts. The new version preserves information about
+download failures for user inspection and re-issues new downloads only if not
+already flagged as unavailable.
+
+Finally, we encountered the manual addition of software providers to the
+system as a hurdle on the phone. On the PC, a new software provider can be
+added by manually placing the provider's _download_ and _pubkey_ files in a
+local depot directory, which is straight-forward when using a shell. However,
+on a touch-screen device, there is no obvious and simple way to supplement the
+system with such information. To still accommodate the user's desire to
+download and install software from arbitrary providers, we added the option to
+explicitly skip the signature verification for downloads. This is useful in
+scenarios where the lack of integrity of downloaded content does not pose a
+risk, e.g., for untrusted applications that are rigidly sandboxed, or during
+development.
+
+Whenever the depot-download subsystem encounters the attribute 'verify="no"'
+for an '' item, it accepts the installation even if no key is
+available. It still applies verification for dependencies whenever possible.
+E.g., if a package of the provider "john" gets installed via 'verify="no"' and
+the package depends on an archive by "genodelabs", for which the public key is
+known, the integrity of the content originating from "genodelabs" is verified.
+
+
+Libraries and applications
+##########################
+
+Qt5 reorganization
+==================
+
+When the Goa tool is used to build an application, all libraries of the used
+API packages get linked to the application and the single Qt5 API package with
+big libraries like QtWebEngine was a bit too much for simple Qt applications.
+For this reason, we split the Qt5 API into smaller packages according to the
+corresponding Qt modules.
+
+As preparation for the release of a binary version of the Qt5 host tools, we
+also reduced the external dependencies of these tools for improved
+compatibility with different host systems and changed their install location
+to the location of the other Genode host tools.
+
+And finally, we added a 'ubuntu-ui-toolkit' meta package in the genode-world
+repository which pulls in all dependencies for the Ubuntu UI toolkit,
+including a runtime with the required ROMs.
+
+
+WireGuard improvements
+======================
+
+There are two smaller changes related to Genode's port of WireGuard. First,
+peers can now be removed from WireGuard at runtime by removing the
+corresponding '' tags from the component's configuration. This operation
+enforces the same assurances as removing a peer from a native WireGuard driver
+in Linux.
+
+The second change has to do with the nature of the port. The WireGuard port is
+one of the rare examples where we use our Linux device driver environment
+(dde_linux) for porting software that is not exactly a driver. The component
+does not depend on a specific hardware configuration and therefore, the
+emulated Linux kernel can be platform-agnostic. Consequently, while porting,
+we created such a variant of the Linux emulation specifically for WireGuard.
+
+However, we realized that this variant can come in handy for ports of other
+hardware-agnostic kernel parts (for instance, lxip) as well. Therefore, we now
+cut it out of the WireGuard port in order to make it a self-contained version
+of the 'lx_emul' library. The new library is called 'virt_lx_emul' and is
+accompanied by the 'virt_linux' target that can be used to build the
+corresponding Linux kernel and run it in Qemu.
+
+
+Updated or removed 3rd-party software
+=====================================
+
+VirtualBox updated to version 6.1.44
+------------------------------------
+
+Our port of VirtualBox underwent some maintenance work published in this
+release. With the tool chain updated to GCC 12, it became necessary to update
+VirtualBox to version 6.1.44 to keep up with the tool-chain changes and fix
+many upstream bugs alongside. Also, we improved several aspects of the port to
+improve robustness of networking, USB, multi-threading, and VM reboot. After
+thorough testing in every-day scenarios, we finally adopted the handling of
+the x86 time-stamp counter from version 5 and disabled the VM exit for the
+RDTSC instruction, which improves the performance of selected scenarios
+significantly. For Windows guests, it has become crucial to configure the
+paravirtualization provider like follows in the _machine.vbox6_ file.
+Otherwise, the guest's TSC calibration fails resulting in a bogus CPU
+frequency assumption.
+
+!
+
+
+Removed ports of pcre16 and icu libraries
+-----------------------------------------
+
+The pcre16 and icu libraries had been used by Qt5 in the past but were not
+used anymore since the last Qt updates. So we removed them from the _libports_
+repository.
+
+
+Device drivers
+##############
+
+Linux device driver environment updated to Linux 6.1.20
+=======================================================
+
+According to [https://genode.org/about/road-map - our roadmap], the update of
+Genode's Linux device driver environment (DDE) to a more recent 6.x Linux
+version was planned for release 23.08. Now, we decided to tackle this update
+with this version already.
+
+Besides the Wireguard port to Genode, the following ported drivers use the
+latest Linux kernel 6.1.20 version now:
+
+* Zynq SD-card driver
+* PCI Wifi driver for i.MX 8MQ
+* all PC drivers (USB host, Wifi, Intel display)
+
+Note that a few drivers are not listed above. The existing drivers for the
+Allwinner and i.MX 8MQ SoC still use older 5.x Linux kernel versions as base.
+However, the Linux device driver environment has been tweaked carefully to
+support a range of Linux kernel versions from 5.11 till 6.1.20.
+
+While doing the update work, we investigated a more sustainable link between
+the Linux kernel drivers for USB and display drivers (DRM/KMS) on the one
+hand, and the Genode API on the other. The outcome is explained in the next
+two sections.
+
+
+Intel display driver
+====================
+
+During the update of DDE Linux to the Linux 6.1.20 version, the dependency on
+internal structures of the Intel framebuffer driver (intel_fbdev) became a
+hassle. Although the update was successful finally, we decided to remove the
+direct usage of intel_fbdev in our ported Intel display driver, in order to
+ease future updates. Nevertheless, the functionality of intel_fbdev is
+required to manage the framebuffer memory to provide a working Genode GUI
+interface by the driver. For that, we investigated the use of the
+[https://www.kernel.org/doc/html/v5.0/gpu/drm-kms.html - Linux DRM/KMS]
+interface, specifically to allocate and manage so called
+[https://www.kernel.org/doc/html/v5.0/gpu/drm-kms.html#dumb-buffer-objects - dumb buffer objects].
+As described in the linked article, the dumb buffers are a standardized and
+streamlined way to make early boot graphics possible driven by user-land
+tools. We adjusted our port along the ioctl's of the dumb buffer functionality
+to manage the framebuffer in our ported display driver.
+
+
+USB
+===
+
+Connecting different USB clients to a USB host controller driver is a delicate
+task. When using a port of a Linux kernel driver, it can quickly become
+brittle because the USB driver API in the Linux kernel is complex and contains
+some semantic dependencies, for instance regarding synchronization, which are
+not always obvious. However, the Linux kernel offers a USB device I/O API to
+the user-land that is used for instance by libusb. This API has to guard the
+USB subsystem against wrong usage, and implements the necessary semantics
+regarding synchronization and dynamic changes of clients and devices. In the
+past, we repeatedly encountered corner-case issues, if clients or devices
+vanished and appeared at a high rate. For the sake of robustness, we decided
+to redesign our internal linking in between the Genode USB API and Linux to
+use the user-level device I/O API of the latter. Moreover, we extended the
+capacity of USB packets in-flight that can be handled by the controller in
+parallel to 32, to enhance the throughput for some USB devices.
+
+
+NVMe storage
+============
+
+Our custom NVMe driver received the following improvements. First we added
+'host-memory-buffer' (HMB) support to the driver, which is a performance
+optimization for NVMe devices that do not make use of a DRAM cache for its
+operational data.
+
+The amount of memory used for the HMB can be set by adding the 'max_hmb_size'
+attribute in the '' node of the driver. This value is checked against
+the constraints imposed by the device. Should the value be less than the
+minimal required amount of memory, it will not be used and a warning is
+issued. On the other hand, if the specified value is larger than the preferred
+amount of memory as favored by the device, it will be capped to the useful
+amount instead.
+
+Naturally, when using the HMB, the required RAM quota of the driver component
+increases by that amount.
+
+Second, we fixed a problem detecting the block size (LBA format) of a given
+namespace. The lower 4 bits of the 'FLABS' register indicate which of the (up
+to) 16 supported LBA formats is used by the namespace. However, instead of
+only making use of those bits, the driver looked at the whole register that
+also includes other information. This led to using the wrong index for reading
+the LBA format and, on certain devices, rendered the driver unusable as the
+assumed block size was detected wrong.
+
+
+Audio-driver update
+===================
+
+We updated the audio driver for HDA devices ported from OpenBSD to version 7.3.
+The functional changes are minimal, but the new version supports more recent
+PC platforms and recognizes more codecs.
+
+
+Platforms
+#########
+
+Base-HW microkernel
+===================
+
+Principle x86 virtualization support (on Qemu)
+----------------------------------------------
+
+This release brings limited support for AMD's Secure Virtual Machine (SVM)
+vCPUs to Genode's custom base-hw microkernel. Supporting SVM is meant as an
+intermediate step towards enabling advanced virtualization workloads using
+VirtualBox on Intel VMX later this year. The approach allows us to craft the
+kernel's virtualization infrastructure using Qemu - which is able to emulate
+SVM in software - and cross-test our implementation against other hypervisors
+in a tightly controlled setting. For reference, we used the time-tested Qemu
+version 4.2 for this line of work.
+
+Implementing principle vCPU support revealed a few points of friction between
+base-hw's kernel interface, which had been designed for the needs of our
+custom ARM VMM, and our kernel-agnostic VM interface on x86 that has been
+carefully crafted to support a range of 3rd party hypervisors, but relies on
+more logic in the kernel-specific VMM library to manage the vCPU state.
+
+The current implementation is able to run several test VM workloads like the
+artificial 'vmm_x86' test, our seoul VMM run scripts with Linux, and - of
+course - Genode VMs on one vCPU. It has thereby reached an important stepping
+stone towards our actual goal of hosting VirtualBox on Intel hardware.
+
+Having shown that base-hw can support the generic x86 VM interface, we will
+mature our implementation and may adapt our interface to make it a better fit
+to base-hw's vCPU execution model in the future.
+
+
+Boot-time RAM detection on the PinePhone
+----------------------------------------
+
+For the PinePhone, we implemented dynamic detection of the system RAM size by
+parsing the values of the DRAM controller as programmed by U-Boot. This way, 2
+and 3 GB models of the PinePhone are supported by Genode.
+
+
+Updated seL4 microkernel
+========================
+
+With this release, we updated the support of the seL4 kernel from 9.0.1 to
+12.1.0 for i.MX6 Sabrelite board and x86_64 PC. The support for 32-bit PC got
+removed since it is unused, and the i.MX7 Sabrelite support got removed since
+it is not supported by the new seL4 kernel anymore.
+
+The updated seL4 kernel requires additional host tools installed, namely
+CMake, Ninja and additional Python3 modules, jinja2, jschonschema, and pyfdt.
+Depending on the distribution, the modules are available as distribution
+package or need to be installed with the python pip3 tool.
diff --git a/doc/release_notes/23-08.txt b/doc/release_notes/23-08.txt
new file mode 100644
index 0000000000..a88c3baa83
--- /dev/null
+++ b/doc/release_notes/23-08.txt
@@ -0,0 +1,786 @@
+
+
+ ===============================================
+ Release notes for the Genode OS Framework 23.08
+ ===============================================
+
+ Genode Labs
+
+
+
+The headline features of Genode 23.08 are concerned with developer tooling.
+First, we re-approached Genode's GDB debugging support with the grand vision
+of easy on-target debugging directly on Sculpt OS. Our new debug monitor
+introduced in Section [Multi-component debug monitor] combines the GDB
+protocol with Genode's init component. Thereby, the monitor can transparently
+be integrated in Genode subsystems and can be used to debug multiple
+components simultaneously.
+
+Second, the Goa tool, which started as an experiment in 2019, has been shaped
+into an all-encompassing alternative to Genode's traditional work flows for
+developing, porting, and publishing applications. The tool got vastly more
+flexible with respect to runtime testing, and even became able to handle
+dependencies between Goa projects. The massive improvements are covered in
+Section [Goa tool gets usability improvements and depot-index publishing support].
+
+Besides the headline features of the release, we admittedly deviated from the
+original plans laid out on our [http:/about/road-map - road map]. Early-on in
+the release cycle, we found ourselves drawn to code modernization, the
+retiring of legacies, and quality assurance. E.g., we finally updated some of
+the most veteran internals of the framework to our modern-day coding
+practices, we urged to continue the success story of our new Linux
+device-driver environment (DDE) by replacing old USB drivers by new components
+leveraging the modern approach, and created a new DDE-Linux-based NIC driver
+for PC hardware while retiring the aged iPXE-based traditional driver. The
+outcome of this tireless work may hardly be visible from a feature perspective.
+But it greatly improves the velocity and quality of the code to maintain down
+the road.
+
+It goes without saying that the other topics of the road map haven't been
+disregarded. In fact we celebrated a break-through with x86 virtualization
+on our base-hw kernel, are diving deep into the latest Intel platforms, and
+working on the user-visible side of the mobile version of Sculpt OS. But since
+those topics are not wrapped up yet, we all have to stay tuned for the next
+release.
+
+
+Multi-component debug monitor
+#############################
+
+The debugging of Genode components using the GNU debugger (GDB) was already
+an anticipated feature when we introduced the first version of the GDB monitor
+component in version
+[https://genode.org/documentation/release-notes/11.05#GDB_monitor_experiment - 11.05]
+and refined it in the subsequent releases
+[https://genode.org/documentation/release-notes/12.02#GDB_monitor_refinements_and_automated_test - 12.02],
+[https://genode.org/documentation/release-notes/13.11#GNU_Debugger - 13.11] (on-target GDB), and
+[https://genode.org/documentation/release-notes/16.05#Enhanced_GDB_support_on_NOVA - 16.05] (supporting NOVA).
+Despite these efforts, the feature remained rarely used in practice.
+In most situations, manual instrumentation with debug messages or the use
+of GDB with the Linux version of Genode remain to be the instruments of choice.
+Driven by the vision of easy on-target debugging on Sculpt OS, we identified
+the following limitations of the existing GDB monitor that stand in the way.
+
+# The GDB monitor supports only one component as debugging target, which makes
+ the debugging of scenarios where components closely interact difficult.
+
+# The existing implementation re-uses the gdbserver code and thereby inherits
+ many POSIX peculiarities that must be stubbed for Genode, yet make the
+ overall implementation complex. Genode is not POSIX after all.
+
+# The integration of the GDB monitor into an existing scenario is a fairly
+ invasive change that requires too much work.
+
+Given these limitations as a backdrop, two key ideas motivated a new approach
+for the revision of Genode's GDB support for this release:
+
+First, by using Genode's sandbox API as foundation for a new debug monitor,
+we would become able to use the monitor as drop-in replacement for 'init',
+potentially going as far as using the monitor for Sculpt's runtime subsystem.
+Wouldn't that approach vastly simplify the integration issue (3)?
+Second, GDB supports the debugging of multiple processes (called inferiors)
+within one session, which would in principle allow us to inspect and debug
+component compositions, addressing the first limitation.
+And third, the casual review of the documentation of the GDB protocol left
+the impression that a Genode-tailored implementation shouldn't be that
+complicated.
+
+The result of these ideas is the new *monitor* component at _os/src/monitor_
+as the designated successor of the traditional gdb_monitor. By leveraging the
+sandbox API, it can be used as a drop-in replacement for the init component
+and monitor multiple components. In real-world scenarios like Sculpt's
+runtime, we deliberately want/need to restrict the debugging to a few selected
+components, however, which calls for the support of a mix of monitored and
+regular components hosted side by side. Given this requirement, the sandbox
+API had to be enhanced to support the selective interception of PD and CPU
+sessions.
+
+Like the original gdb_monitor, the new monitor speaks the GDB remote serial
+protocol over Genode's terminal session. But the protocol implementation does
+not re-use any gdbserver code, sidestepping the complexities of POSIX.
+The monitor supports the essential GDB remote protocol commands for reading
+and writing of memory and registers, for stopping and resuming of threads
+including single-stepping, and it reports the occurrence of page faults and
+exceptions to GDB. Breakpoints are managed by GDB using software breakpoint
+instructions. The GDB protocol is operated in GDB's 'non-stop' mode, which
+means that threads of multiple inferiors can be stopped and resumed
+individually or in groups, depending on the GDB commands issued by the user.
+
+As of now, the monitor supports NOVA on 64-bit x86 as well as Genode's custom
+base-hw kernel on 64-bit ARM and x86. The 64-bit ARM support required a change
+in Genode's customized GDB port to enable shared-library support for this
+architecture. So in order to use Genode's host GDB with the monitor on 64-bit
+ARM, the Genode tool chain needs to be rebuilt with the _tool/tool_chain_
+script.
+
+There exist three run scripts illustrating the new component. The
+_os/run/monitor.run_ script exercises memory inspection via the 'm' command
+and memory modification via the 'M' command by letting a test program monitor
+itself. The _os/run/monitor_gdb.run_ script performs automated tests of various
+GDB commands and the _os/run/monitor_gdb_interactive.run_ script allows for the
+interactive use of GDB to interact with monitored components.
+
+Details about the configuration of the monitor component are given by the
+README file at the _os/src/monitor/_ directory.
+
+
+Goa tool gets usability improvements and depot-index publishing support
+#######################################################################
+
+Moving the Goa tool under the umbrella of Genode Labs in the previous release
+unleashed a wave of substantial improvements.
+
+Most significantly, we were able to integrate support for depot-index projects
+into Goa (Section [Support of index projects]). This greatly simplifies the
+publishing of user-specific Goa projects for the upcoming Sculpt release.
+
+One of the game-changing features of Goa is its ability to easily test-run
+applications on the host system leveraging Genode's ABI compatibility between
+different kernels. However, in various instances, we still required customized
+runtime scenarios in order to render an application runnable by Goa. With this
+release, we further streamlined Goa's base-linux runtime with Sculpt OS
+(Section [Run-stage generalization]).
+
+Apart from these major changes, the lately added shared-library support and
+Rust support have seen practical improvements.
+
+
+Support of index projects
+=========================
+
+With an increasing number of Genode applications being developed with Goa,
+being able to manage and publish a personal depot index with Goa became due.
+In the past, we needed to build, export, and publish each individual Goa
+project and manually add it to the depot index in order to make it available
+for a particular Sculpt release.
+
+For this purpose, we added support for index projects to Goa. An index project
+is defined by an 'index' file. This file follows the structure of a depot index
+but only names the archive names (lacking depot user and version). The
+'goa export' command augments these names with the current depot user and
+version information. By running 'goa publish', the result is published as a
+depot index for the current Sculpt version.
+
+As Goa supports a hierarchical project structure, an index project may
+contain subdirectories with other Goa projects that provide the corresponding
+pkg archives. The 'goa export' command issued within such an index project
+recursively scans the working directory for any Goa project providing the
+required depot archives or any of their dependencies, and exports these
+subprojects as well.
+
+To make working with index projects an even more joyful experience, we changed
+the way Goa looks up version information. Goa used to expect the current
+version of each required depot archive to be specified in a goarc file. For
+each Goa project, however, a 'version' file may be used to specify the current
+version. This file was only evaluated on export of the particular project.
+With this release, Goa now scans the working directory for Goa subprojects in
+order to look up their 'version' file. This spares us keeping the 'version'
+files and goarc files in sync. The new 'bump-version' command adds another
+level of convenience as it automatically updates the 'version' file of a Goa
+project. In combination with the '-r' switch, we are now able to update the
+version information of all subprojects with a single command.
+
+An example of an index project is found at _examples/index_ in the Goa
+repository.
+
+:Goa tool:
+
+ [https://github.com/genodelabs/goa/]
+
+
+Run-stage generalization
+========================
+
+In addition to building, exporting, and publishing of depot archives, Goa
+supports test-running an application project directly on the development
+system by utilizing base-linux. Similarly to how Goa modularized the build
+stage to support various build systems, we generalized the run stage to pave
+the way for other targets than base-linux. The interface of the generalized
+run stage and the current feature set of the linux target is documented by
+'goa help targets'.
+
+In the course of generalizing the run stage, we introduced various plausibility
+checks to further accelerate application development. For instance, we check
+for typos in required and provided services of a runtime, and verify the
+availability of required ROM modules.
+
+Furthermore, the linux target underwent a major revision to streamline the
+application development for Sculpt OS.
+
+* Scenarios using a terminal component require a fonts file system.
+ In Sculpt OS, this is typically provided by instantiating a fonts_fs
+ component. Doing the same in Goa lifts the need to wrap Goa-managed
+ Sculpt packages in a separate test project.
+
+* A route for the mesa_gpu_drv.lib.so ROM module was implicitly added when
+ a Gpu was required. For consistency with existing packages, we now require
+ the runtime file to mention the mesa_gpu_drv.lib.so ROM explicitly.
+
+* For NIC requirements, we used to take the label as the tap-device name to
+ which the NIC driver was bound. Since the 'label' attribute might be
+ evaluated differently by Sculpt OS, we introduced the 'tap_name' attribute
+ instead. For each distinct tap device, we now instantiate a pair of NIC
+ driver and NIC router. Each router uses a distinct subnet for its default
+ domain, starting at 10.0.10.0/24 and ending at 10.0.255.0/24.
+
+* The clipboard ROM and Report requirements are now routed to a report_rom
+ component.
+
+* Arbitrary ROM requirements are routed to an lx_fs component that provides
+ the files found in the project's _var/rom_ directory as individual ROM
+ modules. An example resides in _examples/external_rom_. Thanks to Pirmin
+ Duss for this useful contribution.
+
+* Remaining service requirements that are not handled otherwise will be routed
+ to a black-hole component.
+
+
+Improved support for building shared libraries
+==============================================
+
+Since release 23.02, we are able to
+[https://genode.org/documentation/release-notes/23.02#Building_and_packaging_CMake-based_shared_libraries__via_Goa_ - build CMake-based shared libraries in Goa].
+In this release, this feature has seen a few improvements:
+
+* If available, Goa now calls 'make install' during build in order to install
+ artifacts into _/install_. For libraries, this typically also
+ installs include files into this directory. Having all include files in the
+ build directory is a prerequisite for extracting these as api artifacts
+ (see 'goa help api').
+
+* We added support for publishing api archives.
+
+* 'goa export' now respects the 'common_var_dir' configuration variable and
+ '--common-var-dir' command-line option when exporting api archives.
+
+* We fixed an issue that resulted in large binaries when building shared
+ libraries with Goa.
+
+
+Quality assurance and usability tweaks
+======================================
+
+Increasing our development efforts for the Goa tool demands means to catch
+regressions early on. For this purpose, we added a basic testing facility,
+which validates that our examples still work as expected. Note that we are
+going to address automated testing for arbitrary Goa projects at some point in
+the future.
+
+With this release, we changed the name of the '.goarc' files to 'goarc'. The
+original intention of these files was to allow user-specific settings
+analogously to, e.g., '.bashrc'. However, these files may contain arbitrary Tcl
+code, thus having various '.goarc' files checked into git repositories, made
+things a little bit too obscure because those files are hidden. When a user
+clones a Git repo and invokes Goa commands, this code gets executed. Hence, it
+is only fair to bring this code to the user's attention by not hiding it.
+
+In addition to all the aforementioned major changes, we added a couple of minor
+usability tweaks:
+
+* We added 'goa help import' in order to document the syntax of the 'import'
+ file.
+
+* We added the 'goa depot-dir' command that allows initializing a custom depot
+ directory with the default depot users.
+
+* We added a 'goa run-dir' command that prepares the run directory without
+ actually running the scenario. This is helpful when the run time of 'goa run'
+ is automatically evaluated by external scripts since 'goa run-dir' may take a
+ while downloading the required depot archives.
+
+* We added the 'run_as' configuration variable and '--run-as' command-line
+ option. This allows changing the depot user from which 'goa run' downloads
+ the required archives. See 'goa help config' for more details.
+
+
+Support for the mainline Rust toolchain
+=======================================
+
+When we reintroduced Rust on Genode in the
+[https://genode.org/documentation/release-notes/23.05#Initial_Rust_support - previous]
+release, our implementation relied on a slightly adapted Rust toolchain to
+work around missing support for versioned library symbols in our linker. With
+this release, we are now able to use the mainline 'x86_64-unknown-freebsd'
+target provided by Rust project, eliminating the need for a custom toolchain.
+
+On top of the streamlined Rust support, we created a Goa package for a popular
+Rust command-line application, which will be published along with updated
+system packages in the upcoming Sculpt release.
+
+For details on the mainline Rust toolchain support and the ported package,
+take a look at the dedicated
+[https://genodians.org/atopia/2023-08-24-enabling-the-upstream-rust-toolchain - blog post on Genodians.org].
+
+
+Base framework and OS-level infrastructure
+##########################################
+
+Internal core and base-framework modernization
+==============================================
+
+Genode's API received multiple rounds of modernization in the past years. But
+some of the framework's deepest internals remained largely unchanged over that
+time. Even though one can argue that mature and battle-tested code should
+better not be disrupted, our programming practices are not carved in stone.
+To make Genode's internal code a delight for reviewers, auditors, and future
+maintainers, we revisited the following areas.
+
+Core's page-fault resolution code got reworked for improved clarity and
+safety, by introducing dedicated result types, reducing the use of basic
+types, choosing expressive names, and fostering constness. Along the way, we
+introduced a number of 'print' hooks that greatly ease manual instrumentation
+and streamlines diagnostic messages printed by core. Those messages no longer
+appear when a user-level page-fault handler is registered for the faulted-at
+region map. So the monitor component produces less noise on the attempt to
+dump non-existing memory.
+
+Closely related to the page-fault handling, we tightened the distinction
+between rx and rwx inside core by restricting 'Region_map::attach_executable'
+to create read-only mappings, while offering the option to map the full rights
+using a new 'attach_rwx' method. The 'attach_rwx' method is now used by the
+dynamic linker to explicitly attach the linker area with full rwx rights. With
+the old page-fault handling code, the execute flag was evaluated only for leaf
+dataspaces, not for managed dataspaces while traversing region-map
+hierarchies. With the new page-fault handling code, the execute bit is
+downgraded to no-execute when passing a managed dataspace that is not attached
+as executable.
+
+We ultimately removed the last traces of the global 'env_deprecated()'
+interface that was still relied-on within core and parts of the base library.
+Nowadays, we no longer use global accessors but generally employ
+dependency-injection patterns. Since the 'env_deprecated()' interface is
+closely related to initialization code, the startup code of core and regular
+components got largely refactored, eliminating the reliance on global side
+effects. As a collateral change, the legacy 'main' support for native Genode
+component as well as the now-obsolete 'Entrypoint::schedule_suspend' mechanism
+got removed.
+
+
+API changes
+===========
+
+Register framework update
+-------------------------
+
+The register framework has been updated to ease its use with '-Wconversion'
+warnings enabled, which is the default for Genode components.
+When reading from a bitfield, the new version returns the value in the
+smallest possible integer type, not the register-access type. This way,
+the user of the bitfield value can use appropriate types without the need for
+casting. The update also replaces 'bool' access types with 'uint8_t' access
+types.
+
+Thanks to this change, the net lib - used by Genode's low-level network
+routing components for parsing protocol headers via the register API - has
+been made compliant to strict conversion warnings.
+
+
+Hex-dump utility
+----------------
+
+To aid the monitoring, implementation, and debugging of binary protocols, a
+handy hex-dump utility got added to _util/formatted_output.h_. The new
+'Genode::Hex_dump' class can be used to print a hexadecimal dump of a byte
+range. The data is printed in a format similar to that used by the 'xxd'
+utility. In addition to the 'xxd' format, consecutive duplicate lines are
+replaced with a single "*\n".
+
+
+Libraries and applications
+##########################
+
+New NIC server for raw uplink connectivity
+==========================================
+
+With Genode
+[https://genode.org/documentation/release-notes/21.02#Pluggable_network_device_drivers - 21.02],
+we transitioned all network device drivers to act as session clients in order
+to make them pluggable. We achieved this by introducing a new _uplink_ service
+interface that is very similar to the NIC service but with the peer roles
+switched. Up to now, the only uplink server and uplink-to-NIC adapter was the
+NIC router. This is reasonable as it is the standard network multiplexer in
+Genode and therefore normally sits in front of each network device driver
+anyway. However, there is one major issue with this approach: It binds
+physical network access to layer 3 and 4 routing respectively layer 2
+multiplexing, which, in our case, means that NIC clients can talk to the
+physical network only with what is protocol-wise supported by the NIC router.
+
+That's why Genode 23.08 introduces the new NIC-uplink adapter component. It
+re-enables raw access to physical networks in Genode by forwarding packets
+unmodified and unfiltered between multiple NIC sessions and one uplink
+session. The new component is accompanied by a test script _nic_uplink.run_
+that demonstrates the low-level integration and a Sculpt package _pkg/pc_nic_
+that can be used for deployment in more sophisticated systems together with
+the PC NIC-driver as back end.
+
+One constellation, in which the NIC-uplink server will be especially useful for
+us is the planned enablement of IPv6 on different layers of Genode's network
+stack. More specifically, the tool will allow us to work at IPv6 support in
+both Genode's ported TCP/IP stacks and the NIC router at the same time.
+
+
+New depot-remove component
+==========================
+
+_The work described in this section was contributed by Alice Domage._
+_Thanks for this welcome addition._
+
+Genode's on-target package management allows for the installation of multiple
+versions of the same package side by side, which is useful to roll back the
+system to an earlier state, or to accommodate software depending on an older
+library version. Software is installed into the so-called _depot_ stored on
+the target and populated with downloads on demand. Until now, however, the
+on-target depot could only grow, not shrink. Even though this limitation
+hasn't been a pressing concern for Sculpt OS on the PC, it impeded embedded
+use cases.
+
+The new depot-remove component lifts this limitation by providing an orderly
+way to remove depot content and orphaned dependencies. It operates by reading
+its configuration and processes delete operations based on the provided rules.
+A typical configuration looks as follows.
+
+!
+!
+!
+!
+!
+!
+!
+
+For more details about the configuration options, please refer to the README
+file at _/gems/src/app/depot_remove/_. Furthermore, the
+_gems/run/depot_remove.run_ script illustrates the component by exercising
+several practical use cases.
+
+
+DDE-Linux changes
+=================
+
+With this release, we changed how external events are treated within the
+Linux emulation environment.
+
+Whenever an external event occurred, for example timer or interrupt, the
+corresponding I/O signal handler was triggered. This handler unblocked the
+task waiting for the event and also initiated the immediate execution of all
+unblocked tasks. This, however, could lead to nested execution because these
+tasks might hit serialization points, e.g., synchronously waiting for packet
+stream operations, that under the hood also require handling of other I/O
+signals. Such an execution model is not supported and confusing as it mixes
+application and I/O level signal handling.
+
+So the flagging of the scheduling intent is now decoupled from its execution by
+using an application-level signal handler that is run in the context of the
+component's main entrypoint. The I/O signal handler now triggers the scheduling
+execution by sending a local signal to the EP and only flags the occurrence
+of the external event by unblocking the corresponding task.
+In this context, we reworked the interrupt handling itself. Previously all
+interrupts were immediately processed in the I/O signal handler and only the
+currently pending one was handled. Due to the decoupling change the occurrence
+of interrupts becomes merely flagging a state and requires recording all
+interrupts and dispatch them consecutively in one go.
+
+To facilitate this convention, the Lx_kit initialization function got extended,
+and it is now necessary to pass in a signal handler that is used to perform the
+normally occurring scheduler execution. As this signal handler is part of
+the main object of the DDE-Linux based component it is the natural place to
+perform any additional steps that are required by the component before or after
+executing the scheduler.
+
+As it is sometimes necessary to execute a pending schedule from the EP directly,
+in case the scheduler is called from within an RPC function, the scheduler is
+extended with the 'execute' member function that performs the check that the
+scheduler is called from within the EP and triggers the execution afterwards.
+
+
+Tresor block encryptor
+======================
+
+Following the introduction of the tresor library in the
+[https://genode.org/documentation/release-notes/23.05#Revision_of_Genode_s_custom_block-encryption_infrastructure - previous]
+release, we further polished the tresor tester in order to make it run on a
+broad spectrum of target platforms. For instance, the test can now be run
+without entropy input (permanently warning the user about the security risk)
+because some of our test hardware lacks support for it. Besides that, we
+mainly worked at the resource consumption of the test - made it more adaptable
+or reduced it through improvements. This pleased not only less powerful
+hardware but our test management as well.
+
+Furthermore, we fixed a significant former deficiency with the tresor library.
+The library used to work on the raw on-disc data without decoding first. This
+worked fine for some platforms but caused alignment faults on others. That
+said, the tresor library now always decodes into naturally typed and aligned
+C++ structs before accessing the data.
+
+
+Device drivers
+##############
+
+Intel GPU
+=========
+
+The handling of GPUs is somewhat special within the driver world. A GPU is a
+standalone execution unit that can be programmed much like a CPU. In the past,
+there were fixed function GPUs, which have been gradually replaced by
+dynamically programmable units that execute compiled machine code (think
+shader compilers like GLSL or general purpose computing like CUDA or OpenCL).
+This leads to a situation where a GPU driver cannot trust the client that
+sends its machine code to be executed by the GPU. There exists no sufficient
+way of inspecting the compiled machine code for malicious behavior by the GPU
+driver. Therefore, the only reasonable solution for a GPU driver is to send
+the code to the GPU and hope for the best. In case the code execution is not
+successful, GPUs tend to just hang and the only thing a driver can do is to
+make sure via an IOMMU that the code does not access arbitrary memory and
+program a watchdog timer and reset the GPU to a graceful state in case there
+is no proper response. With the current Genode release, we have implemented
+this behavior for GEN9 (HD graphics) and GEN12 (Intel Iris Xe).
+
+
+Intel display
+=============
+
+The ported Linux Intel display driver now supports USB Type-C connectors as
+used with modern notebooks.
+
+
+New PC network driver based on DDE-Linux
+========================================
+
+Since 2010, we use Ethernet drivers ported from the iPXE project in a tiny
+emulation layer on Genode. While those drivers did a good job for the common
+cases, they always had some rough edges that may not hurt in the original
+network-booting use case but had become a nuisance in Sculpt OS and Genode
+in general. Most prominently the dropped link speed with Intel E1000e cards
+on cable unplug/plug and the moderate throughput on GBit links had to be
+addressed.
+
+Our new DDE Linux approach introduced this year makes the porting of drivers
+from the Linux kernel much easier and less labour-intensive as in the past.
+Also, Linux is a very tempting Ethernet driver donor because of the variety
+of supported devices and the well known excellent performance (especially on
+Intel devices). Moreover, the Intel E1000e driver addresses all issues we
+had with the iPXE implementation and promises a smooth interplay with Intel
+AMT/ME. Note, Intel AMT Serial-over-LAN is still an important debug console
+while deploying Genode on Intel-based notebooks.
+
+Hence, the current release brings the new _pc_nic_drv_ for Intel e1000/e1000e,
+Realtek 8169, and AMD PCnet32 (Qemu) devices on PC and is fully integrated
+into Sculpt OS. Performance-wise the driver easily saturates 1 GBit links in
+our throughput tests.
+
+
+USB host controller
+===================
+
+The USB host controller driver ports for Raspberry Pi 1 and i.MX 6 Quad got
+updated to Linux kernel version 6.1.37 resp. 6.1.20. Both driver ports share
+the renewed device-driver environment approach for Linux introduced in release
+[https://genode.org/documentation/release-notes/21.08#Linux-device-driver_environment_re-imagined - 21.08].
+
+Besides the update of the last remaining outdated USB host controller drivers,
+we have reworked the common C/C++ Linux-to-Genode USB back end used by all USB
+host controller driver incarnations. The internal changes were necessary to
+address issues regarding races during USB session close attempts, resets of
+USB endpoints, and potential stalls during synchronous USB RPC calls.
+
+
+PC audio refinements
+====================
+
+In this release, we simplified the memory allocator in the OpenBSD-based
+audio-driver component and thereby decreased its memory usage. The memory
+subsystem implementation was initially brought over from DDE Linux and is
+geared towards use cases where a high-performing allocator is desired. For the
+audio driver with its clear memory usage pattern, such an allocator is not
+necessary and since no other driver that could benefit from it was ported in
+the meantime, we opted for replacing the implementation with a simpler one
+with less overhead.
+
+We also adapted the mixer state report mechanism to always generate a new
+report on head-phone jack sense events.
+
+Furthermore, we decreased the internal buffer size to implicitly limit the
+number of blocks provisioned for recording that brings them in line with the
+number of blocks used for playback (2).
+
+
+Wifi
+====
+
+With the [DDE-Linux changes] in place, we had to adapt the initialization
+procedure in the wireless LAN driver since it behaves differently to all other
+DDE-Linux-based driver components. The driver is actually a 'Libc::Component'
+due to its incorporation of the 'wpa_spplicant' application and the driver
+itself is confined to its own shared-object to better separate the Linux code.
+
+Since we implement the Linux initcalls as static constructors, we have to
+initialize the Lx_kit before those are executed. This is normally not a
+problem because they are executed manually from within the drivers main object
+on construction. However, in a 'Libc::Component' this happens before our main
+object is constructed. In the past, we used a VFS plugin to perform the
+initialization - as the VFS is also constructed beforehand - but this is no
+longer possible as the driver's main signal handler that now dispatches the
+Lx_kit event signals is not available at this point.
+
+We decided therefore to perform a multi-staged boot-up process where the
+component is now implemented as regular 'Genode::Component' that triggers the
+'Libc::Component' construction manually after performing the Lx_kit
+initialization. This change enabled us to remove the VFS 'wifi' plugin that no
+longer has to be specified in the VFS configuration.
+
+Furthermore, we removed the handcrafted MAC address reporter in favor of the
+Genode C API utility that was recently made available.
+
+
+PinePhone support for buttons and screensaver
+=============================================
+
+To equip the mobile version of Sculpt OS on the PinePhone with a proper
+screensaver, we added drivers for detecting user interactions with the
+PinePhone's physical buttons, namely the volume buttons and the power button.
+
+The volume buttons are connected via cascaded resistors to a single ADC of the
+A64 SoC. The corresponding driver has been added to the genode-allwinner
+repository at _src/drivers/button/pinephone/_ and is accompanied by the
+_button_pinephone.run_ script. It reports KEY_VOLUMEUP and KEY_VOLUMEDOWN
+input events to an event session.
+
+Sensing the power button has been a slightly more delicate issue because the
+power button is connected to the power-management IC (PMIC), which shall only
+be accessed via the system-control processor (SCP). To detect state changes,
+the PMIC's IRQ (routed through the R_INTC to the GIC) is now handled by the
+power driver. This has the added benefit that also other interesting PMIC
+events (like connecting AC) get immediately reported.
+
+With the button drivers in place, we finally equipped Sculpt OS with a
+screensaver as a crucial battery-conserving feature. The screensaver kicks in
+after the user remained inactive in the administrative user interface for some
+time. It also can be manually activated by pressing the power button. While
+the screen is blanked, a press of the power button enables the display again.
+
+Under the hood, Sculpt completely removes the drivers for the display and the
+touchscreen while the screen is blanked, which considerably reduces the power
+draw. The system also switches the CPU to economic mode while the screen is
+blanked. Here are some illustrative data points:
+
+! Max brightness in performance mode: 2.8 W
+! Max brightness in economic mode: 2.6 W
+! Low brightness in economic mode: 1.7 W
+! Screensaver: 1.1 W
+
+You can find the screensaver feature integrated in the latest mobile Sculpt OS
+images published by _nfeske_.
+
+
+Platforms
+#########
+
+NXP i.MX SoC family
+===================
+
+Certain parts of i.MX specific code, like the base support for the hw kernel,
+and the GPIO driver for i.MX got moved from Genode's main repository to the
+corresponding genode-imx repository.
+
+Sculpt OS image creation for MNT Reform2
+----------------------------------------
+
+With this release, we introduce mainline support for Sculpt OS on the MNT
+Reform2. To build a Sculpt OS image for this board you can use the common
+_gems/run/sculpt_image.run_ script, like the following:
+
+! make run/sculpt_image KERNEL=hw BOARD=mnt_reform2 DEPOT=omit
+
+To be effective, you need to extend your RUN_OPT variable accordingly:
+
+! RUN_OPT += --include image/imx8mq_mmc
+
+
+seL4 microkernel
+================
+
+With the update of the seL4 kernel in the
+[https://genode.org/documentation/release-notes/23.05#Updated_seL4_microkernel - previous]
+release we now added several improvements, which reduce the boot-up time of
+Genode's 'core' roottask on seL4 by converting untyped memory to I/O memory on
+demand.
+
+
+Build system and tools
+######################
+
+Depot autopilot on-target test orchestrator
+===========================================
+
+As the rough plan to support automated testing in Goa is shaping up, it makes
+sense to share one convention about expressing the success criteria for a
+package under test between the depot autopilot and Goa. This prospect motivated
+us to review the convention that was used with the depot autopilot up until
+now. The old syntax looked as follows:
+
+!
+!
+!
+!
+! [init -> rom_logger] ROM 'generated':*
+! [init -> dynamic_rom] xray: change (finished)
+!
+! child exited
+! Error:
+!
+! ...
+!
+
+We applied the following simplifications to this syntax:
+* Dropped the intermediate '' tag,
+* Replaced '' by '',
+* Replaced '' by '',
+* Replaced '' by an 'after_seconds'
+ attribute of the '' or '' tags.
+
+So, the above example becomes the following:
+!
+!
+!
+! [init -> rom_logger] ROM 'generated':*
+! [init -> dynamic_rom] xray: change (finished)
+!
+! child exited
+! Error:
+! ...
+!
+
+For now, the depot autopilot maintains backwards-compatibility to allow Genode
+users to adapt to the change progressively. The old scheme is used whenever
+the package runtime contains an '' tag. Note that backwards
+compatibility will be removed after a short transition period.
+All test packages of the official Genode repositories have been updated
+to the new convention.
+
+Furthermore, we took the opportunity to also add a new feature. The optional
+'log_prefix' attribute in the '' and '' tags is a simple but
+handy white-list filter when it comes to typical Genode logs. When matching
+the test log against the pattern given in the affected '' or ''
+tag, the depot autopilot considers only those log lines that start with the
+given prefix. This is an easy way to watch only specific Genode components and
+solve problems with the log order of simultaneously running components.
+
+Last but not least, the transition prompted us to fix a minor issue with the
+depot autopilot log-processing. Color sequences will now be forwarded correctly
+from the test runtime to the log output of the depot autopilot, making the
+analysis of test batteries a more pleasant experience.
+
+
+Updated run-tool defaults for x86_64
+====================================
+
+With the update of the seL4 kernel and the update of the toolchain to GNU GCC
+12 in the previous release, certain x86 assembly instructions like POPCNT are
+generated, which are not supported by the Qemu CPU models we used.
+Previously, the used CPU model was either the default model, or
+'-cpu core2duo' for NOVA, or '-cpu phenom' for SVM virtualization.
+The current release changes the default model to '-cpu Nehalem-v2', and
+selects '-cpu EPYC' for SVM virtualization.
+
+Note that the _build.conf_ file in the x86 build directory must be
+re-generated by you, which otherwise may contain an older Qemu "-cpu " model,
+which can collide with the new default Qemu CPU settings.
diff --git a/doc/release_notes/23-11.txt b/doc/release_notes/23-11.txt
new file mode 100644
index 0000000000..8ff6003b64
--- /dev/null
+++ b/doc/release_notes/23-11.txt
@@ -0,0 +1,799 @@
+
+
+ ===============================================
+ Release notes for the Genode OS Framework 23.11
+ ===============================================
+
+ Genode Labs
+
+
+
+Genode 23.11 brings a healthy mix of OS architectural work, curation of the
+existing framework, and new features. In an arguably radical move - but in
+perfect alignment with microkernel philosophy - we move the IOMMU driver from
+the kernel to user space. This way, Genode attains DMA protection independent
+of the used kernel. Section [Kernel-agnostic DMA protection] covers the
+background and implementation of this novel approach.
+
+We constantly re-evaluate our existing code base for opportunities of curation
+and simplification and the current release is no exception. It bears the fruit
+of an intense one-year cross-examination of Genode's existing virtualization
+interfaces across CPU architectures and kernels, as a collateral effort of
+bringing x86 virtualization to our custom base-hw microkernel. Section
+[Modernized virtualization interface] presents the story and outcome of this
+deep dive.
+
+As another curation effort, the release brings Genode's arsenal of USB device
+drivers in line with our modern DDE Linux porting approach.
+Section [USB device drivers updated to Linux 6.1.20] details this line of work.
+
+Feature-wise, the release contains the underpinnings of the CPU
+frequency/temperature/power monitoring and control feature of the latest
+Sculpt OS release
+(Section [PC power, frequency, temperature sensing and control]),
+showcases the port of the Linphone VoIP stack using the Goa tool
+(Section [Ported 3rd-party software]), and equips the Seoul virtual machine
+monitor with the ability to host 64-bit guests
+(Section [Seoul virtual machine monitor]).
+
+
+Kernel-agnostic DMA protection
+##############################
+
+On our quest towards a PC version of Sculpt OS on our custom (base-hw)
+microkernel, we were able to move an essential chunk away to clear another
+section of the path. Based on the preparatory changes to the platform driver
+regarding IOMMU handling introduced in
+[https://genode.org/documentation/release-notes/23.05#Towards_kernel-agnostic_DMA_protection - release 23.05],
+we were able to enable kernel-agnostic DMA protection on Intel platforms.
+
+Similar to how the MMU protects the system against unintended CPU-initiated
+memory transactions, the IOMMU protects the system against unintended DMA
+transactions. Since components allocate DMA buffers via the platform driver,
+the latter sits in the perfect spot to manage DMA remapping tables for its
+clients and let the IOMMU know about them.
+
+[image dma_remap]
+
+The figure above illustrates how we added remapping to the PC version of
+Sculpt OS. IOMMUs are announced in the ACPI DMAR table, which is parsed by our
+ACPI driver component.
+It particularly evaluates the _DMA Remapping Hardware Unit Defintions_ (DRHDs)
+and _Reserved Memory Region Reporting_ (RMRRs) structures and reports the
+essential details in form of an _acpi_ report. There are typically multiple
+DRHDs with different device scopes. The RMRRs specify memory regions that may
+be DMA targets for certain devices.
+
+The _acpi_ report is used by our PCI decode component, which creates a
+_devices_ report. It adds the DRHDs as devices to this report and annotates
+the found PCI devices with corresponding '' nodes
+according to the DRHDs' device scopes. Moreover, it adds
+'' nodes to the particular devices as specified by the
+RMRRs.
+
+By evaluating the _devices_ report, the platform driver has a complete picture
+of the DMA remapping hardware units and knows about which PCI devices fall
+into their scopes. It takes control over the mentioned _drhdX_ devices on its
+own and sets up the necessary structures that are shared between all sessions
+and devices. For every Platform session and _drhdX_ device used, it creates an
+'Io_mmu::Domain' object that comprises a DMA remapping table. As shown in the
+figure, Client A, which acquires devices in the scope of drhd0 and drhd1, the
+platform driver sets up two DMA remapping tables. The tables are populated with
+the DMA buffers allocated via Client A's platform session. For every acquired
+device, the platform driver maps the corresponding remapping table. Note that
+DMA buffers are allocated on a per-session basis so that all devices in the
+same session will get access to all DMA buffers. To further restrict this,
+Client A could open separate platform sessions for distinct DMA-capable
+devices.
+
+A subtle implementation detail (not shown in the figure) concerns the
+aforementioned reserved memory. The reserved memory regions of a device must
+be added to the corresponding DMA remapping table. Moreover, these regions
+must be accessible at all times, i.e. even before the device is acquired by
+any client. For this purpose, the platform driver creates a default remapping
+table. This table is filled with the reserved memory regions and mapped for
+every unused device that requires access to any reserved memory region.
+
+A particular benefit of moving DMA remapping into the platform driver (apart
+from becoming kernel-agnostic) is that DMA remapping tables are now properly
+allocated from the session's quota. In consequence, this may increase the RAM
+and capability requirements for certain drivers.
+
+The platform driver's support for Intel IOMMUs is enabled by default on the
+NOVA and base-hw kernels. The seL4 and Fiasco.OC kernels are not yet covered.
+Nevertheless, we also kept NOVA's IOMMU enablement intact for the following
+reasons:
+
+* To protect the boot-up process from DMA attacks, the IOMMU should be enabled
+ as early as possible. The platform driver simply takes over control when it
+ is ready.
+
+* The platform driver is not (yet) able to manage interrupt remapping because
+ this requires access to the _I/O Advanced Programmable Interrupt Controller_
+ (IOAPIC) controlled by the kernel. Thus, in this release, we still let NOVA
+ manage the interrupt remapping table.
+
+* As we have not implemented support for AMD IOMMUs yet, we simply keep NOVA
+ in charge of this. If there is no Intel IOMMU present, the platform driver
+ falls back to the device PD for controlling the kernel-managed IOMMU.
+
+Along with the DMA remapping support, we added an _iommu_ report to the
+platform driver. On the PC version of Sculpt OS, this is enabled by default
+and routed to _/report/drivers/iommu_. The report summarizes the state of each
+DRHD. When the platform driver takes control, it also logs a message like
+"enabled IOMMU drhd0 with default mappings". The platform driver can be
+prevented from touching the IOMMU by removing the DRHD info from the _acpi_
+report. This can be achieved by supplying the ACPI driver with the following
+config:
+
+!
+
+_Note that the ACPI driver does not handle configuration updates._
+
+Orthogonal to the DMA remapping support, we changed the allocation policy for
+DMA buffers in the generic part of the platform driver. The new policy leaves
+an unmapped page (guard page) between DMA buffers in the virtual I/O memory
+space. This ensures that a simple DMA buffer overflow does not corrupt other
+DMA buffers. Since this is only a matter of virtual address allocation, it
+does not add any additional RAM costs.
+
+
+Base framework and OS-level infrastructure
+##########################################
+
+PC power, frequency, temperature sensing and control
+====================================================
+
+PC CPU vendors provide various CPU features for the operating system to
+influence frequency and power consumption, like Intel HWP or AMD pstate to
+name just two of them. Some of the features require access to various MSR CPU
+registers, which can solely be accessed by privileged rdmsr and wrmsr
+instructions.
+
+Up to now, this feature was provided in a static manner, namely before Genode
+boots. It was possible to set a fixed desired target power consumption via the
+pre-boot chain loader bender. This feature got introduced with
+[https://genode.org/documentation/release-notes/20.11#Hardware_P-State_support_on_PC_hardware - Genode version 20.11]
+and was refined in
+[https://genode.org/documentation/release-notes/22.11#Configurable_Intel_HWP_mode - version 22.11].
+
+Another and desired approach is to permit the adjustment of the desired power
+consumption depending on the current load of the system. This dynamic way of
+power and frequency management has been in casual development since 2021 and
+first got presented in one [https://genodians.org/alex-ab/2023-05-29-freq_power - sneak peak]
+Genodian article. The feature now found its way into the
+[https://genodians.org/alex-ab/2023-10-23-msr - Sculpt 23.10] release.
+
+With the current Genode release, we have added general support to the
+framework that permits guarded access to selected MSRs via Genode's
+system-control RPC of the protection domain (PD) session. If the underlying
+kernel supports this feature, presently the NOVA kernel, read and write
+requests are forwarded via Genode's 'core' roottask to the kernel. A component
+needs the explicit [https://genode.org/documentation/release-notes/22.02#Restricting_physical_memory_information_to_device_drivers_only - managing_system] configuration role to get
+access to this functionality, which is denied by default.
+
+The actual knowledge about how to manage Intel HWP and AMD pstate is provided
+as a native Genode component, which uses the new 'Pd::system_control'
+interface. The component monitors and reports changes of MSR registers for
+temperature (Intel), frequency (AMD & Intel), and power consumption (Intel
+RAPL). Additionally, it can be instructed - by the means of configuration
+changes - to write some of the registers. Besides the low-level MSR component,
+a Genode package with a GUI component is provided to make the interactive
+usage of the feature more user-friendly. For Sculpt, we added an interactive
+dialog to assign the system-control role to a component like the graphical MSR
+package via the resource dialog. For a more detailed description please refer
+to our [https://genodians.org/alex-ab/2023-10-23-msr - Genodians article]
+for the Sculpt 23.10 release.
+
+
+Modernized virtualization interface
+===================================
+
+When we introduced the
+[https://genode.org/documentation/release-notes/19.05#Kernel-agnostic_virtual-machine_monitors - generic Virtual Machine Monitor (VMM) interface]
+for x86 virtualization with Genode
+[https://genode.org/documentation/release-notes/19.05#Kernel-agnostic_virtual-machine_monitors - version 19.05],
+it was largely modeled after our Genode VMM API for ARM with the following
+characteristics.
+
+* A vCPU's state could be requested, evaluated, and modified with the
+ 'state()' method.
+
+* The vCPU was started by the 'run()' method.
+
+* For synchronization, the vCPU could be stopped with the 'pause()' method.
+
+However, this ostensibly uniform interface for ARM and x86 virtualization
+obscures two significant differences between the architectures.
+
+:Hardware and generic vCPU state:
+
+On ARM, the VMM directly handles the hardware virtualization state, i.e., the
+vCPU state is directly passed to the VMM. In contrast, what is passed to the
+VMM on x86 is a generic _Vcpu_state_. This is due to two aspects of x86
+virtualization: First, there are two competing implementations of
+virtualization on x86: AMD's _Secure Virtual Machine (SVM)_ / _AMD-V_ and
+Intel's _Virtual Machine Extensions (VMX)_. Second, neither interface lends
+itself to passing the vCPU state directly to the VMM: VMX requires privileged
+instructions to access fields in the _Virtual Machine Control Structure
+(VMCS)_. Whereas SVM supports direct access to fields in its _Virtual Machine
+Control Block (VMCB)_, the VMCB (as well as the VMCS) does not represent the
+whole state of the vCPU. Notably, both the VMCS and the VMCB do not include
+the CPU's general purpose registers, thereby warranting a separate data
+structure to synchronize the vCPU state with a VMM.
+
+:vCPU pause and state synchronization:
+
+On ARM, the 'pause()' method simply stopped the vCPU kernel thread from being
+scheduled. Since the VMM's vCPU handler runs on the same CPU core we could be
+certain that the vCPU was not running while the VMM's vCPU handler was
+executing, and calling 'pause()' made sure the vCPU wasn't rescheduled while
+the VMM was modifying its state. In contrast, calling 'pause()' on x86 has
+different semantics. It requests a synchronization point from the hypervisor,
+which responds by issuing a generic _PAUSE_ or _RECALL_ exit in order to
+signal the VMM that state can be injected into the vCPU. The mechanism is
+woven deeply into the device models of our x86 VMMs, and therefore
+asynchronous state synchronization from the VMM needed to be available in the
+VMM.
+
+
+API shortcomings and improvements
+---------------------------------
+
+On ARM, making the hardware vCPU state unconditionally available to the VMM via
+the 'state()' method meant that the API did not enforce any synchronization
+between hypervisor / hardware and VMM accesses to the vCPU state. On x86, the
+asynchronous semantics of the 'pause()' method required complex state tracking
+on the hypervisor side of the interface.
+
+To address both shortcomings, we replaced the previous API with a single
+'with_state()' method that takes a lambda function as an argument. The method
+allows scoped access to the vCPU's state and ensures that the vCPU is stopped
+before calling the supplied lambda function with the vCPU as parameter. Only
+if the lambda function returns 'true', the vCPU is resumed with its state
+updated by the VMM. Otherwise, the vCPU remains stopped.
+
+As a result, the API enforces that the vCPU state is only accessed while the
+vCPU is not running. Moreover, we were able to replace the ambiguous 'pause()'
+method by a generic mechanism that unblocks the vCPU handler, which in turn
+uses the 'with_state()' method to update the vCPU state. Finally, resuming of
+the vCPU is controlled by the return value of the lambda function exclusively
+and, thus, removes the error-prone explicit 'run()' method.
+
+
+Porting hypervisors and VMMs
+----------------------------
+
+The new API was first implemented for *base-hw*'s using AMD's SVM
+virtualization method and recently
+[https://genode.org/documentation/release-notes/23.05#Base-HW_microkernel - introduced]
+as part of the 23.05 release. The reduction of complexity was significant:
+explicitly requesting the vCPU state via 'with_state()' did away with a vast
+amount of vCPU-state tracking in the kernel. Instead, the VMM library
+explicitly requests updates to the vCPU state.
+
+With the first hypervisor ported, we were curious to see how easily our new
+interface could be applied to the *NOVA* hypervisor. The initial pleasant
+reduction of complex state handling in base-nova's VMM library was closely
+followed by the insight that there was no way to match the NOVA-specific
+execution model to our new library interface. The asynchronous nature of the
+'with_state()' interface meant that we needed a way to synchronize the vCPU
+state with the VMM that could be initiated from the VMM. Since NOVA's
+execution model is based on the hypervisor calling into the VMM on VM exits,
+we had to extend NOVA's system call interface to allow for an explicit setting
+and getting of the vCPU state. This was needed because the 'with_state()'
+interface requires that the vCPU state is made available to the caller within
+the method call, so the old model of requesting a _RECALL_ exit that would be
+processed asynchronously couldn't be used here. For the same reason, the vCPU
+exit reason had to be passed with the rest of the vCPU state in the UTCB since
+in this case this information wasn't provided through the VMM portal called
+from the hypervisor. The new 'ec_ctrl' system call variants proved to be a
+simple addition and allowed us to adapt to the new interface while still using
+NOVA's execution model for processing regular exits.
+
+The _blocking system call into the hypervisor_ execution model of *Fiasco.OC*
+and *seL4* offered its own unique set of challenges to the new library
+interface in the interplay between asynchronous 'with_state()' triggers and
+the synchronous vCPU run loop. Fortunately, we were able to meet these
+challenges without changing the kernels.
+
+While adapting our VMMs for ARM and x86, we found varying degrees of
+dependency on permanently accessible vCPU state, which we resolved by
+refactoring the implementations. As a result, the new interface is already
+used since the release of
+[https://genode.org/documentation/articles/sculpt-23-10 - Sculpt OS 23.10].
+We haven't experienced any runtime vCPU state access violations and can now be
+certain that there aren't any silent concurrent accesses to the vCPU state.
+
+All in all, the new VMM library interface has succeeded in reducing complexity
+while providing a more robust access to the vCPU state, which is shared
+between our various hypervisors and VMMs.
+
+
+Dialog API for low-complexity interactive applications
+======================================================
+
+Since version
+[https://genode.org/documentation/release-notes/14.11#New_menu_view_application - 14.11],
+Genode features a custom UI widget renderer in the form of a stand-alone
+component called _menu view_. It was designated for use cases where the
+complexity of commodity GUI tool kits like Qt is unwanted. Menu-view-based
+applications merely consume hover reports and produce dialog descriptions as
+XML. In contrast to GUI toolkit libraries, the widget rendering happens
+outside the address space of the application.
+
+Today, this custom widget renderer is used by a number of simple interactive
+Genode applications, the most prominent being the administrative user
+interface of Sculpt OS. Other examples are the touch keyboard, file vault,
+text area, and interactive
+[https://genodians.org/alex-ab/2023-10-23-msr - system monitoring tools].
+
+In each application, the XML processing used to be implemented via a rather
+ad-hoc-designed set of utilities. These utilities and patterns started to get
+in the way when applications become more complex - as we experienced while
+crafting the
+[https://genodians.org/nfeske/2023-01-05-mobile-user-interface - mobile variant]
+of Sculpt OS. These observations prompted us to formalize the implementation
+of menu-view based applications through a new light-weight framework called
+dialog API. The key ideas are as follows.
+
+First, applications are to be relieved from the technicalities of driving a
+sandboxed menu-view component, or the distinction of touch from pointer-based
+input, or the hovering of GUI elements. These concerns are to be covered by
+a runtime library. The application developer can thereby focus solely on the
+application logic, the UI representation (view) of its internal state (model),
+and the response to user interaction (controller).
+
+Second, the dialog API promotes an immediate translation of the application's
+internal state to its UI representation without the need to create an object
+for each GUI element. The application merely provides a 'view' (const) method
+that is tasked to generate a view of the application's state. This approach
+yields itself to the realization of dynamic user interfaces needing dynamic
+memory allocation inside the application.
+The 'view' method operates on a so-called 'Scope', which loosely corresponds
+to Genode's 'Xml_generator', but it expresses the generated structure using
+C++ types, not strings. A scope can host sub scopes similar to how an XML node
+can host child nodes. Hence, the _view_ method expresses the application's
+view as a composition of scopes such as frames, labels, vbox, or hbox.
+
+Third, user interaction is induced into the application by three callbacks
+'click', 'clack', and 'drag', each taking a location as argument. The location
+is not merely a position but entails the structural location of the user
+interaction within the dialog. For interpreting of the location, the
+application uses the same C++ types as for generating the view. Hence, the C++
+type system is leveraged to attain the consistency between the view and the
+controller, so to speak.
+
+Fourth, structural UI patterns - made out of nested scopes - can be combined
+into reusable building blocks called widgets. In contrast to scopes, widgets
+can have state. Widgets can host other widgets, and thereby allow for the
+implementation of higher-level GUI parts out of lower-level elements.
+
+The API resides at _gems/include/dialog/_ and is accompanied by the dialog
+library that implements the runtime needed for the interplay with the
+menu-view widget renderer. Note that it is specifically designed for the needs
+of Sculpt's UI and similar bare-bones utilities. It is not intended to become
+a desktop-grade general-purpose widget set. For example, complex topics like
+multi-language support are decidedly out of scope. During the release cycle,
+the administrative user interface of Sculpt OS - for both the desktop and
+mobile variants - has been converted to the new API. Also, the text-area
+application and the touch keyboard are using the new API now.
+
+Given that the new API has been confronted with the variety of use cases found
+in Sculpt's administrative user interface, it can now be considered for other
+basic applications. Since we target Genode-internal use for now, proper
+documentation is still missing. However, for the curious, an illustrative
+example can be found at _gems/src/test/dialog/_ accompanied by a corresponding
+_dialog.run_ script. For a real-world application, you may consider studying
+the _app/sculpt_manager/view/_ sub directory of the gems repository.
+
+
+API changes
+===========
+
+Simplified list-model utility
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The so-called 'List_model' utility located at _base/include/list_model.h_ has
+become an established pattern used by Genode components that need to maintain
+an internal data model for XML input data. It is particularly useful whenever
+XML data changes over time, in particular when reconfiguring a component at
+runtime.
+
+The original utility as introduced in version
+[https://genode.org/documentation/release-notes/18.02#API_changes - 18.02]
+relied on a policy-based programming pattern, which is more ceremonial than it
+needs to be, especially with recent versions of C++. The current release
+replaces the original policy-based 'update_from_xml' by a new method that
+takes three functors for creating, destroying, and updating elements as
+arguments. XML nodes are associated with their corresponding internal data
+models by annotating the element type with the 'type_matches' class function
+and the 'matches' method.
+
+Besides the interface change, two minor aspects are worth noting. First, to
+improve safety, list model elements can no longer be copied. Second, to foster
+consistency with other parts of Genode's API, the 'apply_first' method has
+been renamed to 'with_first'.
+
+
+Pruned IRQ-session arguments
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+So far, we have used the 'device_config_phys' argument of the IRQ session to
+implicitly request the use of _Message-Signalled Interrupts_ (MSI) to core.
+This argument specifies the address to the PCI configuration space. However,
+with the addition of Intel IOMMU support to the platform driver, we encountered
+an instance where we need an MSI for a non-PCI device in order to receive fault
+IRQs from the IOMMU. We therefore added an 'irq_type' argument to the IRQ
+session, which allows the explicit specification of whether a LEGACY interrupt
+or an MSI is requested.
+
+Yet, as we exceeded the character limit by adding another argument, we pruned
+the IRQ-session arguments: Since 'device_config_phys' is not relevant for
+LEGACY interrupts, we removed this from the default _Irq_connection_
+constructor. We further added an alternative constructor for MSI, which sets
+'device_config_phys' but omits the 'irq_trigger' and 'irq_polarity' arguments.
+
+
+Libraries and applications
+##########################
+
+Seoul virtual machine monitor
+=============================
+
+The Seoul/Vancouver VMM - introduced to Genode with release 11.11 - is an
+experimental x86-based VMM which runs on Genode@NOVA, Genode@seL4, and
+Genode@Fiasco.OC, and Genode@hw on Intel and on AMD hardware. It has been up
+to now solely used with 32-bit and special crafted VMs. With the addition of
+[https://genode.org/documentation/release-notes/22.11#Seoul_VMM - VirtIO support]
+for GPU, input, and audio, the usage as specialized tailored
+[https://genodians.org/alex-ab/2023-05-09-seoul-23-04 - disposable VMs] became
+quite comfortable.
+
+However, time is ticking for 32bit on x86 and some features aren't provided in
+the same quality as for 64bit VMs. For example, when using Firefox on 32bit,
+the video playback on some webpages gets denied while functioning on 64bit
+without complaints. So, the time came to extend the Seoul VMM by 64bit guest
+support to make it fit for today and avoid further hassles.
+
+Over the year 2023, the Seoul VMM got extended by enabling the instruction
+emulator - called Halifax - to decode
+[https://wiki.osdev.org/X86-64_Instruction_Encoding - x86_64 instructions]
+with additional prefixes and additional 8 general purpose registers. Besides
+the necessary deep dive through this special topic, the Seoul VMM required
+extensions to handle more than 4G guest physical memory. Several changes to
+the guest-memory layout handling and the memory-layout reporting, e.g.,
+[https://wiki.osdev.org/Detecting_Memory_(x86) - VBios e820], were necessary.
+
+Once an early prototype successfully booted a 64bit Linux kernel, we found the
+initial user task of some Linux distributions to fail by complaining about
+unsupported CPUs. As it turned out, glibc-based software (and later also
+llvm-based) have several detection mechanism to identify the running CPU - and
+if they feel uncomfortable, deny to work. So, we had to extend the support to
+report more of the native CPUID values of the host and as an after-effect,
+have to emulate more MSR accesses as performed by 64bit Linux guests.
+Unfortunately, the MSRs between Intel and AMD differ in subtle ways, so a per
+CPU differentiation became necessary in the vCPU model.
+
+Additionally, during testing of the native 64bit Debian VM installation with
+the Seoul VMM, several improvements during early boot, especially for the
+interactive usage of the GRUB bootloader were made. Ready to use packages to
+test drive the 64bit Seoul VMM on Sculpt OS are available via the "alex-ab"
+depot.
+
+[image seoul_64bit]
+ Two instances of the Seoul VMM executing 64-bit Linux
+
+
+Ported 3rd-party software
+=========================
+
+Linphone SIP client
+-------------------
+
+Sculpt on the PinePhone used to provide only support for making and receiving
+regular phone calls but did not yet provide any VoIP functionality. Now, the
+"Linphone Console Client" and the "SIP Client for Ubuntu Touch" got ported to
+Genode to expand the available features on the PinePhone when it comes to
+mobile communication.
+
+We decided to port the [https://linphone.org - Linphone-SDK], the console
+client in particular, to Genode because it seems to be a time-tested solution
+on a range of OSes. Furthermore, it uses the [https://cmake.org - cmake]
+build-system, which makes it the ideal candidate for stressing
+[https://github.com/genodelabs/goa - Goa] with a reasonably complex project.
+Using Goa itself turned out to be straight-forward and by re-using the already
+existing back ends for POSIX-like systems, e.g. OSS for handling audio via the
+mediastreamer library, we only had to tweak the build-system in very few
+places. In the process, we encountered a few short-comings regarding the
+handling of shared libraries in cmake-based Goa projects. We were happy to
+address these and the fixes are part of the current Goa release.
+
+Since the user interface of the console client cannot be used comfortably on
+the PinePhone, it had to be complemented by a GUI application that handles the
+user interaction. While looking for such an application we noticed the
+[https://gitlab.com/ubports-linphone/linphone-simple/ - SIP Client for Ubuntu Touch]
+that utilizes the Ubuntu Touch UI Toolkit - where a port to Genode already
+exists. We adapted that project for our needs and - with the major components
+now in place - created a preset for Sculpt on the PinePhone.
+
+The preset's structure is depicted by the following chart.
+
+[image linphone_preset]
+ Structure of the linphone preset
+
+Each of the two components has its own requirements: The Linphone client needs
+access to the network, has to store its configuration, and requires access to
+the audio subsystem. It is the driving force behind the operation while it
+receives its instructions from the GUI. The GUI needs access to the GPU
+driver, as required for fluent rendering of QML on the PinePhone, as well as
+access to input events for user interaction.
+
+Naturally these requirements are satisfied by other components also
+incorporated into the preset:
+
+* The _Dynamic chroot_ component selects and limits the file-system access of
+ the client to the configured directory. In case of the PinePhone it points
+ to the '/recall/linphone' directory on the SD-card.
+
+* The _SNTP_ component provides the client with a correct real-time clock
+ value. Note that the SNTP component uses a different TCP/IP-stack than the
+ client itself.
+
+* The _Audio driver_ component makes the speaker as well as the microphone
+ available to the client.
+
+* The _GPU driver_ component allows the GUI to render the interface via OpenGL
+ on the GPU.
+
+* The _Touch keyboard_ collects the touch events and translates them into key
+ events that are then consumed by the GUI.
+
+The Linphone client and the GUI themselves are connected via the _terminal
+crosslink_ component where the control channel is formed by connecting stdout
+from the GUI to stdin from the client and vice versa.
+
+As denoted by the chart, the client actually functions as a _daemon_ that is
+running in the background, whereas the GUI is the _app_ the user interacts
+with.
+
+For more information and a usage guide, please refer to the corresponding
+[https://genodians.org/jws/2023-11-16-sip-client-for-genode - Genodians article].
+
+
+Socat
+-----
+
+We ported socat, a multipurpose relay (SOcket CAT), to Genode and created a
+ready-to-use pkg archive that allows for making a terminal session available
+on port '5555'.
+
+
+SDL libraries
+-------------
+
+This release also makes more SDL-related libraries available on Genode.
+The common helper libraries like SDL2-image, SDL2-mixer, SDL2-net, and SDL2-ttf
+complement the SDL2 support, while the SDL-gfx library enhances the support
+of SDL1.2. All these libraries are located in the _genode-world_ repository.
+
+
+Device drivers
+##############
+
+USB device drivers updated to Linux 6.1.20
+==========================================
+
+With our ongoing effort to replace our traditional device-driver porting
+approach by our new
+[https://genode.org/documentation/release-notes/21.08#Linux-device-driver_environment_re-imagined - device-driver environment],
+USB-device drivers were subject to this porting effort during this release
+cycle. This includes the HID driver for keyboard, mouse, and touch support,
+the network driver, which supports USB NICs like AX88179 or the PinePhone's
+CDC Ether profile of its LTE Modem, as well as the USB modem driver that
+offers basic LTE-modem access for modems relying on the
+[https://www.usb.org/document-library/mobile-broadband-interface-model-v10-errata-1-and-adopters-agreement - MBIM]
+configuration.
+
+
+Architecture
+------------
+
+In contrast to the USB host-controller drivers, USB device drivers do not
+communicate with the hardware directly, but only send messages to the USB host
+controller through Genode's USB-session interface. So, from Genode's point of
+view, they can be classified as protocol stacks. Therefore, we based these
+drivers not on the DDE Linux version that offers direct hardware access, but
+on 'virt_linux' as described in release
+[https://genode.org/documentation/release-notes/23.05#WireGuard_improvements - 23.05].
+
+We replaced the actual Linux calls that create USB messages (like control,
+bulk, or IRQ transfers) by custom implementations that forward these messages
+through a USB client session to the host controller. The client-session
+implementation is written in C++. Since our DDE Linux strictly separates C++
+from C-code, we introduced a USB-client C-API that can be called directly by
+the replacement functions.
+
+The same goes for the services the USB drivers offer/use. These services
+are accessed through the respective C-APIs. For example, the HID driver
+communicates with Genode's event session through the event C-API and the NIC
+driver through the uplink C-API.
+
+
+USB HID driver
+--------------
+
+The HID driver is a drop-in replacement of its predecessor. It still offers
+support to handle multiple devices at once, and the configuration remains
+unchanged.
+
+Note that we have dropped support for multi-touch devices, like Wacom, because
+touch was merely in a proof of concept state that should be redesigned and
+rethought for Genode if needed.
+
+
+USB modem
+---------
+
+The LTE-modem driver (usb_modem_drv) has been integrated into the network
+driver (see below).
+
+
+USB net
+-------
+
+The 'usb_net_drv' is a drop-in replacement for its predecessor with the
+exception that an additional configuration attribute is available:
+
+!
+
+Next to the MAC address (like in the previous version), the USB configuration
+profile can be specified with the 'configuration' attribute. For USB devices
+that provide multiple configuration profiles, the Linux code will always
+select the first non-vendor-specific configuration profile found. This may not
+be the desired behavior, and therefore, can now be specified.
+
+The available configuration profile of a device can be found out under Linux
+using:
+
+! lsusb -s: -vvv
+
+Currently the driver supports NICs containing an AX88179A chip and that offer
+the NCM or the ECM profile. Support for the SMSC95XX line of devices has been
+dropped, but may be re-enabled if required.
+
+As mentioned above, the LTE modem support for MBIM-based modems has been
+merged into this driver because an LTE modem is merely a USB networking device
+(for data) plus a control channel. In case the driver discovers an LTE modem,
+it will announce a Genode terminal session as a control channel.
+
+Example configuration for the Huawai ME906s modem:
+
+!
+!
+!
+!
+!
+!
+!
+!
+! ....
+!
+!
+
+The MBIM interface is enabled using configuration profile "3" and the service
+"Terminal" is provided.
+
+We have tested the driver mainly on Lenovo Thinkpad notebooks using Huawai's
+ME906e and Fibocoms's L830-EB-00 modems, but different modems might work as
+well.
+
+
+Current limitations
+-------------------
+
+The current version of 'virt_linux' does not support arm_v6 platforms like
+Raspberry Pi (Zero). We will address this shortcoming with the next release
+and update the drivers accordingly.
+
+
+Platforms
+#########
+
+Linux
+=====
+
+Following the official
+[https://wiki.libsdl.org/SDL2/MigrationGuide - migration guide] of SDL, the
+fb_sdl framebuffer driver was updated from SDL1 to SDL2 by Robin Eklind.
+Thanks to this valuable contribution, fb_sdl is now ready to run on modern
+Linux installations especially in environments that use the Wayland display
+server. Note, to compile the component from source, the installation of
+libsdl2 development packages (e.g., libsdl2-dev, libdrm-dev, and libgbm-dev on
+Ubuntu/Debian) is required.
+
+
+Build system and tools
+######################
+
+Debug information for depot binaries
+====================================
+
+So far, the Genode build system created symbolic links to unstripped binaries
+in the _debug/_ directory to provide useful debug information, but binaries
+from depot archives did not have this information available.
+
+With this release, the 'create', 'publish' and 'download' depot tools received
+an optional 'DBG=1' argument to create, publish, and download 'dbg' depot
+archives with debug-info files in addition to the corresponding 'bin' depot
+archives.
+
+To avoid the storage overhead from duplicated code with archived unstripped
+binaries, we now create separate debug info files using the "GNU debug link"
+method in the Genode build system and for the 'dbg' depot archives.
+
+
+Decommissioned implicit trigger of shared-library builds
+========================================================
+
+Since the very first version, Genode's build system automatically managed
+inter-library dependencies, which allowed us to cleanly separate different
+concerns (like CPU-architecture-specific optimizations) as small static
+libraries, which were automatically visited by the build system whenever
+building a dependent target.
+
+When we later
+[https://genode.org/documentation/release-notes/9.11#Completed_support_for_dynamic_linking - introduced]
+the support for shared libraries, we maintained the existing notion of
+libraries but merely considered shared objects as a special case. Hence,
+whenever a target depends on a shared library, the build system would
+automatically build the shared library before linking it to the target.
+
+With the later introduction of Genode's ABI's in version
+[https://genode.org/documentation/release-notes/17.02#Genode_Application_Binary_Interface - 17.02],
+we effectively dissolved the link-time dependency of targets from shared
+objects, which ultimately paved the ground for Genode's package management.
+However, our build-system retained the original policy of building shared
+libraries before linking dependent targets. Even though this is arguably
+convenient when using many small inter-dependent libraries, with complex
+shared libraries as dependencies, one always needs to locally build those
+complex libraries even though the library internals are rarely touched or the
+library is readily available as a pre-built binary archive. In the presence of
+large 3rd-party libraries, the build system's traditional policy starts to
+stand in the way of quick development-test cycles.
+
+With the current release, we dissolve the implicit built-time dependency of
+targets from shared libraries. Shared libraries must now be explicitly listed
+in the 'build' command of run scripts. For example, for run scripts that build
+Genode's base system along with the C runtime, the build command usually
+contains the following targets.
+
+! core lib/ld init timer lib/libc lib/libm lib/vfs lib/posix
+
+However, in practice most run scripts incorporate those basic ingredients as
+depot archives. So those targets need to be built only if they are touched by
+the development work. To incorporate the results of all explicitly built
+targets into a system image, the 'build_boot_image' command can be used as
+follows. Note that the listing of boot modules does not need to be maintained
+manually anymore.
+
+! build_boot_image [build_artifacts]
+
+During the release cycle of version 23.11, we have revisited all run scripts
+in this respect, and we encourage Genode users to follow suit. The run tool
+tries to give aid to implement this change whenever it detects the presence of
+a .lib.so 'build_boot_image' argument that is not covered by the prior build
+command. For example, on the attempt to integrate 'ld.lib.so' without having
+built 'lib/ld', the following diagnostic message will try to guide you.
+
+! Error: missing build argument for: ld.lib.so
+!
+! The build_boot_image argument may be superfluous or
+! the build step lacks the argument: lib/ld
+!
+! Consider using [build_artifacts] as build_boot_image argument to
+! maintain consistency between the build and build_boot_image steps.
+
+The inconvenience of the need to adopt existing run scripts notwithstanding,
+developers will certainly notice a welcome boost of their work flow,
+especially when working with complex 3rd-party libraries.
diff --git a/doc/release_notes/24-02.txt b/doc/release_notes/24-02.txt
new file mode 100644
index 0000000000..4261c23c19
--- /dev/null
+++ b/doc/release_notes/24-02.txt
@@ -0,0 +1,677 @@
+
+
+ ===============================================
+ Release notes for the Genode OS Framework 24.02
+ ===============================================
+
+ Genode Labs
+
+
+
+Version 24.02 focuses on developer experience and framework infrastructure.
+Genode's Goa SDK has reached prominence in the past few releases. It largely
+streamlines the porting, development, and publishing of software targeting
+Genode and Sculpt OS in particular.
+With the current release, Goa has become able to conveniently use Sculpt OS as
+a remote test target. Regardless of whether targeting a PC or the PinePhone,
+either can be turned into a test target in seconds and the developer's
+compile-test cycle looks exactly the same
+(Section [Sculpt OS as remote test target for the Goa SDK]).
+
+A long anticipated infrastructure topic is the rework of Genode's audio stack
+to accommodate latency-sensitive scenarios, using flexible sample rates, and
+making audio drivers pluggable.
+Section [Revised audio infrastructure] gives an overview of the taken
+architectural approach, the interfaces, and a low-complexity mixer modelled
+as self-sufficient resource multiplexer.
+
+Speaking of infrastructure, we are excited to report to have wrapped up the
+transition to our modern Linux device-driver environment based on Linux 6.x.
+The last piece of the puzzle was the TCP/IP stack that was still based
+on code originating from Linux 4.4.3.
+Section [TCP/IP stack based on DDE-Linux version 6.1.20] details the new
+TCP/IP stack.
+
+According to our [https://genode.org/about/road-map - road map], we plan to
+add suspend/resume as feature to Sculpt OS 24.04. As a crucial stepping stone
+towards this goal, all drivers that cannot be easily restarted must become
+suspend/resume aware.
+Section [Suspend/resume awareness of GPU, AHCI, and NVMe drivers] explains
+this achievement for the AHCI, NVMe, and Intel GPU drivers.
+
+Further highlights of the release are the much improved handling of HID
+events including the generalized calibration of motion events, API safety
+improvements, the prospect of de-privileged tracing in Sculpt OS, and
+multi-client support for Vivante GPUs.
+
+On our road map, we had scheduled two further topics that are notably absent,
+namely USB and SMS. But don't fret. Even though the large rework of our USB
+infrastructure for fine-grained and dynamic USB access has been completed just
+in time, we felt that this far-reaching change should better not be rushed
+into the release. It will be merged shortly after, and settle into the upcoming
+Sculpt OS version 24.04 just fine. The second topic not covered is SMS support
+for the PinePhone, which is a topic actively
+[https://github.com/genodelabs/genode/issues/5127 - worked on] but with no
+user-visible effect until its integration in Sculpt OS in April.
+
+
+Revised audio infrastructure
+############################
+
+After first introduced in version
+[https://genode.org/documentation/release-notes/10.05#Device-class_interfaces_for_NIC_and_Audio-out - 10.05],
+Genode's
+[https://genode.org/documentation/genode-foundations/23.05/components/Common_session_interfaces.html#Audio_output - audio support]
+slowly evolved over the years, covering audio mixing in
+version
+[https://genode.org/documentation/release-notes/10.11#Audio_mixer - 10.11],
+leveraging OpenBSD's audio driver since version
+[https://genode.org/documentation/release-notes/15.05#Audio_drivers_ported_from_OpenBSD - 15.05]
+and offering the OSS interface as VFS plugin since version
+[https://genode.org/documentation/release-notes/20.11#Streamlined_ioctl_handling_in_the_C_runtime___VFS - 20.11].
+With our recent focus on use cases like
+[https://genodians.org/jws/2023-11-16-sip-client-for-genode - VoIP on the PinePhone] or
+[https://genode.org/documentation/release-notes/21.05#Webcam_support - video conferencing],
+however, we identified limitations that cannot be overcome without an
+architectural revision.
+
+First, in the name of simplicity, we used to tie the inter-component audio
+interfaces to a fixed sample rate of 44100 Hz. This has recently become a
+problem because some audio drivers tend to support only 48000 Hz.
+
+Second, in latency-sensitive scenarios, we observed that the existing
+interfaces were prone to effects caused by the drifting of time between the
+producer and consumer of audio data. One effect are buffer under-runs, which
+produce audible noise. The other is the slow accumulation of buffered sample
+data, which increases latency over time (affecting the effectiveness of
+acoustic echo cancellation) and yields an audible buffer overrun after a
+while.
+
+Third, the mixer is a single client of the audio driver, which makes the mixer
+dependent on the liveliness of the driver. Therefore, the driver cannot be
+restarted without also restarting the mixer and - transitively - each client
+of the mixer. The rigid relation between the audio driver and the mixer also
+stands in the way of routing audio between different audio devices operated
+by separate drivers.
+
+After having successfully introduced the concept of _pluggable drivers_ for graphics in version
+[https://genode.org/documentation/release-notes/20.08#The_GUI_stack__restacked - 20.08]
+and applying the same idea to networking in version
+[https://genode.org/documentation/release-notes/21.02#Pluggable_network_device_drivers - 21.02],
+the time was ripe for turning the audio infrastructure upside down.
+
+[image audio_vs_recordplay]
+ original layered architecture (left) compared to the new pluggable
+ architecture (right)
+
+The new architecture as shown on the right turns the mixer into a
+self-sufficient resource multiplexer, which offers a service for playing audio
+and a service for recording audio. Both audio drivers as well as audio
+applications are becoming mere clients of the mixer. With this architecture,
+the dynamic starting, removal, and restarting of the driver, of even multiple
+drivers, is trivially solved.
+
+To bridge the gap between audio clients operating at different sample rates,
+the mixer automatically detects and converts sample rates as needed. Both play
+and record clients are expected to operate periodically. The number of samples
+produced per period is up to each client and does not need to be constant over
+time. The mixer infers the used sample rates and periods by observing the
+behavior of the clients. It measures the jitter of clients to automatically
+adjust buffering parameters to attain continuous playback while trying to
+optimize for low latency. Those runtime-measurements can be augmented by
+explicit configuration values.
+
+Multi-channel playing and recording are realized by one session per channel
+whereas one channel is used to drive the time allocation while all further
+channels merely enqueue/obtain data into/from their respective sessions
+without any synchronous interplay with the mixer.
+
+The mixer routes and mixes audio signals produced by play clients to record
+clients according to its configuration. Typical play clients are an audio
+player or a microphone driver whereas typical record clients are an audio
+recorder or an audio-output driver. A simple mixer configuration looks as
+follows:
+
+!
+!
+!
+!
+!
+!
+!
+!
+!
+
+This configuration defines two signals "left" and "right" that are mixed from
+the audio input of the matching clients. In the example, each play
+session labeled as "left" is mixed into the "left" signal. Each node can
+host an arbitrary number of nodes. The same policy can appear at
+multiple nodes. A node assigns a signal to a record client. In
+the example, a record client labeled "left" is connected to the signal
+"left".
+
+The mixer allows for the cascading of nodes. For example, the following
+signal "lefty" is a mix of the two signals "left" and "right", weighted by
+respective volume attributes.
+
+!
+!
+!
+!
+
+[image mixed_waveforms]
+ Example of the mixer output for a sine wave as the "left" signal (top),
+ a signal mixed 70:30, a signal mixed 30:70, and a square wave as the
+ "right" signal (bottom).
+
+The operation and configuration of the mixer is described in more detail by
+the accompanied README at _os/src/record_play_mixer/_. The inter-component
+interfaces are located at _os/include/play_session/_ and
+_os/include/record_session/_.
+
+The _gems/run/waveform_player.run_ script illustrates the integration of the
+mixer by using a waveform generator as multi-channel play client and an
+oscilloscope as record client.
+
+Current state and next steps
+----------------------------
+
+The new infrastructure is ready to be exercised by the synthetic example
+mentioned above as well as by the _audio_out.run_ and _audio_in.run_ scripts
+located at _repos/dde_bsd/run/_. The OpenBSD-based audio driver can be
+operated in either of two modes. By default, it is compatible to the old audio
+in/out interfaces. The new record/play mode can be enabled by setting the
+'record_play="yes"' config attribute. Over the next release cycle, we will
+successively convert the other pieces of the audio stack, in particular the
+other drivers and the OSS VFS plugin, to the new record and play interfaces.
+Following this transition, the original audio in/out interfaces will be
+removed.
+
+
+Sculpt OS as remote test target for the Goa SDK
+###############################################
+
+The run-stage generalization from
+[https://genode.org/documentation/release-notes/23.08#Run-stage_generalization - release 23.08],
+paved the way for the new run-target "sculpt" that allows using Sculpt OS as
+a remote test target for 'goa run'. Since Goa already placed all the required
+files for running a scenario into a _var/run_ directory, adding this target
+merely involved coming up with a solution for synchronizing the run directory
+with Sculpt OS and getting a hold of the log output. The implementation in Goa
+is accompanied by a _goa_testbed_ package that starts a remotely-controlled
+subsystem on Sculpt OS. It particularly hosts a _lighttpd_ and _tcp_terminal_
+component. The former is used for run-directory synchronization based on HTTP
+PUT. The latter provides the log output of the test scenario via telnet. For
+more details, you may take a look at the corresponding
+[https://genodians.org/jschlatow/2024-01-29-goa-sculpt - blog post on genodians.org].
+
+In order to integrate support for this mechanism into Sculpt OS, we
+supplemented the NIC router configuration with a _http_ and a _telnet_ domain.
+Each of these domains is intended to accommodate a single client. Ports 80 and
+23 of the _uplink_ domain are then forwarded to the clients in the _http_ and
+_telnet_ domain respectively. This is complemented by the _goa_testbed_ preset
+added to the PC and PinePhone version of Sculpt OS that turns the system into
+a ready-to-use remote test target. You can see this feature in action in our
+[https://genodians.org/nfeske/2024-02-15-fosdem-aftermath - FOSDEM talks].
+
+When implementing the Sculpt target in Goa, we also had to come up with a way
+to supply Goa with the IP address of the remote test target. Goa's modularity
+w.r.t. custom run stages motivated us to implement a generic mechanism for
+target-specific options. For this purpose, we added the config variable
+'target_opt' that is defined as a Tcl array. The Sculpt target evaluates the
+array elements 'sculpt-server', 'sculpt-port-http' and 'sculpt-port-telnet'.
+We further augmented Goa's command-line parsing such that individual elements
+of the 'target_opt' as well as the 'version' config variables, which are both
+arrays, can be supplied as command-line arguments. The corresponding arguments
+follow the pattern '--target-opt-
}
-build_boot_image "core ld.lib.so init timer test-cpu_quota test-sync"
-
-#
-# Execution
-#
+build_boot_image [build_artifacts]
append qemu_args "-nographic "
run_genode_until ".*done.*\n.*done.*\n.*done.*\n" 110
-#
-# Conclusion
-#
set err_cnt 0
proc check_counter { name opt cnt total_cnt } {
diff --git a/repos/base-hw/run/cpu_scheduler.run b/repos/base-hw/run/cpu_scheduler.run
index 57d0782bf7..3e36cf4b03 100644
--- a/repos/base-hw/run/cpu_scheduler.run
+++ b/repos/base-hw/run/cpu_scheduler.run
@@ -1,16 +1,7 @@
-#
-# \brief Test CPU-scheduler implementation of core
-# \author Martin Stein
-# \date 2014-09-30
-#
+build { core init lib/ld test/cpu_scheduler }
-# build program images
-build "core init test/cpu_scheduler"
-
-# create directory where the boot files are written to
create_boot_directory
-# the init config is not used but the build system needs it
install_config {
@@ -28,15 +19,12 @@ install_config {
}
-# create single boot image from the compiled program images
-build_boot_image "core ld.lib.so init test-cpu_scheduler"
+build_boot_image [build_artifacts]
-# configure qemu to use 64 MB RAM and avoid GUI mode
-append qemu_args " -nographic"
+append qemu_args " -nographic"
-# execute the test in qemu if the targeted platform is supported
-run_genode_until "done.*\n" 10
+run_genode_until "child .test-cpu_scheduler. exited with exit value .*\n" 10
-# check the output
-grep_output {\[init -> test-cpu_scheduler\]}
-compare_output_to { [init -> test-cpu_scheduler] done }
+grep_output {child .test-cpu_scheduler. exited with exit value}
+
+compare_output_to { [init] child "test-cpu_scheduler" exited with exit value 0 }
diff --git a/repos/base-hw/run/double_list.run b/repos/base-hw/run/double_list.run
deleted file mode 100644
index e4a699b04e..0000000000
--- a/repos/base-hw/run/double_list.run
+++ /dev/null
@@ -1,69 +0,0 @@
-#
-# \brief Test double-list implementation of core
-# \author Martin Stein
-# \date 2014-09-30
-#
-
-# build program images
-build "core init test/double_list"
-
-# create directory where the boot files are written to
-create_boot_directory
-
-# the init config is not used but the build system needs it
-install_config {
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-}
-
-# create single boot image from the compiled program images
-build_boot_image "core ld.lib.so init test-double_list"
-
-# configure qemu to use 64 MB RAM and avoid GUI mode
-append qemu_args " -nographic"
-
-# execute the test in qemu if the targeted platform is supported
-run_genode_until "done.*\n" 10
-
-# check the output
-grep_output {\[init -> test-double_list\]}
-compare_output_to {
- [init -> test-double_list] print each
- [init -> test-double_list] print each
- [init -> test-double_list] 1
- [init -> test-double_list] print each
- [init -> test-double_list] 3
- [init -> test-double_list] 2
- [init -> test-double_list] 5
- [init -> test-double_list] 7
- [init -> test-double_list] 6
- [init -> test-double_list] 4
- [init -> test-double_list] 1
- [init -> test-double_list] print each
- [init -> test-double_list] 8
- [init -> test-double_list] 9
- [init -> test-double_list] 2
- [init -> test-double_list] 5
- [init -> test-double_list] 1
- [init -> test-double_list] 7
- [init -> test-double_list] 6
- [init -> test-double_list] 4
- [init -> test-double_list] 3
- [init -> test-double_list] print each
- [init -> test-double_list] 7
- [init -> test-double_list] 8
- [init -> test-double_list] done
-}
diff --git a/repos/base-hw/src/bootstrap/board/imx53_qsb/board.h b/repos/base-hw/src/bootstrap/board/imx53_qsb/board.h
deleted file mode 100644
index e65079f3af..0000000000
--- a/repos/base-hw/src/bootstrap/board/imx53_qsb/board.h
+++ /dev/null
@@ -1,32 +0,0 @@
-/*
- * \brief i.MX53 Quickstart board definitions
- * \author Stefan Kalkowski
- * \date 2017-03-22
- */
-
-/*
- * Copyright (C) 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 _SRC__BOOTSTRAP__SPEC__IMX53_QSB__BOARD_H_
-#define _SRC__BOOTSTRAP__SPEC__IMX53_QSB__BOARD_H_
-
-#include
-#include
-
-#include
-#include
-
-namespace Board {
-
- using namespace Hw::Imx53_qsb_board;
-
- using Hw::Pic;
-
- bool secure_irq(unsigned irq);
-}
-
-#endif /* _SRC__BOOTSTRAP__SPEC__IMX53_QSB__BOARD_H_ */
diff --git a/repos/base-hw/src/bootstrap/board/imx53_qsb/platform.cc b/repos/base-hw/src/bootstrap/board/imx53_qsb/platform.cc
deleted file mode 100644
index bb684bba63..0000000000
--- a/repos/base-hw/src/bootstrap/board/imx53_qsb/platform.cc
+++ /dev/null
@@ -1,32 +0,0 @@
-/*
- * \brief Specific i.MX53 bootstrap implementations
- * \author Stefan Kalkowski
- * \date 2012-10-24
- */
-
-/*
- * 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.
- */
-
-#include
-#include
-
-using namespace Board;
-
-bool Board::secure_irq(unsigned) { return true; }
-
-
-Bootstrap::Platform::Board::Board()
-:
- early_ram_regions(Memory_region { RAM0_BASE, RAM0_SIZE },
- Memory_region { RAM1_BASE, RAM1_SIZE }),
- core_mmio(Memory_region { UART_1_MMIO_BASE, UART_1_MMIO_SIZE },
- Memory_region { EPIT_1_MMIO_BASE, EPIT_1_MMIO_SIZE },
- Memory_region { IRQ_CONTROLLER_BASE, IRQ_CONTROLLER_SIZE })
-{
- Aipstz aipstz_1(AIPS_1_MMIO_BASE);
- Aipstz aipstz_2(AIPS_2_MMIO_BASE);
-}
diff --git a/repos/base-hw/src/bootstrap/board/imx53_qsb/platform_trustzone.cc b/repos/base-hw/src/bootstrap/board/imx53_qsb/platform_trustzone.cc
deleted file mode 100644
index 912a06bc12..0000000000
--- a/repos/base-hw/src/bootstrap/board/imx53_qsb/platform_trustzone.cc
+++ /dev/null
@@ -1,59 +0,0 @@
-/*
- * \brief Specific i.MX53 bootstrap implementations
- * \author Stefan Kalkowski
- * \date 2012-10-24
- */
-
-/*
- * 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.
- */
-
-#include
-#include
-#include
-#include
-
-using namespace Board;
-
-
-bool Board::secure_irq(unsigned i)
-{
- if (i == EPIT_1_IRQ) return true;
- if (i == EPIT_2_IRQ) return true;
- if (i == I2C_2_IRQ) return true;
- if (i == I2C_3_IRQ) return true;
- if (i == SDHC_IRQ) return true;
-
- if (i >= GPIO1_IRQL && i <= GPIO4_IRQH) return true;
- if (i >= GPIO5_IRQL && i <= GPIO7_IRQH) return true;
- return false;
-}
-
-
-Bootstrap::Platform::Board::Board()
-:
- early_ram_regions(Memory_region { Trustzone::SECURE_RAM_BASE,
- Trustzone::SECURE_RAM_SIZE }),
- core_mmio(Memory_region { UART_1_MMIO_BASE, UART_1_MMIO_SIZE },
- Memory_region { EPIT_1_MMIO_BASE, EPIT_1_MMIO_SIZE },
- Memory_region { IRQ_CONTROLLER_BASE, IRQ_CONTROLLER_SIZE },
- Memory_region { CSU_BASE, CSU_SIZE })
-{
- Aipstz aipstz_1(AIPS_1_MMIO_BASE);
- Aipstz aipstz_2(AIPS_2_MMIO_BASE);
-
- /* set exception vector entry */
- Cpu::Mvbar::write(Hw::Mm::system_exception_vector().base);
-
- /* enable coprocessor 10 + 11 access for TZ VMs */
- Cpu::Nsacr::access_t v = 0;
- Cpu::Nsacr::Cpnsae10::set(v, 1);
- Cpu::Nsacr::Cpnsae11::set(v, 1);
- Cpu::Nsacr::write(v);
-
- /* configure central security unit */
- Csu csu(CSU_BASE, false, true, false, true);
-}
diff --git a/repos/base-hw/src/bootstrap/board/imx6q_sabrelite/board.h b/repos/base-hw/src/bootstrap/board/imx6q_sabrelite/board.h
deleted file mode 100644
index 995b75149a..0000000000
--- a/repos/base-hw/src/bootstrap/board/imx6q_sabrelite/board.h
+++ /dev/null
@@ -1,222 +0,0 @@
-/*
- * \brief i.MX6Quad Sabrelite specific board definitions
- * \author Stefan Kalkowski
- * \date 2019-01-05
- */
-
-/*
- * Copyright (C) 2019 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 _SRC__BOOTSTRAP__SPEC__IMX6Q_SABRELITE__BOARD_H_
-#define _SRC__BOOTSTRAP__SPEC__IMX6Q_SABRELITE__BOARD_H_
-
-#include
-#include
-#include
-#include
-#include
-
-namespace Board {
-
- using namespace Hw::Imx6q_sabrelite_board;
- using Pic = Hw::Gicv2;
- struct L2_cache;
-
- static constexpr bool NON_SECURE = false;
-
- static volatile unsigned long initial_values[][2] {
- // (IOMUX Controller)
- { 0x20e0004, 0x48613005 },
- { 0x20e0008, 0x0 },
- { 0x20e000c, 0x1e00040 },
- { 0x20e0020, 0xfffd4000 },
- { 0x20e0030, 0xf004490 },
- { 0x20e0034, 0x593e4a4 },
- { 0x20e004c, 0x3 },
- { 0x20e0050, 0x3 },
- { 0x20e0054, 0x3 },
- { 0x20e015c, 0x0 },
- { 0x20e0160, 0x0 },
- { 0x20e0164, 0x0 },
- { 0x20e0168, 0x0 },
- { 0x20e0170, 0x0 },
- { 0x20e0174, 0x0 },
- { 0x20e0178, 0x0 },
- { 0x20e017c, 0x0 },
- { 0x20e0180, 0x0 },
- { 0x20e0184, 0x0 },
- { 0x20e0188, 0x0 },
- { 0x20e018c, 0x0 },
- { 0x20e0190, 0x0 },
- { 0x20e0194, 0x0 },
- { 0x20e0198, 0x0 },
- { 0x20e019c, 0x0 },
- { 0x20e01a0, 0x0 },
- { 0x20e01a4, 0x0 },
- { 0x20e01a8, 0x0 },
- { 0x20e01ac, 0x0 },
- { 0x20e01b0, 0x0 },
- { 0x20e01b4, 0x0 },
- { 0x20e01b8, 0x0 },
- { 0x20e01bc, 0x0 },
- { 0x20e01c0, 0x0 },
- { 0x20e01c4, 0x0 },
- { 0x20e01c8, 0x0 },
- { 0x20e01cc, 0x0 },
- { 0x20e0208, 0x2 },
- { 0x20e020c, 0x2 },
- { 0x20e0218, 0x2 },
- { 0x20e0220, 0x0 },
- { 0x20e0224, 0x3 },
- { 0x20e0230, 0x11 },
- { 0x20e02b8, 0x0 },
- { 0x20e02f4, 0x0 },
- { 0x20e033c, 0x2 },
- { 0x20e0344, 0x3 },
- { 0x20e0348, 0x2 },
- { 0x20e035c, 0x3 },
- { 0x20e0360, 0x130b0 },
- { 0x20e0364, 0x110b0 },
- { 0x20e0368, 0x130b0 },
- { 0x20e036c, 0x10030 },
- { 0x20e0370, 0x10030 },
- { 0x20e0374, 0x10030 },
- { 0x20e0378, 0x10030 },
- { 0x20e037c, 0x10030 },
- { 0x20e0388, 0x10030 },
- { 0x20e03b0, 0xb1 },
- { 0x20e03bc, 0xb0 },
- { 0x20e03c0, 0xb0 },
- { 0x20e0470, 0x10 },
- { 0x20e0474, 0x10 },
- { 0x20e0478, 0x10 },
- { 0x20e047c, 0x10 },
- { 0x20e0484, 0x10 },
- { 0x20e0488, 0x10 },
- { 0x20e048c, 0x10 },
- { 0x20e0490, 0x10 },
- { 0x20e0494, 0x10 },
- { 0x20e0498, 0x10 },
- { 0x20e049c, 0x10 },
- { 0x20e04a0, 0x10 },
- { 0x20e04a4, 0x10 },
- { 0x20e04a8, 0x10 },
- { 0x20e04ac, 0x10 },
- { 0x20e04b0, 0x10 },
- { 0x20e04b4, 0x10 },
- { 0x20e04b8, 0x10 },
- { 0x20e04bc, 0x10 },
- { 0x20e04c0, 0x10 },
- { 0x20e04c4, 0x10 },
- { 0x20e04c8, 0x10 },
- { 0x20e04cc, 0x10 },
- { 0x20e04d0, 0x10 },
- { 0x20e04d4, 0x10 },
- { 0x20e04d8, 0x10 },
- { 0x20e04dc, 0x10 },
- { 0x20e04e0, 0x10 },
- { 0x20e04e4, 0x100b0 },
- { 0x20e04e8, 0x100b0 },
- { 0x20e0508, 0x100b0 },
- { 0x20e05f0, 0x30b0 },
- { 0x20e05f4, 0x17059 },
- { 0x20e0600, 0xb1 },
- { 0x20e061c, 0x30b0 },
- { 0x20e069c, 0x1f0b0 },
- { 0x20e06a4, 0x10059 },
- { 0x20e06e0, 0x10059 },
- { 0x20e0724, 0x1b0b1 },
- { 0x20e072c, 0x1b0b1 },
- { 0x20e0730, 0x1b0b1 },
- { 0x20e0744, 0x130b0 },
- { 0x20e07c4, 0x1 },
- { 0x20e0944, 0x1 },
- // (Global Power Controller)
- { 0x20dc008, 0x70f7f01b },
- { 0x20dc00c, 0xff79b60f },
- { 0x20dc010, 0xfffe0003 },
- { 0x20dc014, 0xfef7f9ff },
- // (Power Management Unit)
- { 0x20c8140, 0x4c0013 },
- { 0x20c8150, 0x4010088 },
- { 0x20c8160, 0x8000040b },
- { 0x20c8170, 0xff672f67 },
- // (Clock Controller Module)
- { 0x20c4018, 0x10204 },
- { 0x20c402c, 0x7348c1 },
- { 0x20c4030, 0x33e71f92 },
- { 0x20c4034, 0x12088 },
- { 0x20c4038, 0x12090 },
- { 0x20c4054, 0x78 },
- { 0x20c4060, 0x10e0101 },
- { 0x20c4064, 0x2fe62 },
- { 0x20c4068, 0xc03f0f },
- { 0x20c406c, 0x30fc00 },
- { 0x20c4070, 0x3ff0033 },
- { 0x20c4074, 0x3f3300c3 },
- { 0x20c4078, 0xc303 },
- { 0x20c4080, 0xf03 },
- { 0x20c8010, 0x80003040 },
- { 0x20c8070, 0x1006 },
- { 0x20c80a0, 0x1028 },
- { 0x20c80b0, 0x0 },
- { 0x20c80c0, 0xf4240 },
- { 0x20c80e0, 0x80182001 },
- { 0x20c80f0, 0xd3d150cc },
- { 0x20c8100, 0x5018d0db }
- };
-}
-
-
-struct Board::L2_cache : Hw::Pl310
-{
- L2_cache(Genode::addr_t mmio) : Hw::Pl310(mmio)
- {
- Aux::access_t aux = 0;
- Aux::Full_line_of_zero::set(aux, true);
- Aux::Associativity::set(aux, Aux::Associativity::WAY_16);
- Aux::Way_size::set(aux, Aux::Way_size::KB_64);
- Aux::Share_override::set(aux, true);
- Aux::Replacement_policy::set(aux, Aux::Replacement_policy::PRAND);
- Aux::Ns_lockdown::set(aux, true);
- Aux::Data_prefetch::set(aux, true);
- Aux::Inst_prefetch::set(aux, true);
- Aux::Early_bresp::set(aux, true);
- write(aux);
-
- Tag_ram::access_t tag_ram = 0;
- Tag_ram::Setup_latency::set(tag_ram, 2);
- Tag_ram::Read_latency::set(tag_ram, 3);
- Tag_ram::Write_latency::set(tag_ram, 1);
- write(tag_ram);
-
- Data_ram::access_t data_ram = 0;
- Data_ram::Setup_latency::set(data_ram, 2);
- Data_ram::Read_latency::set(data_ram, 3);
- Data_ram::Write_latency::set(data_ram, 1);
- write(data_ram);
-
- Prefetch_ctrl::access_t prefetch = 0;
- Prefetch_ctrl::Data_prefetch::set(prefetch, 1);
- Prefetch_ctrl::Inst_prefetch::set(prefetch, 1);
- write(prefetch | 0xF);
- }
-
- using Hw::Pl310::invalidate;
-
- void enable()
- {
- Pl310::mask_interrupts();
- write(1);
- }
-
- void disable() {
- write(0);
- }
-};
-
-#endif /* _SRC__BOOTSTRAP__SPEC__IMX6Q_SABRELITE__BOARD_H_ */
diff --git a/repos/base-hw/src/bootstrap/board/imx7d_sabre/board.h b/repos/base-hw/src/bootstrap/board/imx7d_sabre/board.h
deleted file mode 100644
index b4c8446e8b..0000000000
--- a/repos/base-hw/src/bootstrap/board/imx7d_sabre/board.h
+++ /dev/null
@@ -1,29 +0,0 @@
-/*
- * \brief Imx7 Sabrelite specific board definitions
- * \author Stefan Kalkowski
- * \date 2018-11-07
- */
-
-/*
- * Copyright (C) 2018 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 _SRC__BOOTSTRAP__SPEC__IMX7_SABRELITE__BOARD_H_
-#define _SRC__BOOTSTRAP__SPEC__IMX7_SABRELITE__BOARD_H_
-
-#include
-#include
-#include
-#include
-
-namespace Board {
-
- using namespace Hw::Imx7d_sabre_board;
- using Pic = Hw::Gicv2;
- static constexpr bool NON_SECURE = true;
-}
-
-#endif /* _SRC__BOOTSTRAP__SPEC__IMX&_SABRELITE__BOARD_H_ */
diff --git a/repos/base-hw/src/bootstrap/board/imx7d_sabre/platform.cc b/repos/base-hw/src/bootstrap/board/imx7d_sabre/platform.cc
deleted file mode 100644
index 17e4a1ad5f..0000000000
--- a/repos/base-hw/src/bootstrap/board/imx7d_sabre/platform.cc
+++ /dev/null
@@ -1,249 +0,0 @@
-/*
- * \brief Parts of platform that are specific to Imx7 sabrelite
- * \author Stefan Kalkowski
- * \date 2018-11-07
- */
-
-/*
- * Copyright (C) 2018 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.
- */
-
-#include
-#include
-#include
-#include
-
-extern "C" void * _start_setup_stack; /* entrypoint for non-boot CPUs */
-
-using namespace Board;
-
-
-Bootstrap::Platform::Board::Board()
-:
- early_ram_regions(Memory_region { RAM_0_BASE, RAM_0_SIZE }),
- core_mmio(Memory_region { IRQ_CONTROLLER_BASE, IRQ_CONTROLLER_SIZE },
- Memory_region { UART_1_MMIO_BASE, UART_1_MMIO_SIZE })
-{
- Aipstz aipstz_1(AIPS_1_MMIO_BASE);
- Aipstz aipstz_2(AIPS_2_MMIO_BASE);
- Aipstz aipstz_3(AIPS_3_MMIO_BASE);
-
- /* configure CSU */
- for (addr_t start = 0x303e0000; start <= 0x303e00fc; start += 4)
- *(volatile addr_t *)start = 0x00ff00ff;
-
- static volatile unsigned long initial_values[][2] {
- // CCM (Clock Control Module)
- { 0x30384000, 0x3 },
- { 0x30384040, 0x3 },
- { 0x30384060, 0x3 },
- { 0x30384130, 0x3 },
- { 0x30384160, 0x0 },
- { 0x303844f0, 0x3 },
- { 0x30384510, 0x0 },
- { 0x30384520, 0x3 },
- { 0x303846d0, 0x0 },
- { 0x303846e0, 0x0 },
- { 0x30384780, 0x0 },
- { 0x30384790, 0x0 },
- { 0x303847a0, 0x0 },
- { 0x303847b0, 0x0 },
- { 0x303847c0, 0x3 },
- { 0x30384880, 0x0 },
- { 0x303848a0, 0x0 },
- { 0x30384950, 0x0 },
- { 0x30384960, 0x0 },
- { 0x30384970, 0x0 },
- { 0x30384980, 0x0 },
- { 0x30384990, 0x0 },
- { 0x303849a0, 0x0 },
- { 0x303849d0, 0x0 },
- { 0x303849e0, 0x0 },
- { 0x303849f0, 0x0 },
- { 0x303600c0, 0xd2605a56 },
- { 0x303600d0, 0xd2d2d256 },
- { 0x303600d4, 0xd2d2d256 },
- { 0x303600d8, 0xd2d2d256 },
- { 0x303600dc, 0xd2d2d256 },
- { 0x303600e0, 0x80000600 },
- { 0x303600f0, 0x101b },
- // IOMUXC (IOMUX Controller)
- { 0x30330030, 0x14 },
- { 0x30330034, 0x10 },
- { 0x30330074, 0x2 },
- { 0x30330078, 0x2 },
- { 0x3033007c, 0x2 },
- { 0x30330080, 0x2 },
- { 0x30330084, 0x2 },
- { 0x30330088, 0x2 },
- { 0x3033008c, 0x2 },
- { 0x30330090, 0x2 },
- { 0x30330094, 0x2 },
- { 0x30330098, 0x2 },
- { 0x3033009c, 0x2 },
- { 0x303300a0, 0x2 },
- { 0x303300c4, 0x0 },
- { 0x30330150, 0x10 },
- { 0x30330154, 0x10 },
- { 0x30330210, 0x13 },
- { 0x30330214, 0x13 },
- { 0x3033021c, 0x1 },
- { 0x30330220, 0x1 },
- { 0x30330224, 0x1 },
- { 0x303302e4, 0x1 },
- { 0x303302e8, 0x1 },
- { 0x303302ec, 0x1 },
- { 0x303302f0, 0x1 },
- { 0x303302f4, 0x1 },
- { 0x303302f8, 0x1 },
- { 0x303302fc, 0x1 },
- { 0x30330300, 0x1 },
- { 0x30330304, 0x1 },
- { 0x30330308, 0x1 },
- { 0x3033030c, 0x1 },
- { 0x30330310, 0x1 },
- { 0x30330318, 0x59 },
- { 0x303303c0, 0x7f },
- { 0x303303c4, 0x7f },
- { 0x303303f4, 0x34 },
- { 0x303303f8, 0x59 },
- { 0x303303fc, 0x59 },
- { 0x30330400, 0x59 },
- { 0x30330404, 0x19 },
- { 0x30330408, 0x59 },
- { 0x3033040c, 0x59 },
- { 0x30330410, 0x59 },
- { 0x30330414, 0x59 },
- { 0x30330418, 0x59 },
- { 0x3033041c, 0x59 },
- { 0x30330440, 0x19 },
- { 0x30330444, 0x59 },
- { 0x30330448, 0x59 },
- { 0x3033044c, 0x59 },
- { 0x30330450, 0x59 },
- { 0x30330454, 0x59 },
- { 0x30330458, 0x59 },
- { 0x3033045c, 0x59 },
- { 0x30330460, 0x59 },
- { 0x30330464, 0x59 },
- { 0x30330468, 0x19 },
- { 0x30330480, 0x7f },
- { 0x30330484, 0x7f },
- { 0x3033048c, 0x2 },
- { 0x30330490, 0x2 },
- { 0x30330494, 0x2 },
- { 0x3033049c, 0x1 },
- { 0x303304a0, 0x1 },
- { 0x303304a4, 0x1 },
- { 0x303304a8, 0x1 },
- { 0x303304ac, 0x1 },
- { 0x303304b0, 0x1 },
- { 0x303304b4, 0x1 },
- { 0x303304b8, 0x1 },
- { 0x303304bc, 0x1 },
- { 0x303304c0, 0x1 },
- { 0x303304c4, 0x1 },
- { 0x303304c8, 0x1 },
- { 0x30330544, 0x1 },
- { 0x30330548, 0x1 },
- { 0x3033054c, 0x1 },
- { 0x303305dc, 0x1 },
- { 0x303305e0, 0x1 },
- { 0x303305ec, 0x3 },
- { 0x303305f0, 0x3 }
- };
-
- unsigned num_values = sizeof(initial_values) / (2*sizeof(unsigned long));
- for (unsigned i = 0; i < num_values; i++)
- *((volatile unsigned long*)initial_values[i][0]) = initial_values[i][1];
-
-}
-
-
-static inline void switch_to_supervisor_mode(unsigned cpu_id)
-{
- using Cpsr = Hw::Arm_cpu::Psr;
-
- Cpsr::access_t cpsr = 0;
- Cpsr::M::set(cpsr, Cpsr::M::SVC);
- Cpsr::F::set(cpsr, 1);
- Cpsr::I::set(cpsr, 1);
-
- Genode::addr_t const stack = Hw::Mm::hypervisor_stack().base +
- (cpu_id+1) * 0x1000;
-
- asm volatile (
- "msr sp_svc, sp \n" /* copy current mode's sp */
- "msr lr_svc, lr \n" /* copy current mode's lr */
- "msr elr_hyp, lr \n" /* copy current mode's lr to hyp lr */
- "msr sp_hyp, %[stack] \n" /* copy to hyp stack pointer */
- "msr spsr_cxfs, %[cpsr] \n" /* set psr for supervisor mode */
- "adr lr, 1f \n" /* load exception return address */
- "eret \n" /* exception return */
- "1:":: [cpsr] "r" (cpsr), [stack] "r" (stack));
-}
-
-
-unsigned Bootstrap::Platform::enable_mmu()
-{
- static volatile bool primary_cpu = true;
- static unsigned long timer_freq = Cpu::Cntfrq::read();
- unsigned cpu = Cpu::Mpidr::Aff_0::get(Cpu::Mpidr::read());
-
- /* locally initialize interrupt controller */
- ::Board::Pic pic { };
-
- prepare_nonsecure_world(timer_freq);
- prepare_hypervisor((addr_t)core_pd->table_base);
- switch_to_supervisor_mode(cpu);
-
- Cpu::Sctlr::init();
- Cpu::Cpsr::init();
-
- /* primary cpu wakes up all others */
- if (primary_cpu && NR_OF_CPUS > 1) {
- Cpu::invalidate_data_cache();
- primary_cpu = false;
- Cpu::wake_up_all_cpus(&_start_setup_stack);
- }
-
- Cpu::enable_mmu_and_caches((Genode::addr_t)core_pd->table_base);
-
- return cpu;
-}
-
-
-void Board::Cpu::wake_up_all_cpus(void * const ip)
-{
- struct Src : Genode::Mmio
- {
- struct A7_cr0 : Register<0x4, 32>
- {
- struct Core1_por_reset : Bitfield<1,1> {};
- struct Core1_soft_reset : Bitfield<5,1> {};
- };
- struct A7_cr1 : Register<0x8, 32>
- {
- struct Core1_enable : Bitfield<1,1> {};
- };
- struct Gpr3 : Register<0x7c, 32> {}; /* ep core 1 */
- struct Gpr4 : Register<0x80, 32> {}; /* ep core 1 */
-
- Src(void * const entry) : Genode::Mmio(SRC_MMIO_BASE)
- {
- write((Gpr3::access_t)entry);
- write((Gpr4::access_t)entry);
- A7_cr0::access_t v0 = read();
- A7_cr0::Core1_soft_reset::set(v0,1);
- write(v0);
- A7_cr1::access_t v1 = read();
- A7_cr1::Core1_enable::set(v1,1);
- write(v1);
- }
- };
-
- Src src(ip);
-}
diff --git a/repos/base-hw/src/bootstrap/board/nit6_solox/board.h b/repos/base-hw/src/bootstrap/board/nit6_solox/board.h
deleted file mode 100644
index b6df2e5c1d..0000000000
--- a/repos/base-hw/src/bootstrap/board/nit6_solox/board.h
+++ /dev/null
@@ -1,282 +0,0 @@
-/*
- * \brief Nit6 SOLOX specific board definitions
- * \author Stefan Kalkowski
- * \date 2017-10-18
- */
-
-/*
- * Copyright (C) 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 _SRC__BOOTSTRAP__SPEC__NIT6_SOLOX__BOARD_H_
-#define _SRC__BOOTSTRAP__SPEC__NIT6_SOLOX__BOARD_H_
-
-#include
-#include
-#include
-#include
-#include
-
-namespace Board {
-
- using namespace Hw::Nit6_solox_board;
- using Pic = Hw::Gicv2;
- struct L2_cache;
-
- static constexpr bool NON_SECURE = false;
-
- static volatile unsigned long initial_values[][2] {
- // (IOMUX Controller)
- { 0x20E006C, 0x0},
- { 0x20E00CC, 0x10},
- { 0x20E00D0, 0x10},
- { 0x20E00D4, 0x10},
- { 0x20E00D8, 0x10},
- { 0x20E00DC, 0x10},
- { 0x20E00E0, 0x10},
- { 0x20E00E4, 0x10},
- { 0x20E00E8, 0x10},
- { 0x20E00EC, 0x10},
- { 0x20E00F0, 0x10},
- { 0x20E00F4, 0x10},
- { 0x20E00F8, 0x10},
- { 0x20E00FC, 0x10},
- { 0x20E0100, 0x10},
- { 0x20E0104, 0x10},
- { 0x20E0108, 0x10},
- { 0x20E010C, 0x10},
- { 0x20E0110, 0x10},
- { 0x20E0114, 0x10},
- { 0x20E0118, 0x10},
- { 0x20E011C, 0x10},
- { 0x20E0120, 0x10},
- { 0x20E0124, 0x10},
- { 0x20E0128, 0x10},
- { 0x20E012C, 0x10},
- { 0x20E0130, 0x10},
- { 0x20E0134, 0x10},
- { 0x20E0138, 0x15},
- { 0x20E013C, 0x10},
- { 0x20E0150, 0x5},
- { 0x20E0154, 0x5},
- { 0x20E0158, 0x5},
- { 0x20E0224, 0x5},
- { 0x20E0268, 0x5},
- { 0x20E026C, 0x5},
- { 0x20E0270, 0x3},
- { 0x20E0274, 0x3},
- { 0x20E035C, 0x1b8b1},
- { 0x20E0360, 0x1b8b1},
- { 0x20E0364, 0x1b8b1},
- { 0x20E0368, 0x1b8b1},
- { 0x20E0380, 0x1b0b0},
- { 0x20E0384, 0x170b1},
- { 0x20E0390, 0x110b0},
- { 0x20E0394, 0x110b0},
- { 0x20E0398, 0x110b0},
- { 0x20E039C, 0x110b0},
- { 0x20E03A0, 0x110b0},
- { 0x20E03A4, 0x110b0},
- { 0x20E03A8, 0x110b0},
- { 0x20E03AC, 0x110b0},
- { 0x20E03B0, 0x110b0},
- { 0x20E03B4, 0x110b0},
- { 0x20E03B8, 0x110b0},
- { 0x20E03BC, 0x110b0},
- { 0x20E03C0, 0x110b0},
- { 0x20E03D4, 0xb0b0},
- { 0x20E03D8, 0xb0b0},
- { 0x20E03DC, 0xb0b0},
- { 0x20E03E0, 0xb0b0},
- { 0x20E03E4, 0xb0b0},
- { 0x20E03E8, 0xb0b0},
- { 0x20E03FC, 0x1b8b1},
- { 0x20E0404, 0xb0b1},
- { 0x20E0408, 0x1b0b0},
- { 0x20E0410, 0x1b8b1},
- { 0x20E0414, 0x1b0b0},
- { 0x20E0418, 0x1b0b0},
- { 0x20E041C, 0x1b0b0},
- { 0x20E0420, 0x1b0b0},
- { 0x20E0424, 0x1b0b0},
- { 0x20E0428, 0x1b0b0},
- { 0x20E042C, 0x1b0b0},
- { 0x20E0430, 0x1b0b0},
- { 0x20E0434, 0x1b0b0},
- { 0x20E0438, 0x1b0b0},
- { 0x20E043C, 0x1b0b0},
- { 0x20E0440, 0x1b0b0},
- { 0x20E0444, 0x1b0b0},
- { 0x20E0448, 0x1b0b0},
- { 0x20E044C, 0x1b0b0},
- { 0x20E0450, 0x1b0b0},
- { 0x20E0454, 0x1b0b0},
- { 0x20E0458, 0x1b0b0},
- { 0x20E045C, 0x1b0b0},
- { 0x20E0460, 0x1b0b0},
- { 0x20E0464, 0x1b0b0},
- { 0x20E0468, 0x1b0b0},
- { 0x20E046C, 0x1b0b0},
- { 0x20E0470, 0x1b0b0},
- { 0x20E0474, 0x1b0b0},
- { 0x20E0478, 0x1b0b0},
- { 0x20E047C, 0x1b0b0},
- { 0x20E0480, 0x1b0b0},
- { 0x20E0484, 0x1b0b0},
- { 0x20E0488, 0xb0b0},
- { 0x20E0490, 0x30b0},
- { 0x20E0498, 0x30b1},
- { 0x20E049C, 0x30b0},
- { 0x20E04A0, 0x30b1},
- { 0x20E04A4, 0xb0b1},
- { 0x20E04AC, 0x30b0},
- { 0x20E04B0, 0x30b0},
- { 0x20E04B4, 0x30b0},
- { 0x20E04E0, 0xb0b0},
- { 0x20E04E8, 0xb0b0},
- { 0x20E04F0, 0xb0b0},
- { 0x20E04F4, 0xb0b0},
- { 0x20E0508, 0x3081},
- { 0x20E050C, 0x3081},
- { 0x20E0510, 0x3081},
- { 0x20E0514, 0x3081},
- { 0x20E0518, 0x3081},
- { 0x20E051C, 0x3081},
- { 0x20E0520, 0x30b1},
- { 0x20E0524, 0x30b1},
- { 0x20E0528, 0x30b1},
- { 0x20E052C, 0x30b1},
- { 0x20E0530, 0x30b1},
- { 0x20E0534, 0x30b1},
- { 0x20E0538, 0x3081},
- { 0x20E053C, 0x3081},
- { 0x20E0540, 0x3081},
- { 0x20E0544, 0x3081},
- { 0x20E0548, 0x3081},
- { 0x20E054C, 0x3081},
- { 0x20E0550, 0x30b1},
- { 0x20E0554, 0x30b1},
- { 0x20E0558, 0x30b1},
- { 0x20E055C, 0x30b1},
- { 0x20E0560, 0x30b1},
- { 0x20E0564, 0x30b1},
- { 0x20E056C, 0x30b0},
- { 0x20E0570, 0x1b0b0},
- { 0x20E0574, 0x1b0b0},
- { 0x20E0578, 0x1b0b0},
- { 0x20E057C, 0x1b0b0},
- { 0x20E0598, 0x10071},
- { 0x20E059C, 0x17071},
- { 0x20E05A0, 0x17071},
- { 0x20E05A4, 0x17071},
- { 0x20E05A8, 0x17071},
- { 0x20E05AC, 0x17071},
- { 0x20E05B0, 0x1b0b0},
- { 0x20E05B4, 0x1b0b0},
- { 0x20E05B8, 0x1b0b1},
- { 0x20E05BC, 0x1b0b1},
- { 0x20E05C0, 0x100f9},
- { 0x20E05C4, 0x170f9},
- { 0x20E05C8, 0x170f9},
- { 0x20E05CC, 0x170f9},
- { 0x20E05D0, 0x170f9},
- { 0x20E05D4, 0x170f9},
- { 0x20E05D8, 0x170f9},
- { 0x20E05DC, 0x170f9},
- { 0x20E05E0, 0x170f9},
- { 0x20E05E4, 0x170f9},
- { 0x20E05E8, 0x17071},
- { 0x20E083C, 0x2},
- // (Global Power Controller}
- { 0x20DC000, 0x140000},
- { 0x20DC008, 0x2077fe0b},
- { 0x20DC00C, 0xff7db18f},
- { 0x20DC010, 0xfbfe0003},
- { 0x20DC014, 0xff2ff93f},
- // (Power Management Unit}
- { 0x20C8120, 0x11775},
- { 0x20C8140, 0x4c0016},
- { 0x20C8160, 0x8003000a},
- // (Clock Controller Module}
- { 0x20C4004, 0x20000},
- { 0x20C4018, 0x269114},
- { 0x20C401C, 0x4510a9c0},
- { 0x20C4020, 0x13212c06},
- { 0x20C4028, 0x0},
- { 0x20C402C, 0x4b600},
- { 0x20C4030, 0x30074792},
- { 0x20C4038, 0x12153},
- { 0x20C4054, 0x78},
- { 0x20C4060, 0x10e008e},
- { 0x20C4064, 0x2fe62},
- { 0x20C4068, 0xf0c03f0f},
- { 0x20C406C, 0x333c0c00},
- { 0x20C4070, 0x3fff003f},
- { 0x20C4074, 0xfff33ff3},
- { 0x20C4078, 0xc0c3fc},
- { 0x20C407C, 0xf030fff},
- { 0x20C4080, 0x3cfc33},
- { 0x20C8000, 0x80002053},
- { 0x20C8010, 0x80003040},
- { 0x20C8020, 0x3840},
- { 0x20C8070, 0x119006},
- { 0x20C80A0, 0x80002025},
- { 0x20C80B0, 0x13a74},
- { 0x20C80C0, 0xf4240},
- { 0x20C80E0, 0x8030200f},
- { 0x20C80F0, 0xd3d1d0cc},
- { 0x20C8100, 0x5258d0db}
- };
-}
-
-
-struct Board::L2_cache : Hw::Pl310
-{
- L2_cache(Genode::addr_t mmio) : Hw::Pl310(mmio)
- {
- Aux::access_t aux = 0;
- Aux::Full_line_of_zero::set(aux, true);
- Aux::Associativity::set(aux, Aux::Associativity::WAY_16);
- Aux::Way_size::set(aux, Aux::Way_size::KB_16);
- Aux::Replacement_policy::set(aux, Aux::Replacement_policy::PRAND);
- Aux::Ns_lockdown::set(aux, true);
- Aux::Data_prefetch::set(aux, true);
- Aux::Inst_prefetch::set(aux, true);
- Aux::Early_bresp::set(aux, true);
- write(aux);
-
- Tag_ram::access_t tag_ram = 0;
- Tag_ram::Setup_latency::set(tag_ram, 2);
- Tag_ram::Read_latency::set(tag_ram, 3);
- Tag_ram::Write_latency::set(tag_ram, 1);
- write(tag_ram);
-
- Data_ram::access_t data_ram = 0;
- Data_ram::Setup_latency::set(data_ram, 2);
- Data_ram::Read_latency::set(data_ram, 3);
- Data_ram::Write_latency::set(data_ram, 1);
- write(data_ram);
-
- Prefetch_ctrl::access_t prefetch = read();
- Prefetch_ctrl::Data_prefetch::set(prefetch, 1);
- Prefetch_ctrl::Inst_prefetch::set(prefetch, 1);
- write(prefetch | 0xF);
- }
-
- using Hw::Pl310::invalidate;
-
- void enable()
- {
- Pl310::mask_interrupts();
- write(1);
- }
-
- void disable() {
- write(0);
- }
-};
-
-#endif /* _SRC__BOOTSTRAP__SPEC__NIT6_SOLOX__BOARD_H_ */
diff --git a/repos/base-hw/src/bootstrap/board/pbxa9/platform.cc b/repos/base-hw/src/bootstrap/board/pbxa9/platform.cc
index 8746729b57..6c71be40d1 100644
--- a/repos/base-hw/src/bootstrap/board/pbxa9/platform.cc
+++ b/repos/base-hw/src/bootstrap/board/pbxa9/platform.cc
@@ -40,12 +40,12 @@ void Board::Cpu::wake_up_all_cpus(void * const ip)
* read out this register and jump to it after the cpu received
* an interrupt
*/
- struct System_control : Genode::Mmio
+ struct System_control : Genode::Mmio<0x38>
{
struct Flagsset : Register<0x30, 32> { };
struct Flagsclr : Register<0x34, 32> { };
- System_control(void * const ip) : Mmio(SYSTEM_CONTROL_MMIO_BASE)
+ System_control(void * const ip) : Mmio({(char *)SYSTEM_CONTROL_MMIO_BASE, Mmio::SIZE})
{
write(~0UL);
write(reinterpret_cast(ip));
diff --git a/repos/base-hw/src/bootstrap/board/usb_armory/board.h b/repos/base-hw/src/bootstrap/board/usb_armory/board.h
deleted file mode 100644
index 17540a22bb..0000000000
--- a/repos/base-hw/src/bootstrap/board/usb_armory/board.h
+++ /dev/null
@@ -1,32 +0,0 @@
-/*
- * \brief i.MX53 Quickstart board definitions
- * \author Stefan Kalkowski
- * \date 2017-03-22
- */
-
-/*
- * Copyright (C) 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 _SRC__BOOTSTRAP__SPEC__USB_ARMORY__BOARD_H_
-#define _SRC__BOOTSTRAP__SPEC__USB_ARMORY__BOARD_H_
-
-#include
-#include
-
-#include
-#include
-
-namespace Board {
-
- using namespace Hw::Usb_armory_board;
-
- using Hw::Pic;
-
- bool secure_irq(unsigned irq);
-}
-
-#endif /* _SRC__BOOTSTRAP__SPEC__USB_ARMORY__BOARD_H_ */
diff --git a/repos/base-hw/src/bootstrap/board/usb_armory/platform.cc b/repos/base-hw/src/bootstrap/board/usb_armory/platform.cc
deleted file mode 100644
index e055ae8f59..0000000000
--- a/repos/base-hw/src/bootstrap/board/usb_armory/platform.cc
+++ /dev/null
@@ -1,56 +0,0 @@
-/*
- * \brief Specific i.MX53 bootstrap implementations
- * \author Stefan Kalkowski
- * \date 2012-10-24
- */
-
-/*
- * 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.
- */
-
-#include
-#include
-#include
-#include
-
-using namespace Board;
-
-
-bool Board::secure_irq(unsigned i)
-{
- if (i == EPIT_1_IRQ) return true;
- if (i == EPIT_2_IRQ) return true;
- if (i == SDHC_IRQ) return true;
- return false;
-}
-
-
-Bootstrap::Platform::Board::Board()
-:
- early_ram_regions(Memory_region { Trustzone::SECURE_RAM_BASE,
- Trustzone::SECURE_RAM_SIZE }),
- core_mmio(Memory_region { UART_1_MMIO_BASE, UART_1_MMIO_SIZE },
- Memory_region { EPIT_1_MMIO_BASE, EPIT_1_MMIO_SIZE },
- Memory_region { IRQ_CONTROLLER_BASE, IRQ_CONTROLLER_SIZE },
- Memory_region { CSU_BASE, CSU_SIZE })
-{
- Aipstz aipstz_1(AIPS_1_MMIO_BASE);
- Aipstz aipstz_2(AIPS_2_MMIO_BASE);
-
- Pic pic {};
-
- /* set monitor mode exception vector entry */
- Cpu::Mvbar::write(Hw::Mm::system_exception_vector().base);
-
- /* enable coprocessor 10 + 11 access for TZ VMs */
- Cpu::Nsacr::access_t v = 0;
- Cpu::Nsacr::Cpnsae10::set(v, 1);
- Cpu::Nsacr::Cpnsae11::set(v, 1);
- Cpu::Nsacr::write(v);
-
- /* configure central security unit */
- Csu csu(CSU_BASE, true, false, true, false);
-}
diff --git a/repos/base-hw/src/bootstrap/board/virt_qemu_arm_v7a/board.h b/repos/base-hw/src/bootstrap/board/virt_qemu_arm_v7a/board.h
index 4956b88bfc..0aaa5fc957 100644
--- a/repos/base-hw/src/bootstrap/board/virt_qemu_arm_v7a/board.h
+++ b/repos/base-hw/src/bootstrap/board/virt_qemu_arm_v7a/board.h
@@ -27,6 +27,8 @@ namespace Board {
using Psci = Hw::Psci;
using Pic = Hw::Gicv2;
static constexpr bool NON_SECURE = true;
+
+ static constexpr Genode::size_t NR_OF_CPUS = 2;
};
#endif /* _SRC__BOOTSTRAP__SPEC__VIRT__QEMU_H_ */
diff --git a/repos/base-hw/src/bootstrap/board/virt_qemu_arm_v7a/platform.cc b/repos/base-hw/src/bootstrap/board/virt_qemu_arm_v7a/platform.cc
index cf8e55cc2f..ead6097701 100644
--- a/repos/base-hw/src/bootstrap/board/virt_qemu_arm_v7a/platform.cc
+++ b/repos/base-hw/src/bootstrap/board/virt_qemu_arm_v7a/platform.cc
@@ -66,7 +66,7 @@ unsigned Bootstrap::Platform::enable_mmu()
::Board::Pic pic { };
/* primary cpu wakes up all others */
- if (primary_cpu && NR_OF_CPUS > 1) {
+ if (primary_cpu && ::Board::NR_OF_CPUS > 1) {
Cpu::invalidate_data_cache();
primary_cpu = false;
Cpu::wake_up_all_cpus(&_start_setup_stack);
diff --git a/repos/base-hw/src/bootstrap/board/virt_qemu_arm_v8a/board.h b/repos/base-hw/src/bootstrap/board/virt_qemu_arm_v8a/board.h
index 62a197fb70..b3ebd2f231 100644
--- a/repos/base-hw/src/bootstrap/board/virt_qemu_arm_v8a/board.h
+++ b/repos/base-hw/src/bootstrap/board/virt_qemu_arm_v8a/board.h
@@ -31,6 +31,8 @@ namespace Board {
static void wake_up_all_cpus(void*);
};
+ static constexpr Genode::size_t NR_OF_CPUS = 4;
+
using Hw::Pic;
};
diff --git a/repos/base-hw/src/bootstrap/board/wand_quad/board.h b/repos/base-hw/src/bootstrap/board/wand_quad/board.h
deleted file mode 100644
index c52d24e810..0000000000
--- a/repos/base-hw/src/bootstrap/board/wand_quad/board.h
+++ /dev/null
@@ -1,258 +0,0 @@
-/*
- * \brief Pbxa9 specific board definitions
- * \author Stefan Kalkowski
- * \date 2017-02-20
- */
-
-/*
- * Copyright (C) 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 _SRC__BOOTSTRAP__SPEC__WAND_QUAD__BOARD_H_
-#define _SRC__BOOTSTRAP__SPEC__WAND_QUAD__BOARD_H_
-
-#include
-#include
-#include
-#include
-#include
-
-namespace Board {
-
- using namespace Hw::Wand_quad_board;
-
- using Pic = Hw::Gicv2;
-
- struct L2_cache;
-
- static constexpr bool NON_SECURE = false;
-
- static volatile unsigned long initial_values[][2] {
- // (IOMUX Controller)
- { 0x20e0000, 0x1 },
- { 0x20e0004, 0x48643005 },
- { 0x20e0008, 0x221 },
- { 0x20e000c, 0x1e00040 },
- { 0x20e0034, 0x593e4a4 },
- { 0x20e004c, 0x0 },
- { 0x20e0050, 0x0 },
- { 0x20e0054, 0x0 },
- { 0x20e0090, 0x1 },
- { 0x20e0094, 0x1 },
- { 0x20e0098, 0x1 },
- { 0x20e00a4, 0x16 },
- { 0x20e00a8, 0x4 },
- { 0x20e00ac, 0x2 },
- { 0x20e00b0, 0x2 },
- { 0x20e00b4, 0x2 },
- { 0x20e00b8, 0x2 },
- { 0x20e00c4, 0x11 },
- { 0x20e015c, 0x0 },
- { 0x20e0160, 0x0 },
- { 0x20e0164, 0x0 },
- { 0x20e0168, 0x0 },
- { 0x20e016c, 0x0 },
- { 0x20e0170, 0x0 },
- { 0x20e0174, 0x0 },
- { 0x20e0178, 0x0 },
- { 0x20e017c, 0x0 },
- { 0x20e0180, 0x0 },
- { 0x20e0184, 0x0 },
- { 0x20e0188, 0x0 },
- { 0x20e018c, 0x0 },
- { 0x20e0190, 0x0 },
- { 0x20e0194, 0x0 },
- { 0x20e0198, 0x0 },
- { 0x20e019c, 0x0 },
- { 0x20e01a0, 0x0 },
- { 0x20e01a4, 0x0 },
- { 0x20e01a8, 0x0 },
- { 0x20e01ac, 0x0 },
- { 0x20e01b0, 0x0 },
- { 0x20e01b4, 0x0 },
- { 0x20e01b8, 0x0 },
- { 0x20e01bc, 0x0 },
- { 0x20e01c0, 0x0 },
- { 0x20e01c4, 0x0 },
- { 0x20e01c8, 0x0 },
- { 0x20e01cc, 0x0 },
- { 0x20e01d4, 0x1 },
- { 0x20e01e4, 0x3 },
- { 0x20e0220, 0x0 },
- { 0x20e0224, 0x3 },
- { 0x20e022c, 0x4 },
- { 0x20e023c, 0x16 },
- { 0x20e0248, 0x12 },
- { 0x20e0250, 0x5 },
- { 0x20e0264, 0x5 },
- { 0x20e0268, 0x4 },
- { 0x20e026c, 0x4 },
- { 0x20e0270, 0x4 },
- { 0x20e0274, 0x4 },
- { 0x20e02b8, 0x0 },
- { 0x20e0320, 0x2 },
- { 0x20e0348, 0x0 },
- { 0x20e0354, 0x0 },
- { 0x20e0358, 0x0 },
- { 0x20e035c, 0x0 },
- { 0x20e0360, 0x17059 },
- { 0x20e0364, 0x17059 },
- { 0x20e0368, 0x17059 },
- { 0x20e03a0, 0xf0b0 },
- { 0x20e03a4, 0x100b1 },
- { 0x20e03a8, 0x100b1 },
- { 0x20e03ac, 0x100b1 },
- { 0x20e03b8, 0x1b8b1 },
- { 0x20e03c0, 0x1b0b1 },
- { 0x20e03c4, 0x1b0b1 },
- { 0x20e03c8, 0x1b0b1 },
- { 0x20e03cc, 0x1b0b1 },
- { 0x20e03d8, 0x1b8b1 },
- { 0x20e0470, 0x10 },
- { 0x20e0474, 0x10 },
- { 0x20e0478, 0x10 },
- { 0x20e047c, 0x10 },
- { 0x20e0484, 0x10 },
- { 0x20e0488, 0x10 },
- { 0x20e048c, 0x10 },
- { 0x20e0490, 0x10 },
- { 0x20e0494, 0x10 },
- { 0x20e0498, 0x10 },
- { 0x20e049c, 0x10 },
- { 0x20e04a0, 0x10 },
- { 0x20e04a4, 0x10 },
- { 0x20e04a8, 0x10 },
- { 0x20e04ac, 0x10 },
- { 0x20e04b0, 0x10 },
- { 0x20e04b4, 0x10 },
- { 0x20e04b8, 0x10 },
- { 0x20e04bc, 0x10 },
- { 0x20e04c0, 0x10 },
- { 0x20e04c4, 0x10 },
- { 0x20e04c8, 0x10 },
- { 0x20e04cc, 0x10 },
- { 0x20e04d0, 0x10 },
- { 0x20e04d4, 0x10 },
- { 0x20e04d8, 0x10 },
- { 0x20e04dc, 0x10 },
- { 0x20e04e0, 0x10 },
- { 0x20e05e8, 0xb0 },
- { 0x20e05f0, 0xb0 },
- { 0x20e05f4, 0x17059 },
- { 0x20e05fc, 0xb0 },
- { 0x20e0600, 0xb0b0 },
- { 0x20e060c, 0x1b8b1 },
- { 0x20e0618, 0x1b0a8 },
- { 0x20e0638, 0x130b0 },
- { 0x20e063c, 0x110b0 },
- { 0x20e0640, 0x130b0 },
- { 0x20e0644, 0x130b0 },
- { 0x20e064c, 0x1b0b0 },
- { 0x20e06a4, 0x10059 },
- { 0x20e0704, 0x0 },
- { 0x20e0708, 0x1b0b1 },
- { 0x20e0738, 0x10059 },
- { 0x20e073c, 0x10059 },
- { 0x20e0740, 0x17059 },
- { 0x20e0744, 0x17059 },
- { 0x20e083c, 0x1 },
- { 0x20e0870, 0x0 },
- { 0x20e0874, 0x0 },
- { 0x20e08a8, 0x2 },
- { 0x20e08ac, 0x2 },
- { 0x20e092c, 0x1 },
- { 0x20e0930, 0x1 },
-
- // (Global Power Controller)
- { 0x20dc008, 0x6a23e613 },
- { 0x20dc00c, 0xff69b64f },
- { 0x20dc010, 0xfffe0003 },
- { 0x20dc014, 0xff30f7ff },
-
- // (Power Management Unit)
- { 0x20c8120, 0x11775 },
- { 0x20c8140, 0x580016 },
- { 0x20c8160, 0x8000000b },
- { 0x20c8170, 0xc0672f67 },
-
- // (Clock Controller Module)
- { 0x20c4018, 0x10204 },
- { 0x20c402c, 0x7312c1 },
- { 0x20c4030, 0x32271f92 },
- { 0x20c4034, 0x12680 },
- { 0x20c4038, 0x12090 },
- { 0x20c4054, 0x78 },
- { 0x20c4058, 0x41a0000 },
- { 0x20c4060, 0x10e0101 },
- { 0x20c4064, 0x2fe62 },
- { 0x20c4068, 0xc03f0f },
- { 0x20c406c, 0x30fc00 },
- { 0x20c4070, 0x3ff0033 },
- { 0x20c4074, 0x3ff3303f },
- { 0x20c4078, 0x30c300 },
- { 0x20c407c, 0xf0000f3 },
- { 0x20c4080, 0xc00 },
- { 0x20c8000, 0x80002053 },
- { 0x20c8020, 0x3040 },
- { 0x20c8070, 0x1006 },
- { 0x20c80a0, 0x80002031 },
- { 0x20c80b0, 0x7a120 },
- { 0x20c80c0, 0xf4240 },
- { 0x20c80e0, 0x80002003 },
- { 0x20c80f0, 0x9391508c },
- { 0x20c8100, 0x5058d01b }
- };
-}
-
-
-struct Board::L2_cache : Hw::Pl310
-{
- L2_cache(Genode::addr_t mmio) : Hw::Pl310(mmio)
- {
- Aux::access_t aux = 0;
- Aux::Full_line_of_zero::set(aux, true);
- Aux::Associativity::set(aux, Aux::Associativity::WAY_16);
- Aux::Way_size::set(aux, Aux::Way_size::KB_64);
- Aux::Share_override::set(aux, true);
- Aux::Replacement_policy::set(aux, Aux::Replacement_policy::PRAND);
- Aux::Ns_lockdown::set(aux, true);
- Aux::Data_prefetch::set(aux, true);
- Aux::Inst_prefetch::set(aux, true);
- Aux::Early_bresp::set(aux, true);
- write(aux);
-
- Tag_ram::access_t tag_ram = 0;
- Tag_ram::Setup_latency::set(tag_ram, 2);
- Tag_ram::Read_latency::set(tag_ram, 3);
- Tag_ram::Write_latency::set(tag_ram, 1);
- write(tag_ram);
-
- Data_ram::access_t data_ram = 0;
- Data_ram::Setup_latency::set(data_ram, 2);
- Data_ram::Read_latency::set(data_ram, 3);
- Data_ram::Write_latency::set(data_ram, 1);
- write(data_ram);
-
- Prefetch_ctrl::access_t prefetch = 0;
- Prefetch_ctrl::Data_prefetch::set(prefetch, 1);
- Prefetch_ctrl::Inst_prefetch::set(prefetch, 1);
- write(prefetch | 0xF);
- }
-
- using Hw::Pl310::invalidate;
-
- void enable()
- {
- Pl310::mask_interrupts();
- write(1);
- }
-
- void disable() {
- write(0);
- }
-};
-
-#endif /* _SRC__BOOTSTRAP__SPEC__WAND_QUAD__BOARD_H_ */
diff --git a/repos/base-hw/src/bootstrap/env.cc b/repos/base-hw/src/bootstrap/env.cc
deleted file mode 100644
index 64ab81b271..0000000000
--- a/repos/base-hw/src/bootstrap/env.cc
+++ /dev/null
@@ -1,22 +0,0 @@
-/*
- * \brief Environment dummy implementation needed by cxx library
- * \author Stefan Kalkowski
- * \date 2016-09-23
- */
-
-/*
- * Copyright (C) 2016-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.
- */
-
-#include
-#include
-#include
-
-Genode::Env_deprecated * Genode::env_deprecated()
-{
- assert(false);
- return nullptr;
-}
diff --git a/repos/base-hw/src/bootstrap/init.cc b/repos/base-hw/src/bootstrap/init.cc
index 0cc92720fb..9fcda2fec3 100644
--- a/repos/base-hw/src/bootstrap/init.cc
+++ b/repos/base-hw/src/bootstrap/init.cc
@@ -18,6 +18,13 @@
#include
#include
+using namespace Genode;
+
+static constexpr size_t STACK_SIZE = 0x2000;
+
+size_t bootstrap_stack_size = STACK_SIZE;
+uint8_t bootstrap_stack[Board::NR_OF_CPUS][STACK_SIZE]
+__attribute__((aligned(get_page_size())));
Bootstrap::Platform & Bootstrap::platform() {
return *unmanaged_singleton(); }
diff --git a/repos/base-hw/src/bootstrap/platform.cc b/repos/base-hw/src/bootstrap/platform.cc
index 8f56824ac3..93c17f91fb 100644
--- a/repos/base-hw/src/bootstrap/platform.cc
+++ b/repos/base-hw/src/bootstrap/platform.cc
@@ -13,6 +13,7 @@
#include
#include
+#include
#include
#include
@@ -66,9 +67,9 @@ Platform::Pd::Pd(Platform::Ram_allocator & alloc)
using namespace Genode;
addr_t const table_virt_base = Hw::Mm::core_page_tables().base;
map_insert(Mapping((addr_t)table_base, table_virt_base,
- sizeof(Table), Hw::PAGE_FLAGS_KERN_DATA));
+ sizeof(Table), Genode::PAGE_FLAGS_KERN_DATA));
map_insert(Mapping((addr_t)array_base, table_virt_base + sizeof(Table),
- sizeof(Table_array), Hw::PAGE_FLAGS_KERN_DATA));
+ sizeof(Table_array), Genode::PAGE_FLAGS_KERN_DATA));
}
@@ -149,6 +150,36 @@ Mapping Platform::_load_elf()
}
+void Platform::_prepare_cpu_memory_area(size_t cpu_id)
+{
+ using namespace Genode;
+ using namespace Hw;
+ using namespace Hw::Mm;
+
+ size_t slots = cpu_local_memory().size / CPU_LOCAL_MEMORY_SLOT_SIZE;
+
+ if (cpu_id >= slots) {
+ error("CPU memory area too small for cpu id ", cpu_id);
+ error("CPU memory area can hold ", slots, " at max");
+ return;
+ }
+
+ Page_flags flags{RW, NO_EXEC, KERN, GLOBAL, RAM, CACHED};
+
+ addr_t base = cpu_local_memory().base + CPU_LOCAL_MEMORY_SLOT_SIZE*cpu_id;
+ void * const stack_ram = ram_alloc.alloc_aligned(KERNEL_STACK_SIZE, 1);
+ void * const cpu_ram =
+ ram_alloc.alloc_aligned(CPU_LOCAL_MEMORY_SLOT_OBJECT_SIZE, 1);
+
+ core_pd->map_insert(Mapping((addr_t)stack_ram,
+ base+CPU_LOCAL_MEMORY_SLOT_STACK_OFFSET,
+ KERNEL_STACK_SIZE, flags));
+ core_pd->map_insert(Mapping((addr_t)cpu_ram,
+ base+CPU_LOCAL_MEMORY_SLOT_OBJECT_OFFSET,
+ CPU_LOCAL_MEMORY_SLOT_OBJECT_SIZE, flags));
+}
+
+
void Platform::start_core(unsigned cpu_id)
{
typedef void (* Entry)(unsigned) __attribute__((noreturn));
@@ -157,9 +188,9 @@ void Platform::start_core(unsigned cpu_id)
}
-static constexpr Genode::Boot_modules_header & header()
+static constexpr Core::Boot_modules_header &header()
{
- return *((Genode::Boot_modules_header*) &_boot_modules_headers_begin);
+ return *((Core::Boot_modules_header*) &_boot_modules_headers_begin);
}
@@ -183,7 +214,9 @@ Platform::Platform()
/* temporarily map all bootstrap memory 1:1 for transition to core */
// FIXME do not insert as mapping for core
core_pd->map_insert(Mapping(bootstrap_region.base, bootstrap_region.base,
- (addr_t)&_bss_end - (addr_t)&_prog_img_beg, Hw::PAGE_FLAGS_KERN_TEXT));
+ (addr_t)&_bss_end - (addr_t)&_prog_img_beg, Genode::PAGE_FLAGS_KERN_TEXT));
+
+ board.cpus = _prepare_cpu_memory_area();
/* map memory-mapped I/O for core */
board.core_mmio.for_each_mapping([&] (Mapping const & m) {
@@ -195,7 +228,7 @@ Platform::Platform()
/* setup boot info page */
void * bi_base = ram_alloc.alloc(sizeof(Boot_info));
core_pd->map_insert(Mapping((addr_t)bi_base, Hw::Mm::boot_info().base,
- sizeof(Boot_info), Hw::PAGE_FLAGS_KERN_TEXT));
+ sizeof(Boot_info), Genode::PAGE_FLAGS_KERN_TEXT));
Boot_info & bootinfo =
*construct_at(bi_base, (addr_t)&core_pd->table,
(addr_t)&core_pd->array,
diff --git a/repos/base-hw/src/bootstrap/platform.h b/repos/base-hw/src/bootstrap/platform.h
index bc6deebe25..f9aa11657b 100644
--- a/repos/base-hw/src/bootstrap/platform.h
+++ b/repos/base-hw/src/bootstrap/platform.h
@@ -45,9 +45,9 @@ class Bootstrap::Platform
{
Memory_region_array early_ram_regions { };
Memory_region_array late_ram_regions { };
- Mmio_space const core_mmio;
- unsigned cpus { NR_OF_CPUS };
- ::Board::Boot_info info { };
+ Mmio_space core_mmio;
+ unsigned cpus { };
+ ::Board::Boot_info info { };
Board();
};
@@ -83,13 +83,12 @@ class Bootstrap::Platform
void add(Memory_region const &);
void remove(Memory_region const &);
- template
- void for_each_free_region(FUNC functor)
+ void for_each_free_region(auto const &fn)
{
_block_tree().for_each([&] (Block const & b)
{
if (!b.used())
- functor(Memory_region(b.addr(), b.size()));
+ fn(Memory_region(b.addr(), b.size()));
});
}
};
@@ -117,13 +116,13 @@ class Bootstrap::Platform
{
Elf(addr_t const addr) : Genode::Elf_binary(addr) { }
- template void for_each_segment(T functor)
+ void for_each_segment(auto const &fn)
{
Genode::Elf_segment segment;
for (unsigned i = 0; (segment = get_segment(i)).valid(); i++) {
if (segment.flags().skip) continue;
if (segment.mem_size() == 0) continue;
- functor(segment);
+ fn(segment);
}
}
};
@@ -135,7 +134,9 @@ class Bootstrap::Platform
addr_t core_elf_addr;
Elf core_elf;
- Mapping _load_elf();
+ Mapping _load_elf();
+ void _prepare_cpu_memory_area(size_t id);
+ unsigned _prepare_cpu_memory_area();
public:
diff --git a/repos/base-hw/src/bootstrap/platform_cpu_memory_area.cc b/repos/base-hw/src/bootstrap/platform_cpu_memory_area.cc
new file mode 100644
index 0000000000..f9c8419315
--- /dev/null
+++ b/repos/base-hw/src/bootstrap/platform_cpu_memory_area.cc
@@ -0,0 +1,24 @@
+/*
+ * \brief Platform CPU memory area preparation
+ * \author Stefan Kalkowski
+ * \date 2024-04-25
+ */
+
+/*
+ * Copyright (C) 2024 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.
+ */
+
+#include
+
+
+unsigned Bootstrap::Platform::_prepare_cpu_memory_area()
+{
+ using namespace Genode;
+
+ for (size_t id = 0; id < ::Board::NR_OF_CPUS; id++)
+ _prepare_cpu_memory_area(id);
+ return ::Board::NR_OF_CPUS;
+}
diff --git a/repos/base-hw/src/bootstrap/spec/arm/cortex_a9_mmu.cc b/repos/base-hw/src/bootstrap/spec/arm/cortex_a9_mmu.cc
index 1262bd0890..b1e62c1233 100644
--- a/repos/base-hw/src/bootstrap/spec/arm/cortex_a9_mmu.cc
+++ b/repos/base-hw/src/bootstrap/spec/arm/cortex_a9_mmu.cc
@@ -42,7 +42,7 @@ class Cpu_counter
{
while (!Genode::cmpxchg((volatile int*)&_locked, UNLOCKED, LOCKED))
;
- _counter++;
+ _counter = _counter + 1;
Genode::memory_barrier();
_locked = UNLOCKED;
}
@@ -52,7 +52,7 @@ class Cpu_counter
};
-struct Scu : Genode::Mmio
+struct Scu : Genode::Mmio<0x34>
{
struct Cr : Register<0x0, 32>
{
@@ -72,7 +72,7 @@ struct Scu : Genode::Mmio
struct Cpu3_way : Bitfield<12, 4> { };
};
- Scu() : Genode::Mmio(Board::Cpu_mmio::SCU_MMIO_BASE) { }
+ Scu() : Mmio({(char *)Board::Cpu_mmio::SCU_MMIO_BASE, Mmio::SIZE}) { }
void invalidate()
{
diff --git a/repos/base-hw/src/bootstrap/spec/arm/crt0.s b/repos/base-hw/src/bootstrap/spec/arm/crt0.s
index 32c42286bc..8c9e6d3023 100644
--- a/repos/base-hw/src/bootstrap/spec/arm/crt0.s
+++ b/repos/base-hw/src/bootstrap/spec/arm/crt0.s
@@ -63,8 +63,10 @@
mrcne p15, 0, sp, c0, c0, 5 /* read multiprocessor affinity register */
andne sp, sp, #0xff /* set cpu id for non-boot cpu */
- adr r0, _start_stack /* load stack address into r0 */
- adr r1, _start_stack_size /* load stack size per cpu into r1 */
+ adr r0, _bootstrap_stack_local /* load stack address into r0 */
+ adr r1, _bootstrap_stack_size_local /* load stack size per cpu into r1 */
+ ldr r0, [r0]
+ ldr r1, [r1]
ldr r1, [r1]
add sp, #1 /* calculate stack start for CPU */
@@ -101,11 +103,8 @@
_bss_local_end:
.long _bss_end
- _start_stack_size:
- .long STACK_SIZE
+ _bootstrap_stack_local:
+ .long bootstrap_stack
- .align 3
- _start_stack:
- .rept NR_OF_CPUS
- .space STACK_SIZE
- .endr
+ _bootstrap_stack_size_local:
+ .long bootstrap_stack_size
diff --git a/repos/base-hw/src/bootstrap/spec/arm/gicv3.cc b/repos/base-hw/src/bootstrap/spec/arm/gicv3.cc
index 36d5c55a38..8b9015f371 100644
--- a/repos/base-hw/src/bootstrap/spec/arm/gicv3.cc
+++ b/repos/base-hw/src/bootstrap/spec/arm/gicv3.cc
@@ -15,10 +15,14 @@
Hw::Pic::Pic()
:
- _distr(Board::Cpu_mmio::IRQ_CONTROLLER_DISTR_BASE),
- _redistr(Board::Cpu_mmio::IRQ_CONTROLLER_REDIST_BASE),
- _redistr_sgi(Board::Cpu_mmio::IRQ_CONTROLLER_REDIST_BASE +
- Board::Cpu_mmio::IRQ_CONTROLLER_REDIST_SIZE / 2),
+ _distr({(char *)Board::Cpu_mmio::IRQ_CONTROLLER_DISTR_BASE,
+ Board::Cpu_mmio::IRQ_CONTROLLER_DISTR_SIZE}),
+ _redistr({(char *)Board::Cpu_mmio::IRQ_CONTROLLER_REDIST_BASE,
+ Board::Cpu_mmio::IRQ_CONTROLLER_REDIST_SIZE}),
+ _redistr_sgi({(char *)Board::Cpu_mmio::IRQ_CONTROLLER_REDIST_BASE +
+ Board::Cpu_mmio::IRQ_CONTROLLER_REDIST_SIZE / 2,
+ Board::Cpu_mmio::IRQ_CONTROLLER_REDIST_BASE -
+ Board::Cpu_mmio::IRQ_CONTROLLER_REDIST_SIZE / 2}),
_max_irq(_distr.max_irq())
{
/* disable device */
diff --git a/repos/base-hw/src/bootstrap/spec/arm/imx6_platform.cc b/repos/base-hw/src/bootstrap/spec/arm/imx6_platform.cc
deleted file mode 100644
index b77e33f5d9..0000000000
--- a/repos/base-hw/src/bootstrap/spec/arm/imx6_platform.cc
+++ /dev/null
@@ -1,79 +0,0 @@
-/*
- * \brief Specific bootstrap implementations
- * \author Stefan Kalkowski
- * \author Josef Soentgen
- * \author Martin Stein
- * \date 2014-02-25
- */
-
-/*
- * Copyright (C) 2014-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.
- */
-
-#include
-#include
-
-using namespace Board;
-
-Bootstrap::Platform::Board::Board()
-:
- early_ram_regions(Memory_region { RAM_BASE, RAM_SIZE }),
- core_mmio(Memory_region { UART_BASE,
- UART_SIZE },
- Memory_region { CORTEX_A9_PRIVATE_MEM_BASE,
- CORTEX_A9_PRIVATE_MEM_SIZE },
- Memory_region { PL310_MMIO_BASE,
- PL310_MMIO_SIZE })
-{
- Aipstz aipstz_1(AIPS_1_MMIO_BASE);
- Aipstz aipstz_2(AIPS_2_MMIO_BASE);
-
- unsigned num_values = sizeof(initial_values) / (2*sizeof(unsigned long));
- for (unsigned i = 0; i < num_values; i++)
- *((volatile unsigned long*)initial_values[i][0]) = initial_values[i][1];
-}
-
-
-bool Board::Cpu::errata(Board::Cpu::Errata err) {
- return (err == ARM_764369) ? true : false; }
-
-
-void Board::Cpu::wake_up_all_cpus(void * const entry)
-{
- struct Src : Genode::Mmio
- {
- struct Scr : Register<0x0, 32>
- {
- struct Core_1_reset : Bitfield<14,1> {};
- struct Core_2_reset : Bitfield<15,1> {};
- struct Core_3_reset : Bitfield<16,1> {};
- struct Core_1_enable : Bitfield<22,1> {};
- struct Core_2_enable : Bitfield<23,1> {};
- struct Core_3_enable : Bitfield<24,1> {};
- };
- struct Gpr1 : Register<0x20, 32> {}; /* ep core 0 */
- struct Gpr3 : Register<0x28, 32> {}; /* ep core 1 */
- struct Gpr5 : Register<0x30, 32> {}; /* ep core 2 */
- struct Gpr7 : Register<0x38, 32> {}; /* ep core 3 */
-
- Src(void * const entry) : Genode::Mmio(SRC_MMIO_BASE)
- {
- write((Gpr3::access_t)entry);
- write((Gpr5::access_t)entry);
- write((Gpr7::access_t)entry);
- Scr::access_t v = read();
- Scr::Core_1_enable::set(v,1);
- Scr::Core_1_reset::set(v,1);
- Scr::Core_2_enable::set(v,1);
- Scr::Core_2_reset::set(v,1);
- Scr::Core_3_enable::set(v,1);
- Scr::Core_3_reset::set(v,1);
- write(v);
- }
- };
-
- Src src(entry);
-}
diff --git a/repos/base-hw/src/bootstrap/spec/arm/imx_aipstz.h b/repos/base-hw/src/bootstrap/spec/arm/imx_aipstz.h
deleted file mode 100644
index 5d6906561c..0000000000
--- a/repos/base-hw/src/bootstrap/spec/arm/imx_aipstz.h
+++ /dev/null
@@ -1,86 +0,0 @@
-/*
- * \brief Driver for Freescale's AIPSTZ bridge
- * \author Stefan Kalkowski
- * \author Martin Stein
- * \date 2012-10-24
- */
-
-/*
- * 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 _SRC__BOOTSTRAP__SPEC__ARM__IMX_AIPSTZ_H_
-#define _SRC__BOOTSTRAP__SPEC__ARM__IMX_AIPSTZ_H_
-
-#include
-
-namespace Bootstrap {
-
- /**
- * AHB to IP Bridge
- *
- * Interface between the system bus and lower bandwidth IP Slave (IPS)
- * bus peripherals.
- */
- class Aipstz;
-}
-
-
-class Bootstrap::Aipstz : public Genode::Mmio
-{
- private:
-
- /*
- * Configuration of the masters
- */
-
- struct Mpr { enum { ALL_UNBUFFERED_AND_FULLY_TRUSTED = 0x77777777 }; };
- struct Mpr1 : Register<0x0, 32>, Mpr { };
- struct Mpr2 : Register<0x4, 32>, Mpr { };
-
- /*
- * Configuration of the platform peripherals
- */
-
- struct Pacr { enum { ALL_UNBUFFERED_AND_FULLY_UNPROTECTED = 0 }; };
- struct Pacr1 : Register<0x20, 32>, Pacr { };
- struct Pacr2 : Register<0x24, 32>, Pacr { };
- struct Pacr3 : Register<0x28, 32>, Pacr { };
- struct Pacr4 : Register<0x2c, 32>, Pacr { };
-
- /*
- * Configuration of the off-platform peripherals
- */
-
- struct Opacr1 : Register<0x40, 32>, Pacr { };
- struct Opacr2 : Register<0x44, 32>, Pacr { };
- struct Opacr3 : Register<0x48, 32>, Pacr { };
- struct Opacr4 : Register<0x4c, 32>, Pacr { };
- struct Opacr5 : Register<0x50, 32>, Pacr { };
-
- public:
-
- /**
- * Configure this module appropriately for the first kernel run
- */
- Aipstz(Genode::addr_t const base) : Genode::Mmio(base)
- {
- /* avoid AIPS intervention at any memory access */
- write(Mpr::ALL_UNBUFFERED_AND_FULLY_TRUSTED);
- write(Mpr::ALL_UNBUFFERED_AND_FULLY_TRUSTED);
- write(Pacr::ALL_UNBUFFERED_AND_FULLY_UNPROTECTED);
- write(Pacr::ALL_UNBUFFERED_AND_FULLY_UNPROTECTED);
- write(Pacr::ALL_UNBUFFERED_AND_FULLY_UNPROTECTED);
- write(Pacr::ALL_UNBUFFERED_AND_FULLY_UNPROTECTED);
- write(Pacr::ALL_UNBUFFERED_AND_FULLY_UNPROTECTED);
- write(Pacr::ALL_UNBUFFERED_AND_FULLY_UNPROTECTED);
- write(Pacr::ALL_UNBUFFERED_AND_FULLY_UNPROTECTED);
- write(Pacr::ALL_UNBUFFERED_AND_FULLY_UNPROTECTED);
- write(Pacr::ALL_UNBUFFERED_AND_FULLY_UNPROTECTED);
- }
-};
-
-#endif /* _SRC__BOOTSTRAP__SPEC__ARM__IMX_AIPSTZ_H_ */
diff --git a/repos/base-hw/src/bootstrap/spec/arm/imx_csu.h b/repos/base-hw/src/bootstrap/spec/arm/imx_csu.h
deleted file mode 100644
index 51793ce9af..0000000000
--- a/repos/base-hw/src/bootstrap/spec/arm/imx_csu.h
+++ /dev/null
@@ -1,235 +0,0 @@
-/*
- * \brief Driver for the Central Security Unit
- * \author Stefan Kalkowski
- * \date 2012-11-06
- */
-
-/*
- * 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 _SRC__BOOTSTRAP__SPEC__ARM__IMX_CSU_H_
-#define _SRC__BOOTSTRAP__SPEC__ARM__IMX_CSU_H_
-
-#include
-#include
-
-namespace Bootstrap { struct Csu; }
-
-
-struct Bootstrap::Csu : Genode::Mmio
-{
- template
- struct Csl : public Register
- {
- enum {
- SECURE = 0x33,
- UNSECURE = 0xff,
- };
-
- struct Slave_a : Register::template Bitfield<0, 9> { };
- struct Slave_b : Register::template Bitfield<16, 9> { };
- };
-
-
- struct Master : public Register<0x218, 32>
- {
- enum {
- SECURE_UNLOCKED,
- UNSECURE_UNLOCKED,
- SECURE_LOCKED,
- UNSECURE_LOCKED
- };
-
- struct Esdhc3 : Bitfield<0,2> { };
- struct Cortex : Bitfield<2,2> { };
- struct Sdma : Bitfield<4,2> { };
- struct Gpu : Bitfield<6,2> { };
- struct Usb : Bitfield<8,2> { };
- struct Pata : Bitfield<10,2> { };
- struct Mlb : Bitfield<14,2> { };
- struct Rtic : Bitfield<18,2> { };
- struct Esdhc4 : Bitfield<20,2> { };
- struct Fec : Bitfield<22,2> { };
- struct Dap : Bitfield<24,2> { };
- struct Esdhc1 : Bitfield<26,2> { };
- struct Esdhc2 : Bitfield<28,2> { };
- };
-
- struct Alarm_mask : public Register<0x230, 32> { };
- struct Irq_ctrl : public Register<0x368, 32> { };
-
- typedef Csl<0x00> Csl00;
- typedef Csl<0x04> Csl01;
- typedef Csl<0x08> Csl02;
- typedef Csl<0x0c> Csl03;
- typedef Csl<0x10> Csl04;
- typedef Csl<0x14> Csl05;
- typedef Csl<0x18> Csl06;
- typedef Csl<0x1c> Csl07;
- typedef Csl<0x20> Csl08;
- typedef Csl<0x24> Csl09;
- typedef Csl<0x28> Csl10;
- typedef Csl<0x2c> Csl11;
- typedef Csl<0x30> Csl12;
- typedef Csl<0x34> Csl13;
- typedef Csl<0x38> Csl14;
- typedef Csl<0x3c> Csl15;
- typedef Csl<0x40> Csl16;
- typedef Csl<0x44> Csl17;
- typedef Csl<0x48> Csl18;
- typedef Csl<0x4c> Csl19;
- typedef Csl<0x50> Csl20;
- typedef Csl<0x54> Csl21;
- typedef Csl<0x58> Csl22;
- typedef Csl<0x5c> Csl23;
- typedef Csl<0x60> Csl24;
- typedef Csl<0x64> Csl25;
- typedef Csl<0x68> Csl26;
- typedef Csl<0x6c> Csl27;
- typedef Csl<0x70> Csl28;
- typedef Csl<0x74> Csl29;
- typedef Csl<0x78> Csl30;
- typedef Csl<0x7c> Csl31;
-
- Csu(Genode::addr_t base,
- bool secure_uart,
- bool secure_gpio,
- bool secure_esdhc,
- bool secure_i2c) : Genode::Mmio(base)
- {
- /* Power (CCM, SRC, DPLLIP1-4, GPC and OWIRE) */
- write(Csl00::UNSECURE);
-
- /* AHBMAX S0-S2 */
- write(Csl00::UNSECURE);
- write(Csl00::UNSECURE);
- write(Csl00::UNSECURE);
-
- /* AHBMAX M6 */
- write(Csl00::UNSECURE);
-
- /* Timer (EPIT, GPT) TODO */
- write(Csl00::UNSECURE);
-
- /* UART 1-5 */
- Csl00::access_t uart_csl =
- secure_uart ? Csl00::SECURE : Csl00::UNSECURE;
- write(uart_csl);
- write(uart_csl);
- write(uart_csl);
- write(uart_csl);
- write(uart_csl);
-
- /* GPIO */
- Csl00::access_t gpio_csl =
- secure_gpio ? Csl00::SECURE : Csl00::UNSECURE;
- write(gpio_csl);
- write(gpio_csl);
- write(gpio_csl);
- write(gpio_csl);
-
- /* IOMUXC TODO */
- write(Csl00::UNSECURE);
-
- /* SDMA TODO */
- write(Csl00::UNSECURE);
-
- /* USB */
- write(Csl00::UNSECURE);
-
- /* TVE */
- write(Csl00::SECURE);
-
- /* I2C */
- Csl00::access_t i2c_csl =
- secure_i2c ? Csl00::SECURE : Csl00::UNSECURE;
- write(i2c_csl);
- write(i2c_csl);
- write(i2c_csl);
-
- /* IPU */
- write(Csl00::SECURE);
-
- /* Audio */
- write(Csl00::UNSECURE);
-
- /* SATA */
- write(Csl00::UNSECURE);
-
- /* FEC */
- write(Csl00::UNSECURE);
-
- /* SDHCI 1-4 */
- Csl00::access_t esdhc_csl =
- secure_esdhc ? Csl00::SECURE : Csl00::UNSECURE;
- write(esdhc_csl);
- write(esdhc_csl);
- write(esdhc_csl);
- write(esdhc_csl);
-
- /* SPDIF */
- write(Csl00::UNSECURE);
-
- /* GPU 2D */
- write(Csl00::SECURE);
-
- /* GPU 3D */
- write(Csl00::SECURE);
-
- write(Csl00::UNSECURE);
- write(Csl00::UNSECURE);
- write(Csl00::UNSECURE);
- write(Csl00::UNSECURE); // SRTC
- write(Csl00::UNSECURE);
- write(Csl00::UNSECURE);
- write(Csl00::UNSECURE);
- write(Csl00::UNSECURE);
- write(Csl00::UNSECURE);
- write(Csl00::UNSECURE);
- write(Csl00::UNSECURE);
- write(Csl00::UNSECURE);
- write(Csl00::UNSECURE);
- write(Csl00::UNSECURE);
- write(Csl00::UNSECURE);
- write(Csl00::UNSECURE);
- write(Csl00::UNSECURE); // SCC
- write(Csl00::UNSECURE);
- write(Csl00::UNSECURE); // RTIC
- write(Csl00::UNSECURE);
- write(Csl00::UNSECURE);
- write(Csl00::UNSECURE);
- write(Csl00::UNSECURE);
- write(Csl00::UNSECURE);
- write(Csl00::SECURE); //VPU
- write(Csl00::UNSECURE);
- write(Csl00::UNSECURE);
- write(Csl00::UNSECURE);
- write(Csl00::UNSECURE);
- write(Csl00::UNSECURE);
- write(Csl00::UNSECURE);
-
- /* DMA from graphical subsystem is considered to be secure */
- write(Master::SECURE_UNLOCKED);
-
- /* all other DMA operations are insecure */
- write(Master::UNSECURE_UNLOCKED);
- write(Master::UNSECURE_UNLOCKED);
- write(Master::UNSECURE_UNLOCKED);
- write(Master::UNSECURE_UNLOCKED);
- write(Master::UNSECURE_UNLOCKED);
-
- Master::access_t esdhc_master =
- secure_esdhc ? Master::SECURE_UNLOCKED
- : Master::UNSECURE_UNLOCKED;
- write(esdhc_master);
- write(esdhc_master);
- write(esdhc_master);
- write(esdhc_master);
- }
-};
-
-#endif /* _SRC__BOOTSTRAP__SPEC__ARM__IMX_CSU_H_ */
diff --git a/repos/base-hw/src/bootstrap/spec/arm/imx_tzic.cc b/repos/base-hw/src/bootstrap/spec/arm/imx_tzic.cc
deleted file mode 100644
index b9b4e78b1d..0000000000
--- a/repos/base-hw/src/bootstrap/spec/arm/imx_tzic.cc
+++ /dev/null
@@ -1,31 +0,0 @@
-/*
- * \brief Freescale's TrustZone aware interrupt controller
- * \author Stefan Kalkowski
- * \date 2012-10-24
- */
-
-/*
- * Copyright (C) 2012-2013 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.
- */
-
-#include
-
-Hw::Pic::Pic()
-:
- Genode::Mmio(Board::IRQ_CONTROLLER_BASE)
-{
- for (unsigned i = 0; i < NR_OF_IRQ; i++) {
- write(!Board::secure_irq(i), i);
- if (!Board::secure_irq(i)) write(0x80, i);
- write(1, i);
- }
- write(0xff);
- Intctrl::access_t v = 0;
- Intctrl::Enable::set(v, 1);
- Intctrl::Nsen::set(v, 1);
- Intctrl::Nsen_mask::set(v, 1);
- write(v);
-}
diff --git a/repos/base-hw/src/bootstrap/spec/arm_64/cortex_a53_mmu.cc b/repos/base-hw/src/bootstrap/spec/arm_64/cortex_a53_mmu.cc
index e0a80d13bf..5324a5a803 100644
--- a/repos/base-hw/src/bootstrap/spec/arm_64/cortex_a53_mmu.cc
+++ b/repos/base-hw/src/bootstrap/spec/arm_64/cortex_a53_mmu.cc
@@ -64,7 +64,7 @@ static inline void prepare_hypervisor(Cpu::Ttbr::access_t const ttbr,
using namespace Hw::Mm;
/* forbid trace access */
- Cpu::Cptr_el2::access_t cptr = Cpu::Cptr_el2::read();
+ Cpu::Cptr_el2::access_t cptr = 0;
Cpu::Cptr_el2::Tta::set(cptr, 1);
Cpu::Cptr_el2::write(cptr);
@@ -74,7 +74,7 @@ static inline void prepare_hypervisor(Cpu::Ttbr::access_t const ttbr,
/* forbid any 32bit access to coprocessor/sysregs */
Cpu::Hstr_el2::write(0xffff);
- Cpu::Hcr_el2::access_t hcr = Cpu::Hcr_el2::read();
+ Cpu::Hcr_el2::access_t hcr = 0;
Cpu::Hcr_el2::Rw::set(hcr, 1); /* exec in aarch64 */
Cpu::Hcr_el2::write(hcr);
@@ -145,7 +145,8 @@ unsigned Bootstrap::Platform::enable_mmu()
Cpu::Ttbr::Baddr::masked((Genode::addr_t)core_pd->table_base);
/* primary cpu wakes up all others */
- if (primary && NR_OF_CPUS > 1) Cpu::wake_up_all_cpus(&_crt0_start_secondary);
+ if (primary && ::Board::NR_OF_CPUS > 1)
+ Cpu::wake_up_all_cpus(&_crt0_start_secondary);
while (Cpu::current_privilege_level() > Cpu::Current_el::EL1) {
if (Cpu::current_privilege_level() == Cpu::Current_el::EL3) {
@@ -199,6 +200,7 @@ unsigned Bootstrap::Platform::enable_mmu()
Cpu::Sctlr::Sa0::set(sctlr, 1);
Cpu::Sctlr::Sa::set(sctlr, 0);
Cpu::Sctlr::Uct::set(sctlr, 1);
+ Cpu::Sctlr::Uci::set(sctlr, 1);
Cpu::Sctlr_el1::write(sctlr);
return cpu_id;
diff --git a/repos/base-hw/src/bootstrap/spec/arm_64/crt0.s b/repos/base-hw/src/bootstrap/spec/arm_64/crt0.s
index 046fc94b03..22e08a95ca 100644
--- a/repos/base-hw/src/bootstrap/spec/arm_64/crt0.s
+++ b/repos/base-hw/src/bootstrap/spec/arm_64/crt0.s
@@ -114,19 +114,12 @@
** Initialize stack **
**********************/
- .set STACK_SIZE, 0x2000
-
_cpu_number
- ldr x1, =_crt0_start_stack
- ldr x2, [x1]
+ ldr x1, =bootstrap_stack
+ ldr x2, =bootstrap_stack_size
+ ldr x2, [x2]
+ add x0, x0, #1
mul x0, x0, x2
add x1, x1, x0
mov sp, x1
bl init
-
- .p2align 4
- .rept NR_OF_CPUS
- .space STACK_SIZE
- .endr
- _crt0_start_stack:
- .quad STACK_SIZE
diff --git a/repos/base-hw/src/bootstrap/spec/x86_64/crt0.s b/repos/base-hw/src/bootstrap/spec/x86_64/crt0.s
index d158d6d68a..ba927a3f76 100644
--- a/repos/base-hw/src/bootstrap/spec/x86_64/crt0.s
+++ b/repos/base-hw/src/bootstrap/spec/x86_64/crt0.s
@@ -143,16 +143,14 @@ __gdt:
movq $1, %rcx
lock xaddq %rcx, (%rax)
- /* if more CPUs started than supported, then stop them */
- cmp $NR_OF_CPUS, %rcx
- jge 1f
-
/* calculate stack depending on CPU counter */
- movq $STACK_SIZE, %rax
+ leaq bootstrap_stack_size@GOTPCREL(%rip),%rax
+ movq (%rax), %rax
+ movq (%rax), %rax
inc %rcx
mulq %rcx
movq %rax, %rcx
- leaq __bootstrap_stack@GOTPCREL(%rip),%rax
+ leaq bootstrap_stack@GOTPCREL(%rip),%rax
movq (%rax), %rsp
addq %rcx, %rsp
@@ -182,10 +180,6 @@ __gdt:
jmp 1b
- .global bootstrap_stack_size
- bootstrap_stack_size:
- .quad STACK_SIZE
-
/******************************************
** Global Descriptor Table (GDT) **
** See Intel SDM Vol. 3A, section 3.5.1 **
@@ -236,14 +230,7 @@ __gdt:
*********************************/
.bss
-
- /* stack of the temporary initial environment */
.p2align 12
- .globl __bootstrap_stack
- __bootstrap_stack:
- .rept NR_OF_CPUS
- .space STACK_SIZE
- .endr
.globl __initial_ax
__initial_ax:
diff --git a/repos/base-hw/src/bootstrap/spec/x86_64/crt0_translation_table.s b/repos/base-hw/src/bootstrap/spec/x86_64/crt0_translation_table.s
index 6fbde692ce..9a374a4d28 100644
--- a/repos/base-hw/src/bootstrap/spec/x86_64/crt0_translation_table.s
+++ b/repos/base-hw/src/bootstrap/spec/x86_64/crt0_translation_table.s
@@ -18,7 +18,7 @@
.data
/********************************************
- ** Identity mapping from 4KiB to 1GiB **
+ ** Identity mapping from 4KiB to 4GiB **
** plus mappings for LAPIC, I/O APIC MMIO **
** Page 0 containing the Bios Data Area **
** gets mapped to 2MiB - 4KiB readonly. **
@@ -35,7 +35,7 @@
.p2align MIN_PAGE_SIZE_LOG2
_kernel_pdp:
.quad _kernel_pd_0 + 0xf
- .fill 1, 8, 0x0
+ .quad _kernel_pd_1 + 0xf
.quad _kernel_pd_2 + 0xf
.quad _kernel_pd_3 + 0xf
.fill 508, 8, 0x0
@@ -50,6 +50,15 @@
.set entry, entry + 0x200000
.endr
+ /* PD [1G-2G) */
+ .p2align MIN_PAGE_SIZE_LOG2
+ _kernel_pd_1:
+ .set entry, 0x4000018f
+ .rept 512
+ .quad entry
+ .set entry, entry + 0x200000
+ .endr
+
/* PD [2G-3G) */
.p2align MIN_PAGE_SIZE_LOG2
_kernel_pd_2:
diff --git a/repos/base-hw/src/bootstrap/spec/x86_64/multiboot.h b/repos/base-hw/src/bootstrap/spec/x86_64/multiboot.h
index 5c83d806dd..f130674baa 100644
--- a/repos/base-hw/src/bootstrap/spec/x86_64/multiboot.h
+++ b/repos/base-hw/src/bootstrap/spec/x86_64/multiboot.h
@@ -21,7 +21,7 @@
namespace Genode { class Multiboot_info; }
-class Genode::Multiboot_info : Mmio
+class Genode::Multiboot_info : Mmio<0x34>
{
private:
@@ -39,17 +39,17 @@ class Genode::Multiboot_info : Mmio
MAGIC = 0x2badb002,
};
- Multiboot_info(addr_t mbi) : Mmio(mbi) { }
+ Multiboot_info(addr_t mbi) : Mmio({(char *)mbi, Mmio::SIZE}) { }
Multiboot_info(addr_t mbi, bool strip);
- struct Mmap : Genode::Mmio
+ struct Mmap : Genode::Mmio<0x1c>
{
struct Size : Register <0x00, 32> { };
struct Addr : Register <0x04, 64> { };
struct Length : Register <0x0c, 64> { };
struct Type : Register <0x14, 8> { enum { MEMORY = 1 }; };
- Mmap(addr_t mmap = 0) : Mmio(mmap) { }
+ Mmap(addr_t mmap = 0) : Mmio({(char *)mmap, Mmio::SIZE}) { }
};
/**
diff --git a/repos/base-hw/src/bootstrap/spec/x86_64/multiboot2.h b/repos/base-hw/src/bootstrap/spec/x86_64/multiboot2.h
index af10f76946..3fb5fdf4ad 100644
--- a/repos/base-hw/src/bootstrap/spec/x86_64/multiboot2.h
+++ b/repos/base-hw/src/bootstrap/spec/x86_64/multiboot2.h
@@ -19,13 +19,14 @@
namespace Genode { class Multiboot2_info; }
-class Genode::Multiboot2_info : Mmio
+class Genode::Multiboot2_info : Mmio<0x8>
{
private:
struct Size : Register <0x0, 32> { };
- struct Tag : Genode::Mmio
+ template
+ struct Tag_tpl : Genode::Mmio
{
enum { LOG2_SIZE = 3 };
@@ -42,21 +43,23 @@ class Genode::Multiboot2_info : Mmio
};
struct Size : Register <0x04, 32> { };
- Tag(addr_t addr) : Mmio(addr) { }
+ Tag_tpl(addr_t addr) : Mmio({(char *)addr, SIZE}) { }
};
- struct Efi_system_table_64 : Tag
+ using Tag = Tag_tpl<0x8>;
+
+ struct Efi_system_table_64 : Tag_tpl<0x10>
{
struct Pointer : Register <0x08, 64> { };
- Efi_system_table_64(addr_t addr) : Tag(addr) { }
+ Efi_system_table_64(addr_t addr) : Tag_tpl(addr) { }
};
public:
enum { MAGIC = 0x36d76289UL };
- struct Memory : Genode::Mmio
+ struct Memory : Genode::Mmio<0x14>
{
enum { SIZE = 3 * 8 };
@@ -64,19 +67,15 @@ class Genode::Multiboot2_info : Mmio
struct Size : Register <0x08, 64> { };
struct Type : Register <0x10, 32> { enum { MEMORY = 1 }; };
- Memory(addr_t mmap = 0) : Mmio(mmap) { }
+ Memory(addr_t mmap = 0) : Mmio({(char *)mmap, Mmio::SIZE}) { }
};
- Multiboot2_info(addr_t mbi) : Mmio(mbi) { }
+ Multiboot2_info(addr_t mbi) : Mmio({(char *)mbi, Mmio::SIZE}) { }
- template
- void for_each_tag(FUNC_MEM mem_fn,
- FUNC_ACPI acpi_fn,
- FUNC_FB fb_fn,
- FUNC_SYSTAB64 systab64_fn)
+ void for_each_tag(auto const &mem_fn,
+ auto const &acpi_fn,
+ auto const &fb_fn,
+ auto const &systab64_fn)
{
addr_t const size = read();
diff --git a/repos/base-hw/src/bootstrap/spec/x86_64/platform.cc b/repos/base-hw/src/bootstrap/spec/x86_64/platform.cc
index 3dace7cf8b..ed38b1d5e5 100644
--- a/repos/base-hw/src/bootstrap/spec/x86_64/platform.cc
+++ b/repos/base-hw/src/bootstrap/spec/x86_64/platform.cc
@@ -7,7 +7,7 @@
*/
/*
- * Copyright (C) 2015-2018 Genode Labs GmbH
+ * Copyright (C) 2015-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.
@@ -19,7 +19,9 @@
#include
#include
+#include
#include
+#include
using namespace Genode;
@@ -31,10 +33,10 @@ extern "C" Genode::addr_t __initial_ax;
extern "C" Genode::addr_t __initial_bx;
/* pointer to stack base */
-extern "C" Genode::addr_t __bootstrap_stack;
+extern "C" Genode::addr_t bootstrap_stack;
/* number of booted CPUs */
-extern "C" Genode::addr_t __cpus_booted;
+extern "C" Genode::addr_t volatile __cpus_booted;
/* stack size per CPU */
extern "C" Genode::addr_t const bootstrap_stack_size;
@@ -87,6 +89,31 @@ Bootstrap::Platform::Board::Board()
size -= get_page_size();
}
+ /* exclude AP boot code page from normal RAM allocator */
+ if (base <= AP_BOOT_CODE_PAGE && AP_BOOT_CODE_PAGE < base + size) {
+ if (AP_BOOT_CODE_PAGE - base)
+ early_ram_regions.add(Memory_region { base,
+ AP_BOOT_CODE_PAGE - base });
+
+ size -= AP_BOOT_CODE_PAGE - base;
+ size -= (get_page_size() > size) ? size : get_page_size();
+ base = AP_BOOT_CODE_PAGE + get_page_size();
+ }
+
+ /* skip partial 4k pages (seen with Qemu with ahci model enabled) */
+ if (!aligned(base, 12)) {
+ auto new_base = align_addr(base, 12);
+ size -= (new_base - base > size) ? size : new_base - base;
+ base = new_base;
+ }
+
+ /* remove partial 4k pages */
+ if (!aligned(size, 12))
+ size -= size & 0xffful;
+
+ if (!size)
+ return;
+
if (base >= initial_map_max) {
late_ram_regions.add(Memory_region { base, size });
return;
@@ -162,7 +189,8 @@ Bootstrap::Platform::Board::Board()
}
/* remember max supported CPUs and use ACPI to get the actual number */
- unsigned const max_cpus = cpus;
+ unsigned const max_cpus =
+ Hw::Mm::CPU_LOCAL_MEMORY_AREA_SIZE / Hw::Mm::CPU_LOCAL_MEMORY_SLOT_SIZE;
cpus = 0;
/* scan ACPI tables to find out number of CPUs in this machine */
@@ -170,43 +198,43 @@ Bootstrap::Platform::Board::Board()
uint64_t const table_addr = acpi_rsdp.xsdt ? acpi_rsdp.xsdt : acpi_rsdp.rsdt;
if (table_addr) {
- Hw::Acpi_generic * table = reinterpret_cast(table_addr);
+ auto rsdt_xsdt_lambda = [&](auto paddr_table) {
+ addr_t const table_virt_addr = paddr_table;
+ Hw::Acpi_generic * table = reinterpret_cast(table_virt_addr);
+
+ if (!memcmp(table->signature, "FACP", 4)) {
+ info.acpi_fadt = addr_t(table);
+
+ Hw::Acpi_fadt fadt(table);
+ fadt.takeover_acpi();
+
+ Hw::Acpi_facs facs(fadt.facs());
+ facs.wakeup_vector(AP_BOOT_CODE_PAGE);
+
+ auto mem_aligned = paddr_table & _align_mask(12);
+ auto mem_size = align_addr(paddr_table + table->size, 12) - mem_aligned;
+ core_mmio.add({ mem_aligned, mem_size });
+ }
+
+ if (memcmp(table->signature, "APIC", 4))
+ return;
+
+ Hw::for_each_apic_struct(*table,[&](Hw::Apic_madt const *e){
+ if (e->type == Hw::Apic_madt::LAPIC) {
+ Hw::Apic_madt::Lapic lapic(e);
+
+ /* check if APIC is enabled in hardware */
+ if (lapic.valid())
+ cpus ++;
+ }
+ });
+ };
+
+ auto table = reinterpret_cast(table_addr);
if (!memcmp(table->signature, "RSDT", 4)) {
- Hw::for_each_rsdt_entry(*table, [&](uint32_t paddr_table) {
- addr_t const table_virt_addr = paddr_table;
- Hw::Acpi_generic * table = reinterpret_cast(table_virt_addr);
-
- if (memcmp(table->signature, "APIC", 4))
- return;
-
- Hw::for_each_apic_struct(*table,[&](Hw::Apic_madt const *e){
- if (e->type == Hw::Apic_madt::LAPIC) {
- Hw::Apic_madt::Lapic lapic(e);
-
- /* check if APIC is enabled in hardware */
- if (lapic.valid())
- cpus ++;
- }
- });
- });
+ Hw::for_each_rsdt_entry(*table, rsdt_xsdt_lambda);
} else if (!memcmp(table->signature, "XSDT", 4)) {
- Hw::for_each_xsdt_entry(*table, [&](uint64_t paddr_table) {
- addr_t const table_virt_addr = paddr_table;
- Hw::Acpi_generic * table = reinterpret_cast(table_virt_addr);
-
- if (memcmp(table->signature, "APIC", 4))
- return;
-
- Hw::for_each_apic_struct(*table,[&](Hw::Apic_madt const *e){
- if (e->type == Hw::Apic_madt::LAPIC) {
- Hw::Apic_madt::Lapic lapic(e);
-
- /* check if APIC is enabled in hardware */
- if (lapic.valid())
- cpus ++;
- }
- });
- });
+ Hw::for_each_xsdt_entry(*table, rsdt_xsdt_lambda);
}
}
}
@@ -218,65 +246,34 @@ Bootstrap::Platform::Board::Board()
cpus = !cpus ? 1 : max_cpus;
}
- if (cpus > 1) {
- /* copy 16 bit boot code for AP CPUs */
- addr_t ap_code_size = (addr_t)&_start - (addr_t)&_ap;
- memcpy((void *)AP_BOOT_CODE_PAGE, &_ap, ap_code_size);
- }
+ /* copy 16 bit boot code for AP CPUs and for ACPI resume */
+ addr_t ap_code_size = (addr_t)&_start - (addr_t)&_ap;
+ memcpy((void *)AP_BOOT_CODE_PAGE, &_ap, ap_code_size);
}
-struct Lapic : Mmio
+static inline
+void ipi_to_all(Hw::Local_apic &lapic, unsigned const boot_frame,
+ Hw::Local_apic::Icr_low::Delivery_mode::Mode const mode)
{
- struct Svr : Register<0x0f0, 32>
- {
- struct APIC_enable : Bitfield<8, 1> { };
- };
+ using Icr_low = Hw::Local_apic::Icr_low;
- struct Icr_low : Register<0x300, 32>
- {
- struct Vector : Bitfield< 0, 8> { };
- struct Delivery_mode : Bitfield< 8, 3>
- {
- enum Mode { INIT = 5, SIPI = 6 };
- };
- struct Delivery_status : Bitfield<12, 1> { };
- struct Level_assert : Bitfield<14, 1> { };
- struct Dest_shorthand : Bitfield<18, 2>
- {
- enum { ALL_OTHERS = 3 };
- };
- };
-
- struct Icr_high : Register<0x310, 32>
- {
- struct Destination : Bitfield<24, 8> { };
- };
-
- Lapic(addr_t const addr) : Mmio(addr) { }
-};
-
-
-static inline void ipi_to_all(Lapic &lapic, unsigned const boot_frame,
- Lapic::Icr_low::Delivery_mode::Mode const mode)
-{
/* wait until ready */
- while (lapic.read())
+ while (lapic.read())
asm volatile ("pause":::"memory");
unsigned const apic_cpu_id = 0; /* unused for IPI to all */
- Lapic::Icr_low::access_t icr_low = 0;
-
- Lapic::Icr_low::Vector::set(icr_low, boot_frame);
- Lapic::Icr_low::Delivery_mode::set(icr_low, mode);
- Lapic::Icr_low::Level_assert::set(icr_low);
- Lapic::Icr_low::Level_assert::set(icr_low);
- Lapic::Icr_low::Dest_shorthand::set(icr_low, Lapic::Icr_low::Dest_shorthand::ALL_OTHERS);
+ Icr_low::access_t icr_low = 0;
+ Icr_low::Vector::set(icr_low, boot_frame);
+ Icr_low::Delivery_mode::set(icr_low, mode);
+ Icr_low::Level_assert::set(icr_low);
+ Icr_low::Level_assert::set(icr_low);
+ Icr_low::Dest_shorthand::set(icr_low, Icr_low::Dest_shorthand::ALL_OTHERS);
/* program */
- lapic.write(apic_cpu_id);
- lapic.write(icr_low);
+ lapic.write(apic_cpu_id);
+ lapic.write(icr_low);
}
@@ -296,24 +293,27 @@ unsigned Bootstrap::Platform::enable_mmu()
Cpu::Cr3::write(Cpu::Cr3::Pdb::masked((addr_t)core_pd->table_base));
- addr_t const stack_base = reinterpret_cast(&__bootstrap_stack);
- addr_t const this_stack = reinterpret_cast(&stack_base);
- addr_t const cpu_id = (this_stack - stack_base) / bootstrap_stack_size;
+ auto const cpu_id =
+ Cpu::Cpuid_1_ebx::Apic_id::get(Cpu::Cpuid_1_ebx::read());
/* we like to use local APIC */
Cpu::IA32_apic_base::access_t lapic_msr = Cpu::IA32_apic_base::read();
Cpu::IA32_apic_base::Lapic::set(lapic_msr);
Cpu::IA32_apic_base::write(lapic_msr);
- /* skip the SMP when ACPI parsing did not reveal the number of CPUs */
- if (board.cpus <= 1)
- return (unsigned)cpu_id;
-
- Lapic lapic(board.core_mmio.virt_addr(Hw::Cpu_memory_map::lapic_phys_base()));
+ Hw::Local_apic lapic(board.core_mmio.virt_addr(Hw::Cpu_memory_map::lapic_phys_base()));
/* enable local APIC if required */
- if (!lapic.read())
- lapic.write(true);
+ if (!lapic.read())
+ lapic.write(true);
+
+ /* reset assembly counter (crt0.s) by last booted CPU, required for resume */
+ if (__cpus_booted >= board.cpus)
+ __cpus_booted = 0;
+
+ /* skip wakeup IPI for non SMP setups */
+ if (board.cpus <= 1)
+ return (unsigned)cpu_id;
if (!Cpu::IA32_apic_base::Bsp::get(lapic_msr))
/* AP - done */
@@ -322,12 +322,15 @@ unsigned Bootstrap::Platform::enable_mmu()
/* BSP - we're primary CPU - wake now all other CPUs */
/* see Intel Multiprocessor documentation - we need to do INIT-SIPI-SIPI */
- ipi_to_all(lapic, 0 /* unused */, Lapic::Icr_low::Delivery_mode::INIT);
+ ipi_to_all(lapic, 0 /* unused */,
+ Hw::Local_apic::Icr_low::Delivery_mode::INIT);
/* wait 10 ms - debates ongoing whether this is still required */
- ipi_to_all(lapic, AP_BOOT_CODE_PAGE >> 12, Lapic::Icr_low::Delivery_mode::SIPI);
+ ipi_to_all(lapic, AP_BOOT_CODE_PAGE >> 12,
+ Hw::Local_apic::Icr_low::Delivery_mode::SIPI);
/* wait 200 us - debates ongoing whether this is still required */
/* debates ongoing whether the second SIPI is still required */
- ipi_to_all(lapic, AP_BOOT_CODE_PAGE >> 12, Lapic::Icr_low::Delivery_mode::SIPI);
+ ipi_to_all(lapic, AP_BOOT_CODE_PAGE >> 12,
+ Hw::Local_apic::Icr_low::Delivery_mode::SIPI);
return (unsigned)cpu_id;
}
@@ -340,3 +343,13 @@ Board::Serial::Serial(addr_t, size_t, unsigned baudrate)
:
X86_uart(Bios_data_area::singleton()->serial_port(), 0, baudrate)
{ }
+
+
+unsigned Bootstrap::Platform::_prepare_cpu_memory_area()
+{
+ using namespace Genode;
+
+ for (size_t id = 0; id < board.cpus; id++)
+ _prepare_cpu_memory_area(id);
+ return board.cpus;
+}
diff --git a/repos/base-hw/src/core/board/imx53_qsb/board.h b/repos/base-hw/src/core/board/imx53_qsb/board.h
deleted file mode 100644
index 962cc85be4..0000000000
--- a/repos/base-hw/src/core/board/imx53_qsb/board.h
+++ /dev/null
@@ -1,29 +0,0 @@
-/*
- * \brief Board driver
- * \author Stefan Kalkowski
- * \author Martin Stein
- * \date 2012-10-24
- */
-
-/*
- * 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 _CORE__SPEC__IMX53_QSB__BOARD_H_
-#define _CORE__SPEC__IMX53_QSB__BOARD_H_
-
-/* base-hw internal includes */
-#include
-#include
-
-/* base-hw Core includes */
-#include
-#include
-#include
-
-namespace Board { using namespace Hw::Imx53_qsb_board; }
-
-#endif /* _CORE__SPEC__IMX53_QSB__BOARD_H_ */
diff --git a/repos/base-hw/src/core/board/imx6q_sabrelite/board.h b/repos/base-hw/src/core/board/imx6q_sabrelite/board.h
deleted file mode 100644
index 3e36070a8f..0000000000
--- a/repos/base-hw/src/core/board/imx6q_sabrelite/board.h
+++ /dev/null
@@ -1,42 +0,0 @@
-/*
- * \brief Board driver
- * \author Stefan Kalkowski
- * \date 2019-01-05
- */
-
-/*
- * Copyright (C) 2019 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 _CORE__SPEC__IMX6Q_SABRELITE__BOARD_H_
-#define _CORE__SPEC__IMX6Q_SABRELITE__BOARD_H_
-
-/* base-hw internal includes */
-#include
-#include
-
-/* base-hw Core includes */
-#include
-#include
-
-namespace Board {
-
- using namespace Hw::Imx6q_sabrelite_board;
-
- class Global_interrupt_controller { };
- class Pic : public Hw::Gicv2 { public: Pic(Global_interrupt_controller &) { } };
-
- using L2_cache = Hw::Pl310;
-
- L2_cache & l2_cache();
-
- enum {
- CORTEX_A9_PRIVATE_TIMER_CLK = 396000000, /* timer clk runs half the CPU freq */
- CORTEX_A9_PRIVATE_TIMER_DIV = 100,
- };
-}
-
-#endif /* _CORE__SPEC__WAND_QUAD__BOARD_H_ */
diff --git a/repos/base-hw/src/core/board/imx7d_sabre/board.h b/repos/base-hw/src/core/board/imx7d_sabre/board.h
deleted file mode 100644
index 06feed0330..0000000000
--- a/repos/base-hw/src/core/board/imx7d_sabre/board.h
+++ /dev/null
@@ -1,36 +0,0 @@
-/*
- * \brief Board driver for core
- * \author Stefan Kalkowski
- * \date 2018-11-07
- */
-
-/*
- * Copyright (C) 2018 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 _CORE__SPEC__IMX7D_SABRE__BOARD_H_
-#define _CORE__SPEC__IMX7D_SABRE__BOARD_H_
-
-/* base-hw internal includes */
-#include
+: 
+: