Due to how internal is structured around chipset_flash_enable()
entry we need to prepare a crafted programmer_cfg that contains
a board_enable substructure with data derived from the board_enable
subsystem. While this is certainly not perfection, it does make
clear the relationships between board_enable into chipset_flash_enable
and subsequently the overall internal programmer initialisation
in a RAII fashion at the type level over closure upon global
state that is impossible to reason about.
Also flip predicate in report_nonwl_laptop_detected() and
return early with the trivial base-case.
TEST=`$ sudo ./flashrom -p internal --flash-name`.
Change-Id: I459215253845c2af73262943ce91a36464e9eb06
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/73456
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Converting the printlock function pointer
within the flashchip struct into enum values allows for
the flashchips db to be turn into pure, declarative data.
A nice side-effect of this is to reduce link-time symbol
space of chipdrivers and increase modularity of the
spi25_statusreg.c and related implementations.
BUG=none
TEST=ninja test.
Change-Id: I9131348f72c1010e2c213dca4dc4b675a8d8681e
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69934
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Converting the blockprotect unlock function pointer
within the flashchip struct into enum values allows for
the flashchips db to be turn into pure, declarative data.
A nice side-effect of this is to reduce link-time symbol
space of chipdrivers and increase modularity of the
spi25_statusreg.c and related implementations.
BUG=none
TEST=ninja test.
Change-Id: Ie5c5db1b09d07e1a549990d6f5a622fae4c83233
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69933
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
A NULL func pointer is necessary and sufficient for the
condition `NULL func pointer => true' as to not need this
boilerplate as it implies default behaviour of a supported
opcode within the `check_block_eraser()` match supported loop.
Ran;
```
$ find . -name '*.[c,h]' -exec sed -i '/.probe_opcode = default_spi_probe_opcode,/d' '{}' \;
```
Change-Id: Id502c5d2596ad1db52faf05723083620e4c52c12
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70264
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Add [erase,walk]_by_layout_new to use optimised implementations of the
erase function selection algorithm.
Change-Id: Id79ae943eb9d6a817da28381db477725834faaf6
Signed-off-by: Aarya Chaumal <aarya.chaumal@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/71173
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
As part of a GSoC project to optimise the erasure path in flashrom
a completely different algorithm is used to perform erasure. Therefore
we need a mechanism to have the two implementations side by side to
allow for A/B testing and easy reverts should issue arise.
Change-Id: Ib5660db0067c1c799dcb5c8e83b4a4826b236442
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/71119
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
The dummyprogrammer in the opaque case can have a NOP delay
to avoid wasting CPU time and energy.
BUG=b:266014935
TEST=builds
Change-Id: Ia86ad21f011214abc2aa0891a43559f91e2a9591
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/72424
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Only picked up by internal test infra in ChromeOS when
instrumenting futility(1).
The following error was incured,
```
>> Starting firmware updater.
>> Target image: images/bios-kindred.ro-12672-141-0.rw-12672-141-0.bin (RO:Google_Kindred.12672.141.0, RW/A:Google_Kindred.12672.141.0, RW/B:Google_Kindred.12672.141.0).
INFO: update_firmware: Loading current system firmware...
INFO: load_system_firmware: flashrom -r <IMAGE> -p host
Warning: Setting BIOS Control at 0xdc from 0x8b to 0x89 failed.
New value is 0x8b.
At least some flash regions are read protected. You have to use a flash
layout and include only accessible regions. For write operations, you'll
additionally need the --noverify-all switch. See manpage for more details.
read_flash: cannot read inside Management Engine region (0x001000..0x3fffff).
Read operation failed!
ERROR: do_update: Cannot load system active firmware.
```
despite the appropriate flag being set within futility(1).
BUG=b:266748702
TEST=cros fw updates.
Change-Id: Ie04cd62020ca29775fc66a81d2fadd32a5aab5cd
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/72454
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The full writeprotect implementation has proper support and
ability to unlock flash over spi25_statusreg.c. Therefore if
the required bits are available for the given chip prefer
proper writeprotect support instead of adhoc spi25_statusreg.c
helpers.
BUG=b:237485865
BRANCH=none
TEST=Tested on grunt DUT (prog: sb600spi, flash: W25Q128.W):
`flashrom --wp-range 0x0,0x1000000 \
flashrom --wp-status # Result: range=0x0,0x1000000 \
flashrom -w random.bin # Result: success \
flashrom -v random.bin # Result: success \
flashrom --wp-status # Result: range=0x0,0x1000000`
TEST=Tested that chips without WP support can still be unlocked
by deleting decode_range for W25Q128.W flashchip and
retesting on the grunt DUT.
Change-Id: I74b3f5d3a17749ea60485b916b2d87467a5d8b2f
CoAuthored-by: Nikolai Artemiev <nartemiev@google.com>
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69517
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Chip restore callbacks currently are used by
- spi25_statusreg.c unlock functions to restore status register 1.
- s25f.c to restore config register 3.
Both of these cases only need to save a single uint8_t value to restore
the original chip state, however storing a void pointer will allow more
flexible chip restore behaviour. In particular, it will allow
flashrom_wp_cfg objects to be saved and restored, enabling
writeprotect-based unlocking.
BUG=b:237485865,b:247421511
BRANCH=none
TEST=Tested on grunt DUT (prog: sb600spi, flash: W25Q128.W):
`flashrom --wp-range 0x0,0x1000000 \
flashrom --wp-status # Result: range=0x0,0x1000000 \
flashrom -w random.bin # Result: success \
flashrom -v random.bin # Result: success \
flashrom --wp-status # Result: range=0x0,0x1000000`
Change-Id: I311b468a4b0349f4da9584c12b36af6ec2394527
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70349
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: Anastasia Klimchuk <aklm@chromium.org>
The new erase algorithm uses some of the functions which are static to
`flashrom.c`. So make these functions global and add prototypes to
`include\flash.h` and `include\layout.h'.
Change-Id: I7ee7e208948337b88467935fd2861b5f9ad6af9d
Signed-off-by: Aarya Chaumal <aarya.chaumal@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/71174
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
The 'all_skipped' global state can be made into a function
parameter if one just follows though the CFG. Running
`flashrom -p dummy:emulate=SST25VF032B,image=r.bin -w r.bin` displays
the message "Warning: Chip content is identical to the requested image."
Change-Id: I2346c869c47b48604360b0facf9313aae086c8dd
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Co-authored-by: Aarya Chaumal <aarya.chaumal@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67093
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Validate (flash->chip->bustype == BUS_SPI) as ich copies the
chip flags in the opaque master and tries incorrectly
to issue 4BA commands which results in failure.
The issue was detected only in the case of chips >16MB, in
this case 'W25Q256FV' that has the feature bits:
```
.feature_bits = FEATURE_WRSR_WREN | FEATURE_OTP | FEATURE_4BA_ENTER_WREN |
FEATURE_4BA_EAR_C5C8 | FEATURE_4BA_READ | FEATURE_4BA_FAST_READ |
FEATURE_WRSR2,
```
The regression was noticed from,
commit 0741727925b841c2479b993204ce58c5eb75185a ichspi.c: Read chip ID and use it to populate `flash->chip`
TEST=In the case of 'W25Q256FV' on TigerLake.
Change-Id: I7cce4f9c032d33c01bf616e27a50b9727a40fe1b
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/71269
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-by: Sam McNally <sammc@google.com>
Skip unwritable regions if FLASHROM_FLAG_SKIP_UNWRITABLE_REGIONS is
true. If the flag is false, erase operations that include an unwritable
region will not erase anything and return an error.
BUG=b:260440773
BRANCH=none
TEST=flashrom -E on dedede (JSL)
Change-Id: If027a96a024782c7707c6d38680709a1a117f3ef
CoAuthored-by: Edward O'Callaghan <quasisec@google.com>
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70517
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Make write_flash() skip unwritable regions if
FLASHROM_FLAG_SKIP_UNWRITABLE_REGIONS is true. If the flag is false
write operations that include an unwritable region will not write
anything and return an error.
BUG=b:260440773
BRANCH=none
TEST=flashrom -w on dedede (JSL)
Change-Id: Idacf0d5218da9d9929f4877fc7665fe608b87fe0
CoAuthored-by: Edward O'Callaghan <quasisec@google.com>
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70516
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update the check_block_eraser function to use probe_opcode to see if the
given block_eraser is supported by the spi master. This will help to get
a real count of usable block_erasers.
Change-Id: I6591a84ae1fe5bc1648051cc30b9393450033852
Signed-off-by: Aarya Chaumal <aarya.chaumal@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66717
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Make verify_flash() skip read/write-protected regions based on the
FLASHROM_FLAG_SKIP_UNREADABLE and FLASHROM_FLAG_SKIP_UNWRITABLE flags.
If FLASHROM_FLAG_SKIP_UNREADABLE is false, read-protected regions will cause
verification to fail.
If FLASHROM_FLAG_SKIP_UNWRITABLE is false, read-only regions will still
be verified and any mismatch will cause verification to fail. It can be
useful to set the flag to true so that expected mismatches in read-only
regions are ignored by verify_range() after flashing.
BUG=b:260440773
BRANCH=none
TEST=flashrom -v on dedede (JSL)
Change-Id: I61dfadd3c75365f2e55abeea75f673ab791ca5cc
CoAuthored-by: Edward O'Callaghan <quasisec@google.com>
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70515
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Skip read-protected regions if FLASHROM_FLAG_SKIP_UNREADABLE_REGIONS is
true. If the flag is false, read operations that include an
read-protected region will return an error.
BUG=b:260440773
BRANCH=none
TEST=flashrom -r on dedede (JSL)
Change-Id: I22c795d7d08ef8bf773733d9952967b2fa2ef299
CoAuthored-by: Edward O'Callaghan <quasisec@google.com>
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70514
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The romentry structure is the container ADT with some
annotated meta-data such as 'included' or 'file' however
the substantive substructure is a 'flash_region'. Therefore
factor this out.
That is to say, the link list node 'romentry' is obscured by the implementation details of its use-case of 'flash_region' that we
clear up here.
BUG=b:260440773
BRANCH=none
TEST=flashrom_tester
Change-Id: I768742b73db901df5b5208fcbcb8a324a06014c2
CoAuthored-by: Nikolai Artemiev <nartemiev@google.com>
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69196
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
Handle the special cases of both serprog and ch341a_spi.
Also rewrite programmer_delay() to handle the two base
cases of zero time and no valid flashctx yet before
handling per master branching.
Additionally, modify the custom delay function pointer
signature to allow closure over the flashctx. This allows
driver specific delay implementations to recover programmer
specific opaque data within their delay implementations.
Therefore programmer specific delay functions can avoid
programmer specific globals.
Change-Id: Id059abb58b31a066a408009073912da2b224d40c
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67393
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Do not just exit in the middle of the process, rather return
a value back up to the caller to allow proper resource cleanup's
to occur.
Change-Id: Ie4186a40071e9a7296d601582ff15ad7df09c70a
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69474
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The 'chip_safety_check()' already validates the chip structure
within 'prepare_flash_access()' before all subsequent chip operations
such as 'verify_range()' and therefore the chip structure is
guaranteed to be valid in the domain of those operations.
BUG=none
BRANCH=none
TEST=builds
Change-Id: Ifc57dd89715115e03d013691352463a8b3c0dc52
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69471
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The fallback_{un}map() boilerplate code doesn't do anything,
merely distracts away from otherwise linear control flow. Just
drop it as anything in the future that could need such a thing
is free to implement it when required.
Change-Id: Ibb7760f807fae040416cef2797a7dbf6572f7df9
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68963
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
This forges the way for flashchips.c to be pure declarative
data and lookup functions for dispatch to be pure. This
means that the flashchips data could be extracted out to
be agnostic data of the flashrom code and algorithms.
Change-Id: I02ae7e4c67c5bf34ec2fd7ffe4af8a2aba6fd5e5
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69133
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This paves the way to allow for the conversion of flashchip erase_block
func ptr to enumerate values. This change should be a NOP.
TEST=`diff -u <(objdump -D flashchips.o_bk) <(objdump -D flashchips.o)`.
Change-Id: I122295ec9add0fe0efd27273c9725e5d64f6dbe2
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69131
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Apart from the very bespoke case of 'probe_w29ee011()'
the override 'chip_to_probe' name is a nature parameter
to 'probe_flash()'. However we can deal with w29ee011
by providing a probe specific validation function to
check if the chip can indeed be overriden.
TEST=`./flashrom -p internal --flash-name`.
Change-Id: Ifcdace07ea2135d83dea92cfa5c6bec8d7ddf05d
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67091
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
This forges the way for flashchips.c to be pure declarative
data and lookup functions for dispatch to be pure. This
means that the flashchips data could be extracted out to
be agnostic data of the flashrom code and algorithms.
TEST='R|W|E && --flash-name' on ARM, AMD & Intel DUT's.
Change-Id: I612d46fefedf2b69e7e2064aa857fa0756efb4e7
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66788
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This forges the way for flashchips.c to be pure declarative
data and lookup functions for dispatch to be pure. This
means that the flashchips data could be extracted out to
be agnostic data of the flashrom code and algorithms.
TEST='R|W|E && --flash-name' on ARM, AMD & Intel DUT's.
Change-Id: I80149de169464b204fb09f1424a86fc645b740fd
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66782
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
This forges the way for flashchips.c to be pure declarative
data and lookup functions for dispatch to be pure. This
means that the flashchips data could be extracted out to
be agnostic data of the flashrom code and algorithms.
TEST='R|W|E && --flash-name' on ARM, AMD & Intel DUT's.
Change-Id: I00aaab9c83f305cd47e78c36d9c2867f2b73c396
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66781
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
The count_max_decode_exceeding() function is only ever called
within the cli_classic logic so move it there and make it
static. This further cleans up the flashrom.c symbol namespace.
Change-Id: If050eab7db8560676c03d5005a2b391313a0d642
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68438
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
The 'programmer' intended to be used in the control flow
of 'programmer_init()' is a parameter to the function. Therefore
use that symbol directly over the global copy of it.
Change-Id: I71e61f0633bac2fc472971249910bf3bf57cd0eb
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68249
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
get_default_layout() is undefined without a
init_default_layout() so separate out that logic
from probe_flash().
Change-Id: I8fd0af8fb1c32dc9f2b00cc39b518d2f4d98e3ac
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68296
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
As suggested by Angel Pons, add the function `is_internal_programmer`
to cut down on some pre-processor usage by moving it into the new
function.
The function then checks if the internal programmer is the
selected one. If the internal programmer is not built in, then it
just returns false.
Change-Id: I43243b990192077583a9a3a95d35844923d9c158
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66684
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
No opaque masters have a custom mapper. The returned chipaddr is not
fed back into the read/write/erase functions, so this would only be
useful for side effects.
Change-Id: I36f05154edda371b51f8ff416f019837ff1c243d
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68092
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
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>
Drop the explicit need to specify the default 'fallback_{un}map'
callback function pointer from the 'programmer_entry' struct.
This is a reasonable default for every other driver in the tree
with only a select few exceptions [atavia, serprog, dummyflasher
and internal].
Thus this simplifies driver development and paves way
to remove the 'programmer' global handle.
Change-Id: I5ea7bd68f7ae2cd4af9902ef07255ab6ce0bfdb3
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67404
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Drop the explicit need to specify the default 'internal_delay'
callback function pointer in the programmer_entry struct.
This is a reasonable default for every other driver in the
tree with only the two exceptions of ch341a_spi.c and serprog.c.
Thus this simplifies driver development.
Change-Id: I17460bc2c0aebcbb48c8dfa052b260991525cc49
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67391
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The `programmer_param` global variable is only valid within the scope of
the `programmer_init()` function, which calls a programmer-specific init
function that calls `extract_programmer_param_str()` to obtain the value
of programmer-specific parameters.
Get rid of this global variable by piping the "programmer_param" string
through a function parameter specifically added for this purpose in the
past, but was not used yet.
Change-Id: I59397451ea625bd431b15848bad5ec7cb926f22d
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67649
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>
Reviewed-by: Thomas Heijligen <src@posteo.de>
The signature of extract_param() was wrong all the time. It actually
modifies the passed, global `programmer_param` string. This only com-
piled w/o warnings because of a deficiency of the strstr() API. It
takes a const string as argument but returns a mutable pointer to
a substring of it.
As we take a const parameter string in the libflashrom API and should
not change that, we create a copy in programmer_init() instead.
Now that we free our copy of the programmer parameters at the end of
programmer_init() it's more obvious that the string can only be used
during initialization. So also clear `programmer_param` inside
programmer_init() instead of programmer_shutdown().
Change-Id: If6bb2e5e4312b07f756615984bd3757e92b86b0a
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67094
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
By leveraging the programmer_cfg state machine passed
into programmer init() entry-points we may now directly
pass programmer parameterisation values and thus rid
ourseleves of the singleton pattern around programmer_param.
Change-Id: I778609e370e44ad2b63b8baa4984ac03ff4124d8
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66659
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Use the bool type instead of an integer for the variable
`programmer_may_write`, since this represents its purpose much better.
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Change-Id: I69958527ae018a92f1c42734a7990d0c532dee0c
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66885
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
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: I6629f391284c8f1266e4ba66c9976f3df43955d4
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66883
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
