Skip to main content
search
BlogNewsTop News

Using Linux, Zephyr & Greybus for IoT

By October 15, 2020May 6th, 2021No Comments

Written by Christopher Friedt, P.Eng. M.Sc., President & CEO, Friedt Professional Engineering Services, Inc

This year, we ran the second Internet of Things (IoT) Microconference (You, Me, and IoT Two) at Linux Plumbers. Overall, the conference was incredibly well organized and it was great to connect with everyone again, virtually. Some attendees say it was the most organized and most enjoyable virtual conference of the year, and your author is very much inclined to agree with that.

The IoT Microconference had some fantastic topics and presenters, including

The discussions and interactions at the IoT MC have brought momentum to a number of projects in the Linux IoT space, including

  • IEEE 802.15.4 MAC Layer Management
    • These changes will allow users to browse nearby 802.15.4 networks just as they currently do with 802.11 (WiFi) networks
    • Three separate contributors / organizations are working together to bring these patches into Linux
  • WPANUSB

Greybus for IoT

Different Devices in the IoT Architecture. source

The final presentation at Plumbers was on Using Greybus for IoT. For those who are unsure about what Greybus is, feel free to check out any of the following links.

Additional instructional material on how Greybus is used for IoT using the Zephyr Real-Time Operating System and Linux is available via links in the table below.

BoardMediumTopic(s)InstructionsVideo
nrf52840dk_nrf52840Bluetooth Low EnergyGPIO LEDhttps://bit.ly/2NR0NCIhttps://youtu.be/Y_6y6gpZ2GA
cc1352r1_launchxlIEEE 802.15.4GPIO LEDhttps://bit.ly/31FQNV4https://youtu.be/hd60CbiUN1g
cc1352r_sensortagIEEE 802.15.4GPIO LED I2C SPIhttps://bit.ly/3aZK7nehttps://youtu.be/6SNkjiDJ3KY

The first two demonstrations implemented Greybus as a sample app within Zephyr while the last demonstration has shown the evolution to Greybus as a system service in Zephyr.

What Are The Key Values in Greybus for IoT?

The end-goal of supporting Greybus in a microcontroller RTOS such as Zephyr is to reduce the amount of engineering effort required to write and maintain microcontroller firmware – for everyone. As a community-oriented IoT framework, we hope that translates to savings for hobbyists and industry professionals alike.

Cost distribution for an IoT Project involving both Hardware and Software. source

Taking hardware development into consideration as well, the cost of developing an IoT App and a product can balloon quickly, with 50% of costs going to Hardware and Integration. Firmware development lives in a fuzzy Venn-diagram area somewhere within the pie-slices of Hardware & Integration. Of that 50%, it would not be surprising that 35% is directly related to firmware development.

To mitigate the costs mentioned above, the strategy with Greybus for IoT is threefold:

  1. Make non-discoverable buses discoverable
  2. Keep the intelligence in the host
  3. Use standard IP-centric communication APIs

Discoverability

As mentioned at Linux Plumbers, most of the buses used in IoT devices are non-discoverable. That is, there is no way of knowing what buses are available on a given device, nor is it possible to know what devices are attached to the bus, without using platform-specific metadata.

In the desktop and server space, non-discoverable buses are made discoverable using the ACPI standard, passing platform-specific metadata through the BIOS or UEFI firmware.

In the embedded space, non-discoverable buses are made discoverable using Device Tree, passing platform-specific metadata through the bootloader.

With Greybus, devices are made to be discoverable via entries in the Greybus Manifest – a document that is queried as part of the Greybus communications protocol.

Keep the Intelligence in the Host

When we bury most of the application logic in microcontroller firmware, along with device-specific drivers, maintenance becomes costly. Updates can become infrequent and so application logic can suffer from bit-rot. By keeping most of the application logic out of the microcontroller and in a more centralized location, updates can be better tested and deployed more frequently with greater confidence.

