path: root/coreboot-talk.tex

% 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}
\usepackage{newverbs}
\newverbcommand{\vcmd}
  {\begin{lrbox}{\verbbox}}
  {\end{lrbox}\colorbox{gray!30}{\box\verbbox}}

\title{coreboot - the free firmware}
\author[vimacs]{vimacs \texttt{<https://vimacs.lcpu.club>}}
\institute[LCPU]{Linux Club of Peking University}
\date{May 19th, 2018}
\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/}. \\~\\

  You can find the source code of this presentation at:
  \url{https://git.wehack.space/coreboot-talk/}
\end{frame}

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

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

\part{1}

\section{What is coreboot?}

\frame{\tableofcontents[currentsection]}

\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.

  \textbf{The word 'coreboot' should always be written in lowercase,
    even at the start of a sentence.}
\end{frame}

\subsection{History}

\begin{frame}{History: from LinuxBIOS to coreboot}
  coreboot has a very long history, stretching back more than 18 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}

\subsection{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}{libreboot and firmware freedom}
  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}

\begin{frame}[fragile]{me\underline{\space}cleaner}
  ME firmware can be neutralized:
  \begin{itemize}
  \item ME firmware partitions are individually signed, we can remove
    all the partitions except FTPR.
  \item In each partition, the manifests of the modules are signed,
    but the modules are only checked before being executed, so the
    modules that don't need to be executed can be removed.
  \item HAP/MeAltDisable bit in the flash descriptor can be used to
    disable Intel ME.
  \end{itemize}

  For more information, read the me\underline{\space}cleaner wiki at
  \url{https://github.com/corna/me_cleaner/wiki/How-does-it-work%3F}.
\end{frame}

\begin{frame}{LinuxBoot}
  LinuxBoot (\url{https://www.linuxboot.org}) is a firmware for modern
  servers that replaces specific firmware functionality like the UEFI
  DXE phase with a Linux kernel and runtime.

  \begin{figure}[htbp]
    \centering
    \includegraphics[scale=0.5]{images/pi.png}
  \end{figure}
\end{frame}

\begin{frame}{UEFI v.s. NERF}
  NERF is LinuxBoot with u-root as the initramfs. u-root contains boot
  policy tools in Go (e.g. PXE booting, booting via GRUB config) among
  standard busybox-like utilities rewritten in Go.

  \begin{itemize}
  \item UEFI = Unified Extensible Firmware Interface
  \item NERF = Non-Extensible Reduced Firmware
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{Fun stuff, and more}
  \begin{itemize}
  \item Fun stuff: \url{https://www.coreboot.org/Fun_Stuff}
  \item BIOS malware: \url{https://news.ycombinator.com/item?id=10039870}
  \item \vcmd|rm -rf /sys/firmware/efi/efivars| can brick a system
  \item SMM Vulnerabilities in firmware
  \end{itemize}
\end{frame}

\section{How coreboot works}

\frame{\tableofcontents[currentsection]}

\begin{frame}[fragile]{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 \vcmd|make V=1 > build.log| to see which
  files are used to build coreboot for this mainboard.

  All the source code is in the \vcmd|src/| directory, we'll omit it
  in the following slides.
\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}[fragile]{bootblock}
  When the machine starts, PC poionts at reset vector (f000:fff0), the
  CPU runs the bootblock code.

  The bootblock code is in \vcmd|arch/x86/bootblock_romcc.S|,
  which includes:
  \begin{itemize}
    \item cpu/x86/16bit/reset16.inc: the code at reset vector
    \item cpu/x86/16bit/entry16.inc: the 16-bit code that sets CPU to protected mode
    \item cpu/x86/32bit/entry32.inc: sets segment registers
    \item generated/bootblock.inc: generated by ROMCC from
      \vcmd|arch/x86/bootblock_simple.c|, which then runs romstage
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{romstage}
  romstage starts at \vcmd|arch/x86/assembly_entry.S|, which includes:
  \begin{itemize}
    \item cpu/x86/32bit/entry32.inc: loads GDT and sets segment registers
    \item generated/assembly.inc: generated from
      cpu/intel/model\_206ax/cache\_as\_ram.inc, which:
      \begin{itemize}
      \item sets up CAR
      \item calls \vcmd|romstage_main()|, which runs the init code in
        romstage
      \item disable CAR
      \item calls \vcmd|romstage_after_car()|, which calls
        \vcmd|run_ramstage()| to run ramstage
      \end{itemize}
  \end{itemize}

  \vcmd|romstage_main()| is in cpu/intel/car/romstage.c, it calls
  \vcmd|mainboard_romstage_entry()| in
  northbridge/intel/sandybridge/romstage.c, which does the DRAM
  initialization.
\end{frame}

\begin{frame}[fragile]{ramstage}
  ramstage starts at \vcmd|src/arch/x86/c_start.S|, it calls the
  \vcmd|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}{Full disk encryption with LUKS}
  When using coreboot, we can use GRUB or a Linux kernel based OS as
  payload. Therefore, we can do a full disk encryption with LUKS.
\end{frame}

\begin{frame}[fragile]{Linux kernel as payload}
  We can first run a Linux kernel, then using \vcmd|kexec| to run the
  kernel on disk.
  \begin{itemize}
  \item Petitboot: a bootloader designed to run in a Linux environment
    for OPAL on PowerPC/POWER machines and the Playstation 3
  \item Heads: \url{https://github.com/osresearch/heads}
  \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 and Tianocore
  \end{itemize}
\end{frame}

\section{Building and using coreboot}

\frame{\tableofcontents[currentsection]}

\subsection{Building}

\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}
    \vcmd|make crossgcc| or \vcmd|make crossgcc-<arch>|
  \end{block}

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

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

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

\subsection{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}
    \vcmd|flashrom -p <programmer> [-r <file>] [-w <file>]|
  \end{block}

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

  \begin{block}{For ch341a}
    \vcmd|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}
    \vcmd|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}

\frame{\tableofcontents[currentsection]}

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

\begin{frame}{ACPI debug}
  \begin{itemize}
  \item Linux ACPI debugging: Documentation/acpi/debug.txt in Linux
    source code
  \item Linux ACPI table updating:
    \url{https://wiki.archlinux.org/index.php/DSDT\#Using_a_CPIO_archive}
  \end{itemize}
\end{frame}

\section{Join the community}

\frame{\tableofcontents[currentsection]}

\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}[fragile]{Community resources}
  \begin{itemize}
  \item Homepage and wiki: \url{https://www.coreboot.org}
    \begin{itemize}
    \item We can apply for a wiki account and write coreboot wiki.
    \end{itemize}
  \item Mailing list: coreboot@coreboot.org
  \item IRC: \verb|#coreboot| at irc.freenode.net
  \item Mattermost (bridged to IRC): \url{https://chat.coreboot.org}
  \item bug tracking system: \url{https://ticket.coreboot.org/}
  \item twitter: \verb|@coreboot_org|
  \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 \vcmd|make gitconfig|.

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

  If you've modified your code, just amend it, and push again.

  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, and porting coreboot
	    to boards with this platforms
    \item utilities and payloads
    \item Google Chromebooks and related chips
    \item new architectures: RISC-V, POWER8, etc.
  \end{itemize}

\end{frame}

\part{2}

\section{Porting coreboot with autoport}

\frame{\tableofcontents[currentsection]}

\begin{frame}{Porting coreboot with autoport}
  In this section, I'll show how I ported coreboot to Sandy/Ivy Bridge
  laptops and mainboards with autoport.
\end{frame}

\begin{frame}{Chips on a mainboard}
  coreboot needs to initialize these chips.

  \begin{itemize}
  \item CPU
  \item northbridge: RAM init and graphics init
  \item southbridge: PCI, USB, SATA, LPC, GPIO
  \item \href{https://en.wikipedia.org/wiki/Super_I/O}{super I/O}
  \item \href{https://www.coreboot.org/Embedded_controller}{embedded controller}
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{Code for a mainboard}
  You can see what is needed for a mainboard in the directory for this
  mainboard.

  \begin{itemize}
  \item Kconfig: specifies what chips and drivers are used
  \item romstage.c: romstage code, including early southbridge init
    and reading DRAM SPD data
  \item devicetree.cb, mainboard.c: mainboard specific data
  \item gpio.c: GPIO config
  \item acpi/, dsdt.asl, acpi\_tables.c, smihandler.c: ACPI and SMM
    code, some of the code is EC related
  \item cmos.layout, cmos.default
  \end{itemize}
\end{frame}

\begin{frame}{Using autoport}
  autoport is a tool to generate coreboot code for Sandy/Ivy Bridge
  boards.

  It uses inteltool to read the northbridge and southbridge registers.

  Manual fixes (see util/autoport/readme.md):
  \begin{itemize}
  \item where to read SPD data
  \item what is the EHCI debug port
  \item flash chip size
  \item EC and super I/O support!
  \end{itemize}
\end{frame}

\begin{frame}{Tools to work with the OEM firmware}
  Sometimes, we need to know how the OEM firmware works, and implement
  it in coreboot. These tools can help:

  \begin{itemize}
  \item UEFITool (\url{https://github.com/LongSoft/UEFITool}): a tool
    to view, extract and replace the modules in a UEFI firmware
  \item radare2 (\url{https://github.com/radare/radare2}): a reverse
    engineering framework, hex editor, and binary analysis tool
  \end{itemize}
\end{frame}

\subsection{ASRock B75 Pro3-M}

\begin{frame}{ASRock B75 Pro3-M}
  ASRock B75 Pro3-M is a desktop board. Porting coreboot to a desktop
  board is easier than to a laptop:
  \begin{itemize}
  \item Most desktop boards don't have an EC.
  \item Most desktop boards have a serial port at Super I/O, which is
    easier to use than an EHCI debug port.
  \item The flash chips on desktop boards are usually socketed.
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{B75 Pro3-M: Super I/O}
  Just run autoport in GNU/Linux running on this board, and get the
  generated source code.

  B75 Pro3-M uses Nuvoton NCT6776 as Super I/O, which is also used by
  asrock/g41c-gs, so copy the Super I/O related things. If possible,
  see the superiotool output for details.
  \begin{itemize}
  \item Kconfig
  \item devicetree.cb
  \item \vcmd|mainboard_config_superio| in romstage.c
  \end{itemize}
\end{frame}

\begin{frame}{B75 Pro3-M: Hanging on boot, how to solve it?}
  I got the debug output from the serial port, and saw the system
  hanging when configuring PCIe devices.

  I disabled the ASMedia SATA controller in devicetree.cb, and the
  system can boot. Patrick Rudolph saw from the boot log that the
  system stopped after enabling ASPM of the ASMedia SATA controller,
  thinking that the ASPM of that device should be disabled.
  \begin{itemize}
  \item Using ASPM override worked at the time I ported coreboot to
    this board.
  \item Now it uses the ASPM blacklist driver.
  \end{itemize}

  The port of B75 Pro3-M was merged on Aug,
  2017. (\url{https://review.coreboot.org/20227/})
\end{frame}

\subsection{Sandy/Ivy Bridge HP Elitebooks}

\begin{frame}{HP Elitebook 2760p}
  I ported coreboot to HP Elitebooks and succeeded last year. In this
  talk, I'll talk about how I ported coreboot to HP Elitebook 2760p
  (\url{https://review.coreboot.org/18241/}):
  \begin{itemize}
  \item The flash chip is \textbf{socketed}, and is very easy to swap!
  \item Sandy Bridge platform, use autoport to generate the code
  \end{itemize}
\end{frame}

\begin{frame}{I could not power on the machine}
  At first, I built the ROM with the generated code and flashed
  it. However, the power LED of the laptop just blinked and I could
  not power on the laptop.

  Let's look at what an embedded controller does:
  \begin{itemize}
  \item controlling the keyboard, touchpad, buttons and switches
  \item turning the computer on and off
  \item thermal management
  \item battery management
  \item \ldots
  \end{itemize}

  I guess the EC needs to read something from the flash chip to make
  it work, maybe it's the EC firmware.
\end{frame}

\begin{frame}[fragile]{First attempt: Using UEFITool}
  EC firmware is not UEFI modules, so I'll look into the place where
  no UEFI modules are stored, for example, paddings.

  \begin{figure}[htbp]
    \centering
    \includegraphics[scale=0.6]{images/uefitool-extract.jpg}
  \end{figure}
\end{frame}

\begin{frame}[fragile]{EC firmware in the flash chip}
  Using \vcmd|strings|, I can find some interesting things.

  \begin{figure}[htbp]
    \centering
    \includegraphics[scale=0.5]{images/hp_ec.jpg}
  \end{figure}

  Now I can figure out the EC is based on 8051.
\end{frame}

\begin{frame}[fragile]{Editing binary file using radare2}
  I use radare2 to edit binary file. Running \vcmd|r2 -n -w bios.rom|
  to open a binary file for editing. Remember to make a copy of the
  file for backup.

  \begin{itemize}
  \item \vcmd|s addr|: seek to \textit{addr}
  \item \vcmd|s $s-16|: seek to 16 bytes to the end of the file,
    \vcmd|$s| means the file size
  \item \vcmd|wx deadbeef|: write 4 bytes 0xde, 0xad, 0xbe, 0xef to
    the seek offset
  \item \vcmd|wx deadbeef @ addr|: write 4 bytes 0xde, 0xad, 0xbe,
    0xef to \textit{addr}
  \item \vcmd|w0 10|: write 10 zero bytes to the seek offset
  \item \vcmd|wr 10 @ $s-0x100|: write 10 random bytes to 256 bytes to
    the end of the file
  \end{itemize}
\end{frame}

\begin{frame}{Testing where the EC reads in the flash chip}
  Now I use radare2 to write random bytes or zero bytes to the flash
  regions that I think may contain the things the EC needs to read. At
  last, I found two essential regions.
  \begin{itemize}
  \item a $\mathtt{\sim}$64K region starting at 0x780000
  \item a $\mathtt{\sim}$0xa00 region starting at 0x7ff700
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{More observations}
  \begin{figure}[htbp]
    \centering
    \includegraphics[scale=0.6]{images/hp_ec_blobs.png}
  \end{figure}

  Looking at the blobs, it looks like that the first two bytes are the
  sizes of the blobs.

  After changing some bytes in the blobs, the laptop could not power
  on. However, I could enlarge the blob size and append zero bytes.

  At last, I found the next two bytes are checksum bytes, and the
  checksum is SYSV checksum. Another finding is that, the 8 bytes at
  \vcmd|$s-0x100| store the position of the two blobs.
\end{frame}

\begin{frame}{Keyboard}
  After adding the blobs, the laptop boots! However, thek eyboard
  doesn't work, which means the keyboard controller is not
  initialized.
  \begin{itemize}
  \item It uses SMSC KBC1126 which provides EC, super I/O, and KBC
  \item I found an SMSC KBC1122 datasheet
  \item Also I found src/superio/smsc/kbc1100/, so the keyboard works
    finally
  \end{itemize}

  How to use existing drivers:
  \begin{itemize}
  \item Add it to Kconfig
  \item Check other boards that use this driver and learn from it
  \end{itemize}
\end{frame}

\begin{frame}{Fan control}
  The laptop fan always runs on full speed, because EC is not
  initialized properly.

  I didn't find anything about the fan control of this EC, so at last
  I chose to reverse engineering it.

  Using UEFITool, I found a module called EcThermalInit.

  \begin{figure}[htbp]
    \centering
    \includegraphics[scale=0.9]{images/ecthermal.png}
  \end{figure}
\end{frame}

\begin{frame}{Analyzing on this module}
  I found there's a protection in the factory firmware, which makes
  the laptop fail to boot if I remove or modify a UEFI module in the
  DXE core. But it's easy to remove the protection.

  After that, I try to \textbf{remove} and \textbf{modify} the driver,
  to see what code is responsible for the fan control of the laptop.
\end{frame}

\begin{frame}{Reverse engineering with radare2}
  \begin{figure}[htbp]
    \centering
    \includegraphics{images/ecthermal-re.jpg}
  \end{figure}
\end{frame}

\begin{frame}{ACPI}
  I need to implement the ACPI support to support:
  \begin{itemize}
  \item battery status
  \item lid switch handling
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{How an OS initializes the ACPI support}
  In \vcmd|drivers/acpi/acpica/hwacpi.c| of the kernel source code, a
  function called \vcmd|acpi_hw_set_mode| sets ACPI on or off by
  writing a byte called \textit{acpi\_enable} or \textit{acpi\_disable}
  to the SMI command port to trigger an SMI.

  So we have to reverse the SMM modules in the firmware to see what it
  does to enable or disable ACPI.
\end{frame}

\begin{frame}[fragile]{ACPI in HP Elitebooks}
  Fortunately, I found a bit called \vcmd|ACPI| in EC RAM in the
  vendor DSDT, and this bit is set during a system wake up from sleep.

  Using ectool to set this bit, ACPI worked as expected.

  At last, I wrote the ACPI code according to the vendor DSDT, then
  the AC and battery status in HP Elitebooks running coreboot can be
  shown in the OS.
\end{frame}

\subsection{Dell Latitude E6230}

\begin{frame}{Dell Latitude E6230}
  Dell Latitude is another series of business laptops, so I'm also
  interested in porting coreboot to it. A friend of mine gave me a
  E6230, then I used autoport to generate the coreboot code for it.

  \begin{itemize}
  \item EC and Super I/O: MEC5055+ECE5048, I can't find anything about them
  \item Two flash chips: 8M+4M, the 4M one stores the high address part
  \item The 8M flash chip cannot be accessed via ISP
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{What to do when I can't do an ISP}
  I desoldered the 8M flash chip with hot air, and I read its
  content. Then I move all the BIOS region to the 8M chip:
  \begin{itemize}
  \item Use \vcmd|me_cleaner| to shrink the ME firmware, and modify
    the IFD with \vcmd|ifdtool|, so that all the things are in the
    lower 8M.
  \item Solder wires to a socket, so I can easily access and replace
    the chip.
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{Soldering the wires}
  \begin{figure}[htbp]
    \centering
    \includegraphics[scale=0.2]{images/e6230-wires.jpg}
  \end{figure}
\end{frame}

\begin{frame}[fragile]{How to shut down with several instructions?}
  When I was modifying the firmware, I wanted to see if the code in
  some place was run. I wrote some instructions at that place, so that
  the system will shut down if those instructions are executed.

  For Intel systems, there are some PM ports handled by Intel PCH. I
  can shutdown the machine using 3 instructions:

\begin{verbatim}
  mov eax, 0x3c00
  mov dx, PMBASE+4
  out dx, eax
\end{verbatim}

PMBASE can be read from a running machine in PCI configuration space
of 00:1f.0 offset 0x40. You can also disassemble the vendor
firmware. It's usually configured in bootblock or PEI phase.
\end{frame}

\begin{frame}{Making coreboot work on Dell Latitude E6230}
  Using the code generated by autoport, Dell Latitude E6230 can boot
  to OS. However, the system will shutdown in one minute after power
  on.

  Using UEFITool, I found a PEI module called PeiEcIoDriver, removing
  which will cause the laptop shutdown shortly after powering on the
  laptop.
\end{frame}

\begin{frame}[fragile]
  Reversing this module is easy, but after using the EC initialization
  code in coreboot, the laptop will still shutdown.
  \begin{itemize}
  \item The code uses port 0x910 and 0x911, but they're not in the
    decode range when running the generated coreboot code.
  \item The OEM firmware sets the decode range in bootblock, and
    overrides it later, so I can't find this in the running system.
  \item Solution: set the decode range in \vcmd|pch_enable_lpc| in
    romstage.c
  \end{itemize}
\end{frame}

\begin{frame}{Still work in progress}
  You can see the code on gerrit:
  \url{https://review.coreboot.org/22693/}
\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/}
  \item LinuxBoot FAQ: \url{https://www.linuxboot.org/page/faq/}
  \end{itemize}
\end{frame}

\part{3}
\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{document}