summaryrefslogtreecommitdiff
path: root/util/nvmutil/README.md
diff options
context:
space:
mode:
authorLeah Rowe <leah@libreboot.org>2025-01-24 13:13:28 +0000
committerLeah Rowe <leah@libreboot.org>2025-01-24 13:13:28 +0000
commitc829b45c17c529563823045d7dbee592983bdd21 (patch)
treeb9295b173c3ee18d33deb1dcc87ebe4150466123 /util/nvmutil/README.md
parenta98ca5bf65c6c195995493056625649b70030076 (diff)
util/nvmutil: support 16kb and 128kb gbe files
See: https://edc.intel.com/content/www/us/en/design/ipla/software-development-platforms/client/platforms/alder-lake-mobile-p/intel-600-series-chipset-family-on-package-platform-controller-hub-pch-datash/spi0-for-flash/ The rules described there are universal, and replicated elsewhere for many other platforms. The rules are simply: * Flash descriptor is one block size, e.g. 4KB * GbE is two block sizes, so if IfD is 4KB, GbE is 8KB Intel defines 16KB and 128KB GbE files in specs, pertaining to 8KB and 64KB block sizes respectively. The minimum size is 4KB blocksize, for 8KB GbE files which we already supported. On larger block sizes, the same 4KB parts are observed: a single 4KB IfD area at the start of the block, and: 4KB GbE part at the start of the GbE region, and: 4KB GbE part at the start of GbE region plus block size The empty space inbetween is padding, and we ignore it, except when running swap/copy commands. The nvmutil code has been modified, to create a 128KB buffer in memory instead of 8KB, for loading GbE files. Partsize is set to GbE file size divided by 2, and only the area of memory we need to use is mapped; for example, if we're loading a 8KB GbE file into memory, we only touch the first 8KB part of the buffer, or first 16KB for 128KB files. In practise, we almost never see GbE files with sizes higher than 8KB, but *we have seen it*, *AND NOW IT'S SUPPORTED!" Signed-off-by: Leah Rowe <leah@libreboot.org>
Diffstat (limited to 'util/nvmutil/README.md')
0 files changed, 0 insertions, 0 deletions