Difference between revisions of "Flashmap"

From coreboot
Jump to: navigation, search
m (Trace GBB generation)
(How do we fix it (the solution being pursued))
Line 104: Line 104:
  
 
==How do we fix it (the solution being pursued)==
 
==How do we fix it (the solution being pursued)==
 
=== Integration into the coreboot build-system ===
 
 
Something similar to what we do for CBFS files
 
 
cbfs-regions-y += fw_readonly
 
fw_readonly-name  := GOD_SAVE_THE_FIRMWARE
 
fw_readonly-offset := 0xblablabla
 
fw-readonly-size  := 0xblablabla
 
 
Put cbfs files in some default partition unless otherwise specified
 
 
# This is going into wherever the "default" cbfs partition is
 
cbfs-files-y += spd.bin
 
spd.bin-file := $(SPD_BIN)
 
spd.bin-type := 0xab
 
 
Now if we wanted to explicitly put a file in some non-default region, we could do something like
 
 
cbfs-files-y += payloadizer
 
payloadizer-region := USER_CAN_DO_WHATEVER
 
payloadizer-file  := payload_to_the_people
 
payloadizer-type  := blablabla
 
 
The advantage of having the notion of a default region means we can integrate the regionizing without disturbing existing code, which may not care about flash regions.
 

Revision as of 00:15, 12 February 2015

or...

Toward a unified representation for the layout of coreboot flash images

N.B. The changes described herein are being made as part of the Chromium OS project; as such, they will initially be committed to the project's own fork of the main coreboot repository, which is available at https://chromium.googlesource.com/chromiumos/third_party/coreboot. Unless otherwise noted, the paths and processes described throughout this page are as they exist(ed) in a checkout of the master branch of the Chromium OS sources as they appeared at the beginning of 2015. One of the guiding design principles is to keep the tools general enough that they will be helpful to others, and the resulting work will be upstreamed to the main repository once it has been regression-tested in the context of Chromium OS hardware.

How it's currently done (how the Chromium OS project presently constructs firmware images)

Most Intel-based Chromium OS devices currently use an 8 MB firmware image that includes---among other things---the Intel ME firmware, a copy of coreboot including the ramstage and depthcharge (bootloader) payload, two additional copies of the ramstage and bootloader payload, and a separate SeaBIOS payload. The primary description of this format exists in board-specific flattened device tree files, which are used by a script called cros_bundle_firmware to modify the image produced by the coreboot build system. For instance, the layout of the Panther board's firmware exists at https://chromium.googlesource.com/chromiumos/platform/depthcharge/+/master/board/panther/fmap.dts, and results in a final image that looks like this:

Section Offset Contents Original source Packaging procedure Coreboot Kconfig entr[yi](es)
RO
0x700000 Boot (coreboot image) coreboot.rom (coreboot build system) cros_bundle_firmware helper adds depthcharge.payload and compiled (then mod ified) version of fmap.dts to the existing CBFS CONFIG_CMOS_POST_OFFSET, CONFIG_CBFS_SIZE
0x611000 GBB (Google Binary Block) chromeos-config section of fmap.dts cros_bundle_firmware generates and inserts it
0x610840 (Reserved)
0x610800 FWID (Firmware ID)
0x610000 FMAP (Flash MAP)
0x604000 (Reserved)
0x600000 RO-VPD (Vital Product Data)
0x400000 Legacy (SeaBIOS image)
0x3fa000 (Reserved)
0x3f8000 RW-VPD (Vital Product Data)
RW-shared
0x3f6000 Vblock-dev (third-party kernel signing keys)
0x3f4000 Shared-data (RW firmware calibration data)
0x3f0000 ELOG (Event LOG)
0x3e0000 MRC-cache (Memory Reference Code training data)
RW-B
0x3dffc0 FWID-B
0x300000 Main-B (copy of coreboot ramstage and payload)
0x2f0000 Vblock-B (signing keys)
RW-A
0x2effc0 FWID-A
0x210000 Main-A (copy of coreboot ramstage and payload)
0x200000 Vblock-A (signing keys)
FW-descriptor
0x001000 ME (Intel Management Engine firmware blob)
0x000000 FD (Intel Firmware Descriptor header)

What's so bad about that (the pitfalls of this build model that we hope to solve)

Why you should care (how this pertains to all coreboot users)

How do we fix it (the solution being pursued)