Porting Guide/Connectivity

From Tizen Wiki
Jump to: navigation, search

Bluetooth

Bluetooth is the short range communication used to communicate between 2 devices. In Tizen, open source Bluetooth components like BlueZ and ObexD are used. Bluez and Obexd run as the daemon and there is an interface library Bluetooth Framework, used for applications to access BlueZ or ObexD over the D-Bus interface.

This section explains the Bluetooth architecture on the Tizen platform and how Tizen can be ported, along with the configuration parameters and its values.

Bluetooth Low Energy function was implemented in BlueZ and bluetooth-frwk.

The following figure explains the Bluetooth architecture on Tizen.


Bluetooth.png

The Bluetooth framework provides dialogue for the user. It controls the BlueZ, ObexD, and PulseAudio daemons. Bluetooth provides a standard interface between the Bluetooth chip and AP, called the HCI (Host Controller Interface). HCI can be implemented on USB, UART, SDIO, but for the mobile environment, UART is used most. Depending on the chip vendor, HCI Interface Activation can be different. The vendor provides the HCI configuration and the initial scripts. For example, Broadcom and Spreadtrum provide firmware and a loading tool. Tizen supports Bluetooth version 4.2. The supported profiles are GATT, FTP, OPP, MAP, PBAP, A2DP, AVRCP, HSP/HFP, RFCOMM, HID, HDP, and PAN. Bluetooth framework Tizen Bluetooth is based on the open source BlueZ project. BlueZ provides the DBUS API and based on it, Tizen BT framework provides the C Language API. It is recommended to use the Tizen Bluetooth framework.

The following components are necessary for Bluetooth:

  • Application
    • The user dialogue that controls the BlueZ, ObexD, and PulseAudio daemons
  • ObexD
    • The open source component
    • Object exchange daemon
    • Supports OPP, FTP, PBAP, SYNC, and MAP profile stack
  • BluetoothD
    • BluetoothD is the open souce component, Bluez 5.37 is supported
    • Bluetooth central daemon
    • Supports GAP, SDP, A2DP, AVRCP, HFP, HSP, and GATT profile stack
  • Bluetooth Subsystem
    • Provides the BT unix socket. Each protocol can be accessed by its socket.
    • Supports the L2CAP, RFCOMM, SCO, and HCI protocols
  • Bluetooth Driver
    • BT Chip Driver
    • In case of UART, Linux kernel provides the interface.
    • GPIO configuration, rfkill (Radio Frequency Management) and power management can be handled by both the vendor and the porting engineer.
  • BT Firmware Loading Module
    • Depending on the environment, it loads the Bluetooth firmware to the Bluetooth chip.
    • Tizen and the chipset vendor need to implement this together.
    • Package: bluetooth-tools

Porting OAL Interface

The following OAL scripts are run during the Bluetooth stack start and end sequences. These scripts invoke the Bluetooth chip specific (such as Broadcom and Spreadtrum) scripts, provided by the chipset vendor to perform chip specific configuration. These scripts are available in the bluetooth-dev-tools.under package. When this package is installed, it copies the scripts in the /usr/etc/Bluetooth/ directory.

  • bt-stack-up.sh
This script file is used to run the hardware specific script files to power up or start the Bluetooth hardware along the background processes, such as bluez and obexd.
  • bt-stack-down.sh
This script file is used to run the hardware specific script files to power down or stop the Bluetooth hardware along with the background processes, such as bluez and obexd.
  • bt-reset-env.sh
This script file is used to reset the Bluetooth chip by running the bt-stack-down.sh script along with the resource clean up.
Tizen BT Obex profiles

In Tizen, for the obex based profiles, the open source ObexD is used.

  • BT Obex profiles server (obexd)
obexd –d –noplugin=syncevolution,pcsiut,irmc –symlinks –r /ftp_ folder
  • BT Obex profiles client (obex-client)
obex-client

Configuration

