102 lines
3.8 KiB
TeX
102 lines
3.8 KiB
TeX
% 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}
|