CBFSTOOL(8)

๐Ÿ“ฆ
version 25.09 ยท 3 versions
, in debian trixie, ubuntu questing, ubuntu resolute, ubuntu stonking

๐ŸŽ€ CBFSTOOL โ€” NAME

cbfstool โ€” bestie, this is the management utility for CBFS formatted ROM images, straight outta the coreboot tools ๐Ÿ‘‘


๐ŸŒธ SYNOPSIS

cbfstool [-h]
cbfstool FILE COMMAND [-v] [PARAMETERS]...

โœจ DESCRIPTION

Okay so real talk: this is the management utility for CBFS formatted ROM images. That's the whole vibe. It's giving "I poke at firmware and I'm good at it" ๐Ÿ’…


๐Ÿ’– OPTIONS

Every single one, no skipping, periodt:

  • -H header_offset โ€” do NOT go looking for the header, just use this offset* ๐ŸŽฏ
  • -T โ€” output a top-aligned memory address
  • -u โ€” accept short data; fill upward / from the bottom
  • -d โ€” accept short data; fill downward / from the top
  • -F โ€” force it. Do the thing. No cap.
  • -g โ€” generate position and alignment arguments
  • -U โ€” unprocessed; don't decompress or make ELF
  • -v โ€” give me verbose output (-v=INFO, -vv=DEBUG output) ๐Ÿ—ฃ๏ธ
  • -h โ€” display this help message (the classic)
  • --ext-win-base โ€” base of extended decode window in host address space (x86 only)
  • --ext-win-size โ€” size of extended decode window in host address space (x86 only)

๐Ÿ”ฅ COMMANDS

โž• add

add [-r image,regions] -f FILE -n NAME -t TYPE [-A hash]
       [-c compression] [-b base-address | -a alignment] [-p padding
       size] [-y|--xip if TYPE is FSP] [-j topswap-size] (Intel CPUs
       only) [--ibb] [--ext-win-base win-base --ext-win-size win-size]

Add a component โœจ

  • -j valid size: 0x10000 0x20000 0x40000 0x80000 0x100000

๐Ÿš€ add-payload

add-payload [-r image,regions] -f FILE -n NAME [-A hash]
       [-c compression] [-b base-address] (linux specific: [-C cmdline]
       [-I initrd])

Add a payload to the ROM. Linux girlies get the extra -C cmdline and -I initrd moment ๐Ÿง

๐ŸŽญ add-stage

add-stage [-r image,regions] -f FILE -n NAME [-A hash]
       [-c compression] [-b base] [-S
       comma-separated-section(s)-to-ignore] [-a alignment]
       [-Q|--pow2page] [-y|--xip] [--ibb] [--ext-win-base win-base
       --ext-win-size win-size]

Add a stage to the ROM ๐ŸŒŸ

๐Ÿงฑ add-flat-binary

add-flat-binary [-r image,regions] -f FILE -n NAME
       [-A hash] -l load-address -e entry-point [-c compression] [-b
       base]

Add a 32bit flat mode binary

๐Ÿ”ข add-int

add-int [-r image,regions] -i INTEGER -n NAME [-b base]

Add a raw 64-bit integer value. Just a number, living its truth ๐Ÿซถ

๐Ÿ‘‘ add-master-header

add-master-header [-r image,regions] [-j topswap-size] (Intel CPUs only)

Add a legacy CBFS master header

โŒ remove

remove [-r image,regions] -n NAME

Remove a component. Gone. Blocked. Unfollowed ๐Ÿ’€

๐Ÿงน compact

compact -r image,regions

Defragment CBFS image. Self-care for your ROM ๐Ÿง–

๐Ÿ“‹ copy

copy -r image,regions -R source-region

Create a copy (duplicate) cbfs instance in fmap

๐Ÿ—๏ธ create (legacy style)

create -m ARCH -s size [-b bootblock offset]
       [-o CBFS offset] [-H header offset] [-B bootblock]

Create a legacy ROM file with CBFS master header* โœจ

๐Ÿ†• create (new-style)

create -M flashmap [-r list,of,regions,containing,cbfses]

Create a new-style partitioned firmware image

๐Ÿ—บ๏ธ layout

layout [-w]

List mutable (or, with -w, readable) image regions

๐Ÿ–จ๏ธ print

print [-r image,regions] [-k]

Show the contents of the ROM. Show me what you got ๐Ÿ‘€

๐Ÿ“ค extract

extract [-r image,regions] [-m ARCH] -n NAME -f FILE [-U]

Extracts a file from ROM

โœ๏ธ write

write [-F] -r image,regions -f file [-u | -d] [-i int]

Write file into same-size [or larger] raw region

๐Ÿ“– read

read [-r fmap-region] -f file

Extract raw region contents into binary file

โœ‚๏ธ truncate

truncate [-r fmap-region]

Truncate CBFS and print new size on stdout

๐ŸŽˆ expand

expand [-r fmap-region]

Expand CBFS to span entire region


๐Ÿงฎ OFFSETS

So the numbers that come along with the -b, -H, and -o switches* can show up in two possible formats, bestie:

  • if their value is greater than 0x80000000, they get interpreted as a top-aligned x86 memory address
  • otherwise, they're treated as an offset into flash

That's it, that's the rule ๐ŸŒˆ


๐Ÿ›๏ธ ARCHITECTURES

arm64, arm, mips, ppc64, power8, riscv, x86, unknown


๐Ÿ—‚๏ธ TYPES

bootblock, cbfs header, legacy stage, stage, simple elf, fit_payload, optionrom, bootsplash, raw, vsa, mbi, microcode, intel_fit, fsp, mrc, cmos_default, cmos_layout, spd, mrc_cache, mma, efi, struct, deleted, null, amdfw

okay so listen, this part is important: these actions and switches are only valid when working with legacy images whose structure is described primarily by a CBFS master header.

New-style images, in contrast, exclusively make use of an FMAP to describe their layout. That FMAP must minimally contain an 'FMAP' section specifying the location of this FMAP itself, plus a 'COREBOOT' section describing the primary CBFS. ๐Ÿซถ

Also worth noting: when you're working with such images, the -F and -r switches default to 'COREBOOT' for convenience, and the -b switch becomes relative to the selected CBFS region's lowest address.

The one exception to this rule is the top-aligned address, which is always relative to the end of the entire image rather than relative to the local region. This is true for both input (sufficiently large) and output (-T) data. No cap, that's just how it is ๐Ÿ’…


๐Ÿ’œ AUTHORS

  • coresystems GmbH.
  • Man page written by Ahmad Khalifa.

and that's the whole page, bestie ๐ŸŽ€ it shipped as part of System Administration Utilities back in November 2024 โ€” go forth and manage those ROM images, you absolute icon ๐Ÿ‘‘โœจ๐Ÿฆ‹

๐Ÿ“ฆ where this page comes from