We open the device node for the MTD device with this:
dev_fp = fopen(dev_path, "r+")
In C fopen() is allowed to provide _buffered_ access to the file.
That means that the standard library is allowed to read ahead and/or
return cached data. That's really not what we want for something like
this. Let's turn it off.
This fixes a problem where flashrom would sometimes fail to "verify"
that it erased the flash. The error message would look something like
this:
Erasing and writing flash chip... FAILED at 0x0000e220! Expected=0xff, Found=0xe9, failed byte count from 0x0000e200-0x0000e2ff: 0xdc
failed byte count from 0x0000e000-0x0000efff: 0xffffffff
ERASE_FAILED
FAILED!
Uh oh. Erase/write failed. Checking if anything changed.
After the failure I could read the flash device with a new invocation
of flashrom and I would see that, indeed, the erase had worked.
Tracing in the kernel showed that when the failure happened we saw a
pattern that looked like this:
* Read 0x0b00 bytes starting at 0x0000d000
* Read 0x1000 bytes starting at 0x0000db00
* Erase 0x1000 bytes starting at 0x0000e000
...and then there was _not_ a read after the erase. It can be assumed
that, since userspace had already read 0xdb00 - 0xeaff that it was
looking at old buffered data after the erase.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Change-Id: I989afd83a33013b2756a0090d6b08245613215c6
Reviewed-on: https://review.coreboot.org/c/flashrom/+/50155
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The return value for reset function can not be guaranteed when
reset success. There is no way to check if reset success or not.
BUG=b:147402710,b:152558985
BRANCH=none
TEST=builds
Signed-off-by: Shiyu Sun <sshiyu@chromium.org>
Change-Id: Ia6200f7150db4368c26d8dfe779a9e85184b1b06
Reviewed-on: https://review.coreboot.org/c/flashrom/+/49786
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
The `install` argument in `configure_file` is a feature introduced in
meson '0.50.0', but meson.build requests '>=0.47.0'. Meson complains:
WARNING: Project targeting '>=0.47.0' but tried to use feature
introduced in '0.50.0': install arg in configure_file.
To correct this, adjust the `meson_version` value accordingly.
Change-Id: Iadcffb7f8c720ffa8aa5f0ad62638d7b37f39934
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/49924
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Forward port the downstream `commit b17e9e41838`.
When using a forwarding table entry for finding the coreboot table
don't assume one has access to a full 1 MiB where the forwarding
table entry points to. The reason is that the 1 MiB may cover address
regions that have differing cacheability type. As such the kernel will
complain and the mapping will fail. Instead, check the header first then
map in the bytes that it indicates after sanity validation. That way
there is no attempt at requesting an invalid mapping that spans different
memory cacheability attributes.
V.2: Incorperate Nico's and Angels comments from upstream.
BUG=b:66681446
BRANCH=None
TEST=Can successfully run 'flashrom -p host --wp-status' on kahlee
without generating PAT errors.
Original-Change-Id: Ic6c5832b069300cced66e11f4ca4a0bbc6e496de
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/685608
Original-Reviewed-by: Martin Roth <martinroth@chromium.org>
Original-Reviewed-by: Justin TerAvest <teravest@chromium.org>
Change-Id: I43705c19dd7c816098d03f528bde6f180c4c8f24
Signed-off-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/37240
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Using strlen() or strdup() inside strndup() is problematic: if the
input string is not null-terminated, these functions can read past the
end of the buffer, which triggers undefined behavior. Rewrite the
function to never read past the provided `maxlen` bound.
Change-Id: Id34127024085879228626fbad59af03268ec5255
Signed-off-by: Xiang Wang <merle@hardenedliux.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/49741
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Renames the variable cs_bits to pinlvl, to more accurately reflect its
role. pinlvl works in conjunction with pindir to specify GPIO pin state.
Signed-off-by: Alan Green <avg@google.com>
Change-Id: I53d1ccae8fa870f037b03762bec79fee1b7bad21
Reviewed-on: https://review.coreboot.org/c/flashrom/+/49780
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Adds a new arg "gpiol" to allow the four FT2232 GPIOL pins to be set to
any combination of high, low or high-impedance.
The existing arg "csgpiol", is intended to function as an additional
"cs" signal, allowing pins to be set high but not low. This patch
preserves the csgpiol arg for backward compatibility. In the event that
both arguments are specified, gpiol is used.
Signed-off-by: Alan Green <avg@google.com>
Change-Id: I1f2b3b968577e62e3c5b11bcdf4afe2de6eb84ab
Reviewed-on: https://review.coreboot.org/c/flashrom/+/49637
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Xiang Wang <merle@hardenedlinux.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reset FTDI I/O pins to high-Z (input) when shutting down. This allows
other devices to use the SPI bus without having to disconnect the
programmer.
This change will introduce a backward incompatibility in the case where
a user is relying on the state of FTDI outputs post-programming (eg. to
disallow another device from driving CS low).
However, there are likely more cases where releasing the SPI bus is the
correct thing to do.
Signed-off-by: Alan Green <avg@google.com>
Change-Id: I9fae55e532595752983f55fac2298f81699dbe5b
Reviewed-on: https://review.coreboot.org/c/flashrom/+/49632
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Removes unused declaration of noop_shutdown(). The implementation was
removed in 386cc556a4 and this declaration ought to have been removed at
the same time.
Signed-off-by: Alan Green <avg@google.com>
Change-Id: I7599ace08f3635251a80612df4b4d29001f81d35
Reviewed-on: https://review.coreboot.org/c/flashrom/+/49800
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Inline it85xx_spi_common_init() to single call site of
it85xx_spi_init() as the construction is a single phase
one. This allows for less cyclomatic complexity by
validating early and initialisation at the eulogy of the
one entry-point to the driver.
BUG=b:172876667
TEST=builds
Change-Id: Iac1b4ae9c6f34c5265e729ae0a80024800c3c272
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/48196
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Function appears to be vestigial.
Signed-off-by: Alan Green <avg@google.com>
Change-Id: I1b67223aed8be54b60771aa1b2d498836ed28060
Reviewed-on: https://review.coreboot.org/c/flashrom/+/49631
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Move global singleton states into a struct and store within
the spi_master data field for the life-time of the driver.
BUG=b:172876667
TEST=builds
Change-Id: I389d34d62e753c012910aa5ff24a496b24a4753c
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/47655
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Daniel Kurtz <djkurtz@google.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
If the tags are missing the version may not be evaluated correctly.
BUG=b:177691209
BRANCH=none
TEST=none
Change-Id: Ib9f85b2be8b6f5e1332ba98a8a71fcad12331818
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/49618
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The opaque data pointer need not necessarily have constant
data for the life-time of the specific master. This is because
the data field purpose is for the master to use as it sees fit
for managing its own internal state and therefore we should not
constrain this as being RO data at init time.
BUG=none
BRANCH=none
TEST=builds
Change-Id: I686c3c79547e35d48f3fd0b524fc98c176dcea6e
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/49131
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
I have successfully probed/read/erased/written a GD25LQ128D, so marking
this entry as tested.
Signed-off-by: Alan Green <avg@google.com>
Change-Id: Ic5329ebe81b6c1eabfb594f7f7affb3fd460db6b
Reviewed-on: https://review.coreboot.org/c/flashrom/+/49229
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This matches the build flags that are correctly explicitly defined in
meson.build where-as the Makefile is randomly picking up whatever the
system toolchain happens to default to.
Fix dmi.c while we are here to avoid a re-define of _GNU_SOURCE.
BUG=none
TEST=`make` with both gcc and clang.
Change-Id: I4f973927fc018510a3beaa6c4fa2f356c77c7a6e
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/47908
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
register_chip_restore() provides a general mechanism for restoring a chip's state at flashrom exit; it can be used whenever the SR needs to be changed temporarily to perform some operation and changed back after the operation is complete. The only current current use case is in s25f.c, which changes the SR's sector layout bits so that entire flash accessible.
This patch uses the chip restore functionality to reset changes to the status register made by spi_disable_blockprotect_generic(). This should help to ensure consistency across multiple runs of flashrom and make it easier to predict how a specific operation will change the flash.
Imported from cros flashrom at `b170dd4e1d5c33b169c5`
Change-Id: If2f0e73518d40519b7569f627c90a34c364df47c
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/48778
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Allows to force-disable the use of clock_gettime() at build time,
falling back to busy-looping for udelay. This is useful when building
for systems which are known to lie about the resolution of
clock_gettime(), such as Linux guests running under the Muen Separation
Kernel.
Change-Id: I645a5d3f29ffdbd24a58127ab73d7d8755304f45
Signed-off-by: Martin Lucina <martin@lucina.net>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/48796
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Be explicit to mask the first byte after the shifts as
highlighted by Angel Pons.
BUG=none
BRANCH=none
TEST=builds
Change-Id: I7d1215678094d709e79b8f8c96aa3810586cd72e
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Spotted-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/48974
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Shiyu Sun <sshiyu@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update the PAGE_SIZE to 128 as fix r/w on different devices,
also fix the write page mapping for it.
BUG=b:147402710
TEST=build and run flashrom to read&write on multiple devices
Signed-off-by: Shiyu Sun <sshiyu@chromium.org>
Change-Id: Ifcdd3548519eb37440e67fcf6206279cff05b159
Reviewed-on: https://review.coreboot.org/c/flashrom/+/48840
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Check ISP mode before doing reset and add waiting
after the enter ISP mode command.
BUG=None
TEST=build and run mst commands
Signed-off-by: Shiyu Sun <sshiyu@chromium.org>
Change-Id: Ib1ab8370eb6335a77bb293fc98a8ab7be465db4f
Reviewed-on: https://review.coreboot.org/c/flashrom/+/48662
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
This is correct on the Chromium side so fix the missing space
here.
Change-Id: I9dd27a4d8a1b87ce96b2a3f8cbe80f40c79b0354
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/48744
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The field member 'included' is of type boolean and so keep to
using 'true, false' values over numerics like '0'. Get rid of
a unnecessary yet trivial tab at the end of layout.h while we
are here.
BUG=none
BRANCH=none
TEST=builds
Change-Id: Ib594de2834175482ae5e36d9dd354ef2555c53d5
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/48743
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested reading, writing and erasing the internal flash chip using an HP
280 G2 SFF mainboard with an Intel H110 PCH. However, since ME-enabled
chipsets are marked as DEP instead of OK, this one shall also be.
Change-Id: I5deac6e43a43ee9748aaa7dadae50065613488b1
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/48384
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
libusb_exit() call is done by dediprog_open() under the
ret == 1 condition. Removing this line has no impact on
any flow and side effect of the program.
Change-Id: I38b3f3ee3f9d46845df1404791f4a4782320aa7c
Signed-off-by: Medicine Yeh <medicinehy@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/48688
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Adds support for rev 0x59 || 0x61 of did 0x790b.
This is quite confusing however it turns out FCH chipsets
called 'Promontory' contain the so-called SPI100 ip
core that uses memory mapping and not a ring buffer for
transactions. Typically this is found on both Stoney Ridge
and Zen platforms. In light of this, separate out the
promontory path into its own callback struct state tracker
so that it's implementation does not interfere with previous
generations that predate the SPI100 controller.
Since there is some life-time state required to track the mapping
during between the first attempted read and the final tear-down of
the spi master we take the opportunity to avoid static locals and
instead implement the functionality in a re-entrant way for follow
up clean ups.
BUG=none
BRANCH=none
TEST= Zork => 'Promontory (rev 0x61) detected.' &&
Grunt => 'Promontory (rev 0x4b) detected.'
Change-Id: I5ce63b5de863aed0442cb4ffeff981e9b2fa445b
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/44073
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Tested probe/read/erase/write operations succeed with cros
flashrom on rikku chromebox. Marking as DEP to follow
convention for ME-enabled chipsets.
BUG=b:170906609
BRANCH=none
TEST=Applied patch to cros flashrom and verified that
`flashrom -VV` no longer prints a chipset warning on rikku
Change-Id: I0b4d1dd2b271537faea15856442fe183d9de3318
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/47218
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This adds support for Spansion 25Fxxxxx chips. These chips
require their own probing logic because the first 6 bytes
returned by RDID must be examined to identify the chip.
New erase functions are required as the chips support multiple
sector layouts, and the default layout must be changed to be
able to erase the entire flash.
Adapted from cros flashrom at
`9c4c9a56b6a0370b383df9c75d71b3bd469e672d`.
BUG=b:153800073
TEST=builds
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Change-Id: I2d23f9c36ce8b2959807fbeee7f60e02444e3763
Reviewed-on: https://review.coreboot.org/c/flashrom/+/46140
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Allows drivers to register a callback function to reset the
chip state once programming has finished. This is used by
the s25f driver added in a later patch, which needs to change
the chip's sector layout to be able to write to the entire flash.
Adapted from cros flashrom at
`9c4c9a56b6a0370b383df9c75d71b3bd469e672d`.
BUG=b:153800073
BRANCH=none
TEST=builds
Change-Id: I2a522dc1fd3952793fbcad70afc6dd43850fbbc5
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/47276
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Align with the properly tab indented comment on the CrOS
Flashrom side to make things consisent.
Change-Id: I09605bfec203d294077f298f8619bbc7d10cc68a
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/48204
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Unfortunately raiden_debug was upstreamed with a slightly
incorrect name of "raiden_debug" whereas in ChromiumOS
it is known as "raiden_debug_spi" and so correct this to
align. This avoids confusion and divergence for a unified
future.
Change-Id: I0eca35863403c5d4adbe19b31801e8dfa072006f
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/48106
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Unfortantly raiden_debug was upstreamed with a misnaming
of the CONFIG_ make param that introduces unnecessary divergence.
Rename to 'CONFIG_RAIDEN_DEBUG_SPI' as-is downstream.
Change-Id: I07c03647c329286bb223e4dae4665704e508db2c
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/48105
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Have 'determine_generation()' explicitly return 'amd_gen'
and then pass the state into what requires it, thus making
the code more pure, easier to read and more unit-testable.
Change-Id: I99fbad9486123c6b921eab83756de54a53ddfa7a
Signed-off-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/36432
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
This upstreams a ChromiumOS feature that allows the user
of the dummyflasher spi master to either fill with 0x00
or 0xff in the fake flash content by way of a spi master
param.
BUG=b:140394053
BRANCH=none
TEST=none
Change-Id: I37c6dee932e449201d8bbfb03ca6d139da3cb6a2
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/47859
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Make use of the reneterent framework by moving singleton static
state out of the global life-time and into a per-spi_master basis.
This allows for the wbsio_spi master to be reneterent and its internal
state's life-time to be correctly handled by Flashrom's core dispatch
logic.
BUG=none
TEST=builds
Change-Id: Ic97fa41daf26f27b68ced11ddc2a4da91d18f68e
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/47854
Reviewed-by: Sam McNally <sammc@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reshuffle file with no semantic changes, this avoids unnecessary
prototypes for static member functions as to pave the way for further
cleanups as well as an easier to parse implementation.
BUG=none
TEST=builds
Change-Id: Iae9426b6a8ba6a824f7d7e9aaf9f8174b044d04c
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/47853
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Tested reading, writing and erasing the internal flash chip using an HP
Elite 8200 mainboard with an Intel Q67 PCH. However, since ME-enabled
chipsets are marked as DEP instead of OK, this one shall also be.
Change-Id: I2bd431c5c72824654b6b5b840f9af55dfe9d3554
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/47797
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reshuffle file with no semantic changes, this avoids unnecessary
prototypes for static member functions as to be an easier implementation
to parse.
BUG=none
TEST=builds
Change-Id: If3970d850989eafc59cec9158ecfcdafc7a8caea
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/47665
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
