Meet the Firmware Lead For Google's Project Ara Modular Smartphone (Video)

Video Meet the Firmware Lead For Google's Project Ara Modular Smartphone (Video) 25

Posted by Roblimo on Tuesday April 28, 2015 @05:36PM from the build-it-one-piece-at-a-time dept.

Video no longer available.

According to Wikipedia, 'Project Ara is the codename for an initiative that aims to develop an open hardware platform for creating highly modular smartphones.' Google is the sponsor, and the project seems to be moving faster than some people expect it to. There's a Project Ara website, of course, a GitHub repository, a Facebook page, even an Ara subreddit. During his conversation with Timothy Lord, Ara firmware project lead (and spokesman) Marti Bolivar said it won't be long before prototype Ara modular phones start user testing. Meanwhile, if you want to see what Marti and his coworkers have been up to lately, besides this interview, you can read a transcription of his talk (including slides) from the January Project Ara Developers Conference in Singapore.

Tim: Marti, could you go ahead and help explain what you do right now on Project Ara?

Marti: Sure. My name is Marti Bolivar and I’m the firmware lead for the project. So one of the things that the project is doing is producing the silicon, these are the bridge ASICs that help us get existing chipsets onto the UniPro network. And so they all contain microcontrollers. So they all need firmware. And that firmware has to comply with the Greybus specification. So LeafLabs and the Project Ara firmware team more generally is contributing to the design and implementation of the specification itself – well the design and specification itself, I mean its implementation on the firmware.

Tim: Could you explain, what does Greybus mean in this context, what is Greybus?

Marti: So, Project Ara uses a protocol called UniPro for model to model communication. And UniPro specifies a reliable transport layer in terms of the OSI model, and it doesn’t specify too many things on top of that. So Greybus is the name that we are giving to an umbrella grouping of application layer protocols that we are building on top of UniPro in order to make the platform tick.

Tim: And talking about the things that LeafLabs is doing in contributing to the Project Ara development, the design, explain what is the LeafLabs contribution and what is your role with that?

Marti: Sure. So LeafLabs heads up the firmware team. There is a variety of different corporate entities working on the firmware. We both do firmware ourselves and manage the efforts of the other groups.

Tim: So with Project Ara you are actually facing some constraints and some challenges that not even every embedded project faces, namely you have components that are going to be swapped in and out. What difficulties does that raise to you in designing firmware?

Marti: Normally, when you are doing an embedded project and you have to write some firmware, you can pretty much rely on the hardware being static, right? So as you mentioned, this is a new hardware thing. And what static hardware buys you is the ability to bake in exactly the drivers that you know you are going to need, the firmware doesn’t have to be particularly self-describing, right, it can sort of assume that the host device knows it and its capabilities and its register map and is able to have highly tailored driver. But for Project Ara since that’s not really the case, we are designing as part of Greybus a suite of device class protocols that present a much more abstract view of modules onto the network. So instead of for example to set up a battery or a vibrator, just saying like well you better know what voltages to apply and you better know how to read my gas gauge to know how much charge I have left, we have to describe ourselves as a battery first of all, describe our technology, describe variety of other parameters. And then be able to respond to abstractor quests like tell me your charge as a percentage rather than rely on the host to do that computation for us.

Tim: And you also have to essentially plan for devices that may not even exist here?

Marti: Yeah, absolutely. So there has to be a lot of future proofing in the protocol itself.

Tim: How do you take that into account?

Marti: So everything about Greybus is version. Every single protocol has version numbers, we’ve got backwards compatibility policies baked into the protocol itself. And so at the beginning of every module to other module negotiation over UniPro, the first thing is protocol handshaking phase, and then that’s what’s backwards compatibility rules.

Tim: Right now in the process of – actually you mentioned versioning, right now you are in a separate kind of versioning which you call Spiral 2 of development of Project Ara. Can you explain what is a Spiral, how does that work, what does it mean that you are in Phase 2 of it right now?

Marti: Yeah. So, we’re in a Spiral 3 right now.

Tim: Oh, is that right? Okay.

Marti: Yeah. So we’re working on UniPro on the ASICs Version 2. There is a variety of other work going on in terms of the connection between the modules and the endoskeleton itself, making that inductive, variety of other things we are working on, Android release, packaging, et cetera. You can actually check our sites for more details.

Tim: Can you explain how the actual modules are attached to the endoskeleton, and what challenges that has been in the design?

Marti: Sure. So I can comment on the Spiral 2 design. Right now the way they work is, they slide into slots on the endoskeleton, and there is an electro-permanent magnet, which is kind of a crossbreed between a regular electromagnet and a permanent magnet, in that you can apply a power charge to it or, sorry, a pulse of power to it, and cause it to switch states between a highly magnetic state and a weakly magnetic state, and so that’s what binds the module to the endoskeleton once it's inserted.

Tim: And then each one also of course has a selectable component that connects to the endoskeleton as well?

