mirror of
https://review.coreboot.org/flashrom.git
synced 2025-07-01 22:21:16 +02:00
mysteries_intel: Add a section for software vs hardware sequencing
This attempts to explain software sequencing, hardware sequencing, and the "Opaque flash chip". Change-Id: I2445e926aad96060f26d0bc55dd7642c1a404296 Signed-off-by: David Hendricks <david.hendricks@gmail.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/42485 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This commit is contained in:

committed by
Angel Pons

parent
76d2445d39
commit
3c720597c3
@ -5,6 +5,48 @@
|
||||
A0h), so we have no clue if or where it is on ICH8. Out current policy is to
|
||||
not touch it at all and assume/hope it is 0.
|
||||
|
||||
= Software Sequencing vs. Hardware Sequencing and the "Opaque flash chip" =
|
||||
Software sequencing and hardware sequencing are two methods used to interface
|
||||
with the SPI controller on Intel platforms. They can be selected using either
|
||||
ich_spi_mode=swseq or ich_spi_mode=hwseq programmer parameters. Flashrom will
|
||||
attempt to automatically detect which mode to use.
|
||||
|
||||
Software sequencing is the traditional method whereby software running on the
|
||||
CPU handles most of the logic needed to interact with the flash chip. This
|
||||
offers good flexibility since the user can utilize any opcode available in the
|
||||
OPMENU registers, and OPMENU can be left unlocked or on coreboot-supported
|
||||
platforms the owner of the system may program it for their needs before locking
|
||||
it. Advanced or non-standard features of a chip such as write protection and
|
||||
OTP may therefore be directly utilized by software.
|
||||
|
||||
Hardware sequencing is a newer method (since around 2011) whereby most of the
|
||||
logic for interacting with the SPI flash chip is contained within the SPI
|
||||
controller itself and software such as flashrom may only select a few operations
|
||||
chosen by Intel via the Flash Cycle (FCYCLE) field. The chip must conform to
|
||||
specifications from Intel for each chipset/PCH. The specs are given in the
|
||||
"SPI Programming Guide" application note. See [SPI_PROG] cited at the bottom of
|
||||
this document for an example.
|
||||
|
||||
Hardware sequencing simplifies things from a software perspective since the
|
||||
software is guaranteed some minimal level of support and doesn't even need to
|
||||
know the chip's ID or opcodes; it just needs to tell the SPI controller to
|
||||
perform a type of transaction such as "read", "4k block erase", etc. Hence when
|
||||
using hardware sequencing one will see "Opaque flash chip" as the chip's
|
||||
description since software might not be able to identify the chip. The SPI
|
||||
controller can combine multiple physical flash chips to logically appear as a
|
||||
single large flash device, and in such cases it would not make sense for
|
||||
flashrom to try to identify the chip.
|
||||
|
||||
In many non-Intel systems the software has full control of a generic SPI
|
||||
controller where the software controls the SPI signals and also constructs the
|
||||
data payload including pre-op (e.g. write enable latch), opcode, address, and
|
||||
data. Intel SPI flash controllers are purpose-built for flash chip access and
|
||||
the software does not control the hardware directly. This makes Intel SPI
|
||||
controllers less flexible from a software standpoint, however there are some
|
||||
benefits such as guaranteed atomicity and multi-master arbitration needed for
|
||||
modern Intel platforms where the CPU and various microprocessors can share the
|
||||
same flash chip.
|
||||
|
||||
= SMM BIOS Write Protection =
|
||||
Sometimes a hardware vendor will enable "SMM BIOS Write Protect" (SMM_BWP)
|
||||
in the firmware during boot time. The bits that control SMM_BWP are in the
|
||||
|
Reference in New Issue
Block a user