Also by minimizing the functionality that the microcontroller is responsible for, we reduce the attack surface area and arguably improve security.

Standard Communication Protocols and APIs

Greybus for IoT uses IETF, POSIX, and IEEE industry standard APIs and communication methods such as:

  • TCP and UDP protocols with standard BSD Socket API calls such as connect(), send(), sendto(), recv(), and recvfrom()
  • IETF standards such as mDNS (RFC 6762) and DNS Service Discovery (RFC 6763)
  • Standard POSIX calls such as open(), close(), read(), write(), and ioctl() to interact with devices over Greybus

When Greybus is integrated tightly into the host operating system kernel, as is the case for Linux, then the details of the Greybus Protocol itself actually vanish and the developer is only left with standard API calls.

What Next with Greybus for IoT?

After LPC, we have been busy both at the very low level (radio) and at the very high level (tooling and upstreaming). The radio details can get quite technical, so those will be saved for another article. The primary focus right now is making it easy for people to try Greybus out with Linux and Zephyr. To that end, the following objectives were made:

  1. Upstream Changes to Gbridge
  2. WPANUSB
  3. Greybus Module for Zephyr
  4. Greybus Protocol Dissector for Wireshark
  5. Support for DNS Service Discovery via mDNS
  6. Using a Linux Driver for a Remote I2C Peripheral
  7. Authentication and Encryption

Gbridge

Gbridge only requires minor changes to support IPv6 and IPv4 TCP/IP. There is a PR opened for review on GitHub. Previous demos actually hard-coded the IPv6 address. However, once DNS-SD is supported in Zephyr, we can continue to search for services named _greybus._tcp, which is the default method in gbridge today.

WPANUSB

An alternative to the ATUSB is to use WPANUSB which exists both as a Zephyr sample app and as a Linux kernel module. It works for any IEEE 802.15.4-enabled hardware in Zephyr that also has a USB transceiver, such as the nrf52840dk_nrf52840.

While wpanusb is perfectly functional as-is, there is ongoing work in linux-wpan as well as BeagleBoard.org® community to get the wpanusb driver into shape for upstreaming so that it can serve as a generic IEEE 802.15.4 driver for multiple chipsets. This involves changes posted on the linux-wpan mailing list, but a big feature that BeagleBoard.org® is working on involves simultaneously supporting 2.4 GHz and Sub GHz IEEE 802.15.4 frequencies. Eventually, the same device will also simultaneously support BLE.

Greybus for Zephyr

source

There is now a dedicated Zephyr Module for Greybus, although it is still pre-release. There is a branch that is building and flashing succesfully using Zephyr’s sophisticated external module system.

If you have already followed the Zephyr Getting Started Guide, then all that is necessary is to do the following.

west init -m https://github.com/cfriedt/greybus-for-zephyr.git --mr v2.4.0-rc0 greybus-for-zephyr
cd greybus-for-zephyr
west update
cd zephyr
git apply ../greybus-for-zephyr.git/zephyr-pthread-stack-pool.patch
git apply ../greybus-for-zephyr.git/zephyr-gpio-get-direction.patch
west build -b cc1352r_sensortag ../greybus-for-zephyr.git/samples/subsys/greybus/net -- -DOVERLAY_CONFIG=overlay-802154.conf
west flash

Major advantages of using a separate Zephyr Module are that the platform code and application code are now only loosely coupled. Greybus only relies on having a stable device API, a stable threading API, and a stable sockets API.

There are only a few issues (most already with PRs) that need to be resolved until Greybus for Zephyr can cut a release

When those are resolved, Greybus for Zephyr releases will be tracking upstream Zephyr releases.

Greybus Protocol Dissector for Wireshark

There is an issue upstream with Wireshark, but low-level IEEE 802.15.4 radio issues have taken a priority to that in the last while. It is definitely on the agenda and should be completed soon.

