\documentclass[aspectratio=169,obeyspaces,spaces,hyphens,dvipsnames]{beamer}
\usepackage{minted}
\usepackage{newunicodechar}
\usepackage{hyperref}

\mode<presentation>
\usetheme{Bootlin}

%%\newcommand{\codehack}[1]{{\usebeamercolor[fg]{code} {\tt #1}}}


\title{AMP on Cortex A9 with Linux and OpenAMP}
\authors{Gregory CLEMENT}
\email{gregory.clement@bootlin.com}
\slidesurl{http://bootlin.com/pub/conferences/2022/lee/clement-AMP-on-Cortex-A9}
\conference{Live Embedded Event 2022}

\begin{document}

\begin{frame}{\insertconference}
  \fontsize{19}{19}\selectfont
  AMP on Cortex A9\\
   with Linux and OpenAMP
  \begin{columns}
    \column{0.6\textwidth}
    \fontsize{15}{15}\selectfont
    Gregory CLEMENT \\
    Bootlin
    \normalsize
    {\em \insertemail}
    \column{0.4\textwidth}
    \includegraphics[width=0.8\textwidth]{common/logo-square.pdf}\\
  \end{columns}
\end{frame}

\begin{frame}{Gregory CLEMENT}
  \begin{columns}
    \column{0.6\textwidth}
    \begin{itemize}
    \item Embedded Linux engineer and trainer at Bootlin
      \begin{itemize}
      \item Embedded Linux {\bf expertise}
      \item {\bf Development}, consulting and training
      \item Strong open-source focus
      \end{itemize}
    \item Open-source contributor
      \begin{itemize}
      \item Contributing to {\bf kernel support} for the Armada 370,
        375, 38x, 39x and Armada XP ARM SoCs and Armada 3700, 7K/8K
        ARM64 SoCs from Marvell.
      \item Co-maintainer of mvebu sub-architecture (SoCs from Marvell
        Engineering Business Unit)
      \item Living near {\bf Lyon}, France
      \end{itemize}

    \end{itemize}
    \column{0.4\textwidth}
    \includegraphics[width=\textwidth]{common/logo-square.pdf}\\
  \end{columns}
\end{frame}

\begin{frame}{\textbf{AMP} on \textbf{Cortex A9}, why ?}
  \begin{columns}
    \column{0.6\textwidth}
    \begin{itemize}
    \item Usually, with Linux, multiple CPU cores of the same kind are
      used by the same OS in \textbf{SMP}
    \item However, one may want to use one of the cores separately,
      the system becomes \textbf{asymmetric}
    \item The usual reason for it is running a \textbf{Real Time OS}
      with dedicated resources on one of the cores
    \item This allows reducing the disturbance on the second core to
      the minimum and in the same time benefiting of a full feature
      OS: Linux
    \end{itemize}
    \column{0.4\textwidth}
    \includegraphics[width=\textwidth]{AMP-Linux-RTOS.pdf}\\
    \null\vfill
    \null\vfill
    {\fontsize{5}{6}\selectfont Images from Wikipedia, credit:\\}
    {\fontsize{5}{6}\selectfont  - Tux: lewing@isc.tamu.edu Larry Ewing - CC0\\}
    {\fontsize{5}{6}\selectfont  - Chronometer: http://www.simpleicon.com/ SimpleIcon - CC BY 3.0\\}
  \end{columns}
\end{frame}


\begin{frame}{Overview of this talk}
  \begin{itemize}
  \item Presentation of \textbf{OpenAMP}
  \item How Linux kernel communicates with external OS
  \item Adapting Linux kernel and OpenAMP for Cortex A9
  \item Pro, Cons and alternatives
  \end{itemize}
\end{frame}

\subsection{Presentation of \textbf{OpenAMP}}

\begin{frame}{\textbf{OpenAMP} purpose}
  \begin{columns}
    \column{0.8\textwidth}
    \begin{itemize}
    \item \textbf{A}symmetric \textbf{M}ulti-\textbf{P}rocessing
      \begin{itemize}
      \item In \textbf{SMP}: CPU cores treated equally, none reserved
        for special purposes
      \item In \textbf{AMP}: cores treated in different way, either by
        choice or because cores are different
      \end{itemize}
    \item Modern SoCs comes with variety of core, main cores runs Linux
      in SMP, other smaller cores run RTOS, bare metal: need to make
      them communicate
    \item \textbf{OpenAMP} provides a way to manage interactions between
      operating environments
    \item The project seeks to standardize them through open source
      solutions
    \item \textbf{OpenAMP} licence is BSD 3-clause.
    \end{itemize}
    \column{0.2\textwidth}
    \null\vfill
    \null\vfill
    \null\vfill
    \includegraphics[width=\textwidth]{openAMP_combox.pdf}
  \end{columns}
\end{frame}

\begin{frame}{\textbf{OpenAMP} code}
  \begin{columns}
    \column{0.8\textwidth}
    \begin{itemize}
    \item Modern build automation software: \textbf{CMake}
    \item Split in two parts:
      \begin{itemize}
      \item \textbf{libmetal}: this library is the abstraction layer
        that is specific to the system where OpenAMP will run
      \item \textbf{libopen\_amp}: this one provides the API allowing to
        communicate between the different systems
      \end{itemize}
    \item Can be run as bare metal or as a library used by an RTOS or even Linux
    \end{itemize}
    \column{0.2\textwidth}
    \includegraphics[width=\textwidth]{openAMP_combox.pdf}
  \end{columns}
\end{frame}

\subsection{How Linux kernel communicates with external OS}

\begin{frame}{Linux kernel communication with other systems: \textbf{remoteproc}}
  \begin{columns}
    \column{0.8\textwidth}
    \begin{itemize}
    \item To communicate with the other core in an heterogeneous
      configuration, the Linux kernel provides a framework:
      \textbf{Remote Processor Framework} aka \textbf{remoteproc}
    \item This framework allows to control the remote processor: power on, load firmware, power off.
    \item It also allows to setup \textbf{virtio} devices with the remote processor
    \end{itemize}
    \column{0.2\textwidth}
    \includegraphics[width=\textwidth]{Tux.pdf}
  \end{columns}
\end{frame}

\begin{frame}{Linux kernel communication with other systems: \textbf{rpmsg}}
  \begin{columns}
    \column{0.8\textwidth}
    \begin{itemize}
    \item \textbf{rpmsg} is a \textbf{virtio}-based messaging bus that allowing
      communicating with remote processors
    \item \textbf{virtio} is a framework supporting virtualization and
      provides a transport layer based on a shared ring buffer: \textbf{vring}
    \item an \textbf{rpmsg device} is a \emph{communication channel} with a
      remote processor: \textbf{channel}
    \end{itemize}
    \column{0.2\textwidth}
    \includegraphics[width=\textwidth]{Tux.pdf}
  \end{columns}
\end{frame}

\begin{frame}{Firmware management by \textbf{remoteproc}}
  \begin{itemize}
  \item \textbf{remoteproc} being responsible of loading the firmware
    it expects a specific structure
  \item Currently ELF32 and ELF64
  \item \textbf{remoteproc} parses the firmware and loads the segments
    to memory according to the specified device address (might be a
    physical address)
    % if the remote processor is accessing memory directly
  \item Beside the standard ELF segments \textbf{remoteproc} also
    manages a special section: the \textbf{resource table}
  \item This section holds a C structure which contains:
    \begin{itemize}
    \item system resources required by the remote processor
      % such as allocation of physically contiguous memory, or iommu
      % mapping of certain on-chip peripherals.
    \item resources exposed by the remote processor: trace buffers and
      supported virtio devices
      % (and their configurations).
    \end{itemize}
  \end{itemize}
\end{frame}


% virtio + rpmsg schemas to add

\subsection{Adapting Linux kernel and OpenAMP\\ for Cortex A9}

\begin{frame}{ Design choice to support AMP on Cortex A9 }
  \begin{itemize}
  \item Shared memory
    \begin{itemize}
    \item A part of the main memory (DDR) used as shared memory
    \item No use of an SRAM: less dependent on a given SoC
    \end{itemize}
  \item Signalization
    \begin{itemize}
    \item Software interrupt used to signal the presence of a message
    \item Use \textbf{SGI} (Software Generated Interrupt) provided by
      the \textbf{GIC} (the interrupt controller provided by ARM and
      used with Cortex A9)
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{ Adding support to Open AMP: libraries }
  \begin{itemize}
  \item For \textbf{lib\_openamp}, nothing to do expect adding a
    platform cmake file to describe the toolchain option to use.
  \item For \textbf{libmetal}, a few more things, to add the support of
    the SoC (here i.MX6)
    \begin{itemize}
    \item Platform cmake file for the toolchain as done for the openAMP library
    \item Adding \code{sys.c} and \code{sys.h} files to mainly expose
      interrupt support
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{ Using \textbf{OpenAMP} in RTOS }
  \begin{itemize}
  \item For the RTOS project, \textbf{OpenAMP} is used to add the remote
    proc and rpmsg support:
    \begin{itemize}
    \item Create the \code{imx6_a9_rproc.c} file defining the
      platform specific remoteproc implementation. It provides the
      \code{remoteproc_ops} that defines notification operation and
      remote processor management operations. Actually not specific
      to i.MX6 and only to Cortex A9
    \item Create the \code{platform_info.[ch]} files responsible of
      initializing the libmetal, creating a remote proc instance and
      the associated rpmsg devices
    \item Create  the \code{rsc_table.[ch]} files that populate the
      resource table
    \item Add parameter support when registering an interrupt: needed
      for libmetal to use a generic \textbf{ISR} (interrupt service Routine)
    \end{itemize}
  \end{itemize}
\end{frame}


\begin{frame}{ Adding support to Linux: remoteproc driver }
  \begin{itemize}
  \item A \textbf{remoteproc} driver has to be added
  \item In probe function need to setup the GIC to use the
    \textbf{SGI} to receive the signal from the firmware that a
    specific virtqueue has pending messages available
  \item Also implement a \code{parse_fw} operation to prepare the
    shared memory
  \item Finally need to add \code{start} and \code{stop} operations
    \begin{itemize}
    \item \code{start} moves the \textbf{Cortex A9} core outside
      of the SMP group to run the firmware (here \textbf{FreeRTOS})
    \item \code{stop} moves back the \textbf{Cortex A9} core to SMP
      from AMP
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{ Adding support to Linux: SoC specific part }
  \begin{itemize}
  \item While most of the support only rely on \textbf{Cortex A9},
    some parts are SoC dependents
  \item \code{start} and \code{stop} operations uses generics
    functions to migrate core from or to the SMP group
  \item However the way to pass the entry point fo the firmware to the
    core is really SoC specific
  \item As well as the way to actually power up the core
  \item Those functions already exist but have to be made accessible
    outside of the \code{arch/arm/} directory
  \end{itemize}
\end{frame}

\subsection{Pros, Cons and alternatives}

\begin{frame}{ Drawbacks of this solution }
  \begin{itemize}
  \item Not a real \textbf{segregation} between Linux and the RTOS
  \item Nothing prevent the firmware to \textbf{access Linux memory} or to
    manage devices used by Linux kernel drivers
  \item The safety and security depend on the \textbf{design} of the solution
    \begin{itemize}
    \item System Devices Trees might be used to describe each partition
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{ Strength of this solution }
  \begin{itemize}
  \item Based on established and open projects: Linux kernel and
    \textbf{OpenAMP}
  \item Few modifications to do on the mainline projects and most of
    them should be merged
  \item Could be easily extended to any SoC using Cortex A9
  \item \textbf{OpenAMP} allows to continue using an existing coding
    base in an RTOS and in the same time using a standard way to
    interface with Linux.
  \end{itemize}
\end{frame}

\begin{frame}{ Alternative to \textbf{OpenAMP} to use a main core}
  \begin{itemize}
  \item \textbf{Jailhouse} is a partitioning Hypervisor based on Linux
    \begin{itemize}
    \item is able to run bare-metal applications or adapted RTOS
      besides Linux
    \item manages to do a \textbf{real segregation} between Linux and the RTOS
    \item relies on \textbf{virtualization extensions} that are not present on
      Cortex A9 but on more \textbf{recent ARMv7} (Cortex A7, Cortex A15, ...)
      and also on \textbf{ARMv8} (arm64)
    \end{itemize}
  \item Full task isolation
    \begin{itemize}
    \item Isolate a task from the rest of the OS: \textbf{won't be interrupted} at all by the kernel
    \item With userspace driver using UIO it is also possible to
      access the hardware without any system call
    \item However the solution is still \textbf{not merged}
    \end{itemize}
  \end{itemize}
\end{frame}

\questionslide

\end{document}
