% 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}
