Issue #588592  was caused by a patch that broke status register reads. It would be nice if we can come up with a sanity check for this that can run automatically, both in systems with write protection enabled and systems with write protection disabled.

Thoughts on how to do this...

Case 1: If hardware write-protect signal is de-asserted:
- Write-protect signal can be read from hardware (assume it's true).
- We can still attempt to change SPI ROM status register bits and verify the results against the hard-coded table (--wp-list).

Procedure:
1. Attempt to disable WP and clear the range.
2. Read the WP status
3. Ensure that the reported status agrees with that WP is disabled and the range is cleared.
4. Repeat above steps but using a valid range and setting the status register protect bit (--wp-enable).

We might be able to (re-)use the existing util/wp-range.sh and util/wp-toggle.sh scripts for this.

Case 2: If hardware write-protect signal is asserted:
- Things become trickier.
- We can check that the status register protect bit is enabled.
- We can also try clobbering select RO and RW regions to sanity check that WP is working as expected.

Procedure:
1. Read WP range and check that it's set to something sensible. We might get architecture-specific with this, for example check that at least one-quarter of the chip's address space is protected at either the top (x86) or bottom (non-x86). Usually ChromeOS devices have their protection set to a half or quarter of the chip.
2. Attempt to clobber regions that is protected according to the write-protect bits that are reported as being set.
3. Attempt to clobber other select RO and RW regions, expecting failure for RO regions and success for RW regions.

This kind of test will also be useful just to see that lab/test machines are set up correctly. We must make it very clear when a test fails due to misconfiguration so that when something breaks tree sheriffs, test team, lab teams, etc. can triage the problem accurately.