mirror of
https://github.com/genodelabs/genode.git
synced 2024-12-19 13:47:56 +00:00
310 lines
11 KiB
Plaintext
310 lines
11 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="3M"/>
|
|
! <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="2M"/>
|
|
! <provides> <service name="Block"/> </provides>
|
|
! <config><storage /></config>
|
|
!</start>
|
|
|
|
|
|
Network (Nic)
|
|
~~~~~~~~~~~~~
|
|
|
|
Configuration snippet:
|
|
|
|
!<start name="usb_drv">
|
|
! <resource name="RAM" quantum="3M"/>
|
|
! <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="8M"/>
|
|
! <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="8M"/>
|
|
! <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.
|
|
|
|
Configuration snippet:
|
|
|
|
!<start name="wifi_drv">
|
|
! <resource name="RAM" quantum="32M"/>
|
|
! <provides><service name="Nic"/></provides>
|
|
! <config>
|
|
! <libc stdout="/dev/log" stderr="/dev/log" rtc="/dev/rtc">
|
|
! <vfs>
|
|
! <dir name="dev"> <log/> <rtc/>
|
|
! <jitterentropy name="random"/>
|
|
! <jitterentropy name="urandom"/>
|
|
! </dir>
|
|
! <dir name="config"> <ram/> </dir>
|
|
! </vfs>
|
|
! </libc>
|
|
! </config>
|
|
! <route>
|
|
! <service name="Rtc"> <any-child /> </service>
|
|
! <any-service> <parent/> <any-child /> </any-service>
|
|
! </route>
|
|
!</start
|
|
|
|
Per default, the driver scans for available networks only when not
|
|
connected. This can be changed with the 'connected_scan_interval'
|
|
config attribute, which specifies the interval for connected scans in
|
|
seconds, e.g.
|
|
|
|
!<config connected_scan_interval="30">...</config>
|
|
|
|
Also, the driver can be switched to verbose logging with
|
|
|
|
!<config verbose="yes">...</config>
|
|
|
|
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 structure:
|
|
|
|
!<wlan_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="WPA-PSK"/>
|
|
! <accesspoint ssid="foobar" bssid="01:02:03:04:05:07" quality="10" protection="WPA-PSK"/>
|
|
!</wlan_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:
|
|
|
|
!<wlan_state>
|
|
! <accesspoint ssid="foobar" bssid="01:02:03:04:05:06" quality="70" protection="WPA-PSK" state="connected"/>
|
|
!</wlan_state>
|
|
|
|
Valid state values are 'connected', 'disconnected', 'connecting' and
|
|
'disconnecting'.
|
|
|
|
In return, the wifi_drv get its configuration via a ROM module. This ROM
|
|
module contains the configuration for the selected accesspoint.
|
|
To connect to an open accesspoint a configuration like the following is used:
|
|
|
|
!<selected_accesspoint ssid="foobar"/>
|
|
|
|
If the network is protected by, e.g., WPA/WPA2, the protection type as well
|
|
as the the pre-shared key have to be specified:
|
|
|
|
!<selected_accesspoint ssid="securefoobar" protection="WPA-PSK" psk="foobar123!"/>
|
|
|
|
If a network consists of several different access points and a particular one
|
|
should be used it can be selected by specifing its BSSID in a 'bssid'
|
|
attribute.
|
|
|
|
Of all attributes only the 'ssid' attribute is mandatory, all others are
|
|
optional and should only be used when needed.
|
|
|
|
To disconnect from an accesspoint, a empty configuration is sent:
|
|
|
|
!<selected_accesspoint/>
|
|
|
|
By subscribing to both reports and providing the required ROM module, a
|
|
component can control the wireless driver. An example therefore is the Qt
|
|
based component in 'src/app/qt_wifi_connect'.
|
|
|
|
Currently only WPA/WPA2 protection using a pre-shared key is supported.
|
|
|
|
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 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.
|