The major benefit to having a Greybus protocol dissector for Wireshark is that it will provide a quick and reliable way for third-party developers to examine Greybus protocol details, provide network logs, and identify any potential issues.

DNS Service Discovery via mDNS

The DNS Service Discovery feature is quite exciting. Up until this point, Zephyr devices have only responded to A or AAAA DNS queries over mDNS but have not responded to PTR queries – i.e. they have not been able to advertise their network services – and there are many – ranging from HTTP to CoAP.

To enable mDNS / DNS-SD only takes a few lines of code, as shown below. We are hopeful that most if not all Zephyr network services can adopt this with relative ease.

#include <net/dns_sd.h>
static const uint8_t foo_txt[] = {
    "\x06" "path=/"
};
DNS_SD_REGISTER_SERVICE(foo, "My Foo", "_foo", "_tcp", foo_txt, 4242);

Below we use avahi-browse in Linux to resolve Greybus services in our test environment.

$ avahi-browse -t -r _greybus._tcp
+ enp2s0f0 IPv6 zephyr                                        _greybus._tcp        local
= enp2s0f0 IPv6 zephyr                                        _greybus._tcp        local
   hostname = [zephyr.local]
   address = [2001:470:1d:8e9:93c2:1e27:b75c:648c]
   port = [4242]
   txt = []

DNS Service Discovery Response via Multicast DNS

Using a Linux Driver for a Remote I2C Peripheral

One of the major benefits of using Greybus is, as mentioned, the ability to reuse existing Linux device drivers to access remote devices. We can now use the opt3001 ambient light sensor in Linux to interface with a remote opt3001 device on a cc1352r_sensortag over the network.

First, find out which i2c device is associated with Greybus.

ls -la /sys/bus/i2c/devices/* | grep "greybus"
lrwxrwxrwx 1 root root 0 Aug 15 11:24 /sys/bus/i2c/devices/i2c-8 -> ../../../devices/virtual/gb_nl/gn_nl/greybus1/1-2/1-2.2/1-2.2.2/gbphy2/i2c-8

Next, probe the opt3001 Linux device driver to look at i2c peripheral address 0x44 on /dev/i2c-8 (adjust as necessary for your actual i2c device / i2c peripheral address).

echo opt3001 0x44 > /sys/bus/i2c/devices/i2c-8/new_device

An IIO device should be created at /sys/bus/iio/devices/iio:device0 (again, adjust as necessary for your actual IIO device).

# cd /sys/bus/iio/devices/iio:device0
# cat in_illuminance_input
151.280000

Credit goes To Vaishnav for being the first to use a Linux driver over Greybus, 6LowPAN, and IEEE 802.15.4!

Authentication & Encryption

There is a proof of concept changeset that allows SSH keys to be used for public-key authentication as well as initial secure negotiation of an AES-128 session key for symmetric key encryption of the remaining stream. The reason that AES-128 was chosen was because most IoT devices include an AES-128 hardware cryptographic engine.

One of the main concerns with the proof-of-concept is that it was accomplished using the same message format that Greybus itself uses. As this may be somewhat confusing, there is no intention to bring any form of authentication into the Greybus Core within the Linux kernel. It is accomplished entirely within userspace.

However, while keeping things in plaintext makes development easy, it is not a feasible solution for the long term. We are on the lookout for authentication libraries that can be scaled down to work within a microcontroller or scaled up to work within a Linux-based device.

How Can I Help?

Most of our collaboration is happening in the following communities:

All developers and users are welcome to contribute via code, documentation, or tooling.

Conclusion

Greybus for IoT has come a very long way in a relatively short period of time, mostly thanks to the work of a countless number of others who have contributed to the technology. However, BeagleBoard.org® is really responsible for driving this project to completion. Thanks to everyone involved.

We are just a few pull-requests away from an alpha release, so please stay tuned!

Zephyr Project

About Zephyr Project

Close Menu