Video Meet the Firmware Lead For Google's Project Ara Modular Smartphone (Video) 25
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?
Aggressive schedule (Score:5, Funny)
Google said it is working on an aggressive schedule to have the project fully cancelled before 2017.
Re:Aggressive schedule (Score:5, Funny)
Which is still 5 years before this kid's 18th birthday, by the looks of it. And here I thought sweatshops were the only ones using child labor.
Re: (Score:1)
Which is still 5 years before this kid's 18th birthday, by the looks of it. And here I thought sweatshops were the only ones using child labor.
2009 MIT Grad, he is about 29 years old, not that it should matter - https://www.linkedin.com/pub/marti-bolivar/a3/537/375
Project Ara (Score:2)
Hopefully not like Project Ava. Helpful hint: ok to meet the project lead, but don't spend a week with him.
Re: (Score:1)
Is he really chewing gum... (Score:1)
Why slashdot videos are shit (Score:3, Informative)
2. The production quality is shit. The average youtube amateur does a better job. And that's just fucking sad.
3. The content presented is boring and not compelling. Video should be compelling, if we want to absorb raw tech info, that is what text is for.
And lastly I hate to say it but these people on the videos are just so unlikeable to me. This kid here just gives me the impression of a tool/brat/hipster and makes me annoyed before I even watch the video. Dunno, that's just my natural reaction, maybe I'm just an asshole.
I like slashdot because of the quality of information and debates by users in the text comments. Quite often I skip the articles entirely and just read the comments because of the excellent summations users provide. I read slashdot almost every day. This is my first post in years, and I came out of lurking just to say that shit like these videos and slashdot beta has been seriously corrosive to the value that this site provides. Have you fucking idiots doing business development at slashdot not learned anything from what happened to Digg.com ??? I could be wrong but I feel like it is only a matter of time before your users jump ship.
Re: (Score:1)
Re: (Score:2)
This kid here just gives me the impression of a tool/brat/hipster and makes me annoyed before I even watch the video.
I was more distracted by the person on the left with the hipster haircut flipping their hair around, looking out the window, looking at the camera, etc. Then the guy that came in with the French press, started untangling his headphones, twirled around in his chair, poured coffee out of the french press.
Blah Blah Fuck Google (Score:2)