Low Level Sensor Programing and Security Enforcement with MRAA – Brendan Le Foll, Intel Corporation

mraa.io is a simple userspace I/O protocol to unify a plethora of interfaces: UART, GPIO, I2C, ADCs (IIO), 1wire, …. MRAA is the API spec, libmraa is the C/C++ implementation. Also bindings for python, nodejs, java, and unsupported bindings for a bunch of other languages (e.g. lua). Made for monkeys, so easier is better. On Linux, MRAA brings the I/O that is typically reserved for the kernel available to userspace. It’s mainly for quick prototyping, but turns out to be used in actual products. Platform quirks are abstracted, supports lots of devboards. E.g. it does the pinmuxing if necessary. Sometimes even uses devmem if the crappy vendor kernel doesn’t allow things to be done properly.

Most calls are syncrhonous.

GPIO interface allows to register ISR with a callbac function.,

On top of this API, a sensor library has been added: UPM (Useful Plugins for MRAA). It gives code examples of how to use each sensor..

To add a board, there are 3 ways:

  • Raw mode: no platform definition, just map the pins to the kernel representation e.g. gpio numbers.
  • C platform configuration: same kind of mapping, but also override things where necessary.
  • JSON file is similar to raw mode but you can give names etc., just no overrides.

To do things like devmem manipulations safely, there is a daemon that checks permissions.

On Android, there is a peripheralmanager that authorizes access to GPIOs etc. This was reused to support MRAA and a bakcend was added to libmraa that talks to peripheralmanager over Binder. This way, all the sensors become available on Android.

AFB is the equivalent of Binder in Automotive Grade Linux. Every application has a SMACK security context, and a binder in the same security context. The binder exposes the bindings that the application has access to (and only those). AFB doesn’t require the rest of AGL. To use MRAA with this, there is a global libmraa that actually talks to the kernel, and another libmraa in each application that talks to the binder which talks to the global libmraa. This way, each application can only access the messages that were meant for it. The two libmraas are in fact built differently. The application libmraa is built with BUILDARCH=AFB, which replaces all the normal kernel calls with calls to AFB’s binder. In a similar way, it is possible to build a libmraa that uses I/Os that are not directly accessible by the kernel, e.g. an extension board connected over UART.



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s