diff options
author | Leah Rowe <leah@libreboot.org> | 2025-01-24 13:13:28 +0000 |
---|---|---|
committer | Leah Rowe <leah@libreboot.org> | 2025-01-24 13:13:28 +0000 |
commit | c829b45c17c529563823045d7dbee592983bdd21 (patch) | |
tree | b9295b173c3ee18d33deb1dcc87ebe4150466123 /util/nvmutil/README.md | |
parent | a98ca5bf65c6c195995493056625649b70030076 (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