| 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, un-versioned 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, hard-coded 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. |
| |
| * To build new Alex bitmaps, check out "chromeos/autotest-private-x86-alex" |
| on branch "0.11.241.B", and see the tools in |
| client/site_tests/hardware_Components/utils. |
| Reference: https://chrome-internal-review.googlesource.com/23243/ |
| |
| |
| 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: hwid_fonts.font # 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: |
| |
| It is now easier to build bmpblk INSIDE chroot. Just run "make" and everything |
| will be regenerated: |
| |
| (chroot) cd ~/trunk/src/platform/bmpblk |
| (chroot) make |
| |
| This should generate BIOS bmpblock file for all platforms cross all locales, |
| which takes a long time. |
| |
| If you simply want to build image for single target with default locales, do: |
| |
| (chroot) cd ~/trunk/src/platform/bmpblk |
| (chroot) make $BOARD |
| |
| Where $BOARD is the board name of your target, ex: "link". There is one simple |
| reference target "std" with fewer locales so you can test the building procedure |
| faster: "make std". |
| |
| The default generated output files are in ./build/$BOARD. To override output |
| folder, just specify OUTPUT=/path_to_output in Make variables. |
| |
| Note if you want to override the default locales list defined in boards.yaml |
| (for instance, to build with only English locale to speed up testing flow, or |
| to try with all available locales), add LOCALES="<locale-list>" when running |
| make. |
| Example: |
| |
| make LOCALES="en ja es" make link |
| |
| Note if you want to use the "bitmap viewer" utility, since we don't have |
| wxWidgets and X environment inside SDK, it's currently only available OUTSIDE |
| chroot and you have to install these packages manually. For example, on |
| Ubuntu systems, do: |
| |
| sudo apt-get install python-yaml python-wxgtk2.8 |
| |
| And then you can preview the bitmaps by following commands (outside chroot): |
| |
| ./bitmapviewer build/$BOARD/DEFAULT.yaml 1366x768 |
| |
| ------------------- |
| Adding a new target: |
| |
| The following properties of the new target need to be known in |
| advance: |
| |
| |
| - dimensions of display panel in pixels. |
| |
| These are dimensions the firmware initializes the panel to. On ARM |
| platforms dimensions usually match the actual panel hardware. |
| |
| On X86 things are a little more complicated. To determine actual |
| boot screen dimensions first find the setting for |
| CONFIG_FRAMEBUFFER_VESA_MODE in coreboot/configs/config.YOUR_BOARD |
| |
| Then look up the dimension for the found VESA in |
| http://en.wikipedia.org/wiki/VESA_BIOS_Extensions#Modes_defined_by_VESA |
| |
| Note if the panel is much larger (for example, 1920x1080) than default |
| resolution (1366x768), you may want to use a higher resolution of image |
| resources (icons, diagrams, ... etc). To do that, change the "assets_dir" |
| property. |
| |
| Currently we have two directories in images/ containing the image resources |
| in different resolution: "assets" (designed for 1366x768) and "assets2x" |
| (double sized from "assets"). |
| |
| When using "assets2x", you should also override "assets_res" to specify the |
| dimension that best fits given assets (hint: setting "assets_res" to same |
| value as graphics resolution "res" would not resize anything). |
| |
| |
| - device boot ability |
| |
| by default the device should be able to boot into recovery mode from |
| USB and/or SD interfaces. But some devices do not have certain |
| interfaces, some devices can't boot from certain interfaces. That is |
| standard directions for the user shown on the boot screen need to be |
| amended. |
| |
| |
| - set of locales the device boot screen is required to support |
| |
| Country locales can be found in |
| https://chromium.googlesource.com/chromium/src.git/+/master/ui/base/l10n/l10n_util.cc |
| or http://www.science.co.il/language/locale-codes.asp |
| |
| |
| To add a new target (board), edit images/boards.yaml and fill the information: |
| |
| ------------------------------------------------------------------------------ |
| link: |
| # Non-standard Graphics mode 1280x850, with 2560x1700 panel. |
| # Can boot recovery by USB and SD card readers. |
| res: [1280, 850] |
| panel: [2560, 1700] |
| locales: [en, es-419, pt-BR, fr, es, it, de, nl, da, 'no', sv, ko, ja, id, th] |
| ------------------------------------------------------------------------------ |
| |
| The locale name <no> will be interpreted as boolean False in YAML, so we need to |
| quote it as 'no'. |
| |
| If your configuration is exactly the same as existing ones, add your new target |
| name into the existing entry, ex (4 targets with same configuration: falco, |
| peppy, wolf, leon): |
| |
| ------------------------------------------------------------------------------ |
| falco,peppy,wolf,leon: |
| # Using VESA graphics mode 1024x768 (0x0117), streched to 1366x768 panel. |
| # With card reader. USB3 ports will run in USB2 mode for recovery boot. |
| res: [1024, 768] |
| panel: [1366, 768] |
| ------------------------------------------------------------------------------ |
| |
| Now to build images for the new target (as $BOARD) run: |
| |
| $ TARGETS="$BOARD" make |
| |
| or specify the target directly, |
| |
| $ make "$BOARD" |
| |
| The bitmaps and output binary (bmpblk.bin) can be found in ./build/$BOARD. |
| |
| You can preview the images by running Bitmap Viewer OUTSIDE chroot: |
| $ ./bitmap_viewer build/$BOARD/DEFAULT.yaml |
| |
| Information about integrating new bitmaps into the firmware images can |
| be found in http://goo.gl/yXBvz |
| |
| |
| ------------------------------------ |
| Handling generated bitmaps: |
| |
| You can use the gbb_utility to modify your BIOS to contain this new set of |
| bitmaps: |
| |
| gbb_utility -s -b PATH/TO/YOUR/bmpblk.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/bmpblk.bin . |
| |
| Get a copy of the current BIOS: |
| |
| flashrom -p host -r bios.bin |
| |
| Put the new bmpblock in the copy of the BIOS: |
| |
| gbb_utility -s -b bmpblk.bin bios.bin |
| |
| Reflash the BIOS with the new content |
| |
| flashrom -p host -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 bmpblk.bin |
| |
| bmpblk_utility -y bmpblk.bin |
| |
| bmpblk_utility -x -d /SOME/SCRATCH/DIR bmpblk.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. |
| |
| ------------------------------------------------------------------------------ |
| If you want to build OUTSIDE chroot, here's some information: |
| |
| On Ubuntu, you need to install following packages: |
| |
| sudo apt-get install libpango1.0-dev python-imaging librsvg2-bin |
| |
| And you probably want to make sure all required fonts are installed: |
| |
| sudo apt-get install fonts-noto |
| |
| Currently Ubuntu Trusty (14.04) does not have some of required font files |
| (Arabic UI and CJK) so you have to manually install them: |
| mirror=http://commondatastorage.googleapis.com/chromeos-localmirror/distfiles |
| wget "${mirror}/notofonts-20140815.tar.bz2" |
| wget "${mirror}/noto-cjk-20140912.tar.bz2" |
| sudo tar -xvf notofonts-20140815.tar.bz2 -C /usr/share/fonts/truetype |
| sudo tar -xvf noto-cjk-20140912.tar.bz2 -C /usr/share/fonts/truetype |
| sudo fc-cache # Reload font cache. |
| |
| If you want to use the "bitmap viewer" utility, add these packages: |
| |
| sudo apt-get install python-yaml python-wxgtk2.8 |
| |
| We also need some utilities from ChromiumOS source tree. You need to install |
| dependency libraries for them: |
| |
| sudo apt-get install libtspi-dev uuid-dev libyaml-dev |
| |
| On older Ubuntu installations you would also need liblzml-dev, on newer ones - |
| liblzma-dev, try installing both, one at a time, at least one must succeed. |
| |
| Now, time to build the utilities in vboot_reference outside of the chroot: |
| |
| cd src/platform/vboot_reference |
| make |
| |
| Once you've built vboot_reference you'll find the executables in |
| ./build/utility/bmpblk*. If they were built in the standard place they |
| will be found by this tool automatically. If not, their location must be added |
| to your $PATH. |