Jobs

At Cruise I work in the kernel team, focusing on future hardware.

At Apple I worked on the Platform Kernel team, which handled the kernel in common between most Apple products (watches, phones, tablets, laptops, etc). I worked on the ARM side of it. Of the shipped products I can talk about: I was the main platform kernel contact for the A15 Bionic chip, the M2 chip, as well as M3 Pro / M3 Max chips. I cannot say much more (yet?).

At Google I worked on the ADK2012 device and presented it at Google I/O conference in 2012. I wrote the small OS that runs on it, most of the drivers (i2c, accelerometer, light sensor, LED drivers, audio, SD), frameworks (FAT32 library, OGG & SBC decoders), and a fully functional bluetooth stack, including support for even RFCOMM, SDP, and A2DP.

Then, I worked in Android@Home, on a few projects, none of which shipped...

Then, I worked in the Android Wear team making cool wearable devices powered by Android. I was also the tech lead for the android sensor hub project. It shipped in pixel2, polar watch, and is used in billions android phones to the day.

Then, I was on the ChromeOS team, working on ARC++ - the method of running Android apps in ChromeOS. After that, I was the tech lead for NewBlue - the new ChromeOS bluetooth stack

I worked on a project that later became the Fire Phone (though much later). I designed the architecture for the sensor subsystem both on the android side and on the embedded controller side, played a part in the chip selection, wrote the controller code - a small RTOS with threads, clocks, power management, and dynamically loadable sensor drivers. Part of the design was a way to guarantee that the embedded controller will not be bricked when being updated. Besides this, I participated in the bring-up of most subsystems of the device.

I did a lot of the system-level tasks needed to make the Kno device. This included bringing up NVidia's bootloader on the Tegra2, adding mass-storage support to it, and implementing our custom factory install solution. Kernel bring-up was next. NVidia's NAND driver was very slow, so I implemented my own, referencing their TRM and gained a 3x speed advantage over theirs. Since we used raw NAND, and yaffs2 filesystem is not the fastest, I wrote a flash translation layer, on top of which we used the ext4 filesystem. This was much faster than yaffs. I wrote a few other drivers for the device, as needed. Besides the linux work, I also picked our embedded controller (PIC24) and wrote all the software for it, including a basic RTOS, crypto, power management, and SoC <==> ec communication (both as a kernel driver and as a userspace daemon).

I worked on the team that created the replay-debugging feature. This was quite an interesting project that was also built on record-replay. The idea was simple: use the deterministic replay ability of VMWare workstation to replay a VM to an earlier point in time, essentially as if time went backwards. With lots of glue code and lots of reverse-engineering of windows debugging API, it was made to work. GDB support was added later, as well as a lot of optimizations. The feature shipped in VMWare Workstation 6.5 and was used by a lot of developers, including some guys at Mozilla. The number of challenged that we faced in this project was astounding: windows debug API are complex and very low-level, so it was very hard to determine the debugger's intent from its calls to the debug API. Furthermore since we were in deterministic reply, we could not change the state of the virtual machine. Unfortunately for us, breakpoints are set by writing to memory. We had to catch this and detect breakpoints some other way. Same problem applied to watchpoints, library loading, and various other pieces. It was quite a fun project.

As an intern at VMWare I created the prototype for the vassert feature. This feature built on VMWare's record-replay platform to create an innovative debugging technique. Essentially the usual kinds of assert() are slow and big, causing debug builds to be slow and large. VAssert aimed to fix the "slow" issue by creating a special type of assert, that only ran at certain times. Specifically, if executed on real hardware, asserts would be skipped, and not run, resulting in fast execution - much like a release build. In a virtual machine, asserts were also skipped. They were skipped in "record" mode too. In replay mode, however, the asserts were executed; their side-effects were undone to avoid ruining the deterministic nature of replay; and replay was continued. If an assert failed, the virtual machine was made to "go live" and the developer could then debug the issue. Since VMWare record-reply was deterministic, one could replay the same recording over and over, as needed. The feature was presented at VMWorld2007.

I produced many very useful utilities for PalmOS-based PDAs and Phones. Most were tools to accomplish things that Palm said were impossible (that was the main motivation). This included editing OS images of various devices, replacing the memory manager, rewriting bootloaders and various drivers, recording video on devices that did not support it, fixing hardware defects (fixing screen noise and allowing re-calibration of even physically broken touchscreens to work), producing drivers to support entirely new devices (SDHC support, for example), and even a wholly new OS that was binary-compatible with PalmOS, but featured memory protection and true multitasking.