As a consecuence, some of the files that used to include flash.h no
longer need to do so. For this reason, flash.h includes are also deleted
in this commit.
Change-Id: I794a71536a3b85fde39f83c802fa0f5dd8d428e0
Signed-off-by: Antonio Vázquez Blanco <antoniovazquezblanco@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/85539
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-by: David Reguera Garcia (Dreg) <regueragarciadavid@gmail.com>
Reviewed-by: Matti Finder <matti.finder@gmail.com>
This is follow up (or fix) for
commit 26a1eb514ccefc61b110068cf0eea73c397ba045
When probing opcode, all opcodes in POSSIBLE_OPCODES are reported as
supported, even if the opcode is not in curopcodes. This is relying
on reprogramming on-the-fly to handle the gap between POSSIBLE_OPCODES
and curopcodes. However, for locked chipsets on-the-fly is not
happening (is not possible, since list of opcodes is locked), so we
can't rely on it.
So, we need to check whether chipset is locked.
Ticket: https://ticket.coreboot.org/issues/573
Change-Id: I701a86f030cfef43a1158bf075287ade569254e6
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Tested-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/85592
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
ich_spi_send_command() and ich_spi_send_multicommand() will overwrite
the "Sector erase" opcode with the opcode for command via
reprogram_opcode_on_the_fly(), but not restore it, causing the "Sector
erase" opcode may get lost after sending commands, leaving only "Bulk
erase" opcode which erase the whole chip available.
In the mean time, ich_spi_probe_opcode() used not to report opcodes in
POSSIBLE_OPCODES[] but not in curopcodes->opcode[] as supported.
Now, if the opcode being probed is not in curopcodes->opcode[] but in
POSSIBLE_OPCODES[], it will be reported as supported, and programmed
later by ich_spi_send_(multi)command().
Fix:https://ticket.coreboot.org/issues/556
Change-Id: I3fc831fc072e2af9265835cb2f71bf8c222c6a64
Signed-off-by: persmule <persmule@hardenedlinux.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/84253
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
There seems no problem to use ich_spi_probe_opcode() for
spi_master::probe_opcode() on ich7, so we may merge former
spi_master_ich7 and spi_master_ich9 into spi_master_ich, for both
init_ich7_spi() and init_ich_default().
Change-Id: I6a65c97e910622a55da7cef8a10de3af6a99c9e8
Signed-off-by: persmule <persmule@hardenedlinux.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/84593
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
POSSIBLE_OPCODES[] is never modified, so mark it as read-only.
Change-Id: I217f8a9e50b9e2e9f2731adec89a46780874c754
Signed-off-by: persmule <persmule@hardenedlinux.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/84595
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
The function for reprogramming on the fly was using the default
configuration O_ST_M25P as a base and the position 2 as the position
to reprogram. Position 2 corresponds to JEDEC_SE which is often useful
for chip erase (when less than whole chip needs to be erased).
This patch changes the default position to reprogram to 4, which
corresponds to JEDEC_REMS. It is used less often, but if it needs to
be used, it will be discovered missing and reprogrammed back.
For erase opcodes, there is usually several of them available. So if
one is missing, erase still can be performed with the remaining ones.
However, this hides the fact that one of available erase opcodes is
missing (it won't be reprogrammed back), and also it gives non-optimal
erase layout.
Context: https://ticket.coreboot.org/issues/556
Change-Id: I6bc855daedf0af2e8de191f23a3512de3ebc3fef
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/84567
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Based on public Intel 700 Series PCH datasheet, DOC 743835 rev 004.
The IDs of IoT chipset SKUs (ending with E) can only be found in "12th
Gen Intel® Core™ Processors Family (Formerly Known as Alder Lake -S)
for IoT Platforms External Design Specification (EDS) Addendum" DOC
634528 rev 2.7 (NDA).
TEST=Probe flash on Z790 chipset. Run the ich_descriptors_tool and
check the output is correct as expected.
Change-Id: I13ac52d5400c0e2260e12d605077fc2182c379ef
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/83854
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
get_flash_region() emits a struct flash_region, which uses chipoff_t for
the start and end addresses of a region. chipoff_t is defined as a valid
flash address, so it was wrong to be setting the end address to start +
len; this is clearly wrong in the case where there is a single region
because setting end to the flash size generates an address that is
beyond the end of the chip (due to zero-indexing).
This changes the one actual implementation of .get_region in ichspi.c to
use inclusive upper bounds, and corrects all callers of
get_flash_region() to treat the upper bounds as inclusive. Overall this
reduces complexity slightly by removing more downward adjustments by 1
than it needs to add upward adjustments.
TEST=on yaviks, `flashrom -V -x` prints equivalent messages about
"x region (0xZZZZ..0xZZZZ) is readable" before and after this
patch.
Change-Id: Ia0ca867aef33b598c2697fc264807fa5e29683ec
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/82496
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hsuan-ting Chen <roccochen@google.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Since Meteor Lake, configuring region access for FREG9 and higher is
necessary. This configuration is determined using BIOS_BM registers:
BIOS_BM_RAP (Offset 0x118): BIOS Master Read Access Permissions.
Each bit [15:0] corresponds to a region [15:0].
A set bit grants BIOS master read access.
BIOS_BM_WAP (Offset 0x11c): BIOS Master Write Access Permissions.
Each bit [15:0] corresponds to a region [15:0].
A set bit grants BIOS master write/erase access.
Move CHIPSET_METEOR_LAKE to the bottom of the ich_chipset list to ensure
that all the newer chipsets in the future will use BIOS_BM check by
default.
BUG=b:319773700, b:304439294
BUG=b:319336080
TEST=On MTL, use flashrom -VV to see correct FREG9 access
TEST=On ADL, use flashrom -VV to see not break anything
TEST=On APL, use flashrom -VV to see not break anything
Change-Id: I1e06e7b3d470423a6014e623826d9234fdebfbf9
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81357
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add Region 9 for Intel Meteor Lake; update missing regions.
* Include Region 9 as officially required for Intel Meteor Lake platform.
* Incorporate missing region names from https://github.com/coreboot/coreboot/blob/main/util/ifdtool/ifdtool.c for completeness.
Region 5: Device Expansion (DE or DevExp)
Region 9: Device Expansion 2 (DE2 or DevExp2)
Region 10: Innovation Engine (IE)
Region 11: 10 GbE 0
Region 12: 10 GbE 1
Region 15: PTT
BUG=b:319773700
TEST=Run `flashrom -VV` on MTL and see all the regions are printed out
Change-Id: I3b164ce4ae84bfd523fcd8be416c5d13183ed632
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81356
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Clean commit 51e1d0e4b7670e5822560acc724a6a8dd00b6af4
'Add support for Intel Emmitsburg PCH' which broke
CHIPSET_5_SERIES_IBEX_PEAK detection and which assumes C740 is the same
as C620, while its more a close relative to Intel's H570 PCH.
Based on Intel SPI Programming Guide #619386.
Test: Run on Intel ArcherCity CRB with Intel's C741 PCH
using the 'internal' programmer.
Test: Run on BMC and accessed the SPI flash chip over
'linux_mtd' programmer.
Change-Id: I80eebc0fcc14de9df823aceaee77870ad136f94a
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/78186
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In ich_hwseq_get_flash_id, flash_id_to_entry would return
address of a structure present in flashchips array
corresponding to provided manufacture_id and model_id.
If this function returns NULL and if we don't return
after printing the warning using msg_pwarn, we'll be
dereferencing a NULL pointer, hence the return in that
if is provided.
Change-Id: I35c112cd032e3b94e30c347766764392d5bbfe3d
Signed-off-by: Eshan Kelkar <eshangalorithm@gmail.com>
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/71872
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
DJGPP for compiling DOS has other sizes for the normal int types and
therefore throwing errors when using %i %d or %x with uint32_t.
Fix these warnings by using the macros created for it and provided in
inttypes.h.
Change-Id: Ia75b6df981ce60c891161fe553c7ceab8570178d
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/73040
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
A NULL func pointer is necessary and sufficient for the
condition `NULL func pointer => default_spi_write_aai' as to not
need this explicit specification of 'default'.
Therefore Drop the explicit need to specify the 'default_spi_write_aai'
callback function pointer in the spi_master struct. This is a reasonable default for every other driver in the tree with only a few exceptions.
This simplifies the code and driver development.
Change-Id: I7f14aaea0edcf0c08cea0e9cd27d58152707fb2a
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67479
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Region attributes are now stored in a `fd_regions` array after being
decoded in ich9_handle_frap() and used by ich_get_region().
A special cases is handled in ich_get_region(): if there is a gap
between two flash regions, an artificial region is created to fill the
gap. I.e. any address inside the gap will return a region that spans the
gap between the end the of the previous region and the start of the next
region. This allows ich_get_region() to be used to iterate the entire
flash region-by-region.
Read and write operations are assumed to be allowed inside gaps between
regions.
BUG=b:260440773
BRANCH=none
TEST=flashrom -{r,w,E,v} on dedede (JSL)
Change-Id: I019f3f407f6a2a82f686a168457e0e32961ff483
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70127
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Read the flash chip vendor/device ID using hardware sequencing, find the
corresponding flashchip entry, and copy it over to `flash->chip`.
Identifying the chip was not previously required as ICH hardware
sequencing handles chip-level details related to read/write/erase ops.
However writeprotect operations require the chip entry to be identified
so that chip->reg_bits can be used to compute status register values.
BUG=b:253715389,b:253713774
BRANCH=none
TEST=flashrom on dedede (JSL) identifies "W25Q128.V..M" chip
TEST=flashrom -{r,v} on dedede
TEST=write/erase bios region on dedede:
flashrom -{E,w} --layout <(echo '0x381000:0xffffff bios') -i bios
Change-Id: Ia408e1e45dc6f53c0934afd6558e301abfa48ee6
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69195
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Damien Zammit
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Move the FCYCLE bit definitions out of the ICH9 definitions and into
their own section because they are used by PCH100 as well.
Rename HSFC_FCYCLE to ICH9_HSFC_FCYCLE because it is specific to ICH9.
BUG=b:253715389,b:253713774
BRANCH=none
TEST=builds
Change-Id: I0996c5331837276049241600e0ffac21a47ec3af
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70458
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Sam McNally <sammc@google.com>
The non-custom driver programmer delay implementation
'internal_delay()' is unrelated specifically to the
'internal' programmer. The delay implementation is
simply a platform-agnostic host delay implementation.
Therefore, rename to simply default_delay().
Change-Id: I5e04adf16812ceb1480992c92bca25ed80f8897a
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68855
Reviewed-by: Alexander Goncharov <chat@joursoir.net>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Replace `programmer_delay(NULL, [..])` calls with direct
`internal_delay([..])` dispatches explicitly. Custom driver
delays remain hooked as well as core flashrom logic. The
NULL base case of 'programmer_delay()' then becomes a condition
to validate for layering violations or invalid flash contexts.
Change-Id: I1da230804d5e8f47a6e281feb66f381514dc6861
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68434
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Make the spi25 register read/write functions return SPI_INVALID_OPCODE
if the programmer blocks the read/write opcode for the register.
Likewise, make ichspi read/write register functions return
SPI_INVALID_OPCODE for registers >SR1 as they cannot be accessd.
Make writeprotect ignore SPI_INVALID_OPCODE unless it is trying to
read/write SR1, which should always be supported.
BUG=b:253715389,b:253713774,b:240229722
BRANCH=none
TEST=flashrom --wp-{enable,disable,range,list,status} on dedede
Change-Id: I2145749dcc51f4556550650dab5aa1049f879c45
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69129
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Probing an opcode generally shouldn't involve mutating the flashctx
state and currently no probe_opcode functions do that.
Make the flashctx arg const so that call sites don't need to have a
non-const pointer.
BUG=b:253715389,b:253713774
BRANCH=none
TEST=ninja test
Change-Id: I19e98be50d682de2d2715417f8b7b8c62b871617
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70030
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch fixes a potential issue where the SPI controller register
HSFC.FDBC (bits 24-29) value gets incorrectly calculated while passing
the `len` as `0` instead of `1`.
As per Intel EDS, `0b` in the FDBC represents 1 byte while `0x3f`
represents 64-bytes to be transferred. The number of bytes
transferred is the value of this field plus 1.
If we would like to transfer 1 byte then we need to set `0b` in
FDBC for operations like read, write, flash id as to account for
the `set byte count` hence, the `len` argument should be `1`.
Additionally, as per EDS, the FDBC field is ignored for any block
erase command.
BUG=b:258280679
TEST=Able to build flashrom and perform below operations on Google,
Rex and Google, Kano/Taeko.
During `--wp-disable` HW seq operation that requires 1 byte data
transfer.
HSFC.FDBC value while passing `len` as `0` = 0x3f (represents 64-byte)
HSFC.FDBC value while passing `len` as `1` = 0x0 (represents 1-byte)
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I5b911655649c693e576497520687d7810bbd3c54
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69789
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch fixes a regression introduced with
commit 7ed1337309d3fe74f5af09520970f0f1d417399a (ichspi: Factor out
common hwseq_xfer logic into helpers).
The reason for the regression is ignoring the fact that the Fast SPI
controller MMIO register HSFC (0x06) might not hold the default zero
value before initiating the HW sequencing operation.
Having a `1b` value in the HSFC.FDBC (bits 24-29) field would represent
a byte that needs to be transfered.
While debugging the regression, we have observed that the default value
in the FDBC (prior to initiate any operation) is 0x3f (instead of
zero) which represents 64-byte transfer.
localhost ~ # iotools mmio_read32 0x92d16006
0x3f00
<Fast SPI MMIO BAR: 0x92d16000 and HSFC offset: 0x06>
FDBC offset during `--wp-disable` operation represents higher numbers of
bytes than the actual and eventually results in the error.
Additionally, dropped unused variable (struct hwseq_data *hwseq_data).
BUG=b:258280679
TEST=Able to build flashrom and perform below operations on Google, Rex
and Google, Kano/Taeko.
Without this patch:
HSFC register value inside ich_start_hwseq_xfer() before initiating
the HW seq operations: 0x3f00
HSFC register value inside ich_start_hwseq_xfer() during the HW seq
operations (Read Status): 0x3f11
With this patch:
HSFC register value inside ich_start_hwseq_xfer() before initiating
the HW seq operations: 0x0
HSFC register value inside ich_start_hwseq_xfer() during the HW seq
operations (Read Status): 0x11
Additionally, verified other HW sequencing operations (like read, write,
erase, read status, write status, read ID) working fine without any
error.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I4cc3f24f880d1d621f1f48a6e6b276449fa46f98
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69788
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Opaque masters, by design, populate the flashchip structure during
the execution of their probe function. Therefore any opaque master
operation displays a message to the user:
"This flash part has status UNTESTED for operations: WP".
However, for all the other operations (read, write, erase) opaque
masters always mark them as tested. Thus, align WP as marked tested
inline with other opaque chip operations.
BUG=b:258755442
TEST=the following does not display untested message:
1) flashrom -p dummy:size=8388608,emulate=VARIABLE_SIZE
2) flashrom -p internal (on Intel device)
Change-Id: I5ae4cb49eb0abc6ab26cfe2f3359e4e50dd4fd4f
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69842
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Align hwseq path in ichspi with the rest of the flashrom tree
by making hwseq_data a heap allocation within the life-time of
the driver managed by the driver registration API.
Change-Id: Ib362c5ab2d3e8afee2c3c7d3135cc4414d6bd6c3
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68774
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Allow helpers to derive driver specific data from the driver
specific context instead of being a closure over a static
global variable.
Change-Id: Ib0ccf4b32fd1e2be2ecc3a4a4c6e397c8e901a0a
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68773
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Change is a NOP to prepare ichspi to remove hwseq_data being
a global symbol in CB:68774. This allows for the helper
functions to derive their data from the driver data context.
Change-Id: I67b5aa6350930d912e5036473ac3e792debac0bd
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68772
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Modify the `programmer_delay` function signature to allow passing
the flashrom context. Programmers that depend on internal delay
should provide NULL as a context. The use of this function parameter
will be introduced in CB:67393.
TOPIC=programmer_handle_global
TEST=builds
Change-Id: Ibb0bce26ce2052853ee52158d7ba742967a9e229
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66373
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
ICH hwseq does not need to actually mmap flash, and this fails for
flash chips >16 MB, since only the top 16 MB is mapped into the address
space.
Test: Read and write flash on ICH hwseq with 32 MB flash chip.
Change-Id: Ie698071c3181e988f10b750b0e50c9700efaa1a3
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68090
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Move (un)map_flash_region function pointers from programmer_entry to
par_master, spi_master, and opaque_master. This enables programmers to
specify a different mapper per bus, which is needed for the internal
programmer. Mapping is closely tied to the way the memory is accessed
using the other functions in the bus master structs.
Validate that FWH/LPC programmers provide specialized mapping in
register_par_master(); this is needed for chips with
FEATURE_REGISTERMAP, which only exist on FWH or LPC buses.
programmer.c: Update comment in fallback_map(), NULL return is the
desired behavior.
Test: Read firmware on SB600 Promontory mainboard (requires physmap)
Test: Read firmware externally with ft2232_spi
Test: Read firmware on ICH hwseq, verify physmap still occurs
Change-Id: I9c3df6ae260bcdb246dfb0cd8e043919609b014b
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Co-Authored-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67695
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
List of changes:
1. Add a unified `execute SPI flash transfer` function that does:
- Check the SCIP bit prior initiate new operation.
- Start the transfer by setting address and length for transfer,
finally set FGO bit.
- Wait for the transaction to get completed/failed/timed out.
2. All HW Sequencing SPI operation uses `execute SPI flash transfer`
function
Note:
The refactoring xfer logic here assumes setting `HSFC_FDBC to 0` while
performing erase operation using `ich_hwseq_block_erase()`. But it does
not impact the erase operations.
BUG=b:223630977
TEST=Able to perform read-status/write-status/read/write/erase
operation on PCH 600 series chipset (board name: google/kano).
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ic9fd50841449e02f476a8834f4642d6ecad36dc3
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62869
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use the bool type instead of an integer for appropriate variables, since
this represents their purpose much better.
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Change-Id: If7eeacc44921f52aa593ab1302f17a5c5190f830
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66892
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Modify the type signature of the programmer entry-point
xxx_init() functions to allow for the consumption of the
programmer parameterisation string data.
Also plumb programmer_cfg though get_params.
Change-Id: I480589bb50b47fdf5af259d068f49fedfce88ea5
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66661
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Results can be reproduced with the following invocation;
```
$ find -name '*.c' -exec sed -i 's/extract_programmer_param_str(/extract_programmer_param_str(NULL, /g' '{}' \;
```
This allows for a pointer to the actual programmer parameters
to be passed instead of a global.
Change-Id: I781a328fa280e0a9601050dd99a75af72c39c899
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66654
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Instead of checking for the variable arg in multiple compound
statements, separate it out in its own branch and return 0 if arg is
NULL.
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Change-Id: Id1038568ff25cf6f0895b26921cc4a0d7bcfabb7
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65248
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
The hwseq_data struct remains to be a stack allocated
instance for now however it is referenced in the opaque_master
data field of the flash ctx. This allows for worker functions
that leverage hwseq_data state to derive state indirectly via
the flash ctx instead of directly upon the global state.
This allows for unblocking further work to finally dispense
with the stack allocation in favour of a heap allocation with
a defined life-time of the driver.
BUG=b:237839418
TEST=builds
Change-Id: I2ad57d496176cf26edcd0ba40154cc6250846e33
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65205
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Alexander Goncharov <chat@joursoir.net>
Reviewed-by: Thomas Heijligen <src@posteo.de>
This patch calls into `ich_hwseq_set_addr` function by passing
flash address `0` while performing Read and Write status operation
as Intel SPI BWG recommends that "SW should program the FADDR every
time before any transaction as FADDR is used to determine which Chip Select, CS0 if FADDR <= device 0 size, else CS1".
The reason behind setting the flash address in this patch is to adhere
to the Intel recommended reference implementation that programs FADDR.
Additionally, the followup patch will factor out `hwseq_xfer` logic
to create a helper function that ensures all SPI related operational
APIs could leverage the common `hwseq_xfer` logic.
BUG=b:223630977
TEST=Able to perform read-status/write-status operation on PCH
600 series chipset (board name: google/kano).
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ib1d85ebdde99a31728f404d66a1eb4e3599b9054
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65468
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add a field, probe_opcode, to struct spi_master which points to a
function returning a bool by checking if a given command is supported by
the programmer in use. This is used for getting a whitelist of commands
supported by the programmer, as some programmers like ichspi don't
support all opcodes.
Most programmers use the default function, which just returns true.
ICHSPI and dummyflasher use their specialized function.
Change-Id: I6852ef92788221f471a859c879f8aff42558d36d
Signed-off-by: Aarya Chaumal <aarya.chaumal@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65183
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch changes the function name of extract_programmer_param() to
extract_programmer_param_str() as this function name will clearly
specify that it returns the value of the given parameter as a string.
Signed-off-by: Chinmay Lonkar <chinmay20220@gmail.com>
Change-Id: Id7b9fff4d3e1de22abd31b8123a1d237cd0f5c97
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65521
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Use `<tab>.key<tab>*= <value>,`
TEST: `make VERSION=0 MAN_DATE=0` returns the same flashrom binary
before and after the patch
Change-Id: I1c45ea9804ca09e040d7ac98255042f58b01f8ef
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65363
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Simplify ich9_handle_frap() to do the translation to the logical
representation of the ich_access_protection enum in one place and
work from there. This removes some unnecessary branch complexity
and the possibility of out of bounds array accesses.
Change-Id: I1eda067c44a84d662713475d13902c85534a59fe
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65189
Reviewed-by: Sam McNally <sammc@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
The ichspi hwseq path has a opaque master specialisation that
allows for reading and writing STATUS1 registers. Hook the callbacks
with a implementation to allow for this so that writeprotect maybe
supported though this path.
BUG=none
BRANCH=none
TEST=flashrom --wp-status on AMD and Intel DUTs
Change-Id: I7ecbe8491ecea3697922c91af26ca62276e86317
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64540
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Just a trivial patch to fix a few errors found by codespell.
Here's the command I used:
codespell -S subprojects,out \
-L fwe,dout,tast,crate,parms,claus,nt,nd,te,truns,trun
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I4e3b277f220fa70dcab21912c30f1d26d9bd8749
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62840
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch introduces useful macros (read/write/erase) and uses these
macros throughout the SPI operations.
Additionally, implicitly using the HSFC_CYCLE_READ macro for the SPI
read operation.
BUG=b:223630977
TEST=Able to perform read/write/erase operation on PCH 600 series
chipset (board name: Brya).
Additionally, no difference in flashrom binary seen while comparing
flashrom binary generated with CB:62888 and between CB:62888 to
CB:62868 below:
flashrom$ cmp flashrom flashrom_old
<<none>>
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I3ea74b668e5f8d8e4b3da2a8ad8b81f1813e1e80
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62868
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
