genode

History

Martin Stein c70fed29f7 os/timer: interpolate time via timestamps Previously, the Genode::Timer::curr_time always used the Timer_session::elapsed_ms RPC as back end. Now, Genode::Timer reads this remote time only in a periodic fashion independently from the calls to Genode::Timer::curr_time. If now one calls Genode::Timer::curr_time, the function takes the last read remote time value and adapts it using the timestamp difference since the remote-time read. The conversion factor from timestamps to time is estimated on every remote-time read using the last read remote-time value and the timestamp difference since the last remote time read. This commit also re-works the timeout test. The test now has two stages. In the first stage, it tests fast polling of the Genode::Timer::curr_time. This stage checks the error between locally interpolated and timer-driver time as well as wether the locally interpolated time is monotone and sufficiently homogeneous. In the second stage several periodic and one-shot timeouts are scheduled at once. This stage checks if the timeouts trigger sufficiently precise. This commit adds the new Kernel::time syscall to base-hw. The syscall is solely used by the Genode::Timer on base-hw as substitute for the timestamp. This is because on ARM, the timestamp function uses the ARM performance counter that stops counting when the WFI (wait for interrupt) instruction is active. This instruction, however is used by the base-hw idle contexts that get active when no user thread needs to be scheduled. Thus, the ARM performance counter is not a good choice for time interpolation and we use the kernel internal time instead. With this commit, the timeout library becomes a basic library. That means that it is linked against the LDSO which then provides it to the program it serves. Furthermore, you can't use the timeout library anymore without the LDSO because through the kernel-dependent LDSO make-files we can achieve a kernel-dependent timeout implementation. This commit introduces a structured Duration type that shall successively replace the use of Microseconds, Milliseconds, and integer types for duration values. Open issues: * The timeout test fails on Raspberry PI because of precision errors in the first stage. However, this does not render the framework unusable in general on the RPI but merely is an issue when speaking of microseconds precision. * If we run on ARM with another Kernel than HW the timestamp speed may continuously vary from almost 0 up to CPU speed. The Timer, however, only uses interpolation if the timestamp speed remained stable (12.5% tolerance) for at least 3 observation periods. Currently, one period is 100ms, so its 300ms. As long as this is not the case, Timer_session::elapsed_ms is called instead. Anyway, it might happen that the CPU load was stable for some time so interpolation becomes active and now the timestamp speed drops. In the worst case, we would now have 100ms of slowed down time. The bad thing about it would be, that this also affects the timeout of the period. Thus, it might "freeze" the local time for more than 100ms. On the other hand, if the timestamp speed suddenly raises after some stable time, interpolated time can get too fast. This would shorten the period but nonetheless may result in drifting away into the far future. Now we would have the problem that we can't deliver the real time anymore until it has caught up because the output of Timer::curr_time shall be monotone. So, effectively local time might "freeze" again for more than 100ms. It would be a solution to not use the Trace::timestamp on ARM w/o HW but a function whose return value causes the Timer to never use interpolation because of its stability policy. Fixes #2400		2017-05-31 13:16:11 +02:00
..
include	Adjust file headers to refer to the AGPLv3	2017-02-28 12:59:29 +01:00
lib	usb: add OHCI support	2017-05-31 13:16:00 +02:00
patches	lxip: support large sendmsg (like recvmsg)	2017-05-31 13:15:58 +02:00
ports	dde_linux: download libnl from github.com/thom311	2017-05-31 13:16:02 +02:00
recipes/src/usb_drv	Depot-archive recipes	2017-05-31 13:15:56 +02:00
run	Assign cap quotas in run scripts and recipes	2017-05-31 13:16:06 +02:00
src	os/timer: interpolate time via timestamps	2017-05-31 13:16:11 +02:00
intel_fb.list	dde_linux: kernel-version independent file lists	2017-05-31 13:16:02 +02:00
lxip.list	dde_linux: kernel-version independent file lists	2017-05-31 13:16:02 +02:00
README	usb: add OHCI support	2017-05-31 13:16:00 +02:00
usb.list	dde_linux: kernel-version independent file lists	2017-05-31 13:16:02 +02:00
wifi.list	dde_linux: kernel-version independent file lists	2017-05-31 13:16:02 +02:00

README

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.