* * * * *

                       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 <XXXXXXXXXXXXXXXXXXXXX>
> 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 author at [email protected]

You are viewing proxied material from gopher.conman.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.