There are a few configuration changes that need to be made to enable the specific chipset and the scripts and other configuration information, such as UART speed and UART terminal (tty), to be opened specific to the chipset. These changes must be provided by the chipset vendors.

Configuration for the BCM4358 Bluetooth chipset by Broadcomm
  • hciattach
The bluez/tools/hciattach.c project is patched to enable the BCM4358 chipset specific hciattach tool. This service attaches the BT UART HCI interface to the Bluetooth stack at baud rate of 3000000. It is also responsible for loading the Bluetooth firmware on BCM4358.
  • The Bluetooth UART used is /dev/ttySAC3
  • The Broadcom firmware used is BCM4358A1_001.002.005.0032.0066.hcd
  • The UART speed configuration is 3000000 for BCM4358A1
  • The bcmtool used is bcmtool_4358a1
  • The .bd_addr contains the unique Bluetooth address, which is generated during the first Bluetooth activation
  • Register the Bluetooth device:
bcmtool_4358a1 /dev/ttySAC0 –FILE=BCM4358A1_001.002.005.0032.0066.hcd –BAUD=3000000 –ADDR=/csa/bluetooth/.bd_addr –SETSCO=0,0,0,0,0,0,0,3,3,0 –LP
  • Attach a serial device using UART HCI to the Bluetooth stack for a broadcom device:
hciattach /dev/ttySAC3 –S 3000000 bcm2035 3000000 flow
  • Run the Bluetooth daemon version 5.37:
bluetoothd
  • Bring the device up, set up the device name, and enable the SSP mode:
hciconfig hci0 up
hciconfig hci0 name “Tizen-Mobile”
hciconfig hci0 sspmode 1
  • Switch on the Bluetooth radio:
rfkill unblock bluetooth
  • Switch off the Bluetooth radio:
rfkill block bluetooth
Configuration for the sc2331 Bluetooth chipset by Spreadtrum
  • hciattach
The bluez/tools/hciattach.c is patched to enable the sc2331 chipset specific hciattach tool. This service attaches the BT UART HCI interface to the Bluetooth stack at baud rate of 3000000. It is also responsible for loading the BT firmware on sc2331.
  • Registering the Bluetooth device:
The cp2-download tool is provided for downloading the firmware provided with Spreadtrum. This tool also downloads the Wi-Fi firmware at the booting time.
  • Install the following files in the target's /usr/lib/firmware directory:
sc2331_fdl.bin
sc2331_fw.bin
scx35_pikeavivaltove_3M_MARLIN_connectivity_calibration.ini
scx35_pikeavivaltove_3M_MARLIN_connectivity_configure.ini
  • The Bluetooth UART used is /dev/ttyS0.
  • The UART speed configuration is 3000000 for sc2331.
  • Attach a serial device using UART HCI to the Bluetooth stack:
hciattach -s 3000000 /dev/ttyS0 sprd 3000000 flow
  • Run the bluetooth daemon version 5.37:
bluetoothd
  • Bring the device up, set up the device name, and enable the SSP mode:
hciconfig hci0 up
hciconfig hci0 name “Tizen-Mobile”
hciconfig hci0 sspmode 1

References

Open source component version: BlueZ 5.37

For more information, see http://www.bluez.org/.

Reference kernel configuration for Bluetooth

The following kernel .config are enabled for Broadcom Bluetooth support:

CONFIG_BT=y
CONFIG_BT_L2CAP=y
CONFIG_BT_RFCOMM=y
CONFIG_BT_RFCOMM_TTY=y
CONFIG_BT_BNEP=y
CONFIG_BT_HIDP=y
CONFIG_BT_HCIUART=y
CONFIG_BT_HCIUART_H4=y
CONFIG_BCM4330=y
CONFIG_RFKILL=y
CONFIG_RFKILL_INPUT=y
CONFIG_RXTRA_FIRMWARE_BCM4330=”BCM4330.hcd”

