# GBridge (Greybus Bridge)

Greybus is a protocol layer for UniPro bus.
It was supposed to be used by modular phones to control modules.

GBridge is an application that can be used to support other bus / network,
such as TCP/IP or bluetooth. 

## SVC
The SVC take a central piece in Greybus.
It is in charge of module hot plug / hot unplug detection,
create / destroy connections, etc.
In modular phones, the SVC is a micro-controller but here,
we don't have a micro-controller to detect modules,
so we have to simulate it.

SVC protocol has been made for UniPro.
Most of the SVC operations are useless or not adapted for non UniPro modules.
The current implementation of SVC protocol only implements the mandatory
operations though some of them are not correctly implemented
(such as DME operations).

## Netlink
GBridge is using netlink to communicate with Greybus.
Currently, netlink is only used to transmit Greybus operations,
but it's planned to use it to control Greybus when SVC protocol is not adapted.

## Controller
The controller is actually the link between the SVC, netlink and all the
modules.
The controller is actually handling some operations made by SVC in phones,
such as modules detection and connection.

### Bluetooth controller
The Bluetooth controller scans continuously to detect new bluetooth module.
When a Bluetooth module with the "GREYBUS" string in its name show up,
the controller will generate an hotplug event and create a connection.
Currently, the controller open a RFCOMM socket that is not available for BLE.
It's planned to use L2CAP instead of RFCOMM to support both Bluetooth and BLE.
Because RFCOMM doesn't have any notion of channel, the controller use the
padding bytes in operation header to store the cport number.

### TCP/IP
The controller use avahi to detect a new module.
The controller only add module with a `_greybus._tcp` service.
Avahi is currently the easiest way to detect a new device on the host but
may be it is not adapted for the small microcontrollers used for IOT.
The controller will open one socket per cport, so there no need to store
the cport number number in Greybus operation.
The connection is initiated by the controller, so the module must open
a socket for each cport to connect.

### GBSIM
GBSIM controller provides a way to test quickly and easily Greybus, Greybus netlink and gbridge.
This simulates a module. This currently implements only few protocols:
- control protocol
- manifest protocol
- loopback protocol

## Build

### Requirements
- A kernel >= 4.9 or the Greybus headers
- libnl, to build gbridge for the host
- libblueooth, to enable support of bluetooth for gbridge in host mode
- libavahi, required to support tcp/ip

### gbridge for the host
```
git clone https://github.com/anobli/gbridge.git
cd gbridge
autoconf
automake --add-missing
./configure --enable-netlink --enable-tcpip
make
```

### gbridge for a tcp/ip device
cd gbridge
autoconf
automake --add-missing
GBDIR=/path/to/greybus/headers ./configure --enable-gbsim --enable-tcpip
make

## Usage

### Kernel
First, you need to load Greybus module:
`modprobe gb_netlink # will also load greybus module`

After, you should load modules for protocols you want to use:
```
modprobe gb_phy
modprobe gb_loopback
...
```

### gbridge
`./gbridge`
That's it. Nothing else to do!
gbridge will detect new modules on bluetooth or TCP/IP and then
it will send hotplug event to Greybus.
Then, Greybus will try to connect to module, get manifest and create
the appropriate devices and entries in sysfs.