1 files changed, 101 insertions, 0 deletions
diff --git a/2010/gsm_foss-mt2010/part-mtk.tex b/2010/gsm_foss-mt2010/part-mtk.tex
new file mode 100644
index 0000000..17baffc
--- /dev/null
+++ b/2010/gsm_foss-mt2010/part-mtk.tex
@@ -0,0 +1,101 @@
+% Day 2
+\part{How MTK could use GSM FOSS}
+
+\begin{frame}{Part II - MTK and Free / Open Source Software}
+\tableofcontents
+\end{frame}
+
+\section{Open Source GSM tools for Debugging + Testing}
+
+\begin{frame}{Possible use cases for OpenBSC}
+OpenBSC or OpenBTS in R\&D
+\begin{itemize}
+	\item Inexpensive simulation of GSM network for R\&D
+	\item Flexible since any aspect can be modified by altering source code
+	\item Complex and more exotic parts of GSM protocol spec can be tested
+	\item Much more functionality than CMD 55 / Racal 6103 or similar
+	\item Ability to send malformed L3 messages (fuzzing) for MTK MS stack security improvement
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Other GSM tools}
+\begin{itemize}
+	\item airprobe: Tracing of Um air interface
+	\item SIMtrace: Tracing of SIM card interface
+\end{itemize}
+\end{frame}
+
+\begin{frame}{General advantages of FOSS based solution}
+\begin{itemize}
+	\item MTK has full access to source code
+	\item New features can be added on any level of the protocol stack
+	\item No dependency on a single supplier
+	\item Lower cost means available to more MTK engineers
+	\item Lower cost means available to more MTK customers (factory testing, field tests with OEM customers, ...)
+\end{itemize}
+\end{frame}
+
+\section{Single-Core Android smart phone}
+
+\begin{frame}{MTK feature phone vs. smart phone}
+\begin{itemize}
+	\item MTK's advantage so far: Low cost sigle-core feature phone
+	\begin{itemize}
+		\item Baseband processor runs Nucleus, GSM stack, UI and rich application stack (Camera, H.264, GPRS, TCP/IP, ...)
+		\item Other suppliers have to use dual core
+	\end{itemize}
+	\item However, MTKs Nucleus based OS has custom/proprietary APIs
+	\item Not many 3rd party applications can be installed on the phone
+	\item Android, iPhone, Windows Mobile have standard API / environment
+	\item Thus, MTK needs to offer 'standard' smart phone solution
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Proposal: Single core Android smart phone}
+\begin{itemize}
+	\item Android, WinMobile, etc. have dual-core architecture
+	\begin{itemize}
+		\item GSM/3G protocol stack on baseband processor
+		\item UI + applications on application processor
+	\end{itemize}
+	\item If MTK now goes for Android smart phone, why go dual core?
+	\begin{itemize}
+		\item Simply port L1 code into Linux kernel (IRQ/FIQ driven)
+		\item Make sure you follow the GPL and release L1 as Open Source
+		\item Run your L2/L3/L4 as proprietary userspace process on Linux
+	\end{itemize}
+	\item Single-core Android phone has less ARM core licensing cost and less silicon size
+\end{itemize}
+\end{frame}
+
+\section{Linux development and the community}
+
+\begin{frame}{SoC vendors and Linux ports}
+\begin{itemize}
+	\item A number of SoC vendors have been used with Linux for many years
+	\item Port of Linux / BSP has originally been done by 3rd party or community
+	\item SoC vendors started to become more active in the last 5 years
+	\item Original: Create port, ship it to customer, done.
+	\item SoC customers end up with vendor-specific code
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Disadvantages of vendor ports}
+\begin{itemize}
+	\item Fast progress in mainline Linux kernel development
+	\item Customers want latest kernel for latest features / performance
+	\item Vendor port (not in mainline) always behind mainline
+	\item Porting out-of-mainline vendor port into new mainline is lots of work
+	\item Customers end up with old vendor-specific code
+\end{itemize}
+\end{frame}
+
+\begin{frame}{SoC vendors need to include their port mainline}
+\begin{itemize}
+	\item Major SoC vendors now work together with mainline developers
+	\item Support SoC in latest mainline developer version
+	\item Actively submit port into mainline Linux kernel
+	\item Port in mainline stays automatically current/up-to-date
+	\item Continued maintenance effort is shared by all parties
+\end{itemize}
+\end{frame}