The following kernel .config are enabled for Bluetooth AVRCP support:

CONFIG_INPUT_MISC=y
CONFIG_INPUT_UINPUT=y

The following kernel .config are enabled for Bluetooth HID support:

CONFIG_INPUT_GP2A=y
CONFIG_INPUT_KR3DH=y

The following kernel .config are enabled for Bluetooth Audio (SCO-over-PCM) support:

CONFIG_BT_SCO=y
CONFIG_INPUT_GP2A=y
CONFIG_INPUT_KR3DH=y

The following kernel .config are enabled for Bluetooth Audio (SCO-over-PCM) support:

CONFIG_BT_SCO=y

WLAN

This section provides a step-by-step explanation of what's involved in adding a new Wi-Fi driver and making Wi-Fi work. Wlan.png

Feature Overview:

  • WLAN (802.11 b/g/n)
  • WPS PBC
  • EAP (PEAP, TTLS)

Tizen uses wpa_supplicant as the platform interface to the Wi-Fi device. Your Wi-Fi driver must be compatible with the standard wpa_supplicant.

The Tizen WLAN architecture is centered on the Linux wireless (IEEE-802.11) subsystem. The Linux wireless SW stack defines the WLAN hardware adaptation software interfaces that need to be used in Tizen. In practice, the required interfaces are defined by cfg80211 for FullMAC WLAN devices and by mac80211 for SoftMAC WLAN devices. In addition, a Linux network interface needs to be supported towards the Linux TCP/IP stack.

The Connection Manager (ConnMan) is a daemon for managing internet connections within embedded devices running the Linux operating system.

The wpa_supplicant is a WPA Supplicant with support for WPA and WPA2 (IEEE 802.11i / RSN). Supplicant is the IEEE 802.1X/WPA component that is used in the client stations. It implements key negotiation with a WPA Authenticator and it controls the roaming and IEEE 802.11 authentication/association of the WLAN driver.

Porting OAL Interface

The WLAN driver plugin is specific to a Wi-Fi chipset. This includes firmware and tools specific to Wi-Fi chipsets. Wi-Fi chipset firmware and tools files must be copied to the WLAN driver plugin directory, built, and installed before testing the Wi-Fi functionality. Because of Tizen platform requirement, the Wi-Fi driver must create the /opt/etc/.mac.info file, which has the MAC address of device.

The WLAN driver plugin contains the wlan.sh file (located in /usr/bin/wlan.sh), which is used to load or unload the Wi-Fi driver firmware.

When the wifi_activate() function is called, the load driver request is sent to the NET-CONFIG daemon. The NET-CONFIG daemon loads the Wi-Fi driver using the wlan.sh script file. Similarly, the wifi_deactivate() function requests unloading of the Wi-Fi driver. In case of Wi-Fi Direct, the wifi_direct_activate() and wifi_direct_deactivate() functions make the Wi-Fi Direct manager load or unload the Wi-Fi driver using the wlan.sh script.

Using the /usr/bin/wlan.sh script:

  • wlan.sh start: Power up the Wi-Fi driver in station mode by loading the driver and running the firmware file.
  • wlan.sh p2p: Power up the Wi-Fi driver in Wi-Fi Direct mode by loading the driver and running the firmware file.
  • wlan.sh softap: Power up the Wi-Fi driver in Soft AP mode by loading the driver and running the firmware file.
  • wlan.sh stop: Power down the Wi-Fi driver.

All other Wi-Fi related functionality is handled by the ConnMan daemon

References

Reference kernel configurations
  • These options need to be enabled if the driver supports the cfg802.11 configuration API, instead of the wireless extension API. For more information, see http://linuxwireless.org.
CONFIG_CFG80211
CONFIG_LIB80211
CONFIG_MAC80211 (Enable this flag, if the driver supports the softMAC feature)
  • The following configuration options must be enabled in the kernel if the driver supports wireless extension APIs.