Marti: Sure. So there is an interface block between the module and the endoskeleton that pins out UniPro, it pins out power and ground and it pins out an RF bust for antenna modules or any other modules basically.

Tim: And the things that are working right now, you actually have quite a few components that are working right now. Can you talk about the state of the project as far as what components are working at the moment?

Marti: Sure. From a firmware perspective we’ve brought up our dev works on the ASIC Version 1. We’ve demonstrated that the form factor phone will boot to Android, we’ve shown touch working. And right now we are working on bringing up ASIC version 2.

Tim: The speed of development has been I think from an outsider perspective pretty amazing, because you know when I first heard of this project, it didn’t seem like something that would actually see the light of day and if you are actually going to have some user testing very soon. How has it been from your perspective as designer within the project, is this pretty exciting environment in which to work?

Marti: Yeah, I mean, speaking personally, it's amazing. I really am excited about this technology and working on the project.

Tim: How much faster is this developing than you expected, let's say? Is this a project you thought would reach the light of day when you first started working on it?

Marti: Oh sure. I wouldn't have joined on it if I didn't think it was going to work or had no chance to work.

Tim: Is anyone clamoring to be on the list within the company to try to be on the testing circle?

Marti: Well, as the developers, we're on the front lines for testing always, right?

Tim: Are you actually able to use the phone on a day-to-day basis at all in anyway?

Marti: Right now, we don't use the phone on a day-to-day basis internally.

Tim: Okay. So, I realize that you're working at LeafLabs. And you described when we started this call, you guys moved into a new office, can you tell us where they are. Where are you sitting right now? It’s a nice environment.

Marti: Sure. Yeah, we're at the Industry Lab co-working space, which is in Cambridge, Massachusetts, and we're located pretty near to MIT, so LeafLabs is an MIT spin-off and there's a bunch of companies out here. So, Industry Lab is in several floors of a kind of lovely brick building that has a real history of selling technology to the various nerds in the Cambridge area.

Tim: Marti, Project Ara is a more open project than a typical phone company's project; as in designing a new phone, we don't see what Apple or Samsung are working on, they don't ask anyone to contribute. Can you talk about how open Ara is and how people can contribute to it?

Marti: Sure. Project Ara releases the platform specification as part of the model developer’s kit and puts them up on the Project Ara website. It contains schematics and layout files for all the reference modules we’ve made, all the firmware that we’re writing is open source on GitHub. Our specification, the Greybus specification, is open source on GitHub. You can watch all of them in real-time. The kernel code is up on there as well. There are links to getting more information on Android. Our development boards, you can get schematics. I would say that from a technical perspective, everything that I’m working on is out in the open right now.

Tim: It will be like more expensive for someone to replicate it in quantity one though.

Marti: Sorry?

Tim: It’ll be a lot more expensive for someone to replicate it with quantity one based on the information that’s available. It’ll be pretty hard for someone to home brew their own Project Ara device.

Marti: Harder? Yes, sorry, I don’t know if I can say hard.... Maybe I can say – so one of the things that we talked about at our last developer’s conference was a variety of ways that we’re making it possible for module developers to join on. There is going to be dev works that you’re going to be able to use the same dev works that we’re going to be using. And sure it’d be difficult to cut your own UniPro ASIC, but that’s why bridge ASICs are really helpful to outside developers. They can use them, they can incorporate them into their own designs and they can do so in an environment that they totally control; everything down to the build system is available for hacking.

Tim: Okay. Let me ask you about the openness of Project Ara versus the openness of Android. So Android is not particularly known as a hot swappable operating system. Most devices, they come with a known suite of sensors, spring resolution, everything like that. And Project Ara is actually doing something that is the opposite on those fronts because it is all about swapping those things out. How difficult is it to make Android a hot swappable operating system?

Marti: There are a variety of changes that are needed in Android at many different layers. From the bottom, there are a lot of configuration files that the device manufacturer is expected to include as part of their Android build, which specify all the hardware that is present on the device. And those files are stored in read-only partitions. And so, they don’t change and the hardware is not expected to change. So, those are being replaced with dynamic alternatives. The Android Hardware Abstraction Layers which are users based libraries that abstract the Kernel API used for the particular hardware in question for a variety of cases, cameras, audio, et cetera, are usually normally filled out by vendor and they expose if he has two system services, which allow the system service to drive the hardware in a more abstract way, and those often assume that the hardware configuration of the device is also fixed. So, there is work ongoing to make those dynamic and support hot swappable devices to understand the kernel emitting events, events which indicate that a model has been inserted and to convey that information up to higher layers all the way up to apps.

Tim: Is it a factor for nearly every module that could be used? What are some examples of the modules that really most need to be hot swappable.

Marti: Well, I guess, part of the beauty of the platform is that users get to decide, I can’t really say what most needs to happen, right?

This discussion has been archived. No new comments can be posted.