* * * * * Cellphone guts for the curious … M thought I might find the following email he sent to some of his fellow cow- orkers interesting (and I did). He also gave me permission to post it here. So, if you were ever interested in the internal processing guts of a cell phone, well, here you go … > From: MXXXXXXXXXXXX > To: XXXXXXXX XXXX XXXXXXXXXXXXXXXXXXXXXX > Subject: XXXXXXXXXX firmware guts for the curious … > Date: Sun, 20 Jan 2013 19:07:00 -0500 > > So I found myself poking around inside the firmware of my personal cell > phone, an HTC EVO 3D. This phone is based on the XXXXXXXXXXXXXXXXXXX > chipset. In investigating something about how my phone worked I decided to > disassemble the cellular firmware on it and see how some of the EVDO stuff > was done. I found some interesting things for those of you who are curious > as to how some of these things work beyond the Linux side of Android. If > you aren't then feel free to skip this e-mail. > > A cell phone running something like Android had a complete separation > between the application processor (the CPU (Central Processing Unit) > running Linux, your apps, the GUI (Graphical User Interface), all that > stuff) and the cell phone processor (runs the mobile data stack, voice > codecs, speakerphone echo cancellation and all other manner of hard real- > time stuff). The (somewhat incorrect) terms of “application processor” and > “baseband processor” were assigned to these two CPUs, respectively. So why > the separation in the first place? Well Linux isn't very good at things > like voice or real-time. Running a cellular radio is quite a bit of real > time code. And all the speech pathways of the actual “phone” part are also > a bit much for Linux to deal with. Linux, as with much “desktop” style > software out there gives little thought to things like interrupt latency— > making it a terrible OS (Operating System) to do anything hardware. Plus it > makes sense that when smartphones first started popping up everywhere that > you had a bunch of grizzly EE (Electrical Engineering) guys doing the RF > (Radio Frequency) stuff who didn't want to mess with Linux and all that > “high level crap.” (And yes, I fall squarely in that camp). So the dual-CPU > approach keeps the different types of engineers from getting in each > others' way. > > I used to think that the baseband firmware was pretty traditional, > monolithic piece of embedded software. Turns out I was dead wrong. I can > only guess at the reasons for their architecture since I have no real > contacts at XXXXXXXX. But the firmware is actually quite a hodgepodge of > things. Those of you who fancy yourselves software archaeologists may find > this informative. > > The software behind the baseband CPU is quite interesting and totally > undocumented. But I dug in and found a fascinating world. First everything > in the XXXXXXXXXX baseband runs under a hypervisor—which they call a > “microvisor.” For those of you unfamiliar with what this means it's a bit > like running VMware on a bare computer and then running Linux and Windows > simultaneously. Only in this case the hypervisor is a commercial port of > the L4 microkernel [1]. The hypervisor divides the processor into “cells” > that each run their own distinctive world. Most of the cellular modem > software runs under an OS called Iguana [2]. Iguana wraps an older RTOS > (Real-Time Operating System) used by XXXXXXXX called REX that now runs > inside an L4 task and makes it a message-based server. Those of you who > worked with me at XXXXXXX may remember how we ran [one operating system] on > top of [another operating system] on our XXXXXXXXXX XXXXX PBX—this is kind > of the same thing. Only the ARM architecture is far saner to deal with than > x86 when it comes to virtualization. > > The cellular software running under these layers is called > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX—and it's a quite typical > monolithic embedded blob of software. But it's had a few interfaces shoved > in it and now communicates with the rest of the firmware through a message > based interface. > > So why did they go to all the trouble to run their embedded firmware under > L4? Well there is more running on the baseband processor than you may > think. It's grown in complexity and now contains several large pieces of > disjoint software, so the microkernel approach starts to make sense when > you consider how much legacy code they have. Poking around I found out the > XXXXXXXXXX firmware also uses pForth [3]. Mostly it looks likes for remote > diagnostics the cellular carrier can send blobs of FORTH code right to the > radio. The radio firmware also seems to have an IP (Internet Protocol) > stack (with TCP (Transmission Control Protocol)) so it can do its own > interesting things (both bad and good). This TCP stack is what talks to the > cellular network. The rmnet0 interface actually goes over shared memory and > talks to this IP stack (which is where PPP (Point-to-Point Protocol) is > actually running). > > The GPS (Global Positioning System) functionality of your phone is also > quite a huge pile of code and again the Linux side of things sees a very > simple interface where coordinates are fed into the application processor. > The huge amount of code necessary to do the actual positioning (and the > associated WAAS (Wide Area Augentation System) & aGPS (Assisted Global > Positioning System) stuff) also runs as a task under L4. There are also a > pile of DSP (Digital Signal Processor)'s running their own kernel that > communicate with the L4 kernel for management purposes. > > I think XXXXXXXX is planning on eventually removing the distinct baseband > processor—maybe in their low-cost chipsets. You can run Linux under L4. > This means the entire Android application processor could in theory be > virtualized and run alongside the baseband software on a single core. I > could see some advantages to this and I wonder if XXXXXXXX is working on > (or implemented) this. A quick peek at the various device drivers in the > open source kernels for the XXXXXXXXXX shows the drivers just fill in > buffers and queue messages in a very high level manner compared to a > typical device driver. Since the hardware is actually managed by stuff > running under Iguana. Since this is just a message interface it wouldn't be > terribly difficult to move everything to a single core design. > [1] http://www.ok-labs.com/products/okl4-microvisor [2] http://en.wikipedia.org/wiki/REX_OS [3] http://www.softsynth.com/pforth/ Email Sean Conner at sean@conman.org .