Google Git
Sign in
chromium / chromiumos / third_party / ap_wpsr / refs/heads/factory-rauru-16167.B
commit255db4276448491a4dc87383ba3dc6c5fce56cdc[log] [tgz]
authorHsuan Ting Chen <[email protected]>Wed Sep 11 11:32:36 2024
committerChromeos LUCI <[email protected]>Wed Sep 11 14:58:20 2024
treecbef4602804627acafe537ca13eefe2036e784e7
parent6a49659eb407127e5b847bfc7387169dba7134fc [diff]
imports: Keep up with flashrom

Update all the files under import/ from upstream flashrom to support
newer chips e.g. XM25QH128D.

Also we shouldn't include GD25B128E now since the ToT flashrom doesn't
include it yet.

All the files in import/ comes from commit 8685230caa03940772358db6927c6076397a6d78

BUG=b:350672382
TEST=check both flashrom and ap_wpsr ToT have XM25QH128D
TEST=check both flashrom and ap_wpsr ToT don't have GD25B128E

Change-Id: Ie6339aa4dae47a6a84bcb3bdfe5b573aa503f2ed
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/ap_wpsr/+/5850996
Commit-Queue: Jian-Jia Su <[email protected]>
Reviewed-by: Jian-Jia Su <[email protected]>
Auto-Submit: Hsuan Ting Chen <[email protected]>
Commit-Queue: Hsuan Ting Chen <[email protected]>
Tested-by: Hsuan Ting Chen <[email protected]>
4 files changed
tree: cbef4602804627acafe537ca13eefe2036e784e7
  1. imports/
  2. shim/
  3. COPYING
  4. DIR_METADATA
  5. main.c
  6. meson.build
  7. OWNERS
  8. README.md
README.md

ap_wpsr tool

The ap_wpsr tool was built to address specific requirements of AP RO verification that intends to measure SR contents for invariance after signature validation.

The tool leverages the flashrom SPI flash chips database to produce theoretical mask,value pairs for a given WP configuration (i.e. protection range start and length) and flash chip part name.

limitations

There are however some limitations. While the tool is pure logic (no side-effects) and intended to calculate values with reasonable fidelity there could however be inaccuracies.

These inaccuracies can be the result of any combination of the following factors:

  • Incorrect writeprotoct SR topology data within the database.
  • Duplicate chips or otherwise ambiguous chip identifiers (id or string name).
  • OTP fused values within the SPI flash chip itself.

A precise flash chip name is required to be cited physically on what chip is being worked with (and not via probing or other inferences). This precise name needs to be mapped to the corresponding name within the database to produce the tool output products. The output products must be cross-validated with the datasheet to ensure the products are consistent with expectations and any errors in the database are corrected with a patch back to the canonical flashrom flashchips database upstream.

usage

An example usage could be ./ap_wpsr -n "W25Q128.V" -s 0x40000 -l 0xFC0000.

finding chip names

The ap_wpsr tool needs to be given the name of the flashrom chip entry to use for calculating mask,value pairs. This name may not match the vendor name, for example the chip “W25Q128FVSIG” corresponds to a flashrom entry called “W25Q128.V”.

These steps should be followed to find the flashrom chip name for your chip:

  • Check the chip's datasheet to find the vendor and device ID values.
  • Inspect flashchips.h to find matching ID define macros.
  • Inspect flashchips.c to find the chip entry that uses those ID macros
  • If there are multiple flashrom chip entries with the same IDs, check all of them against the datasheet to find the correct one.
  • Finally, check that the chip entry has a reg_bits field and that it matches the datasheet exactly. Verify that all WP-related bits in the datasheet are included in reg_bits and vice versa.
  • If there are no matching chip entries, create one for the chip and send a patch to upstream flashrom for review.
  • Pass the matching entry's name to the tool via the -n option.

src structure

There are two key parts to the tool imports/ and shim/. The shim/ directory just contains enough symbols to allow linking of the imports/ source taken from upstream flashrom. The imports/ contains two key ingredients - the chip database and the writeprotection calculation code. These should be kept up to date by importing fresh copies from flashrom.