CONFIG_WIRELESS_EXT=y
CONFIG_WEXT_CORE=y
CONFIG_WEXT_PROC=y
CONFIG_WEXT_PRIV=y
CONFIG_WEXT_SPY=y
CONFIG_WIRELESS_EXT_SYSFS=y

NFC

The NFC application enables the user to read and/or import the content written on an NFC tag, edit the content written on an NFC tag, write and save data in an NFC tag, and load and save the NFC data from or in a file.

Nfc.png

The NFC client acts as an interface between the NFC app and the NFC manager, while writing or editing tag information in any physical tag. The NFC manager is the main interface, which actually deals with NFC physical tags, creates a connection with tags, and detects it. It is a daemon process to control the NFC chipset (such as NXP pn544). It provides the read and write service and basic P2P communication service, as well as the basic API for the client application. The NFC stack contains the required plugin, based on the NFC chipset. Currently, the nfc-plugin-nxp is used for the NXP chipset. The NFC plugin acts as an interface between the NFC chipset with the NFC framework (nfc-manager). It must be implemented according to the interface provided by the nfc-manager.

Porting OAL Interface

The NFC plugin is implemented as a shared library and it interfaces the Tizen nfc-manager and the vendor NFC chip. The NFC manager loads the libnfc-plugin.so library at runtime from the /usr/lib/libnfc-plugin.so directory. Any vendor-specific plugin is installed within the same path. The plugin must be written with predefined OAL API interfaces.

During initialization, the nfc-manager loads the nfc-plugin.so library, searches for the onload() function, and calls the function with an interface structure instance as an argument for mapping of all the OAL interfaces. These OAL/OEM interfaces are implemented according to the underlying NFC chipset. Once the mapping is done, the NFC manager interact with nfc-plugin, which implements the vendor specific OAL interfaces.

The following example shows the onload() function for reference:

Bool
onload(net_nfc_oem_interface_s *oem_interfaces)
{
    oem_interfaces->init = xxx;  /* xxx refers to plugin APIs */
    oem_interfaces->deinit = xxx;
    oem_interfaces->register_listener = xxx;
    oem_interfaces->unregister_listener = xxx;
    oem_interfaces->check_firmware_version = xxx;

    return true;
}

The NFC OAL interfaces are defined in the following structure. Use the net_nfc_oem_controller.h header file.

typedef struct _net_nfc_oem_interface_s
{
    net_nfc_oem_controller_init init;
    net_nfc_oem_controller_deinit deinit;
    net_nfc_oem_controller_register_listener register_listener;
    net_nfc_oem_controller_unregister_listener unregister_listener;
    net_nfc_oem_controller_check_firmware_version check_firmware_version;
    net_nfc_oem_controller_update_firmware update_firmeware;
    net_nfc_oem_controller_get_stack_information get_stack_information;
    net_nfc_oem_controller_configure_discovery configure_discovery;
    net_nfc_oem_controller_get_secure_element_list get_secure_element_list;
    net_nfc_oem_controller_set_secure_element_mode set_secure_element_mode;
    net_nfc_oem_controller_connect connect;
    net_nfc_oem_controller_connect disconnect;
    net_nfc_oem_controller_check_ndef check_ndef;
    net_nfc_oem_controller_check_target_presence check_presence;
    net_nfc_oem_controller_read_ndef read_ndef;
    net_nfc_oem_controller_write_ndef write_ndef;
    net_nfc_oem_controller_make_read_only_ndef make_read_only_ndef;
    net_nfc_oem_controller_transceive transceive;
    net_nfc_oem_controller_format_ndef format_ndef;
    net_nfc_oem_controller_exception_handler exception_handler;
    net_nfc_oem_controller_is_ready is_ready;
    net_nfc_oem_controller_llcp_config config_llcp;
    net_nfc_oem_controller_llcp_check_llcp check_llcp_status;
    net_nfc_oem_controller_llcp_activate_llcp activate_llcp;
    net_nfc_oem_controller_llcp_create_socket create_llcp_socket;
    net_nfc_oem_controller_llcp_bind bind_llcp_socket;
    net_nfc_oem_controller_llcp_listen listen_llcp_socket;
    net_nfc_oem_controller_llcp_accept accept_llcp_socket;
    net_nfc_oem_controller_llcp_connect_by_url connect_llcp_by_url;
    net_nfc_oem_controller_llcp_connect connect_llcp;
    net_nfc_oem_controller_llcp_disconnect disconnect_llcp;
    net_nfc_oem_controller_llcp_socket_close close_llcp_socket;
    net_nfc_oem_controller_llcp_recv recv_llcp;
    net_nfc_oem_controller_llcp_send send_llcp;
    net_nfc_oem_controller_llcp_recv_from recv_from_llcp;
    net_nfc_oem_controller_llcp_send_to send_to_llcp;
    net_nfc_oem_controller_llcp_reject reject_llcp;
    net_nfc_oem_controller_llcp_get_remote_config get_remote_config;
    net_nfc_oem_controller_llcp_get_remote_socket_info get_remote_socket_info;
    net_nfc_oem_controller_sim_test sim_test;
    net_nfc_oem_controller_test_mode_on test_mode_on;
    net_nfc_oem_controller_test_mode_off test_mode_off;
net_nfc_oem_controller_support_nfc support_nfc;
} net_nfc_oem_interface_s;

