mirror of
https://github.com/genodelabs/genode.git
synced 2024-12-27 09:12:32 +00:00
2b1732bdec
All autopilot scripts use 12 or more MiB for the usb_drv and my personal tests never succeeded with less on x86 test machines.
318 lines
12 KiB
Plaintext
318 lines
12 KiB
Plaintext
Device drivers ported from the Linux kernel
|
|
|
|
USB
|
|
###
|
|
|
|
Controller configuration
|
|
~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The driver can be started using different or all USB controller types a platform
|
|
offers (USB 1.0/2.0/3.0). Note that not all controllers are supported by all
|
|
platforms. Controllers can be enabled as attribute in the config node of the
|
|
driver. Supported attributes are: 'uhci', 'ohci', 'ehci', and 'xhci'.
|
|
|
|
|
|
Configuration snippet to enable UHCI and EHCI
|
|
|
|
! <config uhci="yes" ehci="yes">
|
|
|
|
BIOS Handoff
|
|
~~~~~~~~~~~~
|
|
|
|
Per default the USB driver performs a hand off of the USB controller from the
|
|
BIOS, since it still may access the controller when booting, for example, from
|
|
a USB device. The BIOS hand off induces the execution of BIOS/SMM USB driver
|
|
code and potentially DMA operations. Unfortunately, some ACPI tables report
|
|
wrong RMRR information, which implicates IOMMU faults on illegal DMA
|
|
operations and consequently the hand off may fail after noticeably long
|
|
timeouts. Therefore, the hand off can be disabled in the USB driver
|
|
configuration like follows.
|
|
|
|
! <config bios_handoff="no"/>
|
|
|
|
HID
|
|
~~~
|
|
|
|
Supports keyboard and mouse. A run script can be found under 'run/usb_hid.run'.
|
|
|
|
Configuration snippet:
|
|
|
|
!<start name="usb_drv">
|
|
! <resource name="RAM" quantum="12M"/>
|
|
! <provides><service name="Input"/></provides>
|
|
! <config uhci="yes" ohci="yes" ehci="yes" xhci="yes">
|
|
! <hid/>
|
|
! </config>
|
|
!</start>
|
|
|
|
Note: It has been observed that certain 1.0 versions of Qemu do not generate
|
|
mouse interrupts. The mouse driver should work correctly on Qemu 1.0.93 and
|
|
above.
|
|
|
|
HID - Touchscreen support
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Touchscreen absolute coordinates must be calibrated (e.g. re-calculated) to
|
|
screen absolute coordinates. The screen resolution is not determined
|
|
automatically by the USB driver, but can be configured as sub node of the
|
|
hid xml tag:
|
|
|
|
!...
|
|
!<hid>
|
|
! <touchscreen width="1024" height="768" multitouch="no"/>
|
|
!</hid>
|
|
!...
|
|
|
|
If a touchscreen is multi-touch-capable than the multitouch attribute gears
|
|
which type of Genode input events are generated. If set to 'no' (default)
|
|
than absolute events are generated and no multitouch events. If set to 'yes'
|
|
solely multitouch events are generated.
|
|
|
|
Storage
|
|
~~~~~~~
|
|
|
|
Currently supports one USB storage device. Hot plugging has not been tested. A
|
|
run script can be found under 'run/usb_storage.run'.
|
|
|
|
Configuration snippet:
|
|
|
|
!<start name="usb_drv">
|
|
! <resource name="RAM" quantum="12M"/>
|
|
! <provides> <service name="Block"/> </provides>
|
|
! <config><storage /></config>
|
|
!</start>
|
|
|
|
|
|
Network (Nic)
|
|
~~~~~~~~~~~~~
|
|
|
|
Configuration snippet:
|
|
|
|
!<start name="usb_drv">
|
|
! <resource name="RAM" quantum="12M"/>
|
|
! <provides>
|
|
! <service name="Nic"/>
|
|
! <service name="Input"/>
|
|
! </provides>
|
|
! <config ehci="yes" xhci="yes">
|
|
! <nic mac="2e:60:90:0c:4e:01" />
|
|
! <hid/>
|
|
! </config>
|
|
!</start>
|
|
|
|
Please observe that this setup starts the HID and Nic service at the same time.
|
|
Also there is the 'mac' attribute where one can specify the hardware address of
|
|
the network interface. This is necessary in case the EEPROM of the network card
|
|
cannot be accessed via the host controller making it impossible to retrieve the
|
|
devices hardware address. If this is the case and no 'mac' attribute is given a
|
|
fallback address will be assigned to the network device. Note that the fallback
|
|
address will always be the same.
|
|
|
|
|
|
RAW
|
|
~~~
|
|
|
|
Allows raw access to USB devices via the 'Usb' session interface.
|
|
|
|
Configuration snippet:
|
|
|
|
!<start name="usb_drv">
|
|
! <resource name="RAM" quantum="12M"/>
|
|
! <provides><service name="Usb"/></provides>
|
|
! <config uhci="yes" ohci="yes" ehci="yes" xhci="yes">
|
|
! <raw>
|
|
! <report devices="yes"/>
|
|
! </raw>
|
|
! </config>
|
|
!</start>
|
|
|
|
The optional 'devices' report lists the connected devices and gets updated
|
|
when devices are added or removed.
|
|
|
|
Example report:
|
|
|
|
!<devices>
|
|
! <device label="usb-1-7" vendor_id="0x1f75" product_id="0x0917" bus="0x0001" dev="0x0007"/>
|
|
! <device label="usb-1-6" vendor_id="0x13fe" product_id="0x5200" bus="0x0001" dev="0x0006"/>
|
|
! <device label="usb-1-4" vendor_id="0x17ef" product_id="0x4816" bus="0x0001" dev="0x0004"/>
|
|
! <device label="usb-1-3" vendor_id="0x0a5c" product_id="0x217f" bus="0x0001" dev="0x0003"/>
|
|
! <device label="usb-2-2" vendor_id="0x8087" product_id="0x0020" bus="0x0002" dev="0x0002"/>
|
|
! <device label="usb-1-2" vendor_id="0x8087" product_id="0x0020" bus="0x0001" dev="0x0002"/>
|
|
! <device label="usb-2-1" vendor_id="0x1d6b" product_id="0x0002" bus="0x0002" dev="0x0001"/>
|
|
! <device label="usb-1-1" vendor_id="0x1d6b" product_id="0x0002" bus="0x0001" dev="0x0001"/>
|
|
!</devices>
|
|
|
|
For every device a unique identifier is generated that is used to access the
|
|
USB device. Only devices that have a valid policy configured at the USB driver
|
|
can be accessed by a client. The following configuration allows 'comp1' to
|
|
access the device 'usb-1-6':
|
|
|
|
!<start name="usb_drv">
|
|
! <resource name="RAM" quantum="12M"/>
|
|
! <provides><service name="Usb"/></provides>
|
|
! <config uhci="yes" ohci="yes" ehci="yes" xhci="yes">
|
|
! <raw>
|
|
! <report devices="yes"/>
|
|
! <policy label="comp1 -> usb-1-6" vendor_id="0x13fe" product_id="0x5200" bus="0x0001" dev="0x0006"/>
|
|
! </raw>
|
|
! </config>
|
|
!</start>
|
|
|
|
In addition to the mandatory 'label' attribute the policy node also
|
|
contains optional attribute tuples of which at least one has to be present.
|
|
The 'vendor_id' and 'product_id' tuple selects a device regardless of its
|
|
location on the USB bus and is mostly used in static configurations. The
|
|
'bus' and 'dev' tuple selects a specific device via its bus locations and
|
|
device address. It is mostly used in dynamic configurations because the device
|
|
address is not fixed and may change every time the same device is plugged in.
|
|
|
|
The configuration of the USB driver can be changed at runtime to satisfy
|
|
dynamic configurations or rather policies when using the 'Usb' session
|
|
interface.
|
|
|
|
|
|
LXIP
|
|
####
|
|
|
|
LXIP is a port of the Linux TCP/IP stack to Genode. It is build as a shared
|
|
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'.
|
|
|
|
|
|
lx_kit
|
|
######
|
|
|
|
The modular lx_kit seperates the required back end functionality of the Linux
|
|
emulation environment from the front end. Thereby each driver can reuse
|
|
specific parts or supply more suitable implementations by itself. It is used to
|
|
reduce the amount of redundant code in each driver.
|
|
|
|
The lx_kit is split into several layers whose structure is as follows:
|
|
|
|
The first layer in _repos/dde_linux/src/include/lx_emul_ contains those header
|
|
files that provide the structural definitions and function declarations of the
|
|
Linux API, e.g. _errno.h_ provides all error code values. The second layer in
|
|
_repos/dde_linux/src/include/lx_emul/impl_ contains the implementation of
|
|
selected functions, e.g. _slab.h_ provides the implementation of 'kmalloc()'.
|
|
The lx_kit back end API is the third layer and provides the _Lx::Malloc_
|
|
interface (_repos/dde_linux/src/include/lx_kit/malloc.h_) which is used to
|
|
implement 'kmalloc()'. There are several generic implementations of the lx_kit
|
|
interfaces that can be used by a driver.
|
|
|
|
A driver typically includes a 'lx_emul/impl/xyz.h' header once directly in its
|
|
lx_emul compilation unit. The lx_kit interface files are only included in those
|
|
compilation units that use or implement the interface. If a driver wants to use
|
|
a generic implementation it must add the source file to its source file list.
|
|
The generic implementations are located in _repos/dde_linux/src/lx_kit/_.
|
|
|
|
The modular lx_kit still depends on the private _lx_emul.h_ header file that is
|
|
tailored to each driver. Since the lx_kit already contains much of the
|
|
declarations and definitions that were originally placed in these private
|
|
header files, those files can now ommit a large amount of code.
|