version: 22.05

The extra definition introduced by commit:
"lx_emul & arm: define ZERO_PAGE" re-defined the macro included
by a header of the contrib sources. This commit removes the
contrib header and defines thereby missing macros.

README

@@ -13,8 +13,8 @@ the project's official website:
   [https://genode.org/documentation/general-overview]
 
 The current implementation can be compiled for 8 different kernels: Linux,
-L4ka::Pistachio, L4/Fiasco, OKL4, NOVA, Fiasco.OC, seL4, and a custom
-kernel for running Genode directly on ARM-based hardware. Whereas the Linux
+L4ka::Pistachio, L4/Fiasco, OKL4, NOVA, Fiasco.OC, seL4, and a custom "hw"
+microkernel for running Genode without a 3rd-party kernel. Whereas the Linux
 version serves us as development vehicle and enables us to rapidly develop the
 generic parts of the system, the actual target platforms of the framework are
 microkernels. There is no "perfect" microkernel - and neither should there be
@@ -85,6 +85,17 @@ The source tree is composed of the following subdirectories:
   keys and download locations of software providers.
 
 
+Additional hardware support
+###########################
+
+The framework supports a variety of hardware platforms such as different ARM
+SoC families via supplemental repositories.
+
+:Repositories maintained by Genode Labs:
+
+  [https://github.com/orgs/genodelabs/repositories]
+
+
 Additional community-maintained components
 ##########################################
 

VERSION

@@ -1 +1 @@
-22.02
+22.05

doc/components.txt

@@ -66,7 +66,13 @@ Device drivers
 
 Device drivers usually reside in the _src/drivers/_ subdirectory of source-code
 repositories. The most predominant repositories hosting device drivers are
-'os', 'dde_ipxe', 'dde_linux'.
+'os', 'dde_ipxe', 'dde_linux', 'pc'. The main source tree is accompanied
+by a variety of optional source-code repositories, each hosting the support of
+a different SoC family such as NXP's i.MX, Allwinner, Xilinx Zynq, or RISC-V.
+
+:Repositories maintained by Genode Labs:
+
+  [https://github.com/orgs/genodelabs/repositories]
 
 
 Platform devices
@@ -138,12 +144,6 @@ capture-session and event-session interfaces respectively.
 :_os/src/drivers/framebuffer/pl11x/_:
   Driver for the PL110/PL111 LCD display.
 
-:_os/src/drivers/framebuffer/imx53/_:
-  Driver for LCD output on i.MX53 SoCs.
-
-:_os/src/drivers/framebuffer/rpi/_:
-  Driver for the HDMI output of the Raspberry Pi.
-
 :_os/src/drivers/framebuffer/sdl/_:
   Serves as both framebuffer and input driver on Linux using libSDL. This
   driver is only usable on the Linux base platform.
@@ -151,11 +151,11 @@ capture-session and event-session interfaces respectively.
 :_os/src/drivers/gpu/intel/_:
   An experimental Intel Graphics GPU multiplexer for Broadwell and newer.
 
-:_dde_linux/src/drivers/framebuffer/intel/_:
+:_pc/src/drivers/framebuffer/intel/_:
   Framebuffer driver for Intel i915 compatible graphic cards based on
   the Linux Intel KMS driver.
 
-:_dde_linux/src/drivers/usb_host/_:
+:_pc/src/drivers/usb_host/_:
   USB host-controller driver that provides an USB session interface to
   USB drivers.
 
@@ -205,17 +205,14 @@ Block drivers
 All block drivers implement the block-session interface defined at
 _os/include/block_session/_.
 
-:_os/src/drivers/sd_card/spec/pl180/_:
+:_os/src/drivers/sd_card/pl180/_:
   Driver for SD-cards connected via the PL180 device as found on the PBX-A9
   platform.
 
-:_os/src/drivers/sd_card/spec/imx53/_:
+:_os/src/drivers/sd_card/imx53/_:
   Driver for SD-cards connected to the Freescale i.MX53 platform like the
   Quick Start Board or the USB armory device.
 
-:_os/src/drivers/sd_card/spec/rpi/_:
-  Driver for SD-cards connected to the Raspberry Pi.
-
 :_os/src/drivers/ahci/_:
   Driver for SATA disks and CD-ROMs on x86 PCs.
 
@@ -237,7 +234,7 @@ defined at _os/include/nic_session/_.
   Driver that uses a Linux tap device as back end. It is only useful on the
   Linux base platform.
 
-:_os/src/drivers/nic/spec/lan9118/_:
+:_os/src/drivers/nic/lan9118/_:
   Native device driver for the LAN9118 network adaptor as featured on the
   PBX-A9 platform.
 
@@ -245,8 +242,8 @@ defined at _os/include/nic_session/_.
   Device drivers ported from the iPXE project. Supported devices are Intel
   E1000 and pcnet32.
 
-:_dde_linux/src/drivers/wifi/_:
-  The wifi_drv component is a port of the Linux mac802.11 stack, including the
+:_pc/src/drivers/wifi/_:
+  The wifi driver component is a port of the Linux mac802.11 stack, including the
   iwlwifi driver. It enables the use of Intel Wireless 6xxx and 7xxx cards.
 
 :_dde_linux/src/drivers/usb_net/_:
@@ -256,16 +253,6 @@ defined at _os/include/nic_session/_.
   Driver for ethernet NICs of the i.MX SoC family.
 
 
-General-purpose I/O drivers
-===========================
-
-:_os/src/drivers/gpio/spec/imx53/_:
-  Driver for accessing the GPIO pins of i.MX53 platforms.
-
-:_os/src/drivers/gpio/spec/rpi/_:
-  Driver for accessing the GPIO pins of Raspberry Pi platforms.
-
-
 Resource multiplexers
 #####################
 
@@ -431,6 +418,9 @@ Separate components
 :_os/src/server/black_hole/_:
   Mockup implementation of Genode session interfaces.
 
+:_dde_linux/src/app/wireguard/_:
+  Port of the Linux implementation of the WireGuard VPN as Genode component.
+
 
 VFS plugins
 ===========
@@ -473,6 +463,9 @@ components that use the Genode's VFS library directly.
 :_libports/src/lib/vfs/fatfs/_:
   A VFS plugin that allows for the mounting of FAT-formatted block devices.
 
+:_os/src/lib/vfs/tap/_:
+  A VFS plugin for the interaction with raw network packets.
+
 :_dde_rump/src/lib/vfs/rump/_:
   A VFS plugin that enables the use of NetBSD's file-system drivers such
   as ext2 or msdos.

doc/news.txt

@@ -4,13 +4,141 @@
                                ===========
 
 
+Genode OS Framework release 22.05 | 2022-05-31
+##############################################
+
+| The highlights of Genode 22.05 are the new support for WireGuard virtual
+| private networks and a fresh lineup of PC device drivers. Further topics are
+| basic telephony with the PinePhone and dynamic device management on Xilinx
+| Zynq.
+
+Version 22.05 closely adheres the goals as set forth in our
+[https://genode.org/about/road-map - roadmap].
+In particular, the envisioned support of WireGuard VPNs came to fruition
+in the form of a dedicated VPN component based on the Linux implementation of
+the WireGuard protocol. Thanks to this component, the network access of Genode
+systems like [https://genode.org/download/sculpt - Sculpt OS] can now be
+protected using state-of-the-art VPN security.
+
+The second prominent topic is the new lineup of PC device drivers, which had
+been developed using Genode's novel Linux device-driver environment that
+allows the reuse of Linux kernel subsystems as individually sandboxed Genode
+components. The work comprises complex drivers like the wireless LAN stack
+including Intel's Wifi driver and the latest Intel display driver. The
+revamped drivers not only bring the modern feature set of the respective Linux
+5.14.21 subsystems to Genode, but they also validate the efficiency of the new
+porting approach.
+
+The vision of a Genode-based smartphone appears as a recurring topic throughout
+the year, with the current release not being an exception. Three achievements
+stand out. First, Genode gained the principle ability to issue and receive
+voice calls with the PinePhone. Second, in anticipation of sophisticated
+energy-management, the release introduces a Genode-specific custom firmware
+for the PinePhone's system-control processor. And third, it is accompanied
+with the second revision of the
+[https://genode.org/documentation/genode-platforms-22-05.pdf - Genode Platforms]
+document that covers the porting process of Genode to a mobile platform in a
+tutorial of over 200 pages.
+
+Besides those prominent topics, the release comes with numerous framework
+improvements, reaching from a forthcoming new PC platform driver, over
+performance optimizations and usability refinements, to dynamic device
+management on FPGA-based Xilinx Zynq devices.
+
+Discover these and more topics of the new version in the official
+[https:/documentation/release-notes/22.05 - release documentation of version 22.05...]
+
+
+Genode SoC porting guide | 2022-05-25
+#####################################
+
+| In the second revision of the Genode Platforms document, Genode Labs shares
+| its former in-house expertise about moving Genode to new hardware devices.
+
+If you ever wondered how to make sense of highly-complex ARM SoCs without
+accurate public documentation, what it takes to bring a modern microkernel
+from one SoC to another, how to transplant and re-animate individual Linux
+kernel subsystems into sandboxed user-level components, or how to craft a
+custom bare-bones operating system out of Genode's components, the new
+revision of the Genode Platforms document is for you.
+
+[https://genode.org/documentation/genode-platforms-22-05.pdf - Genode Platforms 22.05] (PDF)
+
+During the past two years, Genode developer Norman Feske captured his
+practical experience with enabling Genode on a new hardware platform, namely
+the PinePhone.
+
+The process starts with basics like executing tiny bits of custom code, and
+continues with the porting of the microkernel, creating work flows for testing
+and packaging, and bringing up the Genode user land.
+
+With those fundamentals covered, the main part is concerned with the
+complexities of driving the device hardware of modern SoCs, ranging from
+low-level pin controls, over networking, up to driving sophisticated devices
+like the display and touch screen. For the latter, the ability of reusing
+device drivers from the Linux kernel plays a crucial role. Hence, the guide
+presents Genode's practical methodology and tooling behind the black art of
+transplanting and reanimating unmodified Linux kernel code into Genode
+components. Along the way, there are countless little tips and tricks that
+help to turn low-level grunt work into a fun and worthwhile experience.
+
+The document closes with a glimpse at real-world scenarios, culminating in
+the setup of the modem and the routing of audio signals to issue voice calls.
+
+
+Sculpt OS release 22.04 | 2022-04-28
+####################################
+
+| Sculpt OS version 22.04 introduces the concept of service-level sandboxing
+| and features completely new drivers for wireless, graphics, and USB.
+
+On the user-visible surface, the new version of Sculpt OS looks and feels
+familiar to users of the previous version. Under the hood, however, at the
+nitty-gritty hardware-support level, it features completely revamped device
+drivers for Intel wireless, Intel graphics, and USB.
+
+In a major surgery, the new drivers got transplanted from the Linux kernel
+version 5.14.21 using Genode's unique
+[https://genode.org/documentation/release-notes/21.08#Linux-device-driver_environment_re-imagined - DDE]
+approach.
+In contrast to Linux where the drivers are part of the almighty operating-system
+kernel, Sculpt OS hosts each of the drivers in a dedicated sandbox as plain
+user-level component. So Sculpt users can enjoy the broad hardware support
+of up-to-date Linux drivers without ultimately trusting those staggeringly
+complex driver stacks.
+
+Closely related, the support of hardware-accelerated graphics that we
+introduced with the previous version
+[https://genode.org/news/sculpt-os-release-21.10 - 21.10]
+received substantial optimization and stabilization. With the new version,
+Sculpt users can not only run native OpenGL applications but can even go as far
+as using hardware-accelerated graphics via guest operating systems hosted
+within VirtualBox on top of Sculpt.
+
+Being a component-based operating system following the principle of least
+privilege, Sculpt OS gives users ultimate control over the system resources
+exposed to each component. The new version equips the user with additional
+means to exercise control over the deployed software: A new optional
+component called black hole can now be used as placeholder for various system
+resources when deploying an application. For example, a virtual machine can
+be shielded from the network by connecting its network traffic to the black
+hole. This also works for audio, video capturing, USB, and other commonly used
+system resources. As this mechanism works at the level of individual services,
+the documentation refers to it as _service-level sandboxing_, resembling a
+poster-child for the natural power of capability-based security.
+
+Sculpt OS 22.04 is available as ready-to-use system image at the
+[https://genode.org/download/sculpt - Sculpt download page] and is accompanied
+with updated [https://genode.org/documentation/articles/sculpt-22-04 - documentation].
+
+
 Genode OS Framework release 22.02 | 2022-02-28
 ##############################################
 
 | With Genode 22.02, 3D acceleration becomes available to guest operating
 | systems running in VirtualBox 6, Sculpt OS evolves into a versatile framework
 | for building special-purpose operating systems, and Genode starts to interact
-| with the modem of the Pinephone.
+| with the modem of the PinePhone.
 
 The features mentioned above are merely the tip of the iceberg of version
 22.02. In fact, the majority of the development work during the release cycle
@@ -27,7 +155,7 @@ hardware, the current release lifts the potential of Sculpt's architecture for
 the creation of special-purpose operating-system appliances. The gained
 flexibility took even us developers by surprise! Thanks to the new modular
 approach, we were able to demonstrate a bare-bones version of Sculpt OS on
-the Pinephone at FOSDEM, or accelerate our development workflow by routinely
+the PinePhone at FOSDEM, or accelerate our development workflow by routinely
 running Sculpt OS directly on the Linux kernel.
 
 The intensive device-driver-related developments of the previous releases
@@ -36,7 +164,7 @@ drivers in Genode to PC hardware, starting with a fresh port of the USB host
 controller driver. The Intel GPU driver received numerous performance
 improvements and can now even be combined with guest operating systems running
 in VirtualBox 6. Further notable driver-related improvements are the new
-ability to interact with the modem on the Pinephone and largely streamlined
+ability to interact with the modem on the PinePhone and largely streamlined
 driver infrastructure for the Raspberry Pi.
 
 All the details of the new version can be found in the
@@ -52,12 +180,12 @@ Road Map for 2022 | 2022-01-18
 Following Genode's major technical breakthroughs in the areas of reusing Linux
 drivers, hardware-accelerated graphics, and the native execution of Chromium
 during 2021, we will pursue _mobile usability_ as overarching theme in 2022.
-Specifically, we aspire the routine use of Genode on the Pinephone as a
+Specifically, we aspire the routine use of Genode on the PinePhone as a
 platform for video chat, using WireGuard to protect the communications.
 
 This vision motivates a large variety of challenging technical topics.
 To name a few, we have to squeeze good performance out of the
-resource-constrained Pinephone hardware, focus on UI latency and the quality
+resource-constrained PinePhone hardware, focus on UI latency and the quality
 of service of audio streaming, come up with a somewhat usable touch-based
 user interface, and get to the guts of power management.
 
@@ -76,7 +204,7 @@ Genode OS Framework release 21.11 | 2021-11-30
 ##############################################
 
 | Genode 21.11 puts the spotlight on device drivers. Interactive Genode
-| scenarios come to the Pinephone, hardware-accelerated graphics becomes
+| scenarios come to the PinePhone, hardware-accelerated graphics becomes
 | available on Intel Gen9+ and Vivante GPUs, and Xilnx Zynq receives
 | new love.
 
@@ -84,7 +212,7 @@ The previous release presented our new take on porting drivers from Linux, and
 the architectural integration of hardware-accelerated graphics in Genode-based
 systems. The just released version 21.11 is the continuation of both topics.
 Thanks to our streamlined approach for transplanting Linux drivers to Genode, we
-were able to reuse the Pinephone's Linux drivers for the display and
+were able to reuse the PinePhone's Linux drivers for the display and
 touchscreen without modification. But, in contrast to running those drivers in
 the Linux kernel, we are walking on new ground by confining each driver in a
 separate sandbox.
@@ -165,7 +293,7 @@ Genode OS Framework release 21.08 | 2021-08-31
 ##############################################
 
 | The highlights of Genode 21.08 are revamped GPU support as well as new
-| drivers for the Pinephone and MNT-Reform laptop based on a new streamlined
+| drivers for the PinePhone and MNT-Reform laptop based on a new streamlined
 | approach for porting Linux kernel code. Further topics range from VirtualBox
 | improvements, over media playback in the native web browser, to LTE
 | connectivity in Sculpt OS.
@@ -178,7 +306,7 @@ Linux to Genode used to be a time-intensive affair, which forced a narrow
 focus on very few SoCs on us. With the streamlined porting approach introduced
 with the new release, we become able to dramatically reduce the costs,
 creating the prospect of a much broader hardware support. The first success
-stories of the new way of porting are added graphics drivers for the Pinephone
+stories of the new way of porting are added graphics drivers for the PinePhone
 and the MNT-Reform laptop, a network driver for the Pine-A64-LTS board, and an
 SD-card driver for the MNT-Reform.
 
@@ -310,7 +438,7 @@ Genode OS Framework release 21.02 | 2021-02-25
 | support for the Pine-A64-LTS board, and revived work on RISC-V.
 
 Many topics of the current release draw a connection to our overarching goal
-to use Genode on the Pinephone by the end of the year. Besides the obvious
+to use Genode on the PinePhone by the end of the year. Besides the obvious
 steps of enabling the hardware - starting with the Pine-A64-LTS board - the
 release introduces mobile-data connectivity as a Genode feature, and changes
 the network-driver architecture in anticipation of dynamic power-management
@@ -334,7 +462,7 @@ For the full story, please refer to the
 Road Map for 2021 | 2021-01-15
 ##############################
 
-| In 2021, we plan to bring Genode to the Pinephone, advance the framework's
+| In 2021, we plan to bring Genode to the PinePhone, advance the framework's
 | GPU support, and focus on development workflows.
 
 During the annual road-map discussion on Genode's public
@@ -342,13 +470,13 @@ During the annual road-map discussion on Genode's public
 the following hot topics for this year emerged.
 
 First and most inspiring for many Genode developers, we aspire to have
-Genode running on the Pinephone with basic feature-phone functionality by the
+Genode running on the PinePhone with basic feature-phone functionality by the
 end of the year. Since this will involve substantial device-driver-related
 developments, the team will take this line of work as an opportunity to
 advance the tooling and workflows for carrying out such tasks. This, in turn,
 will hopefully ease the on-boarding of new driver developers in the future.
 
-Closely related to the Pinephone scenario, the project will make optimizations
+Closely related to the PinePhone scenario, the project will make optimizations
 a top priority this year. The opportunities are plenty, ranging from
 micro-optimizations, over API refinements, to architectural changes if
 needed.

doc/release_notes/21-02.txt

@@ -21,7 +21,7 @@ disrupting network-application stacks.
 
 Second, the release features the infrastructure needed for mobile-data
 communication over LTE, which is a prerequisite for our ambition to use Genode
-on the Pinephone. Section [LTE modem stack] gives insights into the involved
+on the PinePhone. Section [LTE modem stack] gives insights into the involved
 components and the architecture.
 
 Third, we are happy to feature the initial version of VirtualBox 6 for
@@ -518,7 +518,7 @@ Pine-A64-LTS single board computer
 ==================================
 
 Our [https://genode.org/about/road-map - road map] envisions
-the use of Genode on the Pinephone by the end of the year. As a first stepping
+the use of Genode on the PinePhone by the end of the year. As a first stepping
 stone, the current release adds basic board support for the
 [https://pine64.com/product-category/pine-a64-ltslong-term-supply/ - Pine-A64-LTS]
 single-board computer. We take this line of work as a welcome opportunity to

doc/release_notes/21-05.txt

@@ -147,7 +147,7 @@ system. The boot time of Sculpt OS has always been relatively quick compared
 to commodity operating systems. E.g., on a 5-years old laptop like a Lenovo
 x260, the system used to boot in about 5 seconds to the graphical user
 interface. However, with the anticipation of Sculpt OS on lower-end platforms
-like the Pinephone and with the vision of instant-on systems, we wondered
+like the PinePhone and with the vision of instant-on systems, we wondered
 about the potential for improvement.
 
 While gathering a CPU-load profile of the boot process using the top tool, we

doc/release_notes/21-08.txt

@@ -30,7 +30,7 @@ DDE-Linux could be. Section [Linux-device-driver environment re-imagined]
 presents the results of this recent line of development that promises to dwarf
 the costs of driver-porting work compared to our time-tested approach. The
 results have an immediate impact on our ambition to bring Genode to the
-Pinephone as our added network and framebuffer drivers for the Allwinner A64
+PinePhone as our added network and framebuffer drivers for the Allwinner A64
 SoC leverage the new DDE already.
 
 The challenge of using hardware-accelerated graphics (GPUs) on Genode makes a
@@ -187,7 +187,7 @@ resounding success. The i.MX8MQ repository features drivers for framebuffer
 output and SD-card access,
 [https://genodians.org/skalk/2021-08-02-mnt-reform2-sdcard - targeting the MNT Reform laptop].
 The Allwinner repository contains a network driver for the Pine-A64-LTS board
-and a new framebuffer driver for the Pinephone. No single line of Linux code
+and a new framebuffer driver for the PinePhone. No single line of Linux code
 had to be changed.
 
 We found that the development of those driver components took only a fraction
@@ -203,7 +203,7 @@ exploratory experience.
 That said, it is not all roses. Components based on Linux drivers have to
 carry substantial Linux-specific bureaucracy along with them. The resulting
 components tend to be somewhat obese given their relatively narrow purpose.
-E.g., the executable binary of the framebuffer driver for the Pinephone is
+E.g., the executable binary of the framebuffer driver for the PinePhone is
 1.5 MiB in size, most of which is presumably dead weight.
 
 
@@ -568,7 +568,7 @@ Modular integration of LTE modem stack in Sculpt OS
 
 In version [https://genode.org/documentation/release-notes/21.02#LTE_modem_stack - 21.02],
 we announced the LTE modem support as a prerequisite for using Genode on the
-Pinephone. Since most of our development laptops also come with LTE modems or
+PinePhone. Since most of our development laptops also come with LTE modems or
 an extension slot for installing one, we explored ways to augment the Sculpt
 scenario with mobile networking on demand, i.e., by the installation of
 additional components. The result is documented by means of an

doc/release_notes/21-11.txt

@@ -11,9 +11,9 @@
 Version 21.11 of the Genode OS Framework puts device drivers into the
 spotlight. Where to begin? Back in
 [https://genode.org/news/road-map-for-2021 - January], we envisioned Genode
-running on the Pinephone. With the current release, the first interactive
+running on the PinePhone. With the current release, the first interactive
 Genode scenarios become alive on this platform. Unlike the regular Linux-based
-systems used on the Pinephone, we are walking on new ground by running each
+systems used on the PinePhone, we are walking on new ground by running each
 individual driver in a dedicated sandbox.
 
 Speaking of 64-bit ARM platforms, Genode's support for the i.MX8 SoC family
@@ -91,7 +91,7 @@ Kalkowski took the i.MX-related code to his
 Johannes Schlatow took the Xilinx Zynq code to his
 [https://github.com/jschlatow/genode-zynq - genode-zynq] repository,
 Norman Feske
-maintains the Allwinner code for the Pinephone in
+maintains the Allwinner code for the PinePhone in
 his [https://github.com/nfeske/genode-allwinner - genode-allwinner]
 repository, and Sebastian Sumpf gave the RISC-V support a new home
 at his [https://github.com/ssumpf/genode-riscv - genode-riscv] repository.
@@ -173,11 +173,11 @@ corresponding line in your etc/build.conf. Step-by-step instructions for
 individual boards can be found at _repos/zynq/doc/_.
 
 
-Allwinner A64 (Pinephone)
+Allwinner A64 (PinePhone)
 =========================
 
 During the release cycle, Genode's support for the Allwinner A64 SoC, and
-the Pinephone in particular, made big leaps forward. The corresponding code
+the PinePhone in particular, made big leaps forward. The corresponding code
 is hosted in the dedicated
 [https://github.com/nfeske/genode-allwinner - genode-allwinner] repository.
 
@@ -186,7 +186,7 @@ updated to 5.14.1 in order to support the revision v2 of the Pine-A64-LTS
 board, which features a different Ethernet PHY, namely the Motorcomm YT8511
 PHY. Genode's 'pine_a64lts' board supports both board revisions now.
 
-To enable touchscreen input on the Pinephone, the corresponding driver for the
+To enable touchscreen input on the PinePhone, the corresponding driver for the
 Goodix touchscreen controller has been ported from the Linux kernel. It
 complements the framebuffer driver that we introduced with the previous
 release. Combined, both drivers enable the use of Genode's regular interactive
@@ -199,10 +199,10 @@ now handled by a new A64-specific version of the platform driver.
   Genode's nano-3D example responding to touch input
 
 The improved driver support is accompanied with new tooling for booting Genode
-on the Pinephone, either via USB fastboot, or via SD-card. Both options are
+on the PinePhone, either via USB fastboot, or via SD-card. Both options are
 described in the following Genodians article.
 
-:Booting Genode on the Pinephone:
+:Booting Genode on the PinePhone:
 
   [https://genodians.org/nfeske/2021-09-20-pine-fun-pinephone-boot]
 
@@ -291,7 +291,7 @@ input becomes explicit. A client can no longer drive a pin that is an input
 signal unless explicitly permitted.
 
 The interfaces were created and time-tested in the context of our
-Pinephone-related development, in particular during the work described in the
+PinePhone-related development, in particular during the work described in the
 following two articles.
 
 :Device access from the user level:
@@ -325,7 +325,7 @@ Time-multiplexed pin direction
 
 There exist rare use cases for changing the direction of an I/O pin during
 runtime. For example, the Goodix touchscreen controller as found in the
-Pinephone monitors the state of its interrupt signal during reset. During its
+PinePhone monitors the state of its interrupt signal during reset. During its
 normal operation, this signal is driven by the touchscreen controller but
 during reset, it is driven by the host to send one bit of information (I2C
 address selection). We support this time-multiplexed use of one pin as both
@@ -367,7 +367,7 @@ Genode events. The interface is located at
 _repos/os/include/genode_c_api/event.h_ whereas the implementation resides at
 _repos/os/src/lib/genode_c_api/event.cc_.
 The initial version is limited to multitouch events only.
-As of now, it is used by the Goodix touchscreen driver for the Pinephone.
+As of now, it is used by the Goodix touchscreen driver for the PinePhone.
 
 
 Event filter for converting touch to pointer input
@@ -399,7 +399,7 @@ as input filter, reworked in
 [https://genode.org/documentation/release-notes/20.08#Replacing_the_input_filter_with_an_event_filter - 20.08]).
 The new filter comes in the form of a new '<touch-click>' node in the filter's
 '<output>' definition. For example, the configuration of the event filter that
-sits in-between the Goodix touchscreen driver for the Pinephone and the
+sits in-between the Goodix touchscreen driver for the PinePhone and the
 nitpicker GUI server looks as follows.
 
 ! <config>

doc/release_notes/22-02.txt

@@ -27,7 +27,7 @@ driver work for several platforms (Section [Device drivers]). In particular,
 we started to apply our new method of porting Linux driver code to PC drivers
 such as our new USB host controller driver. The Intel GPU driver received
 welcome performance optimizations and became usable for guest operating
-systems running in VirtualBox 6. On the Pinephone, Genode has started
+systems running in VirtualBox 6. On the PinePhone, Genode has started
 interacting with the modem.
 
 From a functional perspective, the highlight of the release is the
@@ -35,7 +35,7 @@ extension of Sculpt OS towards a highly customizable toolkit for building
 special-purpose operating systems defined at integration time
 (Section [Framework for special-purpose Sculpt-based operating systems]).
 This new level of flexibility cleared the path to running a bare-bones
-version of Sculpt OS on the Pinephone, or directly on a Linux kernel.
+version of Sculpt OS on the PinePhone, or directly on a Linux kernel.
 
 
 Framework for special-purpose Sculpt-based operating systems
@@ -212,11 +212,11 @@ redirected to core using the optional 'LOG=core' argument on the command line.
 ! build/x86_64$ make run/sculpt KERNEL=nova BOARD=pc SCULPT=default LOG=core
 
 
-Sculpt OS meets the Pinephone
+Sculpt OS meets the PinePhone
 =============================
 
 Thanks to the greatly modularized new version of Sculpt OS, we have become
-able to run a minimalistic version of Sculpt on the Pinephone, as demonstrated
+able to run a minimalistic version of Sculpt on the PinePhone, as demonstrated
 in our recent presentation at FOSDEM.
 
 : <video preload="none" controls="controls">
@@ -224,14 +224,14 @@ in our recent presentation at FOSDEM.
 :            type='video/webm; codecs="vp9, opus"' />
 : </video>
 
-:Genode meets the Pinephone:
+:Genode meets the PinePhone:
 
   [https://fosdem.org/2022/schedule/event/nfeske/]
 
   _Microkernel developer room at FOSDEM, 2022-02-05_
 
 Despite lacking drivers for storage and network connectivity, we are already
-able to put together interesting interactive system images for the Pinephone.
+able to put together interesting interactive system images for the PinePhone.
 To make this possible, a few additional steps had to be taken though.
 
 First, we had to make Sculpt's administrative GUI able to respond to touch
@@ -878,11 +878,11 @@ configuration (example):
 ! </config>
 
 
-Pinephone modem access
+PinePhone modem access
 ======================
 
 On our way towards a Genode-based phone, we enabled the low-level access of
-the Quectel-EG25 modem as found in the Pinephone. This line of work is hosted
+the Quectel-EG25 modem as found in the PinePhone. This line of work is hosted
 in the [https://github.com/genodelabs/genode-allwinner - genode-allwinner]
 repository and consists of two parts. First, the modem driver at
 _src/drivers/modem/pinephone/_ takes care of the powering and initialization
@@ -897,9 +897,9 @@ A first example scenario is provided by the
 [https://github.com/genodelabs/genode-allwinner/blob/22.02/run/modem_pinephone.run - modem_pinephone.run]
 script. It comprises the modem driver and two instances of the UART driver.
 One UART driver is connected to the modem's control channel whereas the other
-is connected to the default serial interface of the Pinephone. By bridging
+is connected to the default serial interface of the PinePhone. By bridging
 both drivers via a terminal-crosslink component, the scenario allows for
-the direct interaction with the modem over the Pinephone's serial channel,
+the direct interaction with the modem over the PinePhone's serial channel,
 e.g., unlocking a SIM card or sending SMS messages via the 'AT+CMGS' command.
 
 

doc/release_notes/22-05.txt

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

doc/road_map.txt

@@ -35,7 +35,7 @@ for Genode with very little friction. On the way, we created new methodology
 and tooling, as well as extensive documentation in the form of the "Genode
 Platforms" document. Thanks to the new drivers ported from the Linux kernel,
 we were able to witness interactive Genode scenarios becoming alive on the
-Pinephone by the end of the year.
+PinePhone by the end of the year.
 
 The third major topic was the growing sophistication of Genode-native
 workloads, with the media features of the Chromium-based browser on 64-bit ARM
@@ -66,22 +66,22 @@ outcome, which will hopefully propel Genode to new heights in 2022.
 2022 - Mobile Usability
 #######################
 
-After having enabled the first interactive Genode scenarios on the Pinephone
-last year, we plan to take Genode on the Pinephone to a level where we can
+After having enabled the first interactive Genode scenarios on the PinePhone
+last year, we plan to take Genode on the PinePhone to a level where we can
 routinely use it for advanced applications, in particular video chat. This
 vision confronts us with a multitude of hard technical nuts to crack such as
 power efficiency, UI latency, quality-of-service of audio processing, drivers
 for multi-media devices, WebRTC performance, and usability. This grand theme
-will not only address the Pinephone specifically. The efficiency gains will
+will not only address the PinePhone specifically. The efficiency gains will
 benefit all Genode use cases large and small.
 
-Our theme of the Genode-based video chat on the Pinephone fuels several
+Our theme of the Genode-based video chat on the PinePhone fuels several
 ambitions in closely related areas. In particular, we aspire using WireGuard
 to secure private communication, and experiment with the operation of
 hardware-based trust anchors as the basis for encrypted storage and
 communication.
 
-Besides the Pinephone, we will steadily nurture the quality and scope of
+Besides the PinePhone, we will steadily nurture the quality and scope of
 driver support on PC hardware, which remains the primary platform for the
 day-to-day use of Sculpt OS. So you can expect us to keep up with recent
 generations of Intel-based hardware. In this area, we plan to make IOMMU
@@ -102,7 +102,7 @@ February - Release 22.02
 
 * OpenGL in VirtualBox 6
 * Sculpt OS as tool kit for special-purpose OS images
-* Pinephone
+* PinePhone
   * Modem access
   * Touch-screen compatibility of Sculpt OS
 
@@ -115,13 +115,13 @@ May - Release 22.05
 * WireGuard VPN
 * Updated drivers for PC hardware (Wifi, Intel framebuffer, USB)
 * New tracing tool with support for CTF and PCAP
-* Pinephone telephony
+* PinePhone telephony
 
 
 August - Release 22.08
 ======================
 
-* Pinephone
+* PinePhone
   * Morph browser
   * Media record and playback capabilities
 * FPGA-powered DMA protection for the Zynq-7000 SoC
@@ -132,7 +132,7 @@ August - Release 22.08
 November - Release 22.11
 ========================
 
-* Pinephone
+* PinePhone
   * WebRTC-based video chat
   * Power management
 * Base mechanism for suspend-resume on PC hardware

repos/README

@@ -26,22 +26,22 @@ but build upon of each other:
   These directories contain platform-specific source-code repositories
   complementing the 'base' repository. The following platforms are supported:
 
+  :'hw':
+    The hw platform hosts Genode on a custom microkernel specifically
+    developed for Genode. The name "hw" denotes that Genode is executed on
+    bare hardware without a 3rd-party kernel underneath.
+
   :'linux':
     Linux kernel (both x86_32 and x86_64)
 
   :'nova':
-    NOVA hypervisor developed at University of Technology Dresden
+    NOVA hypervisor ([https://hypervisor.org])
 
   :'foc':
     Fiasco.OC is a modernized version of the Fiasco microkernel with a
     completely revised kernel interface fostering capability-based
     security. It is not compatible with L4/Fiasco.
 
-  :'hw':
-    The hw platform allows the execution of Genode on bare ARM and x86 hardware
-    without the need for a separate kernel. The kernel functionality is
-    included in core.
-
   :'okl4':
     OKL4 kernel (x86_32 and ARM) developed at Open-Kernel-Labs.
 
@@ -52,13 +52,12 @@ but build upon of each other:
     L4/Fiasco kernel developed at University of Technology Dresden.
 
   :'sel4':
-    seL4 microkernel developed at NICTA/General Dynamics
-    See[https://sel4.systems/]
+    seL4 microkernel ([https://sel4.systems/])
 
 :'os':
 
-  This directory contains the non-base OS components such as the init process,
-  device drivers, and basic system services.
+  This directory contains the non-base OS components such as the init
+  component, device drivers, and basic system services.
 
 :'demo':
 
@@ -78,18 +77,17 @@ but build upon of each other:
   upstream source code but means to download the code and adapt it to Genode.
   For instructions about how to use this mechanism, please consult the README
   file at the top level of the repository. Among the 3rd-party libraries
-  are Qt5, libSDL, freetype, Python, ncurses, Mesa, and libav.
+  are Qt5, freetype, ncurses, and Mesa.
 
 :'dde_linux':
 
   This source-code repository contains the device driver environment for
-  executing Linux device drivers natively on Genode. Currently, this
-  repository hosts the USB stack.
+  executing Linux subsystems as Genode components.
 
 :'dde_ipxe':
 
   This source-code repository contains the device-driver environment for
-  executing drivers of the iPXE project.
+  executing network drivers of the iPXE project.
 
 :'dde_bsd':
 

repos/base-fiasco/recipes/src/base-fiasco/hash

@@ -1 +1 @@
-2022-04-12 515112b4fff8f569ab6194cabbde0dc8e8446c82
+2022-05-24 1790ce242c001ed77aab9695f69923a44d1dc1d1

repos/base-foc/recipes/src/base-foc-imx6q_sabrelite/hash

@@ -1 +1 @@
-2022-04-12 b1e43bda46dcc2e180649bed9990230bbc6f5eb3
+2022-05-24 f7900083623a2009d35234c47d2475dea8f6cf53

repos/base-foc/recipes/src/base-foc-imx7d_sabre/hash

@@ -1 +1 @@
-2022-04-12 587953d4a135f958b156bf9ec31adfbc2c84881a
+2022-05-24 f7d228f6419c2fc9b1b0faf4ba8d88862ba61e81

repos/base-foc/recipes/src/base-foc-pbxa9/hash

@@ -1 +1 @@
-2022-04-12 99c54bf391d7e438022b70b39ba175ee13a831f8
+2022-05-24 391b798b7c1d1b44ff65d855980eb41a8f4a87c1

repos/base-foc/recipes/src/base-foc-pc/hash

@@ -1 +1 @@
-2022-04-12 4fe361144ecfe216246e5ba199f578c69ebbec57
+2022-05-24 79eab679e71dd70803b0e1647a23e2ba86c76f50

repos/base-foc/recipes/src/base-foc-rpi3/hash

@@ -1 +1 @@
-2022-04-12 b920fe281256f366f1565444ba07bc136897ba06
+2022-05-24 7a16aeb081d1392c36d83f526936f17cc9560442

repos/base-hw/recipes/src/base-hw-imx53_qsb/hash

@@ -1 +1 @@
-2022-04-12 97ecc02ab7544f8b8bad04a2d23178ce0f14f566
+2022-05-24 ab1cb582165e76bda4abf27870f44ad7d1ae5b6d

repos/base-hw/recipes/src/base-hw-imx53_qsb_tz/hash

@@ -1 +1 @@
-2022-04-12 46afb000e6e14e6580e66f489891b14ea7765ddc
+2022-05-24 0fff6ce83b962b3fd54cf6eda0a157cb0cb0c9d5

repos/base-hw/recipes/src/base-hw-imx6q_sabrelite/hash

@@ -1 +1 @@
-2022-04-12 2dcfe4b1dc0cf006c4c2acbcfb6b72fcf8e50890
+2022-05-24 8c17512664a648eaed876c815ea678770eda3280

repos/base-hw/recipes/src/base-hw-imx7d_sabre/hash

@@ -1 +1 @@
-2022-04-12 90a97e63f9870468b957b2493a6c433dd5b0a64c
+2022-05-24 edc396d9bc9a2ebf73590e70c1363020226909be

repos/base-hw/recipes/src/base-hw-nit6_solox/hash

@@ -1 +1 @@
-2022-04-12 1eb2a74c06a2130d39d57edcb31e19365e1ee2d9
+2022-05-24 da90478c4c0b8993041bc59488eedb124e680e78

repos/base-hw/recipes/src/base-hw-pbxa9/hash

@@ -1 +1 @@
-2022-04-12 d562748afbe8ef29883d33de8c2c63740a3adc30
+2022-05-24 1b34e317209c48bfc88af6118db32be261ce3e0c

repos/base-hw/recipes/src/base-hw-pc/hash

@@ -1 +1 @@
-2022-04-12 0af1ada2933e4af5b0d07c8586f39f60d31d68f9
+2022-05-24 46e9f88209bbc95228d3882cc0831770315402e4

repos/base-hw/recipes/src/base-hw-virt_qemu/hash

@@ -1 +1 @@
-2022-04-12 8ed294db10dc8aad6f6c379d3f8ec6359e1bbd5d
+2022-05-24 bb6c39c093a24d2ec4ff1d00e397529c51e95fa7

repos/base-linux/recipes/src/base-linux/hash

@@ -1 +1 @@
-2022-04-12 082a29a3ed60ac0208796eb53be9daab7713de28
+2022-05-24 4aea382035415c79bf5d551642ebfa64d42e4d21

repos/base-nova/include/nova/syscall-generic.h

@@ -242,6 +242,14 @@ namespace Nova {
 		EC_DONATE_SC = 2U,
 		EC_RESCHEDULE = 3U,
 		EC_MIGRATE = 4U,
+		EC_TIME = 5U,
+	};
+
+	enum Sc_op {
+		SC_TIME_IDLE   = 0,
+		SC_TIME_CROSS  = 1,
+		SC_TIME_KILLED = 2,
+		SC_EC_TIME     = 3,
 	};
 
 	/**

repos/base-nova/include/spec/32bit/nova/syscalls.h

@@ -182,6 +182,40 @@ namespace Nova {
 		return (uint8_t)status;
 	}
 
+
+	ALWAYS_INLINE
+	inline uint8_t syscall_6(Syscall s, uint8_t flags, unsigned sel,
+	                         mword_t &p1, mword_t &p2, mword_t &p3,
+	                         mword_t &p4)
+	{
+		mword_t status = eax(s, flags, sel);
+
+		asm volatile ("  push %%ebp;"
+		              "  push %%ebx;"
+
+		              "  mov %%ecx, %%ebx;"
+		              "  mov %%esp, %%ecx;"
+		              "  mov %%edx, %%ebp;"
+
+		              "  call 0f;"
+		              "0:"
+		              "  addl $(1f-0b), (%%esp);"
+		              "  mov (%%esp), %%edx;"
+		              "sysenter;"
+		              "1:"
+
+		              "  mov %%ebp, %%edx;"
+		              "  mov %%ebx, %%ecx;"
+		              "  pop %%ebx;"
+		              "  pop %%ebp;"
+		              : "+a" (status), "+D" (p1), "+S" (p2), "+c" (p3),
+		                "+d" (p4)
+		              :
+		              : "memory");
+		return (uint8_t)status;
+	}
+
+
 	ALWAYS_INLINE
 	inline uint8_t call(unsigned pt)
 	{
@@ -239,14 +273,51 @@ namespace Nova {
 	}
 
 
+	ALWAYS_INLINE
+	inline uint8_t util_time(Syscall const syscall, mword_t const cap,
+	                         uint8_t const op, unsigned long long &time)
+	{
+		mword_t time_h = 0, time_l = 0;
+		uint8_t res = syscall_5(syscall, op, cap, time_h, time_l);
+		time = (uint64_t(time_h) << 32ULL) | uint64_t(time_l);
+		return res;
+	}
+
+
+	ALWAYS_INLINE
+	inline uint8_t sc_ec_time(mword_t const cap_sc, mword_t const cap_ec,
+	                          unsigned long long &time_sc,
+	                          unsigned long long &time_ec)
+	{
+		mword_t time_h_sc = cap_ec, time_l_sc = 0;
+		mword_t time_h_ec = 0,      time_l_ec = 0;
+		uint8_t res = syscall_6(NOVA_SC_CTRL, Sc_op::SC_EC_TIME, cap_sc,
+		                        time_h_sc, time_l_sc, time_h_ec,
+		                        time_l_ec);
+		time_sc = (uint64_t(time_h_sc) << 32ULL) | uint64_t(time_l_sc);
+		time_ec = (uint64_t(time_h_ec) << 32ULL) | uint64_t(time_l_ec);
+		return res;
+	}
+
+
 	ALWAYS_INLINE
 	inline uint8_t ec_ctrl(Ec_op op, mword_t ec = ~0UL, mword_t para = ~0UL,
 	                       Crd crd = 0)
 	{
+		if (op == EC_TIME)
+			return NOVA_INV_HYPERCALL;
+
 		return syscall_2(NOVA_EC_CTRL, op, ec, para, crd.value());
 	}
 
 
+	ALWAYS_INLINE
+	inline uint8_t ec_time(mword_t const ec, unsigned long long &time)
+	{
+		return util_time(NOVA_EC_CTRL, ec, Ec_op::EC_TIME, time);
+	}
+
+
 	ALWAYS_INLINE
 	inline uint8_t create_sc(unsigned sc, unsigned pd, unsigned ec, Qpd qpd)
 	{
@@ -396,13 +467,9 @@ namespace Nova {
 
 
 	ALWAYS_INLINE
-	inline uint8_t sc_ctrl(unsigned sc, unsigned long long &time, uint8_t op = 0)
+	inline uint8_t sc_ctrl(unsigned const sc, unsigned long long &time, uint8_t op = 0)
 	{
-		mword_t time_h = 0, time_l = 0;
-		uint8_t res = syscall_5(NOVA_SC_CTRL, op, sc, time_h, time_l);
-		time = time_h;
-		time = (time << 32ULL) | time_l;
-		return res;
+		return util_time(NOVA_SC_CTRL, sc, op, time);
 	}
 }
 #endif /* _INCLUDE__SPEC__32BIT__NOVA__SYSCALLS_H_ */

repos/base-nova/include/spec/64bit/nova/syscalls.h

@@ -132,6 +132,24 @@ namespace Nova {
 		return  (uint8_t)status;
 	}
 
+	ALWAYS_INLINE
+	inline uint8_t syscall_6(Syscall s, uint8_t flags, mword_t sel,
+	                         mword_t &p1, mword_t &p2, mword_t &p3,
+	                         mword_t &p4)
+	{
+		mword_t status = rdi(s, flags, sel);
+
+		register mword_t r8 asm ("r8") = p4;
+
+		asm volatile ("syscall"
+		              : "+D" (status), "+S"(p1), "+d"(p2), "+a"(p3), "+r"(r8)
+		              :
+		              : "rcx", "r11", "memory");
+
+		p4 = r8;
+
+		return  (uint8_t)status;
+	}
 
 	ALWAYS_INLINE
 	inline uint8_t call(mword_t pt)
@@ -191,14 +209,51 @@ namespace Nova {
 	}
 
 
+	ALWAYS_INLINE
+	inline uint8_t util_time(Syscall const syscall, mword_t const cap,
+	                         uint8_t const op, unsigned long long &time)
+	{
+		mword_t time_h = 0, time_l = 0;
+		uint8_t res = syscall_5(syscall, op, cap, time_h, time_l);
+		time = (time_h << 32ULL) | (time_l & 0xFFFFFFFFULL);
+		return res;
+	}
+
+
+	ALWAYS_INLINE
+	inline uint8_t sc_ec_time(mword_t const cap_sc, mword_t const cap_ec,
+	                          unsigned long long &time_sc,
+	                          unsigned long long &time_ec)
+	{
+		mword_t time_h_sc = cap_ec, time_l_sc = 0;
+		mword_t time_h_ec = 0, time_l_ec = 0;
+		uint8_t res = syscall_6(NOVA_SC_CTRL, Sc_op::SC_EC_TIME, cap_sc,
+		                        time_h_sc, time_l_sc, time_h_ec,
+		                        time_l_ec);
+		time_sc = (time_h_sc << 32ULL) | (time_l_sc & 0xFFFFFFFFULL);
+		time_ec = (time_h_ec << 32ULL) | (time_l_ec & 0xFFFFFFFFULL);
+		return res;
+	}
+
+
 	ALWAYS_INLINE
 	inline uint8_t ec_ctrl(Ec_op op, mword_t ec = ~0UL, mword_t para = ~0UL,
 	                       Crd crd = 0)
 	{
+		if (op == EC_TIME)
+			return NOVA_INV_HYPERCALL;
+
 		return syscall_2(NOVA_EC_CTRL, op, ec, para, crd.value());
 	}
 
 
+	ALWAYS_INLINE
+	inline uint8_t ec_time(mword_t const ec, unsigned long long &time)
+	{
+		return util_time(NOVA_EC_CTRL, ec, Ec_op::EC_TIME, time);
+	}
+
+
 	ALWAYS_INLINE
 	inline uint8_t create_sc(mword_t sc, mword_t pd, mword_t ec, Qpd qpd)
 	{
@@ -316,13 +371,10 @@ namespace Nova {
 
 
 	ALWAYS_INLINE
-	inline uint8_t sc_ctrl(mword_t sm, unsigned long long &time, uint8_t op = 0)
+	inline uint8_t sc_ctrl(mword_t const sc, unsigned long long &time,
+	                       Sc_op const op)
 	{
-		mword_t time_h = 0, time_l = 0;
-		uint8_t res = syscall_5(NOVA_SC_CTRL, op, sm, time_h, time_l);
-		time = time_h;
-		time = (time << 32ULL) | (time_l & 0xFFFFFFFFULL);
-		return res;
+		return util_time(NOVA_SC_CTRL, sc, op, time);
 	}
 
 

repos/base-nova/ports/nova.hash

@@ -1 +1 @@
-36430efef054479ea2cc06f2052a85a09e9bf232
+33a2fa953ec52b0f63b921f4d33d68891c0aada0

repos/base-nova/ports/nova.port

@@ -4,7 +4,7 @@ DOWNLOADS := nova.git
 
 # r10 branch
 URL(nova) := https://github.com/alex-ab/NOVA.git
-REV(nova) := d7804f2125ad9ba1b86ad983261f72bdc1c0cfe7
+REV(nova) := 00dc49bc18e7f72a9c85487e8f94fd859511d89d
 DIR(nova) := src/kernel/nova
 
 PATCHES   := $(sort $(wildcard $(REP_DIR)/patches/*.patch))

repos/base-nova/recipes/api/base-nova/hash

@@ -1 +1 @@
-2021-12-16 d00dfe16c059040c919a1357290f72eea835c360
+2022-05-24 91bc8d51bbe703d56f5671019d14e4636f21bf1f

repos/base-nova/recipes/src/base-nova/hash

@@ -1 +1 @@
-2022-04-27 79e707a36495b1440bda0a2d0784591467afb52e
+2022-05-24 8b59a28ade1392bae4aa772bbead1584a2dde1de

repos/base-nova/src/core/platform.cc

@@ -391,23 +391,6 @@ Platform::Platform()
 	              Obj_crd(sc_idle_base, log2cpu), true))
 		nova_die();
 
-	/* test reading out idle SCs */
-	bool sc_init = true;
-	for (unsigned i = 0; i < hip.cpu_max(); i++) {
-
-		if (!hip.is_cpu_enabled(i))
-			continue;
-
-		uint64_t n_time;
-		uint8_t res = Nova::sc_ctrl(sc_idle_base + i, n_time);
-		if (res != Nova::NOVA_OK) {
-			sc_init = false;
-			error(i, " ", res, " ", n_time, " - failed");
-		}
-	}
-	if (!sc_init)
-		nova_die();
-
 	/* configure virtual address spaces */
 #ifdef __x86_64__
 	_vm_size = 0x7fffc0000000UL - _vm_base;
@@ -865,19 +848,30 @@ Platform::Platform()
 			Info trace_source_info() const override
 			{
 				uint64_t sc_time = 0;
+				uint64_t ec_time = 0;
+				uint8_t  res = 0;
 
-				enum SYSCALL_OP { IDLE_SC = 0, CROSS_SC = 1,
-				                  KILLED_SC = 2 };
-				uint8_t syscall_op =  (name == "cross")  ? CROSS_SC :
-				                     ((name == "killed") ? KILLED_SC : IDLE_SC);
+				if (name == "killed") {
+					res = Nova::sc_ec_time(sc_sel, sc_sel,
+					                       sc_time, ec_time);
+				} else {
+					auto syscall_op = (name == "cross")
+					                ? Sc_op::SC_TIME_CROSS
+					                : Sc_op::SC_TIME_IDLE;
+
+					res = Nova::sc_ctrl(sc_sel, sc_time,
+					                    syscall_op);
+
+					if (syscall_op == Sc_op::SC_TIME_IDLE)
+						ec_time = sc_time;
+				}
 
-				uint8_t res = Nova::sc_ctrl(sc_sel, sc_time, syscall_op);
 				if (res != Nova::NOVA_OK)
-					warning("sc_ctrl on idle SC cap, op=", syscall_op,
+					warning("sc_ctrl on ", name, " failed"
 					        ", res=", res);
 
 				return { Session_label("kernel"), Trace::Thread_name(name),
-				         Trace::Execution_time(sc_time, sc_time), affinity };
+				         Trace::Execution_time(ec_time, sc_time), affinity };
 			}
 
 			Trace_source(Trace::Source_registry &registry,
@@ -920,16 +914,26 @@ Platform::Platform()
 		 */
 		Info trace_source_info() const override
 		{
+			uint64_t ec_time = 0;
 			uint64_t sc_time = 0;
 
 			if (name == "root") {
-				uint8_t res = Nova::sc_ctrl(ec_sc_sel + 1, sc_time);
+				uint8_t res = Nova::sc_ec_time(ec_sc_sel + 1,
+				                               ec_sc_sel,
+				                               sc_time,
+				                               ec_time);
 				if (res != Nova::NOVA_OK)
-					warning("sc_ctrl for ", name, " thread failed res=", res);
+					warning("sc_ec_time for root failed "
+					        "res=", res);
+			} else {
+				uint8_t res = Nova::ec_time(ec_sc_sel, ec_time);
+				if (res != Nova::NOVA_OK)
+					warning("ec_time for", name, " thread "
+					        "failed res=", res);
 			}
 
 			return { Session_label("core"), name,
-			         Trace::Execution_time(sc_time, sc_time), location };
+			         Trace::Execution_time(ec_time, sc_time), location };
 		}
 
 		Core_trace_source(Trace::Source_registry &registry,

repos/base-nova/src/core/platform_thread.cc

@@ -314,17 +314,22 @@ const char * Platform_thread::pd_name() const {
 
 Trace::Execution_time Platform_thread::execution_time() const
 {
-	unsigned long long time = 0;
+	uint64_t sc_time = 0;
+	uint64_t ec_time = 0;
 
-	/* for ECs without a SC we simply return 0 */
-	if (!sc_created())
-		return { time, time, Nova::Qpd::DEFAULT_QUANTUM, _priority };
+	if (!sc_created()) {
+		/* time executed by EC (on whatever SC) */
+		uint8_t res = Nova::ec_time(_sel_ec(), ec_time);
+		if (res != Nova::NOVA_OK)
+			warning("ec_time failed res=", res);
+		return { ec_time, sc_time, Nova::Qpd::DEFAULT_QUANTUM, _priority };
+	}
 
-	uint8_t res = Nova::sc_ctrl(_sel_sc(), time);
+	uint8_t res = Nova::sc_ec_time(_sel_sc(), _sel_ec(), sc_time, ec_time);
 	if (res != Nova::NOVA_OK)
 		warning("sc_ctrl failed res=", res);
 
-	return { time, time, Nova::Qpd::DEFAULT_QUANTUM, _priority };
+	return { ec_time, sc_time, Nova::Qpd::DEFAULT_QUANTUM, _priority };
 }
 
 

repos/base-nova/src/core/thread_start.cc

@@ -127,10 +127,14 @@ void Thread::start()
 		 */
 		Info trace_source_info() const override
 		{
-			uint64_t sc_time = 0;
+			uint64_t ec_time = 0;
+
+			uint8_t res = Nova::ec_time(thread.native_thread().ec_sel, ec_time);
+			if (res != Nova::NOVA_OK)
+				warning("ec_time for core thread failed res=", res);
 
 			return { Session_label("core"), thread.name(),
-			         Trace::Execution_time(sc_time, sc_time), thread._affinity };
+			         Trace::Execution_time(ec_time, 0), thread._affinity };
 		}
 
 		Core_trace_source(Trace::Source_registry &registry, Thread &t)

repos/base-nova/src/core/vm_session_component.cc

@@ -85,14 +85,15 @@ static uint8_t _with_kernel_quota_upgrade(addr_t const pd_target,
 
 Trace::Source::Info Vm_session_component::Vcpu::trace_source_info() const
 {
+	uint64_t ec_time = 0;
 	uint64_t sc_time = 0;
 
-	uint8_t res = Nova::sc_ctrl(sc_sel(), sc_time);
+	uint8_t res = Nova::sc_ec_time(sc_sel(), ec_sel(), sc_time, ec_time);
 	if (res != Nova::NOVA_OK)
-		warning("sc_ctrl failed res=", res);
+		warning("vCPU sc_ec_time failed res=", res);
 
 	return { _label, String<5>("vCPU"),
-	         Trace::Execution_time(sc_time, sc_time,
+	         Trace::Execution_time(ec_time, sc_time,
 	                               Nova::Qpd::DEFAULT_QUANTUM, _priority),
 	         _location };
 }

repos/base-okl4/recipes/src/base-okl4/hash

@@ -1 +1 @@
-2022-04-12 75bbf010d07ee7f147f9dc6f81d7bc2fec70ef19
+2022-05-24 3b2acba4ebd649394e26217802598cf650a4b226

repos/base-pistachio/recipes/src/base-pistachio/hash

@@ -1 +1 @@
-2022-04-12 d749455e1dda2b9018e3ba608690d32a2254d1ce
+2022-05-24 ca2c90ebcbaa61ade7373d6ea48a608912cd2629

repos/base-sel4/recipes/src/base-sel4-imx6q_sabrelite/hash

@@ -1 +1 @@
-2022-04-12 6bbbe187b314a07dbf166553defb70213efcf362
+2022-05-24 5d9558d34f4bd3f3e34d9b175fe3eb37be3561be

repos/base-sel4/recipes/src/base-sel4-imx7d_sabre/hash

@@ -1 +1 @@
-2022-04-12 72aef283487d98ed4bff3a7de5449b489b21653d
+2022-05-24 70a360e5c7b6aed126fb99fc3666cfce030cf53e

repos/base-sel4/recipes/src/base-sel4-x86/hash

@@ -1 +1 @@
-2022-04-12 9b448f6076f23f98bce0f14a2f71b238a06cce4e
+2022-05-24 fa03ec1bf7ea9b643319d67dbd52e146e0d98189

repos/base/board/pbxa9/devices

@@ -0,0 +1,25 @@
+<devices>
+	<device name="sp810_syscon0" type="arm,sp810">
+		<io_mem address="0x10001000" size="0x1000"/>
+	</device>
+
+	<device name="clcd" type="arm,pl111">
+		<io_mem address="0x10020000" size="0x1000"/>
+	</device>
+
+	<device name="mmc0" type="arm,pl18x">
+		<io_mem address="0x10005000" size="0x1000"/>
+	</device>
+
+	<device name="pl050" type="arm,pl050">
+		<io_mem address="0x10006000" size="0x1000"/>
+		<io_mem address="0x10007000" size="0x1000"/>
+		<irq    number="52"/>
+		<irq    number="53"/>
+	</device>
+
+	<device name="ethernet" type="smsc,lan9118">
+		<io_mem address="0x4e000000" size="0x1000"/>
+		<irq    number="60"/>
+	</device>
+</devices>

repos/base/include/base/trace/buffer.h

@@ -251,6 +251,9 @@ class Genode::Trace::Simple_buffer
 
 			public:
 
+				/* return invalid entry (checked by last()) */
+				static Entry invalid()     { return Entry(0); }
+
 				size_t      length() const { return _entry->len; }
 				char const *data()   const { return _entry->data; }
 
@@ -264,8 +267,18 @@ class Genode::Trace::Simple_buffer
 				bool head()     const { return !last() && _entry->head(); }
 		};
 
+		/* Return whether buffer has been initialized. */
+		bool initialized() const { return _size && _head_offset <= _size; }
+
 		/* Return the very first entry at the start of the buffer. */
-		Entry first() const { return Entry(_entries); }
+		Entry first() const
+		{
+			/* return invalid entry if buffer is uninitialised */
+			if (!initialized())
+				return Entry::invalid();
+
+			return Entry(_entries);
+		}
 
 		/**
 		 * Return the entry that follows the given entry.
@@ -278,14 +291,14 @@ class Genode::Trace::Simple_buffer
 		Entry next(Entry entry) const
 		{
 			if (entry.last() || entry._padding())
-				return Entry(0);
+				return Entry::invalid();
 
 			if (entry.head())
 				return entry;
 
 			addr_t const offset = (addr_t)entry.data() - (addr_t)_entries;
 			if (offset + entry.length() + sizeof(_Entry) > _size)
-				return Entry(0);
+				return Entry::invalid();
 
 			return Entry((_Entry const *)((addr_t)entry.data() + entry.length()));
 		}
@@ -382,11 +395,11 @@ class Genode::Trace::Partitioned_buffer
 		 ** Functions called from the TRACE client **
 		 ********************************************/
 
-		unsigned wrapped() { return _wrapped; }
+		unsigned           wrapped()      const { return _wrapped; }
+		unsigned long long lost_entries() const { return _lost_entries; }
 
-		unsigned long long lost_entries() { return _lost_entries; }
-
-		Entry first() const { return _consumer().first(); }
+		Entry first()       const { return _consumer().first(); }
+		bool  initialized() const { return _secondary_offset > 0 && _consumer().initialized(); }
 
 		/**
 		 * Return the entry that follows the given entry.

repos/base/recipes/api/base/hash

@@ -1 +1 @@
-2022-04-12 fb3628ad0b213af0ee5f4411d21ca2cdba196ee5
+2022-05-24 d4b5b53bc270cebd87bf01a93c6da241077aad42

repos/base/recipes/pkg/test-ds_ownership/hash

@@ -1 +1 @@
-2022-04-12 8afcd6b3a2bdbca1b4e81a21d62d49d1f639f582
+2022-05-24 5e486a0f27fdda0a70b9275d62257d98e26589c8

repos/base/recipes/pkg/test-entrypoint/hash

@@ -1 +1 @@
-2022-04-12 761a24703964e8e3c89fe0eb663e0bb2cb307b5c
+2022-05-24 e35abe047c7ec7fe02c0939de16bfc80ed421d38

repos/base/recipes/pkg/test-log/hash

@@ -1 +1 @@
-2022-04-12 69c48bcdde51e229e9cb67134acfbd336bad1809
+2022-05-24 79d43c7e33381048618dbd7ba6ca34a3eda23f6c

repos/base/recipes/pkg/test-mmio/hash

@@ -1 +1 @@
-2022-04-12 4fef76b4378b7b84d912fcdc954cb210b9c0550d
+2022-05-24 4b2af7d33e8264d080be962d0a4d9a6404ec4bc0

repos/base/recipes/pkg/test-new_delete/hash

@@ -1 +1 @@
-2022-04-12 0d99d7c84ebbd237cb9c3e634e05389c912dd8ee
+2022-05-24 ed1f37d2213211897d5360c9a8f32404d670722a

repos/base/recipes/pkg/test-reconstructible/hash

@@ -1 +1 @@
-2022-04-12 a9c0c59d77f9a3abd01a7b0d90fa2fab1124558b
+2022-05-24 f09098d18ca36bc8829a673be78dd80460c3d65e

repos/base/recipes/pkg/test-registry/hash

@@ -1 +1 @@
-2022-04-12 1d18ff087d642bc0c5577d97a2fd34572ffe050f
+2022-05-24 3f91b26dbd239c52bb9af22e8f7713743ee851f4

repos/base/recipes/pkg/test-rm_fault/hash

@@ -1 +1 @@
-2022-04-12 8900883d68a00225e378fbf584b9d897f33c2f01
+2022-05-24 edbf57617935a054a681e097a611006496ed4c88

repos/base/recipes/pkg/test-rm_fault_no_nox/hash

@@ -1 +1 @@
-2022-04-12 a222b8a01346342d03e94a466d333b482250a77f
+2022-05-24 ce2c9008ed6ea0db13999e9c6ab77a098d4f94a0

repos/base/recipes/pkg/test-rm_nested/hash

@@ -1 +1 @@
-2022-04-12 b85580f5c6d7098671bc106756f083a4af46d8e7
+2022-05-24 afd4f2249a2d56bb6b29b6c0d24923ef2ec215c9

repos/base/recipes/pkg/test-rm_stress/hash

@@ -1 +1 @@
-2022-04-12 544d9bc6d1aab7f8749776afead8807b74907f94
+2022-05-24 436a166f1c4371619d7a64bf879dd0ce2dc75429

repos/base/recipes/pkg/test-sanitizer/hash

@@ -1 +1 @@
-2022-04-12 c4ebd781140f75099d3b6f46b6a77337008765a0
+2022-05-24 3877f6f98ff7c3921bdb7b2b83f40a161e9cd5bb

repos/base/recipes/pkg/test-stack_smash/hash

@@ -1 +1 @@
-2022-04-12 82ec283c5e41e5a75dc013d3d94f538d937473d6
+2022-05-24 00a8e3979871b2a0ab67088c3d2b57454ed653f9

repos/base/recipes/pkg/test-synced_interface/hash

@@ -1 +1 @@
-2022-04-12 7f00747f5171f4c2c53d7772cb792504c5eb904f
+2022-05-24 ab7b5f631d4abf8b01ed6b08c4da83b4164564a8

repos/base/recipes/pkg/test-timer/hash

@@ -1 +1 @@
-2022-04-12 5bbe2f681e5dede0b27bbb3b36d20420af9fb4f7
+2022-05-24 91ed52185381c38cf7e425fb0c351b46c4548b4f

repos/base/recipes/pkg/test-tls/hash

@@ -1 +1 @@
-2022-04-12 bdb723f20c48fb55e00343c28fb049ac5bc6bd52
+2022-05-24 7ff4d04d0b470eb6974b633bb0dca1212158f625

repos/base/recipes/pkg/test-token/hash

@@ -1 +1 @@
-2022-04-12 7cca5f89f5480d543abeebd45fe12be82ba22793
+2022-05-24 b96b88fee3e0946fea12a44cea94963b2b16d173

repos/base/recipes/pkg/test-xml_generator/hash

@@ -1 +1 @@
-2022-04-12 cc56de5578aec851e1eaaf8bbe9d1be06b5445ba
+2022-05-24 c2d9a2849fe51277372d301c9a46d034c4674ab9

repos/base/recipes/pkg/test-xml_node/hash

@@ -1 +1 @@
-2022-04-12 77ed90de2b6f85dc293aa37124286567c947b664
+2022-05-24 88eb29b90a1e663e1f58de04a6a178f3a035f3f5

repos/base/recipes/src/test-ds_ownership/hash

@@ -1 +1 @@
-2022-04-12 75748d834e4e2d2818673488476418c2e9cc56bf
+2022-05-24 715bfaa6ea0bff54c0e2477c1bbccf56c0bfc935

repos/base/recipes/src/test-entrypoint/hash

@@ -1 +1 @@
-2022-04-12 53faf43def8ccb133f7c795233986d48b430420f
+2022-05-24 05d5db1ec0b7fff36e8526fe701873731fd08660

repos/base/recipes/src/test-log/hash

@@ -1 +1 @@
-2022-04-12 4d60e90714205f78fc3886a49fc29aaf338c8253
+2022-05-24 7d26fbbb584ab24b8156eda78a8eca5bc9e1122f

repos/base/recipes/src/test-mmio/hash

@@ -1 +1 @@
-2022-04-12 324c809a3e76c5e0810a6f230a804f8cbe13c4cb
+2022-05-24 6542fc1df645f45c9fc71b5c18b458a9e630470d

repos/base/recipes/src/test-new_delete/hash

@@ -1 +1 @@
-2022-04-12 c279d75f47baa0886774379c2c2d9d81de315fb4
+2022-05-24 67caefb3bbf5926dbd2ca46bbe933882de542db3

repos/base/recipes/src/test-reconstructible/hash

@@ -1 +1 @@
-2022-04-12 d8861e98b74a05ca2b29198ece000cc7de86680c
+2022-05-24 915f8bebfcdbfe4ef499ea94985303bacebeb8e8

repos/base/recipes/src/test-registry/hash

@@ -1 +1 @@
-2022-04-12 c8ec50e2779f9c614d4546c09beafb3c49df17af
+2022-05-24 e1e3559b2f3010d96d19e81cbaa6abbeb07c6251

repos/base/recipes/src/test-rm_fault/hash

@@ -1 +1 @@
-2022-04-12 09822f3897cdeb262aa071815dbcd73684f6e89e
+2022-05-24 93812b90ee88b44d4fc3b26af77ad0344359e51a

repos/base/recipes/src/test-rm_nested/hash

@@ -1 +1 @@
-2022-04-12 5c83887aff45c71edd2b0a20ef8472e16b248f21
+2022-05-24 465cc6225756312ca657c39d5a398fd276088118

repos/base/recipes/src/test-rm_stress/hash

@@ -1 +1 @@
-2022-04-12 ed17306e6ff7c21446cd409cc22bf5c4f3bad88a
+2022-05-24 dd009dd4ea58101e1c15e5bd38cad4241f726fa4

repos/base/recipes/src/test-sanitizer/hash

@@ -1 +1 @@
-2022-04-12 80146d4e0cac667402e6cb52de0668b301121025
+2022-05-24 34b25aabaef3112a38eb0a24a13cf6e42da6ba65

repos/base/recipes/src/test-segfault/hash

@@ -1 +1 @@
-2022-04-12 0129e7397e0503cb1562206b03bcdafe5ac6133d
+2022-05-24 632e59190a6bcfe40a5a88ecff9f05e2924a43b1

repos/base/recipes/src/test-stack_smash/hash

@@ -1 +1 @@
-2022-04-12 329a76b6116a58718c0d63be5ea22d94ca17925b
+2022-05-24 4e254230305117e2ce5dd2c13caa650ea65251e7

repos/base/recipes/src/test-synced_interface/hash

@@ -1 +1 @@
-2022-04-12 7d2b5210ec3b32e0a8692274f6f740332fd3e1af
+2022-05-24 f9126bd0df2b402150c7ef76138d5ecb8cee05d4

repos/base/recipes/src/test-timer/hash

@@ -1 +1 @@
-2022-04-12 4d532160ed71fb086bcdc6169291ae10d48b56b8
+2022-05-24 402acbf040b8f905dcc0979700f6077d36dc707d

repos/base/recipes/src/test-tls/hash

@@ -1 +1 @@
-2022-04-12 2983606e3daac976fc676a6494d694be8b2de629
+2022-05-24 4ddec10779302c6d0c47ccbeba806fe1278e182b

repos/base/recipes/src/test-token/hash

@@ -1 +1 @@
-2022-04-12 3abadc1fb51217acb0d9f46bec922e8915e2b240
+2022-05-24 f04c4162857259fd48d864e9076ae401c9093dbb

repos/base/recipes/src/test-xml_generator/hash

@@ -1 +1 @@
-2022-04-12 5e04ad9b6f635189db3fcda4bd44d4b4f39f6d03
+2022-05-24 e91f2b05a682df2206b8f487b7cb01cc8150350e

repos/base/recipes/src/test-xml_node/hash

@@ -1 +1 @@
-2022-04-12 6432ce98d2c92781bb1dbdfe701725279ebf27c2
+2022-05-24 39a7ce53177b2bad4928846f40b8ef542d8f6840

repos/dde_bsd/recipes/pkg/bsd_audio_drv/hash

@@ -1 +1 @@
-2022-04-12 2025f131853e478e2dfbce68436be9d0a225c2b3
+2022-05-24 1457c977583577de2e68eae2ac492c7a95ba9e4c

repos/dde_bsd/recipes/src/bsd_audio_drv/hash

@@ -1 +1 @@
-2022-04-12 dbb1fde49cb0566905830584123db6c9c266a6a5
+2022-05-24 d468d19c3211d09086b582583fa745223ff47594

repos/dde_ipxe/recipes/pkg/ipxe_nic_drv/hash

@@ -1 +1 @@
-2022-04-27 b3df287f0aa303a7cafb168296c47f5b3f7a9ff6
+2022-05-24 d7226793ef4487760e21fbac216881184e04de20

repos/dde_ipxe/recipes/src/ipxe_nic_drv/hash

@@ -1 +1 @@
-2022-04-27 aa176da773d379078728090b516d7e6abd2fcbc3
+2022-05-24 489d48889bcec01cac3c2646f24edab38128ed7c

repos/dde_linux/README

@@ -33,118 +33,6 @@ library named 'lxip.lib.so'. The IP stack can be interfaced using Genode's
 version of 'libc' by linking your application to 'lxip_libc' plugin in your
 'target.mk' file.
 
-WiFi
-####
-
-The wifi_drv component is a port of the Linux mac802.11 stack, including the
-iwlwifi driver as well as libnl and wpa_supplicant, to Genode.
-
-To start the component the following configuration snippet can be used:
-
-!<start name="wifi_drv" caps="200">
-!  <resource name="RAM" quantum="24M"/>
-!  <provides><service name="Nic"/></provides>
-!  <config>
-!    <libc stdout="/dev/null" stderr="/dev/null" rtc="/dev/rtc"/>
-!    <vfs>
-!      <dir name="dev"> <log/> <null/> <rtc/>
-!      <jitterentropy name="random"/>
-!      <jitterentropy name="urandom"/>
-!      </dir>
-!    </vfs>
-!  </config>
-!  <route>
-!    <service name="Rtc"> <any-child /> </service>
-!    <any-service> <parent/> <any-child /> </any-service>
-!  </route>
-!</start
-
-The driver will request access to the ROM module 'wifi_config' to
-connect to a network:
-
-!<wifi_config connected_scan_interval="30" scan_interval="10" rfkill="no">
-!  <network ssid="Foobar" protection="WPA2" passphrase="allyourbase"/>
-!</wifi_config>
-
-To temporarily prevent any radio activity, the 'rfkill' attribute
-can be set to 'true'.
-
-If the network is protected by, e.g., WPA/WPA2, the protection type, either
-'WPA' or 'WPA2' as well as the the passphrase have to be specified.
-The 'bssid' attribute can be used to select a specifc accesspoint within a
-network. Of all attributes only the 'ssid' attribute is mandatory, all others
-are optional and should only be used when needed.
-
-The configuration may contain more than one network. In This case the driver
-will try to select the best one it gets a response from. To prevent it
-from automatically joining the network the 'auto_connect' attribute must be
-set to 'false'; the default value is 'true'. If the 'explicit_scan' attribute
-is set, the driver will pro-actively scan for a hidden network with the given
-SSID:
-
-!<wifi_config connected_scan_interval="30" scan_interval="10">
-!  <network ssid="Zero" protection="WPA2" passphrase="allyourbase"/>
-!  <network ssid="Skynet" protection="WPA" passphrase="12345678"
-!           explicit_scan="true" auto_connect="false"/>
-!</wifi_config>
-
-By default, the driver scans for available networks only when not
-connected. This can be changed with the 'connected_scan_interval'
-attribute, which specifies the interval for connected scans in
-seconds and directly influences any roaming decision, i.e., select
-a better fit accesspoint for the configured network.
-
-Also, the driver can be switched to verbose logging during runtime
-by setting the 'verbose' or 'verbose_state' attribute to 'true'.
-
-The wifi_drv creates two distinct reports to communicate its state and
-information about the wireless infrastructure to other components. The
-first one is a list of all available accesspoints. The following examplary
-report shows its general structure:
-
-!<accesspoints>
-!  <accesspoint ssid="skynet" bssid="00:01:02:03:04:05" quality="40"/>
-!  <accesspoint ssid="foobar" bssid="01:02:03:04:05:06" quality="70" protection="WPA2"/>
-!  <accesspoint ssid="foobar" bssid="01:02:03:04:05:07" quality="10" protection="WPA2"/>
-!</accesspoints>
-
-Each accesspoint node has attributes that contain the SSID and the BSSID
-of the accesspoint as well as the link quality (signal strength). These
-attributes are mandatory. If the network is protected, the node will also
-have an attribute describing the type of protection in addition.
-
-The second report provides information about the state of the connection
-to the currently connected accesspoint:
-
-!<state>
-!  <accesspoint ssid="foobar" bssid="01:02:03:04:05:06" quality="70" freq="2418" state="connected"/>
-!</state>
-
-Valid state values are 'connected', 'disconnected', 'connecting'. Depending
-on the state, there are additional attributes that can be checked. In case
-of an authentication error, e.g. the passphrase is wrong, the 'auth_failure'
-attribute will be set to 'true'. The 'rfkilled' attribute is set to 'true'
-if a disconnect was triggered by disabling the radio activity via setting
-the 'rfkill' attribute.
-
-By subscribing to both reports and providing the required 'wifi_config' ROM
-module, a component is able control the wireless driver.
-
-Currently only WPA/WPA2 protection using a passphrase is supported and the the
-SSID is copied verbatim. At the moment, there is no way to express or escape
-non alphanumeric characters.
-
-On certain cards, e.g. Intel Wireless 6200 ABG, it may be necessary to disable
-the 11n mode. This can be achieved by setting the 'use_11n' attribute in
-the 'wifi_config' node to 'no'.
-
-The driver optionally reports the following information under the
-label "devices" if requested in the config as depicted.
-
-! <config> <report mac_address="true"/> </config>
-
-! <devices> <nic mac_address="02:00:00:00:00:01"/> </devices>
-
 
 lx_kit
 ######

repos/dde_linux/intel_fb.list

@@ -1,271 +0,0 @@
-linux-x.x.x/arch/x86/include/asm/agp.h
-linux-x.x.x/arch/x86/include/asm/iosf_mbi.h
-linux-x.x.x/arch/x86/include/asm/pci-direct.h
-linux-x.x.x/arch/x86/kernel/early-quirks.c
-linux-x.x.x/drivers/char/agp/agp.h
-linux-x.x.x/drivers/char/agp/backend.c
-linux-x.x.x/drivers/char/agp/generic.c
-linux-x.x.x/drivers/char/agp/intel-agp.h
-linux-x.x.x/drivers/char/agp/intel-gtt.c
-linux-x.x.x/drivers/dma-buf/dma-fence.c
-linux-x.x.x/drivers/dma-buf/dma-fence-array.c
-linux-x.x.x/drivers/gpu/drm/drm_atomic_helper.c
-linux-x.x.x/drivers/gpu/drm/drm_atomic.c
-linux-x.x.x/drivers/gpu/drm/drm_blend.c
-linux-x.x.x/drivers/gpu/drm/drm_bridge.c
-linux-x.x.x/drivers/gpu/drm/drm_cache.c
-linux-x.x.x/drivers/gpu/drm/drm_connector.c
-linux-x.x.x/drivers/gpu/drm/drm_color_mgmt.c
-linux-x.x.x/drivers/gpu/drm/drm_crtc.c
-linux-x.x.x/drivers/gpu/drm/drm_crtc_helper.c
-linux-x.x.x/drivers/gpu/drm/drm_crtc_helper_internal.h
-linux-x.x.x/drivers/gpu/drm/drm_crtc_internal.h
-linux-x.x.x/drivers/gpu/drm/drm_dp_dual_mode_helper.c
-linux-x.x.x/drivers/gpu/drm/drm_dp_helper.c
-linux-x.x.x/drivers/gpu/drm/drm_dp_mst_topology.c
-linux-x.x.x/drivers/gpu/drm/drm_edid.c
-linux-x.x.x/drivers/gpu/drm/drm_encoder.c
-linux-x.x.x/drivers/gpu/drm/drm_fourcc.c
-linux-x.x.x/drivers/gpu/drm/drm_framebuffer.c
-linux-x.x.x/drivers/gpu/drm/drm_gem.c
-linux-x.x.x/drivers/gpu/drm/drm_internal.h
-linux-x.x.x/drivers/gpu/drm/drm_irq.c
-linux-x.x.x/drivers/gpu/drm/drm_mm.c
-linux-x.x.x/drivers/gpu/drm/drm_mode_config.c
-linux-x.x.x/drivers/gpu/drm/drm_mode_object.c
-linux-x.x.x/drivers/gpu/drm/drm_modes.c
-linux-x.x.x/drivers/gpu/drm/drm_modeset_helper.c
-linux-x.x.x/drivers/gpu/drm/drm_modeset_lock.c
-linux-x.x.x/drivers/gpu/drm/drm_plane.c
-linux-x.x.x/drivers/gpu/drm/drm_plane_helper.c
-linux-x.x.x/drivers/gpu/drm/drm_probe_helper.c
-linux-x.x.x/drivers/gpu/drm/drm_property.c
-linux-x.x.x/drivers/gpu/drm/drm_rect.c
-linux-x.x.x/drivers/gpu/drm/drm_vblank.c
-linux-x.x.x/drivers/gpu/drm/drm_vma_manager.c
-linux-x.x.x/drivers/gpu/drm/i915/i915_drv.c
-linux-x.x.x/drivers/gpu/drm/i915/i915_drv.h
-linux-x.x.x/drivers/gpu/drm/i915/i915_vma.c
-linux-x.x.x/drivers/gpu/drm/i915/i915_gem.c
-linux-x.x.x/drivers/gpu/drm/i915/i915_gem.h
-linux-x.x.x/drivers/gpu/drm/i915/i915_gemfs.h
-linux-x.x.x/drivers/gpu/drm/i915/i915_gem_batch_pool.h
-linux-x.x.x/drivers/gpu/drm/i915/i915_gem_context.c
-linux-x.x.x/drivers/gpu/drm/i915/i915_gem_context.h
-linux-x.x.x/drivers/gpu/drm/i915/i915_gem_clflush.c
-linux-x.x.x/drivers/gpu/drm/i915/i915_gem_clflush.h
-linux-x.x.x/drivers/gpu/drm/i915/i915_gem_fence_reg.c
-linux-x.x.x/drivers/gpu/drm/i915/i915_gem_fence_reg.h
-linux-x.x.x/drivers/gpu/drm/i915/i915_gem_gtt.c
-linux-x.x.x/drivers/gpu/drm/i915/i915_gem_gtt.h
-linux-x.x.x/drivers/gpu/drm/i915/i915_gem_internal.c
-linux-x.x.x/drivers/gpu/drm/i915/i915_gem_object.h
-linux-x.x.x/drivers/gpu/drm/i915/i915_gem_render_state.c
-linux-x.x.x/drivers/gpu/drm/i915/i915_gem_render_state.h
-linux-x.x.x/drivers/gpu/drm/i915/i915_gem_request.c
-linux-x.x.x/drivers/gpu/drm/i915/i915_gem_request.h
-linux-x.x.x/drivers/gpu/drm/i915/i915_gem_stolen.c
-linux-x.x.x/drivers/gpu/drm/i915/i915_gem_tiling.c
-linux-x.x.x/drivers/gpu/drm/i915/i915_gem_timeline.c
-linux-x.x.x/drivers/gpu/drm/i915/i915_gem_timeline.h
-linux-x.x.x/drivers/gpu/drm/i915/i915_irq.c
-linux-x.x.x/drivers/gpu/drm/i915/i915_params.h
-linux-x.x.x/drivers/gpu/drm/i915/i915_pci.c
-linux-x.x.x/drivers/gpu/drm/i915/i915_pmu.h
-linux-x.x.x/drivers/gpu/drm/i915/i915_pvinfo.h
-linux-x.x.x/drivers/gpu/drm/i915/i915_reg.h
-linux-x.x.x/drivers/gpu/drm/i915/i915_selftest.h
-linux-x.x.x/drivers/gpu/drm/i915/i915_sw_fence.h
-linux-x.x.x/drivers/gpu/drm/i915/i915_syncmap.h
-linux-x.x.x/drivers/gpu/drm/i915/i915_utils.h
-linux-x.x.x/drivers/gpu/drm/i915/i915_vma.h
-linux-x.x.x/drivers/gpu/drm/i915/i915_vgpu.c
-linux-x.x.x/drivers/gpu/drm/i915/i915_vgpu.h
-linux-x.x.x/drivers/gpu/drm/i915/intel_atomic.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_atomic_plane.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_bios.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_bios.h
-linux-x.x.x/drivers/gpu/drm/i915/intel_cdclk.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_color.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_crt.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_device_info.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_device_info.h
-linux-x.x.x/drivers/gpu/drm/i915/intel_ddi.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_display.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_display.h
-linux-x.x.x/drivers/gpu/drm/i915/intel_dp.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_dp_link_training.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_dp_mst.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_dpio_phy.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_dpll_mgr.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_dpll_mgr.h
-linux-x.x.x/drivers/gpu/drm/i915/intel_drv.h
-linux-x.x.x/drivers/gpu/drm/i915/intel_dsi_pll.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_dsi.h
-linux-x.x.x/drivers/gpu/drm/i915/intel_fbc.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_fifo_underrun.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_frontbuffer.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_frontbuffer.h
-linux-x.x.x/drivers/gpu/drm/i915/intel_guc.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_guc.h
-linux-x.x.x/drivers/gpu/drm/i915/intel_guc_ct.h
-linux-x.x.x/drivers/gpu/drm/i915/intel_guc_fw.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_guc_fw.h
-linux-x.x.x/drivers/gpu/drm/i915/intel_guc_fwif.h
-linux-x.x.x/drivers/gpu/drm/i915/intel_guc_log.h
-linux-x.x.x/drivers/gpu/drm/i915/intel_guc_reg.h
-linux-x.x.x/drivers/gpu/drm/i915/intel_guc_submission.h
-linux-x.x.x/drivers/gpu/drm/i915/intel_gvt.h
-linux-x.x.x/drivers/gpu/drm/i915/intel_hdmi.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_hotplug.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_huc.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_huc.h
-linux-x.x.x/drivers/gpu/drm/i915/intel_i2c.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_lrc.h
-linux-x.x.x/drivers/gpu/drm/i915/intel_lspcon.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_lvds.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_mocs.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_mocs.h
-linux-x.x.x/drivers/gpu/drm/i915/intel_modes.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_opregion.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_opregion.h
-linux-x.x.x/drivers/gpu/drm/i915/intel_overlay.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_panel.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_pm.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_psr.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_renderstate.h
-linux-x.x.x/drivers/gpu/drm/i915/intel_renderstate_gen6.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_renderstate_gen7.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_renderstate_gen8.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_renderstate_gen9.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_ringbuffer.h
-linux-x.x.x/drivers/gpu/drm/i915/intel_runtime_pm.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_sdvo.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_sdvo_regs.h
-linux-x.x.x/drivers/gpu/drm/i915/intel_sideband.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_sprite.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_uc.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_uc.h
-linux-x.x.x/drivers/gpu/drm/i915/intel_uc_fw.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_uc_fw.h
-linux-x.x.x/drivers/gpu/drm/i915/intel_uncore.c
-linux-x.x.x/drivers/gpu/drm/i915/intel_uncore.h
-linux-x.x.x/drivers/gpu/drm/i915/intel_vbt_defs.h
-linux-x.x.x/drivers/i2c/algos/i2c-algo-bit.c
-linux-x.x.x/drivers/i2c/i2c-boardinfo.c
-linux-x.x.x/drivers/i2c/i2c-core.h
-linux-x.x.x/drivers/i2c/i2c-core-base.c
-linux-x.x.x/drivers/i2c/i2c-core-smbus.c
-linux-x.x.x/drivers/video/hdmi.c
-linux-x.x.x/include/asm-generic/atomic64.h
-linux-x.x.x/include/asm-generic/bitops/__ffs.h
-linux-x.x.x/include/asm-generic/bitops/__fls.h
-linux-x.x.x/include/asm-generic/bitops/ffs.h
-linux-x.x.x/include/asm-generic/bitops/fls.h
-linux-x.x.x/include/asm-generic/bitops/fls64.h
-linux-x.x.x/include/asm-generic/bitops/non-atomic.h
-linux-x.x.x/include/asm-generic/getorder.h
-linux-x.x.x/include/asm-generic/ioctl.h
-linux-x.x.x/include/drm/drmP.h
-linux-x.x.x/include/drm/drm_agpsupport.h
-linux-x.x.x/include/drm/drm_atomic.h
-linux-x.x.x/include/drm/drm_atomic_helper.h
-linux-x.x.x/include/drm/drm_auth.h
-linux-x.x.x/include/drm/drm_blend.h
-linux-x.x.x/include/drm/drm_bridge.h
-linux-x.x.x/include/drm/drm_cache.h
-linux-x.x.x/include/drm/drm_connector.h
-linux-x.x.x/include/drm/drm_color_mgmt.h
-linux-x.x.x/include/drm/drm_crtc.h
-linux-x.x.x/include/drm/drm_crtc_helper.h
-linux-x.x.x/include/drm/drm_debugfs_crc.h
-linux-x.x.x/include/drm/drm_device.h
-linux-x.x.x/include/drm/drm_displayid.h
-linux-x.x.x/include/drm/drm_dp_dual_mode_helper.h
-linux-x.x.x/include/drm/drm_dp_helper.h
-linux-x.x.x/include/drm/drm_dp_mst_helper.h
-linux-x.x.x/include/drm/drm_drv.h
-linux-x.x.x/include/drm/drm_edid.h
-linux-x.x.x/include/drm/drm_encoder.h
-linux-x.x.x/include/drm/drm_file.h
-linux-x.x.x/include/drm/drm_fixed.h
-linux-x.x.x/include/drm/drm_fourcc.h
-linux-x.x.x/include/drm/drm_framebuffer.h
-linux-x.x.x/include/drm/drm_gem.h
-linux-x.x.x/include/drm/drm_global.h
-linux-x.x.x/include/drm/drm_hashtab.h
-linux-x.x.x/include/drm/drm_ioctl.h
-linux-x.x.x/include/drm/drm_irq.h
-linux-x.x.x/include/drm/drm_legacy.h
-linux-x.x.x/include/drm/drm_mm.h
-linux-x.x.x/include/drm/drm_mipi_dsi.h
-linux-x.x.x/include/drm/drm_mode_config.h
-linux-x.x.x/include/drm/drm_mode_object.h
-linux-x.x.x/include/drm/drm_modes.h
-linux-x.x.x/include/drm/drm_modeset_helper.h
-linux-x.x.x/include/drm/drm_modeset_helper_vtables.h
-linux-x.x.x/include/drm/drm_modeset_lock.h
-linux-x.x.x/include/drm/drm_pci.h
-linux-x.x.x/include/drm/drm_plane.h
-linux-x.x.x/include/drm/drm_plane_helper.h
-linux-x.x.x/include/drm/drm_print.h
-linux-x.x.x/include/drm/drm_prime.h
-linux-x.x.x/include/drm/drm_property.h
-linux-x.x.x/include/drm/drm_rect.h
-linux-x.x.x/include/drm/drm_scdc_helper.h
-linux-x.x.x/include/drm/drm_utils.h
-linux-x.x.x/include/drm/drm_vma_manager.h
-linux-x.x.x/include/drm/drm_vblank.h
-linux-x.x.x/include/drm/i915_drm.h
-linux-x.x.x/include/drm/i915_pciids.h
-linux-x.x.x/include/drm/intel-gtt.h
-linux-x.x.x/include/linux/agp_backend.h
-linux-x.x.x/include/linux/circ_buf.h
-linux-x.x.x/include/linux/dma-fence.h
-linux-x.x.x/include/linux/dma-fence-array.h
-linux-x.x.x/include/linux/hdmi.h
-linux-x.x.x/include/linux/firmware.h
-linux-x.x.x/include/linux/gpio/consumer.h
-linux-x.x.x/include/linux/i2c-algo-bit.h
-linux-x.x.x/include/linux/i2c.h
-linux-x.x.x/include/linux/idr.h
-linux-x.x.x/include/linux/interval_tree.h
-linux-x.x.x/include/linux/interval_tree_generic.h
-linux-x.x.x/include/linux/irqhandler.h
-linux-x.x.x/include/linux/io-mapping.h
-linux-x.x.x/include/linux/list.h
-linux-x.x.x/include/linux/list_sort.h
-linux-x.x.x/include/linux/llist.h
-linux-x.x.x/include/linux/math64.h
-linux-x.x.x/include/linux/log2.h
-linux-x.x.x/include/linux/pagevec.h
-linux-x.x.x/include/linux/pci_ids.h
-linux-x.x.x/include/linux/pm_runtime.h
-linux-x.x.x/include/linux/pm_wakeirq.h
-linux-x.x.x/include/linux/ratelimit.h
-linux-x.x.x/include/linux/radix-tree.h
-linux-x.x.x/include/linux/rbtree.h
-linux-x.x.x/include/linux/rbtree_augmented.h
-linux-x.x.x/include/linux/scatterlist.h
-linux-x.x.x/include/linux/sort.h
-linux-x.x.x/include/linux/vga_switcheroo.h
-linux-x.x.x/include/uapi/asm-generic/ioctl.h
-linux-x.x.x/include/uapi/drm/drm.h
-linux-x.x.x/include/uapi/drm/drm_fourcc.h
-linux-x.x.x/include/uapi/drm/drm_mode.h
-linux-x.x.x/include/uapi/drm/i915_drm.h
-linux-x.x.x/include/uapi/linux/byteorder/little_endian.h
-linux-x.x.x/include/uapi/linux/fb.h
-linux-x.x.x/include/uapi/linux/i2c.h
-linux-x.x.x/include/uapi/linux/pci_regs.h
-linux-x.x.x/include/uapi/linux/swab.h
-linux-x.x.x/include/video/display_timing.h
-linux-x.x.x/include/video/videomode.h
-linux-x.x.x/lib/div64.c
-linux-x.x.x/lib/idr.c
-linux-x.x.x/lib/list_sort.c
-linux-x.x.x/lib/llist.c
-linux-x.x.x/lib/radix-tree.c
-linux-x.x.x/lib/rbtree.c
-linux-x.x.x/lib/scatterlist.c

repos/dde_linux/lib/import/import-intel_fb_include.mk

@@ -1,28 +0,0 @@
-LX_CONTRIB_DIR := $(call select_from_ports,dde_linux)/src/drivers/framebuffer/intel
-SRC_DIR        := $(REP_DIR)/src/drivers/framebuffer/intel
-
-# architecture-dependent includes
-ifeq ($(filter-out $(SPECS),x86),)
-  ARCH_SRC_INC_DIR += $(REP_DIR)/src/include/spec/x86 \
-                      $(LX_CONTRIB_DIR)/arch/x86/include
-  ifeq ($(filter-out $(SPECS),32bit),)
-    ARCH_SRC_INC_DIR += $(REP_DIR)/src/include/spec/x86_32
-  endif # 32bit
-  ifeq ($(filter-out $(SPECS),64bit),)
-    ARCH_SRC_INC_DIR += $(REP_DIR)/src/include/spec/x86_64
-  endif # 64bit
-endif # x86
-
-INC_DIR += $(SRC_DIR)/include \
-           $(REP_DIR)/src/include \
-           $(ARCH_SRC_INC_DIR) \
-           $(LX_CONTRIB_DIR)/drivers/gpu/drm \
-           $(LX_CONTRIB_DIR)/drivers/gpu/include/drm \
-           $(LX_CONTRIB_DIR)/drivers/gpu/include \
-           $(LX_CONTRIB_DIR)/include \
-           $(LX_CONTRIB_DIR)/include/uapi \
-           $(LIB_CACHE_DIR)/intel_fb_include/include/include/include
-
-CC_OPT += -U__linux__ -D__KERNEL__
-CC_OPT += -DCONFIG_DRM_I915_KMS -DCONFIG_I2C -DCONFIG_I2C_BOARDINFO
-CC_OPT += -DCONFIG_ACPI

repos/dde_linux/lib/import/import-legacy_wifi_include.mk

@@ -1,27 +0,0 @@
-WIFI_CONTRIB_DIR := $(call select_from_ports,dde_linux)/src/lib/wifi
-SRC_DIR          := $(REP_DIR)/src/lib/legacy/wifi
-
-# architecture-dependent includes
-ifeq ($(filter-out $(SPECS),x86),)
-  ARCH_SRC_INC_DIR += $(REP_DIR)/src/include/spec/x86
-  ifeq ($(filter-out $(SPECS),32bit),)
-    ARCH_SRC_INC_DIR += $(REP_DIR)/src/include/spec/x86_32
-  endif # 32bit
-  ifeq ($(filter-out $(SPECS),64bit),)
-    ARCH_SRC_INC_DIR += $(REP_DIR)/src/include/spec/x86_64
-  endif # 64bit
-endif # x86
-
-
-#
-# The order of include-search directories is important, we need to look into
-# 'contrib' before falling back to our custom 'lx_emul.h' header.
-#
-INC_DIR += $(SRC_DIR) \
-           $(SRC_DIR)/include
-INC_DIR += $(REP_DIR)/src/include
-INC_DIR += $(ARCH_SRC_INC_DIR)
-INC_DIR += $(WIFI_CONTRIB_DIR)/include \
-           $(WIFI_CONTRIB_DIR)/include/uapi \
-           $(WIFI_CONTRIB_DIR)/drivers/net/wireless/iwlwifi
-INC_DIR += $(LIB_CACHE_DIR)/legacy_wifi_include/include/include/include

repos/dde_linux/lib/import/import-libnl.mk

@@ -1,4 +1,4 @@
-NL_CONTRIB_INC_DIR := $(call select_from_ports,dde_linux)/src/lib/libnl
+NL_CONTRIB_INC_DIR := $(call select_from_ports,libnl)/src/lib/libnl
 INC_DIR += $(NL_CONTRIB_INC_DIR)/include
 
 LIBNL_INC_DIR = $(REP_DIR)/src/lib/libnl/include

repos/dde_linux/lib/import/import-lx_emul_common.inc

@@ -44,12 +44,18 @@ ifeq ($(filter-out $(SPECS),x86_32),)
 LX_ARCH   := x86
 GEN_ARCH  := x86
 SPEC_ARCH := x86_32
+
+# temporarily add the following include path for x86 platform_session wrapper
+INC_DIR += $(DDE_LINUX_DIR)/src/include/spec/x86/lx_kit
 endif
 
 ifeq ($(filter-out $(SPECS),x86_64),)
 LX_ARCH   := x86
 GEN_ARCH  := x86
 SPEC_ARCH := x86_64
+
+# temporarily add the following include path for x86 platform_session wrapper
+INC_DIR += $(DDE_LINUX_DIR)/src/include/spec/x86/lx_kit
 endif
 
 ifeq ($(filter-out $(SPECS),arm),)
@@ -70,20 +76,17 @@ else
 TARGET_SOURCE_LIST := $(PRG_DIR)/source.list
 endif
 
-SHADOW_INC_DIR      := $(DDE_LINUX_DIR)/src/include/lx_emul/shadow
-GEN_SHADOW_INC_DIR  := $(DDE_LINUX_DIR)/src/include/spec/$(GEN_ARCH)/lx_emul/shadow
-SPEC_SHADOW_INC_DIR := $(DDE_LINUX_DIR)/src/include/spec/$(SPEC_ARCH)/lx_emul/shadow
+SHADOW_INC_DIR      := $(DDE_LINUX_DIR)/src/include/lx_emul/shadow/include
+SPEC_SHADOW_INC_DIR := $(DDE_LINUX_DIR)/src/include/lx_emul/shadow/arch/$(LX_ARCH)/include
 
 SRC_C   += lx_emul/spec/$(GEN_ARCH)/irqchip.c
 SRC_C   += lx_emul/spec/$(GEN_ARCH)/start.c
 SRC_S   += lx_kit/spec/$(SPEC_ARCH)/setjmp.S
 
-INC_DIR += $(DDE_LINUX_DIR)/src/include/spec/$(GEN_ARCH)/lx_kit
 INC_DIR += $(DDE_LINUX_DIR)/src/include/spec/$(SPEC_ARCH)
 INC_DIR += $(DDE_LINUX_DIR)/src/include/spec/x86
 INC_DIR += $(DDE_LINUX_DIR)/src/include
 INC_DIR += $(SPEC_SHADOW_INC_DIR)
-INC_DIR += $(GEN_SHADOW_INC_DIR)
 INC_DIR += $(SHADOW_INC_DIR)
 
 vpath % $(DDE_LINUX_DIR)/src/lib
@@ -102,6 +105,19 @@ INC_DIR += $(LX_GEN_DIR)/arch/$(LX_ARCH)/include/generated/uapi
 INC_DIR += $(LX_SRC_DIR)/include/uapi
 INC_DIR += $(LX_GEN_DIR)/include/generated/uapi
 
+ifeq ($(filter-out $(SPECS),arm_v7),)
+CC_DEF  += -D__LINUX_ARM_ARCH__=7
+endif
+
+ifeq ($(filter-out $(SPECS),arm_v6),)
+CC_DEF  += -D__LINUX_ARM_ARCH__=6
+endif
+
+ifeq ($(filter-out $(SPECS),arm),)
+# needed definitions of some arm assembler macros
+CC_DEF += -include asm/unified.h
+endif
+
 CC_DEF   += -include $(LX_SRC_DIR)/include/linux/kconfig.h
 CC_DEF   += -include $(LX_SRC_DIR)/include/linux/compiler_types.h
 CC_DEF   += -D__KERNEL__ -DCONFIG_CC_HAS_K_CONSTRAINT=1
@@ -135,7 +151,7 @@ CUSTOM_TARGET_DEPS += $(TARGET_SOURCE_LIST)
 
 # Define per-compilation-unit CC_OPT defines needed by MODULE* macros in Linux
 define CC_OPT_LX_RULES =
-CC_OPT_$(1) = -DKBUILD_MODFILE='"$(1)"' -DKBUILD_BASENAME='"$(notdir $(1))"' -DKBUILD_MODNAME='"$(notdir $(1))"'
+CC_OPT_$(1) += -DKBUILD_MODFILE='"$(1)"' -DKBUILD_BASENAME='"$(notdir $(1))"' -DKBUILD_MODNAME='"$(notdir $(1))"'
 endef
 
 $(foreach file,$(LX_SRC),$(eval $(call CC_OPT_LX_RULES,$(file:%.c=%))))
@@ -173,9 +189,6 @@ gen_crc32table: $(LX_SRC_DIR)/lib/gen_crc32table.c
 GLOBAL_DEPS += $(wildcard $(addsuffix /linux/*.h,$(SHADOW_INC_DIR))) \
                $(wildcard $(addsuffix /asm/*.h,$(SHADOW_INC_DIR)))
 
-GLOBAL_DEPS += $(wildcard $(addsuffix /linux/*.h,$(GEN_SHADOW_INC_DIR))) \
-               $(wildcard $(addsuffix /asm/*.h,$(GEN_SHADOW_INC_DIR)))
-
 GLOBAL_DEPS += $(wildcard $(addsuffix /linux/*.h,$(SPEC_SHADOW_INC_DIR))) \
                $(wildcard $(addsuffix /asm/*.h,$(SPEC_SHADOW_INC_DIR)))
 

repos/dde_linux/lib/mk/iwl_firmware.mk

@@ -1,21 +0,0 @@
-#
-# Pseudo library to copy Intel Wireless firmware to build directory
-#
-
-WIFI_CONTRIB_DIR := $(call select_from_ports,dde_linux)
-
-IMAGES  := $(notdir $(wildcard $(WIFI_CONTRIB_DIR)/firmware/*.ucode))
-IMAGES  += $(notdir $(wildcard $(WIFI_CONTRIB_DIR)/firmware/*.db))
-BIN_DIR := $(BUILD_BASE_DIR)/bin
-FW_DIR  := $(WIFI_CONTRIB_DIR)/firmware
-
-CUSTOM_TARGET_DEPS += $(addprefix $(BIN_DIR)/,$(IMAGES))
-
-$(BIN_DIR)/%.ucode: $(FW_DIR)/%.ucode
-	$(VERBOSE)cp $^ $@
-
-$(BIN_DIR)/%.db: $(FW_DIR)/%.db
-	$(VERBOSE)cp $^ $@
-
-
-CC_CXX_WARN_STRICT =

repos/dde_linux/lib/mk/legacy_wifi.inc

@@ -1,134 +0,0 @@
-LIB_DIR          := $(REP_DIR)/src/lib/legacy/wifi
-LIB_INC_DIR      := $(LIB_DIR)/include
-
-WIFI_CONTRIB_DIR := $(call select_from_ports,dde_linux)/src/lib/wifi
-DRIVERS_DIR      := $(WIFI_CONTRIB_DIR)/drivers
-WIFI_DIR         := $(WIFI_CONTRIB_DIR)/net
-
-SHARED_LIB = yes
-
-#
-# legacy_wifi_include *must* be the first library, otherwise the include
-# order is wrong
-#
-LIBS  += legacy_wifi_include lx_kit_setjmp nic_driver
-
-LD_OPT += --version-script=$(LIB_DIR)/symbol.map
-
-SRC_CC += dummies.cc init.cc lxcc_emul.cc nic.cc socket_call.cc random.cc \
-          firmware.cc
-
-# lx_kit
-SRC_CC += mapped_io_mem_range.cc irq.cc pci.cc malloc.cc scheduler.cc \
-          work.cc timer.cc printf.cc bug.cc env.cc
-
-SRC_C += lxc_emul.c dummies_new.c
-
-CC_WARN  =
-CC_OPT  += -fno-builtin-toupper
-
-CC_C_OPT   += -std=gnu89
-CC_C_OPT   += -include $(LIB_INC_DIR)/lx_emul.h
-CC_C_OPT   += -Wall -Wno-unused-variable -Wno-unused-function -Wno-uninitialized
-CC_C_OPT   += -Wno-unused-but-set-variable -Wno-pointer-sign -Wno-cast-qual
-CC_C_OPT   += -Wno-stringop-truncation
-CC_CXX_OPT += -Wall -fpermissive
-
-CC_OPT += -U__linux__ -D __KERNEL__ -DCONFIG_PCI
-#CC_OPT += -DCONFIG_INET
-CC_OPT += -DCONFIG_NET -DCONFIG_NET_NS -DCONFIG_WLAN #-D__MAC80211_DRIVER_TRACE
-
-# CONFIG options
-CC_OPT += -DCONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=1
-
-# needed for firmware loading
-CC_OPT += -DCONFIG_FW_LOADER
-
-# bling bling
-CC_OPT += -DCONFIG_LEDS_TRIGGERS -DCONFIG_MAC80211_LEDS
-
-# mesh
-CC_OPT += -DCONFIG_MAC80211_MESH
-
-# power management
-CC_OPT += -DCONFIG_PM -DCONFIG_PM_SLEEP
-
-# rfkill
-CC_OPT += -DCONFIG_RFKILL -DCONFIG_RFKILL_INPUT
-# choose default pid algorithm
-CC_OPT += -DCONFIG_MAC80211_RC_PID -DCONFIG_MAC80211_RC_DEFAULT=\"pid\"
-
-CC_OPT += -DCONFIG_CFG80211
-
-#
-# Suffix of global 'module_init' function
-#
-MOD_SUFFIX =
-CC_OPT += -DMOD_SUFFIX=$(MOD_SUFFIX)
-
-SRC_C += lib/bsearch.c
-SRC_C += lib/bucket_locks.c
-SRC_C += lib/crc32.c
-SRC_C += lib/ctype.c
-SRC_C += lib/gcd.c
-
-# crypto
-SRC_C += $(addprefix crypto/, $(notdir $(wildcard $(WIFI_CONTRIB_DIR)/crypto/*.c)))
-
-# net
-SRC_C += net/core/datagram.c
-SRC_C += net/core/rtnetlink.c
-SRC_C += net/core/skbuff.c
-SRC_C += net/core/sock.c
-SRC_C += net/ethernet/eth.c
-SRC_C += net/netlink/af_netlink.c
-SRC_C += net/netlink/genetlink.c
-SRC_C += net/packet/af_packet.c
-
-# netlink
-SRC_C += lib/nlattr.c
-SRC_C += lib/rbtree.c
-SRC_C += lib/rhashtable.c
-
-# wifi mac80211
-SRC_C += $(addprefix net/mac80211/, $(notdir $(wildcard $(WIFI_DIR)/mac80211/*.c)))
-CC_OPT += -DCONFIG_MAC80211_RC_MINSTREL -DCONFIG_MAC80211_RC_MINSTREL_HT
-CC_OPT += -DCONFIG_MAC80211_STA_HASH_MAX_SIZE=0
-
-# wifi rfkill
-SRC_C += $(addprefix net/rfkill/, $(notdir $(wildcard $(WIFI_DIR)/rfkill/*.c)))
-INC_DIR += $(WIFI_DIR)/rfkill
-
-# wifi cfg80211
-SRC_C   += $(addprefix net/wireless/, $(notdir $(wildcard $(WIFI_DIR)/wireless/*.c)))
-INC_DIR += $(WIFI_DIR)/wireless
-CC_OPT  += -DCONFIG_CFG80211_REG_RELAX_NO_IR=0
-
-# led driver
-SRC_C += $(addprefix drivers/leds/, $(notdir $(wildcard $(DRIVERS_DIR)/leds/*.c)))
-CC_OPT += -DCONFIG_LEDS_TRIGGERS
-
-CC_OPT += -D__CHECK_ENDIAN__
-
-# iwlwifi driver
-DRV_DIR_IWLWIFI := drivers/net/wireless/intel/iwlwifi
-SRC_C += $(addprefix $(DRV_DIR_IWLWIFI)/,      $(notdir $(wildcard $(WIFI_CONTRIB_DIR)/$(DRV_DIR_IWLWIFI)/*.c)))
-SRC_C += $(addprefix $(DRV_DIR_IWLWIFI)/cfg/,  $(notdir $(wildcard $(WIFI_CONTRIB_DIR)/$(DRV_DIR_IWLWIFI)/cfg/*.c)))
-SRC_C += $(addprefix $(DRV_DIR_IWLWIFI)/dvm/,  $(notdir $(wildcard $(WIFI_CONTRIB_DIR)/$(DRV_DIR_IWLWIFI)/dvm/*.c)))
-SRC_C += $(addprefix $(DRV_DIR_IWLWIFI)/fw/,   $(notdir $(wildcard $(WIFI_CONTRIB_DIR)/$(DRV_DIR_IWLWIFI)/fw/*.c)))
-SRC_C += $(addprefix $(DRV_DIR_IWLWIFI)/mvm/,  $(notdir $(wildcard $(WIFI_CONTRIB_DIR)/$(DRV_DIR_IWLWIFI)/mvm/*.c)))
-SRC_C += $(addprefix $(DRV_DIR_IWLWIFI)/pcie/, $(notdir $(wildcard $(WIFI_CONTRIB_DIR)/$(DRV_DIR_IWLWIFI)/pcie/*.c)))
-INC_DIR += $(WIFI_CONTRIB_DIR)/$(DRV_DIR_IWLWIFI)
-INC_DIR += $(WIFI_CONTRIB_DIR)/$(DRV_DIR_IWLWIFI)/fw
-CC_OPT += -DCONFIG_IWLMVM -DCONFIG_IWLDVM -DCONFIG_IWLWIFI_LEDS
-CC_OPT += -DCONFIG_IWLWIFI_DEBUG
-
-vpath %.c  $(DRIVERS_DIR)
-vpath %.c  $(WIFI_CONTRIB_DIR)/drivers/net/wireless/
-vpath %.c  $(WIFI_DIR)
-vpath %.c  $(WIFI_CONTRIB_DIR)
-vpath %.c  $(LIB_DIR)
-vpath %.cc $(LIB_DIR)
-vpath %.cc $(REP_DIR)/src/lib/legacy/lx_kit
-
-# vi: set ft=make :

repos/dde_linux/lib/mk/legacy_wifi_include.mk

@@ -1,39 +0,0 @@
-ifeq ($(called_from_lib_mk),yes)
-
-WIFI_CONTRIB_DIR := $(call select_from_ports,dde_linux)/src/lib/wifi
-LX_EMUL_H        := $(REP_DIR)/src/lib/legacy/wifi/include/lx_emul.h
-
-#
-# Determine the header files included by the contrib code. For each
-# of these header files we create a symlink to 'lx_emul.h'.
-#
-SCAN_DIRS := $(addprefix $(WIFI_CONTRIB_DIR)/include/, asm-generic crypto linux net trace uapi) \
-             $(addprefix $(WIFI_CONTRIB_DIR)/, crypto drivers lib net)
-GEN_INCLUDES := $(shell grep -rIh "^\#include .*\/" $(SCAN_DIRS) |\
-                        sed "s/^\#include [^<\"]*[<\"]\([^>\"]*\)[>\"].*/\1/" |\
-                        sort | uniq)
-#
-# Filter out original Linux headers that exist in the contrib directory
-#
-NO_GEN_INCLUDES := $(shell cd $(WIFI_CONTRIB_DIR)/; find include  -name "*.h" |\
-                           sed "s/.\///" | sed "s/.*include\///")
-GEN_INCLUDES    := $(filter-out $(NO_GEN_INCLUDES),$(GEN_INCLUDES))
-
-#
-# Put Linux headers in 'GEN_INC' dir, since some include use "../../" paths use
-# three level include hierarchy
-#
-GEN_INC         := $(shell pwd)/include/include/include
-GEN_INCLUDES    := $(addprefix $(GEN_INC)/,$(GEN_INCLUDES))
-
-all: $(GEN_INCLUDES)
-
-$(GEN_INCLUDES):
-	$(VERBOSE)mkdir -p $(dir $@)
-	$(VERBOSE)ln -s $(LX_EMUL_H) $@
-
-endif
-
-# vi: set ft=make :
-
-CC_CXX_WARN_STRICT =

repos/dde_linux/lib/mk/libnl.inc

@@ -3,7 +3,7 @@ LIB_INC_DIR = $(LIB_DIR)/include
 
 LIBS += libc libnl_include
 
-LIBNL_CONTRIB_DIR := $(call select_from_ports,dde_linux)/src/lib/libnl
+LIBNL_CONTRIB_DIR := $(call select_from_ports,libnl)/src/lib/libnl
 
 INC_DIR += $(LIB_INC_DIR)
 INC_DIR += $(LIBNL_CONTRIB_DIR)/include

repos/dde_linux/lib/mk/libnl_include.mk

@@ -1,6 +1,6 @@
 ifeq ($(called_from_lib_mk),yes)
 
-LIBNL_CONTRIB_DIR := $(call select_from_ports,dde_linux)/src/lib/libnl
+LIBNL_CONTRIB_DIR := $(call select_from_ports,libnl)/src/lib/libnl
 LIBNL_EMUL_H      := $(REP_DIR)/src/lib/libnl/include/libnl_emul.h
 
 #

repos/dde_linux/lib/mk/spec/arm_64/virt_linux_generated.mk

@@ -0,0 +1,3 @@
+LINUX_ARCH=arm64
+
+include $(REP_DIR)/lib/mk/virt_linux_generated.inc