The nfc_oem_interface_s is exported in the nfc-plugin. Using this interface structure, the nfc-manager communicates with the OAL interfaces at runtime. The NFC plugin loads when the nfc-manager is started and the plugin init() function is called to initialize the NFC chip.

int (*init) (net_nfc_oem_controller_init*);

The deinit() function the nfc-manager issues to deinitialize the NFC chip:

int (*deinit) (net_nfc_oem_controller_deinit *);
Sending the notification to the upper layer (NFC Service)

Refer to the phdal4nfc_message_glib.c file. The g_idle_add_full is used for handling the message in the NFC Service. You can use the callback client asynchronously in the client context. Post a message in queue, and the message is processed by a client thread.

Reference implementation of the NFC plugin

Sample code snippets cannot be reproduced. Code is proriatory. For reference, see the nfc-plugin-emul and nfc-plugin-nxp files.

Configuration

The nfc-plugin package must be saved to the /usr/lib/libnfc-plugin.so directory when installed. When the nfc-manager starts, it looks for the plugin library and loads it dynamically from this path.

References

Enable the following configuration options in the kernel .config.

Using Pn544: CONFIG_PN544_NFC
Using Pn65n: CONFIG_PN65N_NFC

API references available are under the Tizen_3.0_Porting_Guide#Appendix_2.

For more information, see http://nfc-forum.org/.

MTP

  • MTP exchanges can only occur between 2 products at a time, and in each communication, 1 product acts as the initiator and the other as the responder.
  • The initiator is the product that initiates actions with the responder by sending operations to the responder.

Mtp-initiator.png

  • The responder can not initiate any actions, and can only send responses to operations sent by the initiator or send events.

Mtp-responder.png

  • In the Tizen system, the USB host is the initiator, and the USB device is the responder.


Porting OAL Interface

  • Tizen MTP initiator and responder do not have an OAL Interface.
  • There are extension possibilities of the MTP Transport layer.


Configuration

MTP Initiator
  • The MTP Initiator consist of 3 packages.
mtp-initiator daemon
mtp-initiator api
libmtp opensource
  • The MTP initiator does not operate independently. It requires the help of another module, such as USB.
  • When the USB device is connected to the host, the module must run the MTP initiator daemon.
MTP Responder
  • The MTP responder consist of 1 package.
mtp-responder daemon
  • The MTP responder does not operate independently. It requires the help of another module, such as USB.
  • When the USB device is connected to the host, the module must run the MTP responder daemon.

References