The next project on the horizon: A Free Software CardOS
Now that we have a 100% free software GSM protocol stack and baseband
firmware for the network and mobile phone side, the only remaining
proprietary part is the SIM card. And what is a SIM card? It's a
small embedded computer / SoC with integrated flash + RAM.
Once again, like in many other areas of the telecommunications industry,
development of Free Software has been hampered by lack of available
register-level hardware documentation. Without such information, how
should you be able to program? Hardware without such documentation is
an insult to every software developer.
The next problem is that typically, the Card Operating System (COS) is
written into mask ROM of the smartcard SoC. Making such a mask is quite
expensive, and it means that for every software version, different
silicon will have to be produced. So unless you are going to have
millions of units in quantity, it is unlikely that it would make
However, in recent years, purely flash based smartcard chips have been
available and getting less and less expensive. However, none of them
(like the Atmel AT90SC7272 or similar devices) have freely available
documentation. Furthermore, availability on the open market is somewhat
of a problem, mainly because they have been used extensively by people
cracking encrypted satellite TV channels. In recent years, the
smartcard industry is trying hard to cut any kind of supply to that
group of users.
However, luckily, we now see small/independent chip design houses in
China picking up and producing their own smartcard chips. They are not
only cheaper, but they simply hand out the documentation to anyone who
asks them. No questions asked, no NDA required. Welcome to the
promised land! That's what Free Software developers like:
- Free access to documentation without any confidentiality agreements
- development samples available at the same price as quantity pricing
- inexpensive development hardware with JTAG access
- reference source code provided without NDA
- they are happy that somebody wants to develop for their hardware
As you can see, I am quite enthusiastic about this. I like this
no-bullshit approach. No stupid marketing and sales droids who charge
ridiculous fees for proprietary development tools that are inflexible
and force developers to use one particular OS/IDE/toolchain.
I'm not sure how much time there will be, given the multitude of other
projects that are all asking for attention. However, I think this is a
chance that the Free Software community doesn't get every day. Let's
hope some other people like bare iron programming in small embedded
systems can get excited and we can create a FOSS COS. It doesn't have
to be something serious. Something quite simple would be sufficient for
the beginning. I'm not thinking of EAL4+ certification, multiple
channels and public key crypto. SIM/USIM cards are simple, they just
require a bit of filesystem read/write operations plus authentication.
And luckily, SIM toolkit development doesn't have to be done in Java
this way, either ;)
OsmoSDR status update
It has been two months since I first was able to play with the OsmoSDR hardware prototypes. Back at
that time, there was no FPGA code yet, and some hardware bugs still had
to be resolved. Nonetheless, the e4k tuner driver could already be
implemented and tuning was confirmed by looking at the analog i/q
Meanwhile, the hardware has been re-worked by SR-Systems and FPGA VHDL
code written by maintech.de. Ever since that, they dropped the ball
again with me as I had been careless enough to volunteer for writing
And that's what I did or at least tried to do for quite some time during
the last two weeks. The main problem was that I didn't have much time.
The second problem was that I never was able to get the SSC (synchronous
serial controller) receive DMA working.
This was a really odd experience, as I've worked a lot with that very
same SSC peripheral before, while writing firmware for the OpenPICC
some 6 years ago. However, this was in an at91sam7s, where the SSC is
interfaced with the PDC (Peripheral DMA Controller). In the at91sam3u
of OsmoSDR, it interfaces with a more modern DMAC/HDMA controller,
capable of scatter-gather DMA and other fancy stuff.
Atmel has provided reference code that uses the SSC DMA in transmit mode
(for a USB audio device playing back music via the Wolfson codec on the
SAM3U-EK board). After thoroughly studying the DMAC/HDMA documentation I
set out to write code for DMA-based SSC receiver. And it never worked.
I actually wrote two independent implementations, one from scratch and
the other based on Atmel reference code. Neither of them worked. It
seemed to be a problem with the hardware hand-shaking between SSC and
DMAC. The SSC was successfully receiving data, and that data could be
read out from the CPU using a polling or IRQ based driver. But if
you're running at something like 32 Mbps and don't have a FIFO, you
desperately want to use DMA. When the DMA handshaking was turned off,
the DMA code worked, but of course it read the same received word
several thousand times before the next data arrived on the SSC.
In the end, I was actually convinced it must be a silicon bug. Until I
thought well, maybe they just connected the flow controller to a
different ID in Rx and Tx direction. Since there are only 16 such
identifiers, it was relatively easy to brute-force all of them and see
if it worked. And voila - using the identifier 4, it worked!
So what had happened? The Atmel-provided reference code contained a
#define BOARD_SSC_DMA_HW_SRC_REQ_ID AT91C_HDMA_SRC_PER_3
and that was wrong. 3 is valid for SSC TX but not for SSC RX.
Unfortunately I never found any of those magic numbers in the SAM3U
manual either. They are not documented in the chapter of the SSC, and
they are not documented in the chapter about HDMA/DMAC either. And they
are not identical with the Peripheral Identifiers that are used all over
the chip for the built-in peripherals.
In case anyone else is interested, a patch can be found at my
at91lib git repository.
I filed a ticket with Atmel support, and they pointed out in fact there
was a table with those identifiers somewhere in the early introductory
chapters where you can see a brief summary of the features of each
integrated peripheral. Unfortunately they use slightly different naming
in that chapter and in the DMAC, so a full-text search also didn't find
them. Neither is that table visible in the PDF index.
So about four man-days later it was finally working. Another day was
spent on integrating it with the USB DMA for sending high-speed
isochronous transfers over the bus into the PC. And ever since I'm
happily receiving something like 500,000 or 1,000,000 samples / second
from an alsa device, using snd-usb-audio. Luckily, unlike MacOS or
Windows, the Linux audio drivers don't make arbitrary restrictions in
the sample rate. According to the USB Audio spec, the sample rate can
be any 24bit number. So audio devices with 16.7 Ms/s are very much
within the spec. I hope some of the other OS driver writers would take
that to their heart.
One of the first captures can be found at this
link, containing a bzip2ed wave file in S16LE format Stereo (I/Q).
It contains a FM audio signal transmitted using a small pocket-sized FM
There is no I/Q DC offset calibration yet, but once that is done we're
probably able to finally put the design into production.