% This work is licensed under the Creative Commons Attribution 4.0
% International License. To view a copy of this license, visit
% http://creativecommons.org/licenses/by/4.0/ or send a letter to
% Creative Commons, PO Box 1866, Mountain View, CA 94042, USA.

\documentclass{beamer}
\usetheme{Madrid}
\usepackage{hyperref}
\usepackage{verbatim}

\title{coreboot - the free firmware}
\author[Iru Cai]{Iru Cai \texttt{<vimacs.hacks@gmail.com>}}
%\institute[LCPU]{Linux Club of Peking University}
\date{Nov 23th, 2016}
\begin{document}

\begin{frame}
\titlepage
\end{frame}

\begin{frame}{License}
  This work is licensed under the Creative Commons Attribution 4.0
  International License. To view a copy of this license, visit
  \url{http://creativecommons.org/licenses/by/4.0/}.
\end{frame}

\begin{frame}{Index}
\tableofcontents[part=1]
\end{frame}

\part{1}

\begin{frame}[fragile]{What is coreboot?}
  coreboot is an extended firmware platform that delivers a lightning
  fast and secure boot experience on modern computers and embedded
  systems. As an Open Source project it provides auditability and
  maximum control over technology.

  \begin{itemize}
    \item Homepage: \url{https://www.coreboot.org}
    \item Mailing list: coreboot@coreboot.org
    \item IRC: \#coreboot at irc.freenode.net
    \item twitter: @coreboot\_org
  \end{itemize}
\end{frame}

\section{History}
\begin{frame}{History: from LinuxBIOS to coreboot}
  coreboot has a very long history, stretching back more than 15 years
  to when it was known as LinuxBIOS. While the project has gone
  through lots of changes over the years, many of the earliest
  developers still contribute today.
\end{frame}

\begin{frame}{LinuxBIOS v1: 1999-2000}
  The coreboot project originally started as LinuxBIOS in 1999 at Los
  Alamos National Labs (LANL) by Ron Minnich. Ron needed to boot a
  cluster made up of many x86 mainboards without the hassles that are
  part of the PC BIOS. The goal was to do minimal hardware
  initilization in order to boot Linux as fast as possible. Linux
  already had the drivers and support to initialize the majority of
  devices. Ron and a number of other key contributors from LANL, Linux
  NetworkX, and other open source firmware projects successfully
  booted Linux from flash. From there they were able to discover other
  nodes in the cluster, load a full kernel and user space, and start
  the clustering software.
\end{frame}

\begin{frame}{LinuxBIOS v2: 2000-2005}
  After the initial success of v1, the design was expanded to support
  more CPU architectures (x86, Alpha, PPC) and to support developers
  with increasingly diverse needs.

  One of the design goal is to have little assembly as possible.
  \begin{itemize}
  \item standard C cannot be used because C compiler requires memory
    for stack
  \item the new DDR memory controllers required significantly more
    configuration and a lot more ASM
  \item solution: ROMCC by Eric Biederman
  \end{itemize}

  LinuxBIOS device tree was introduced.

  Many target systems had flash that were too small to hold both the
  hardware initialization code and the Linux kernel. Payloads were
  created.
  \begin{itemize}
  \item modified etherboot for clusters
  \item FILO for disk-based boot
  \end{itemize}
\end{frame}

\begin{frame}{LinuxBIOS v2+: 2005-2008}
  Cache as RAM was introduced in 2005.

  Stefan Reinauer formed a company named coresystems GmbH to support
  LinuxBIOS. Stefan was one of the primary developers and co-leaders
  of LinuxBIOS with Ron Minnich. His significant contributions
  included the first AMD64 port, the original ACPI implementation, the
  original SMM implementation, the flashrom utility, and the FILO
  payload development and maintainer.

  In 2005, FSF started the Free BIOS campaign to support LinuxBIOS
  development. Ward Vandewege of FSF ported LinuxBIOS to the FSF
  servers and other mainboards.
\end{frame}

\begin{frame}{LinuxBIOS v3: 2006-2008}
  By 2006, LinuxBIOS had already supported hundreds of
  mainboards. With so many boards, there were problems with porting
  additional silicon and systems.

  \begin{itemize}
  \item Developers fixed and clarified many driver and bus support
    issues in the device tree.
  \item Kconfig
  \item firmware image archive called LAR (LinuxBIOS Archiver), which
    led to the more refined and flexible concept of CBFS
  \end{itemize}

  It wasn't the main development branch; it was essentially an R\&D
  branch, where the best ideas were backported to v2.
\end{frame}

\begin{frame}{2008: LinuxBIOS renamed coreboot}
  \url{https://www.coreboot.org/pipermail/coreboot/2008-January/029135.html}
  \begin{itemize}
  \item LinuxBIOS = (core boot code) + (Linux kernel)
  \item Linux was no longer booted directly from flash
  \end{itemize}
\end{frame}

\begin{frame}{coreboot v4}
  \begin{itemize}
  \item In early 2010, coreboot moved from SVN to Git
  \item during the transition, the community took the opportunity to
    recognize the advancements of the past 10 years and updated to
    version 4.0.
  \item contributions from AMD: AMD Generic Encapsulated Software
    Architecture (AGESA)
  \item Google Chromebook
  \item Intel FSP
  \item libreboot for ThinkPad T60
  \item
    \href{https://www.coreboot.org/pipermail/coreboot/2015-July/080120.html}{coreboot
      v4.1}
  \end{itemize}
\end{frame}

\begin{frame}{About libreboot}
  Some firmware components are non-free:
  \begin{itemize}
  \item Intel ME firmware/AMD PSP
  \item Intel FSP/closed source AGESA
  \item Option ROMs (including VGA BIOS)
  \item CPU microcode
  \item EC firmware
  \end{itemize}

  Libreboot is a coreboot distribution that removes proprietary
  components, including Intel ME, FSP, VGA BIOS, etc. On some laptops,
  the EC firmware is also free(Chromium EC in Chromebooks).
\end{frame}

\section{Why use coreboot}
\begin{frame}[fragile]{Why use coreboot}

  You can see the advantages of coreboot at:
  \url{https://www.coreboot.org/users.html}

  \begin{itemize}
  \item coreboot is free software (see
    \href{https://www.fsf.org/campaigns/priority-projects/priority-projects/highpriorityprojects#Coreboot}{FSF
      Free BIOS Campaign})
  \item fast boot times
  \item it's flexible
  \end{itemize}
\end{frame}

\begin{frame}{Fun stuff on BIOS}
  \begin{itemize}
  \item \url{https://www.coreboot.org/Fun_Stuff}
  \end{itemize}
\end{frame}

\section{How coreboot works}
\begin{frame}{How coreboot works}
%On Intel x86 architecture, the first instruction is at 0xFFFFFFF0.
%src/cpu/x86/16bit/reset16.inc
%_start16bit(entry16.inc): enter protected mode
%__protected_start(entry32.inc)
  %src/arch/x86/bootblock_romcc.S

  We'll take lenovo/x230 as example to see how a machine boots with
  coreboot.

  We can build coreboot with ``\texttt{make V=1 > build.log}`` to see which
  files are used to build coreboot for this mainboard.
\end{frame}

\begin{frame}{coreboot stages}
  The coreboot firmware runs in several stages.
  \begin{itemize}
  \item bootblock: the earliest code that the CPU runs
  \item romstage: before main memory is ready, only the code in the
    flash can be run, and no other memory can be used
  \item ramstage: after main memory can be used, the ramstage code is
    uncompressed in memory, and do the remaining initialization
  \item payload: OS or OS loader
  \end{itemize}
\end{frame}

\begin{frame}{bootblock}
  When the machine starts, PC poionts at reset vector (f000:fff0), the
  CPU runs the bootblock code.

  The bootblock code is in src/arch/x86/bootblock\_romcc.S, which
  includes:
  \begin{itemize}
    \item src/cpu/x86/16bit/reset16.inc: the code at reset vector
    \item src/cpu/x86/16bit/entry16.inc: the 16-bit code that sets CPU to protected mode
    \item src/cpu/x86/32bit/entry32.inc: sets segment registers
    \item generated/bootblock.inc: generated from src/arch/x86/bootblock\_simple.c with ROMCC
  \end{itemize}

  bootblock\_simple.c then runs romstage.
\end{frame}

\begin{frame}{romstage}
  romstage starts at src/arch/x86/assembly\_entry.S, which includes:
  \begin{itemize}
    \item src/cpu/x86/32bit/entry32.inc: loads GDT and sets segment registers
    \item generated/assembly.inc: generated from
      src/cpu/intel/model\_206ax/cache\_as\_ram.inc, which sets up CAR
      and runs the init code in romstage by calling ramstage\_main(),
      then runs ramstage by calling romstage\_after\_car() which calls
      run\_ramstage().
  \end{itemize}

  ramstage\_main() is in src/cpu/intel/car/romstage.c, it calls
  mainboard\_romstage\_entry() in
  src/northbridge/intel/sandybridge/romstage.c, which does the DRAM
  initialization.
\end{frame}

\begin{frame}{ramstage}
  ramstage starts at src/arch/x86/c\_start.S, it calls the ``main``
  function in src/lib/hardwaremain.c.

  There are 12 boot states defined in source code. Functions for each
  state are run in ramstage. At last payload is loaded and run.
\end{frame}

\begin{frame}{Payloads}
  There are many coreboot payloads:
  \begin{itemize}
  \item SeaBIOS: a PC BIOS implementation
  \item GRUB2
  \item Linux kernel
  \item Tianocore: a UEFI implementation by Intel
  \item depthcharge: a bootloader written by Google for Chromebooks
  \item u-boot
  \end{itemize}

  Some useful tools can also be payloads:
  \begin{itemize}
  \item nvramcui: a tool to edit CMOS
  \item coreinfo: system information
  \item memtest86+
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{Supported OSes}
  coreboot supports many operating systems:
  \begin{itemize}
  \item Linux: boots via GRUB2,SeaBIOS, or using Linux kernel as
    payload
  \item OpenBSD: boots via SeaBIOS with VGA option ROM. Now it
    supports UEFI and don't need VGA BIOS, so it now supports
    libreboot. See
    \href{https://lists.nongnu.org/archive/html/libreboot/2016-04/msg00010.html}{libreboot
      mailing list}.
  \item Windows: boots via SeaBIOS with VGA option ROM. Windows 8
    should be able to boot with Tianocore without VGA BIOS.
  \end{itemize}
\end{frame}

\section{Building and using coreboot}
\begin{frame}[fragile]{Building coreboot and run on QEMU}

  \url{https://www.coreboot.org/Lesson1} is a good place to start.

  \begin{block}{Build a cross toolchain for building coreboot}
    make crossgcc or \verb|make crossgcc-<arch>|
  \end{block}

  \begin{block}{Generate a configuration}
    make nconfig
  \end{block}

  At last do a ``make`` to build it, the built firmware is at
  build/coreboot.rom.

  \begin{block}{Run coreboot on QEMU}
    qemu-system-i386 -bios build/coreboot.rom
  \end{block}
\end{frame}

\section{Flashing}
\begin{frame}{Hardware flashing}
  To use coreboot on real machines, we need to know how to flash
  externally with a hardware flash programmer.
  \begin{itemize}
  \item Most of the mainboards can only be flashed externally with
    factory firmware running.
  \item We need to flash externally to unbrick a machine.
  \end{itemize}

  We need a programmer and a connector to connect the flash.
\end{frame}

\begin{frame}{Tools to flash a chip}
  A lot of mainboards use SPI NOR flash, most of them are in SOIC-8
  package.

  To program SPI NOR flash, we can use one of the following tools:
  \begin{itemize}
  \item Using Linux SPI: Raspberry Pi, Beaglebone
  \item Micro controllers: Arduino, Bus Pirate, STM32
  \item Programmers: ch341a, dediprog
  \end{itemize}

  To connect with SOIC-8 or SOIC-16 flash chips, we can use a clip.
\end{frame}

\begin{frame}[fragile]{Flash with flashrom}
  We can use flashrom to flash the chips.

  \begin{block}{command line}
    \verb|flashrom -p <programmer> [-r <file>] [-w <file>]|
  \end{block}

  \begin{block}{For Linux SPI}
    \verb|flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=1024|
  \end{block}

  \begin{block}{For ch341a}
    \verb|flashrom -p ch341a_spi|
  \end{block}

\end{frame}

\begin{frame}[fragile]{Internal flashing with flashrom}
  Many boards can be flashed internally with coreboot flashed.

  \begin{block}{internal flashing}
    \verb|flashrom -p internal:laptop=force_I_want_a_brick|
  \end{block}

  We can also use a layout file to flash part of the ROM.
  \begin{block}{flashing with layout}
\begin{verbatim}
flashrom -p <prog> --layout layout.txt \
  --image bios -w <file>
\end{verbatim}
  \end{block}
\end{frame}

\section{Utilities and Debugging}
\begin{frame}{Utilities and Debugging}
  To work with coreboot, we have many tools to use:
  \begin{itemize}
  \item nvramtool: dump CMOS contents, display and modify CMOS settings
  \item cbmem: display coreboot table and logs
  \item ectool: read and write EC memory, sometimes useful
  \item autoport: generate the code for a board you want to port,
    usually needs further changes
  \end{itemize}

  To debug coreboot, we can read the cbmem console in a working
  system. We can also use a EHCI debug dongle.
  \begin{itemize}
  \item Net20DC is an expensive device, and its company is bankrupt.
  \item We can use a development board with OTG port, e.g. BeagleBone,
    Cubieboard
  \end{itemize}

  For systems with serial output, we can also do the debugging with
  it.
\end{frame}

\section{Join the community}

\begin{frame}{The coreboot community}
  You can visit ``Community and infrastructure`` section of
  \url{https://www.coreboot.org/developers.html} to get an overview of
  coreboot community.

  Some advice:
  \begin{itemize}
    \item Learn to use mailing list and IRC.
    \item \href{http://catb.org/~esr/faqs/smart-questions.html}{Ask
      Questions The Smart Way}
  \end{itemize}
\end{frame}

\begin{frame}{Reporting bugs and Writing documents}
  \begin{itemize}
  \item To join the community, learn to use mailing list and IRC.
  \item There's a bug tracking system: \url{http://ticket.coreboot.org/}
  \item We can apply for a wiki account and write coreboot wiki.
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{I want to write some code}
  Gerrit code review is the project management system for coreboot.

  To push code to gerrit, you can manually set up the scripts, or just
  run \verb|make gitconfig|.

  Using gerrit is easy:
  \begin{itemize}
  \item To push code: \verb|git push origin HEAD:refs/for/master|
  \item We can add a topic: \verb|HEAD:refs/for/master%topic=some_topic|
  \item To push a draft: \verb|HEAD:refs/drafts/master|
  \end{itemize}

  I recommend working in a new git branch instead of master.
\end{frame}

\begin{frame}{Google Summer of Code}

  coreboot has been a GSoC mentoring organization for many years. We
  can read the project reports at \url{https://blogs.coreboot.org}.

  \begin{itemize}
  \item GSoC 2016 projects:
    \begin{itemize}
      \item better RISC-V support
      \item serialICE
      \item flashrom
    \end{itemize}

  \item GSoC 2015 projects:
    \begin{itemize}
      \item H8S Embedded Controller
      \item coreboot for AArch64 QEMU
      \item end user flash tool
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{The status of coreboot}

  The current development of coreboot focuses on:
  \begin{itemize}
    \item improvement on old platforms
    \item utilities and payloads
    \item Google Chromebooks and related chips
    \item new architectures: RISC-V, POWER8, etc.
  \end{itemize}

\end{frame}

\section{References}
\begin{frame}{References}
  \begin{itemize}
  \item coreboot history: Embedded Firmware Solutions, by Jiming Sun,
    Vincent Zimmer, Marc Jones, and Stefan Reinauer
  \item libreboot: \url{https://libreboot.org/faq/}
  \end{itemize}
\end{frame}

\begin{comment}
\part{2}
\section{[OT] Choosing hardware friendly to free software}
\begin{frame}{Hardware choosing(Machines)}
  \begin{block}{Laptops}
    \begin{itemize}
    \item laptops with libreboot supported, e.g. Lenovo X200
    \item Intel platforms up to Ivy Bridge supports coreboot without
      FSP, and there's no boot guard.
    \end{itemize}
  \end{block}

  \begin{block}{Development boards}
    \begin{itemize}
    \item Raspberry Pi is very popular, but it's not so open.
    \item Allwinner is not so friendly to free software community, but
      Allwinner chips has good community support.
    \item Beaglebone Black seems popular in coreboot and libreboot
      community.
    \end{itemize}
  \end{block}
\end{frame}

\begin{frame}{Hardware choosing(wifi cards and GPU)}
  \begin{block}{wifi cards}
    \begin{itemize}
    \item Atheros 802.11n chips have free driver and do not need
      proprietary firmware.
    \item AR9382 is very cheap (down to 20 CNY on taobao), with
      excellent dual-band 300M performance.
    \item Broadcom sucks, so is Realtek.
    \item Chips from Intel,TI,etc. need proprietary firmware.
    \end{itemize}
  \end{block}

  \begin{block}{GPUs}
    Many GPUs needs proprietary firmware blobs. There are some GPUs
    that Linux-libre can use:
    \begin{itemize}
    \item Intel Graphics before Skylake
    \item NVIDIA chips up to Kepler with nouveau driver
    \item embedded GPUs: freedreno, etnaviv, etc.
    \end{itemize}
  \end{block}
\end{frame}
\end{comment}

\end{document}