scripts/newbitmaps/README

This directory contains the sources for the new-style BIOS bitmaps, and a
simple (and ugly) tool to view the configuration file that describes how
each screen is displayed.

Note:

Due to continuing improvements and tweaks, there have been several different
formats used for the BIOS bitmaps.

Because the bitmap images and display code is part of the Read-Only BIOS,
back-porting any new bitmaps to older devices is not possible.


Old-style, unversioned bitmaps. Used in Mario / Cr-48.

In the Cr-48 BIOS there are four BIOS screens that may be presented to the
user. Each contains a graphic, a URL, and some informative text. The screens
are single bitmap images, hardcoded in read-only BIOS (because they have to
display even when the R/W BIOS and SSD are both completely erased). They can
be replaced at manufacturing time, but creating the screens is difficult.
The format is a compressed EFI firmware volume that is generated when the
BIOS is compiled. The result is an opaque blob that cannot be viewed or
edited with linux-based tools.


Version 1.0, new-style bitmaps. Used in Alex / Samsung Series 5.

The BIOS continues to display the same basic screens, but it uses a
different format internally (which we call the bmpblock). Each screen has
separate bitmaps for the basic graphic, the URL, and the informative text,
and the screen is displayed by rendering each component in order. This
allows us to modify and replace any bitmap (most frequently the HWID), using
standard command-line linux tools such as imagemagick. Compositing each
screen in this way also means that we can easily provide localized BIOS
screens or custom messages. The BIOS rotates through the localizations by
pressing the arrow keys when any screen is displayed.


Version 1.1. Used in ZGB / Acer AC700.

This is essentially the same as version 1.0, except that the ASCII HWID
string can be rendered directly by the BIOS instead of as a bitmap. In the
screen description, the magic image name "$HWID" (or "$HWID.rtol" for a
right-justified placement) indicates that the ASCII HWID value should be
displayed at the given coordinates instead of a bitmap image. This means
that we only need to generate one bmpblock for all locales, since the ASCII
HWID string can be changed at the factory using "gbb_utility". The
last-displayed locale is stored in nvram, so it's sticky across reboots. The
factory process sets the default locale to the appropriate region.


Version 1.2. Used by any BIOS that uses "vboot_api.h" (ARM, Stumpy, etc.)

The "vboot wrapper" is a refactoring of the vboot_reference library to
isolate our verified boot stuff from the underlying BIOS. Among other
things, it places the burden of displaying the ASCII HWID value on the
vboot_reference library, which means the bmpblock must contain a "font" to
translate the ASCII characters in the HWID into graphical images. The yaml
file must now specify a font file for the $HWID (and $HWID.rtol, if used)
image name. For example:

  bmpblock: 1.2
  images:
    $HWID: font.bin            # THIS IS NOW REQUIRED WHEN USING $HWID
  screens:
    scr_0_0:
     - [ 0, 0, $HWID]
  localizations:
    - [ scr_0_0, scr_0_0, scr_0_0, scr_0_0 ]
  locale_index:
    en

The old v1.1 bmpblock will be accepted by the vboot wrapper, but a $HWID
screen without a corresponding font should be silently ignored.


Version 2.0. Used by BIOS with complex composition (Kiev, Link, Snow, etc.)

The max number of components in one screen has increased from 8 to 16, makes
bitmap block structure incompatible with previous versions.



--------------------------------------------
Instructions for manually rebuilding things:


We do most of the image manipulation using ImageMagick, which is much easier
and simpler to do OUTSIDE of the chroot. So the first step is to just build
vboot_reference outside of the chroot.

  cd src/platform/vboot_reference
  make

You'll probably need to install several additional packages to make this
work. On Ubuntu you may find you need libtspi-dev, uuid-dev, and
imagemagick. If you want to use scripts/newbitmaps/bitmap_viewer, you may
need python-yaml and python-wxgtk2.8.


Once you've built vboot_reference you'll find the executables in
./build/utility/ (and ./build/cgpt/cgpt, if you want it). Put these
somewhere in your $PATH.

Now you should be able to just run "make" and everything will be
regenerated:

  cd scripts/newbitmaps
  make

This should generate both x86 and ARM versions of the BIOS bmpblock file,
although ARM may not be 100% correct just yet.


You can use the gbb_utility to modify your BIOS to contain this new set of
bitmaps:

  gbb_utility -s -b PATH/TO/YOUR/bmpblock.bin OLDBIOS.bin NEWBIOS.bin



You can do that last step on the chromebook device itself, provided that the
BIOS write-protection is disabled. gbb_utility should be in the rootfs:

  Become root:

    sudo bash

  Copy your new bmpblock over:

    cd /mnt/stateful_partition
    scp USER@SOMEHOST:/SOMEPATH/bmpblock.bin .

  Get a copy of the current BIOS:

    flashrom -p internal:bus=spi -r bios.bin

  Put the new bmpblock in the copy of the BIOS:

    gbb_utility -s -b bmpblock.bin bios.bin

  Reflash the BIOS with the new content

    flashrom -p internal:bus=spi -w bios.bin

  Reboot. You should see your new bitmaps appear whenever the BIOS screens
  are displayed. If you have more than one localization, you should be able
  to cycle among them with the arrow keys.


If you want to examine a binary bmpblock that you've pulled from a BIOS
image, the bmpblk_utility has options to display or unpack the binary.

  bmpblk_utility bmpblock.bin

  bmpblk_utility -y bmpblock.bin

  bmpblk_utility -x -d /SOME/SCRATCH/DIR bmpblock.bin

Once you've unpacked it you can use the bitmap_viewer on the unpacked
config.yaml file to see what it looks like. There's not (yet) a single tool
that directly displays the raw binary.