summaryrefslogtreecommitdiffstats
path: root/flash.h
Commit message (Collapse)AuthorAgeFilesLines
* Introduce an `include` directory for header filesThomas Heijligen2022-04-291-494/+0
| | | | | | | | | | | | Move all header files to the new `include` directory. Adapt include directives and build systems to the new directory. Change-Id: Iaddd6bbfa0624b166d422f665877f096983bf4cf Signed-off-by: Felix Singer <felix.singer@secunet.com> Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/58622 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
* writeprotect: add WPS bit and always set it to zeroSergii Dmytruk2022-04-291-0/+3
| | | | | | | | | | | | | | | WPS bit controls use of individual block protection which is mutually exclusive with protection based on ranges. Proper support requires extension of the API as well as implementation, so here we're just making sure that range-based protection is enabled and our WP configuration is not ignored by the chip. Change-Id: I2c26ec65d64a3b6fb1f1a73690bc771415db2744 Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/60231 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nikolai Artemiev <nartemiev@google.com> Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
* spi25_statusreg.c: add SR3 read/write supportSergii Dmytruk2022-04-291-0/+1
| | | | | | | | | | | | | | | | Adds support for reading and writing the third status register. Feature flag is not needed because it would never on its own control whether SR3 access occurs. If added, it would be in one of three possible states: wrong, useless or redundant. Change-Id: Id987c544c02da2b956e6ad2c525265cac8f15be1 Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/60230 Reviewed-by: Anastasia Klimchuk <aklm@chromium.org> Reviewed-by: Nikolai Artemiev <nartemiev@google.com> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* Drop STANDALONE modeThomas Heijligen2022-04-131-2/+0
| | | | | | | | | | | | | | | | STANDALONE mode was used to build flashrom without having support for file handling. This was relevant to build libflashrom on top of libpayload. For a while now, the code which is covered by STANDALONE has moved to cli_*.c and is not used for libflashrom. Therefore we can drop STANDALONE mode. Change-Id: I58fb82270a9884a323d9850176708d230fdc5165 Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/63469 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
* flashchips,writeprotect_ranges: add range decoding functionNikolai Artemiev2022-03-011-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow chips to specify functions that map status register bits to protection ranges. These are used to enumerate available ranges and determine the protection state of chips. The patch also adds a range decoding function for the example chips. Many other chips can also be handled by it, though some will require different functions (e.g. MX25L6406 and related chips). Another approach that has been tried in cros flashrom is maintaining tables of range data, but it quickly becomes error prone and hard to validate. Using a function to interpret the ranges allows compact encoding with most chips and is flexible enough to allow chips with less predictable ranges to be handled as well. BUG=b:195381327,b:153800563 BRANCH=none TEST=dumped range tables, checked against datasheets Change-Id: Id163ed80938a946a502ed116e48e8236e36eb203 Signed-off-by: Nikolai Artemiev <nartemiev@google.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/58480 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
* flash.h,flashchips.c: add writeprotect bit layout map to chipsNikolai Artemiev2022-03-011-0/+50
| | | | | | | | | | | | | | | | | | | | | | | | This patch adds a register bit map `struct reg_bit_info`, with fields for storing the register, bit index, and writability of each bit that affects the chip's write protection. This allows writeprotect code to be independent of the register layout of any specific chip. The new fields have been filled out for example chips. The representation is centered around describing how bits can be accessed and modified, rather than the layout of registers. This is generally easier to work with in code that needs to access specific bits and typically requires specifying the locations of fewer bits overall. BUG=b:195381327,b:153800563 BRANCH=none TEST=flashrom --wp-{enable,disable,range,list,status} at end of patch series Change-Id: Id08d77e6d4ca5109c0d698271146d026dbc21284 Signed-off-by: Nikolai Artemiev <nartemiev@google.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/58477 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
* spi25_statusreg,flashchips: add SR2 read/write supportNikolai Artemiev2022-02-281-0/+3
| | | | | | | | | | | | | | | | | | | | | This patch adds support for reading and writing the second status register and enables it on a limited set of flash chips. Chip support for RDSR2/WRSR2/extended WRSR is represented using feature flags to be consistent with how other SPI capabilities are represented. BUG=b:195381327,b:153800563 BRANCH=none TEST=flashrom -{r,w,E} TEST=flashrom --wp-{enable,disable,range,list,status} at end of patch series TEST=logged SR2 read/write values during wp commands Change-Id: I34a503b0958e8f2f22a2a993a6ea529eb46b41db Signed-off-by: Nikolai Artemiev <nartemiev@google.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/58570 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Anastasia Klimchuk <aklm@chromium.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
* spi25_statusreg: make register read/write functions genericNikolai Artemiev2022-02-281-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds new spi_{read,write}_register() functions that take the source/destination register as an argument. Currently they can only access SR1, support for other registers will be added in another patch. Since we're refactoring things, this commit also makes spi_read_register() return an error code, making it possible to identify error conditions that spi_read_status_register() concealed. This also removes the initial 100ms delay between writing a register and the first attempt to check the chip's status. An initial delay was added to avoid needing to read the status register multiple times, but that is unlikely to cause problems on modern flash chips. BUG=b:195381327,b:153800563 BRANCH=none TEST=flashrom -{r,w,E} TEST=flashrom --wp-{enable,disable,range,list,status} at end of patch series Change-Id: I0a3951bbf993f2d8d830143b29d3ce16cc6901d7 Signed-off-by: Nikolai Artemiev <nartemiev@google.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/58475 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Anastasia Klimchuk <aklm@chromium.org> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
* writeprotect, cli_classic: delete old writeprotect codeNikolai Artemiev2022-02-281-1/+0
| | | | | | | | | | | | | | | | | | | | | Delete writeprotect code that was previously extracted from the cros tree. This is the first of a series of commits adding writeprotect support. Following commits incrementally implement writeprotect operations, culminating in writeprotect support for three example chips: GD25LQ128, GD25Q32, and GD25Q256. BUG=b:195381327,b:153800563 BRANCH=none TEST=flashrom -{r,w,E} TEST=flashrom --wp-{enable,disable,range,list,status} at end of patch series Change-Id: I67e9b31f86465e5a8f7d3def637198671ee818a8 Signed-off-by: Nikolai Artemiev <nartemiev@google.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/58474 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
* flashrom.c: Move do_*() helpers into cli_classic.cEdward O'Callaghan2022-01-271-4/+0
| | | | | | | | | | | | | | | These helpers are only used by the CLI logic and so we localise them here to move towards cli_classic being a pure libflashrom user. BUG=b:208132085 TEST=`make` Change-Id: If1112155e2421e0178fd73f847cbb80868387433 Signed-off-by: Edward O'Callaghan <quasisec@google.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/60070 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
* flashrom.c: Make {read,write}_buf_from_include_args() publicEdward O'Callaghan2022-01-271-0/+2
| | | | | | | | | | | | | | | This allows for moving all the do_*() helper functions use for the cli from flashrom.c within static local functions in cli_classic.c BUG=b:208132085 TEST=`make` Change-Id: Ia0abec655a682ca449d0e8ba620886a2d616b86d Signed-off-by: Edward O'Callaghan <quasisec@google.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/60069 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
* cli_classic.c: Convert do_erase() to libflashrom callEdward O'Callaghan2022-01-221-1/+1
| | | | | | | | | | | | | | | | | Inline emergency_help_message() to cli_classic call site. This leaves do_erase() a redudant wrapper and moves us a step closer to cli_classic as a pure libflashrom user by using flashrom_flash_erase(). BUG=b:208132085 TEST=`flashrom -E` Change-Id: I8566164e7dbad69cf478b24208014f10fb99e4d0 Signed-off-by: Edward O'Callaghan <quasisec@google.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/60068 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
* hwaccess: replace flashrom specific macros by compiler definesThomas Heijligen2021-10-151-2/+0
| | | | | | | | | | Replace the remaining IS_* macros with the associated compiler defines Change-Id: Ia0f022d12390722816066d292e1878824adc613c Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.de> Reviewed-on: https://review.coreboot.org/c/flashrom/+/58280 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
* flashrom.c: Make extract_param() static localEdward O'Callaghan2021-07-161-1/+0
| | | | | | | | | | | | | | | The function is only ever used within flashrom.c. BUG=none BRANCH=none TEST=builds Change-Id: I81f1cdb9df98c151201390edeb69c74defe7881f Signed-off-by: Edward O'Callaghan <quasisec@google.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/56295 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
* layout: Tidy up the include-args APINico Huber2021-06-261-4/+0
| | | | | | | | | | | | Move all forward declarations into `layout.h`, use consistent naming. Change-Id: I0e87c9d91b9bc4d78f9cee98caff6985803f7be7 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/flashrom/+/54287 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Anastasia Klimchuk <aklm@chromium.org> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* layout: Kill the global layoutNico Huber2021-06-261-1/+0
| | | | | | | | Change-Id: Ic302e9c5faf1368e5ca244ce461e55e14f916ab8 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/flashrom/+/54286 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
* layout: Rework normalize_romentries() APINico Huber2021-06-261-1/+0
| | | | | | | | | | | | | | Rename it to layout_sanity_checks() as that is what it does and let it work on the currently active layout instead of the global layout. Change-Id: Ifae3480d4bd68c939c291f05734544e93f00306c Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/flashrom/+/54285 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Anastasia Klimchuk <aklm@chromium.org> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* layout: Introduce flashrom_layout_new()Nico Huber2021-06-261-1/+1
| | | | | | | | | | | | | | | | | It initializes an empty layout. Currently the maximum number of entries has to be specified, which will vanish once we use dynamic allocation per entry. We replace the two special cases `single_layout` and `ich_layout` with dynamically allocated layouts. As a result, we have to take care to release the `default_layout` in a flashctx once we are done with it. Change-Id: I2ae7246493ff592e631cce924777925c7825e398 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/flashrom/+/33543 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
* cli_classic.c: add -x option for do_extract()Daniel Campello2021-05-021-0/+1
| | | | | | | | | | | | | | This change introduces a new option to extract all layout regions to files with the name of each region (or with the provided filename via -i region:file). It is implemented by mutating the flash layout to include all regions and backfilling the entry->file with entry->name (replacing spaces with underscores) Signed-off-by: Daniel Campello <campello@chromium.org> Change-Id: I8c69223fa92cf5b50abe070f1ab9f19d3b42f6ff Reviewed-on: https://review.coreboot.org/c/flashrom/+/52450 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
* layout: Add -i <region>[:<file>] supportDaniel Campello2021-04-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add an optional sub-parameter to the -i parameter to allow building the image to be written from multiple files. This will also allow regions to be read from flash and written to separate image files. This is a rebase of a patch that was ported from chromiumos. A lot of things have changed, but the idea is the same. Original patch by Louis Yung-Chieh Lo <yjlou@chromium.org>: Summary: Support -i partition:file feature for both read and write. Commit: 9c7525f Review URL: http://codereview.chromium.org/6611015 Ported version by Stefan Tauner <stefan.tauner@student.tuwien.ac.at> and Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>: Summary: [PATCH 2/6] layout: Add -i <region>[:<file>] support. Review URL: https://mail.coreboot.org/pipermail/flashrom/2013-October/011729.html Change-Id: Ic5465659605d8431d931053967b40290195cfd99 Signed-off-by: David Hendricks <dhendrix@chromium.org> Signed-off-by: Stefan Tauner <stefan.tauner@student.tuwien.ac.at> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Edward O'Callaghan <quasisec@google.com> Signed-off-by: Daniel Campello <campello@chromium.org> Co-Authored-by: Edward O'Callaghan <quasisec@google.com> Co-Authored-by: Daniel Campello <campello@chromium.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/23021 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Sam McNally <sammc@google.com> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
* flashrom.c: implement chip restore callback registrationNikolai Artemiev2020-12-031-0/+11
| | | | | | | | | | | | | | | | | | | | 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>
* flash.h: Trivial indent fix of commentEdward O'Callaghan2020-12-011-3/+4
| | | | | | | | | | | 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>
* flashrom.c,flash.h: Kill dead fn shutdown_free()Edward O'Callaghan2020-10-241-1/+0
| | | | | | | | | | | | | | Seems to be dead code with no call sites. BUG=none BRANCH=none TEST=builds Change-Id: Ic9f33415b8a357916891cb2006612cbf5e6aa559 Signed-off-by: Edward O'Callaghan <quasisec@google.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/46546 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Sam McNally <sammc@google.com>
* Add writeprotect support infrastructureEdward O'Callaghan2020-09-281-0/+4
| | | | | | | | | | | | | | | | The following just lays out the structure for write protect manipulation of SPI flash chips in Flashrom. We later follow up with adding support for each manufacturer group. BUG=b:153800563 BRANCH=none TEST=builds Change-Id: Id93b5a1cb2da476fa8a7dde41d7b963024117474 Signed-off-by: Edward O'Callaghan <quasisec@google.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/40325 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* Revert "flashchips: port S25FS(128S) chip from chromiumos"Nico Huber2020-05-011-3/+0
| | | | | | | | | | | | | | | | | | | | | This reverts commit a3519561bd0fb44153bb376322b799000657576f. Breaks support for most SPI flash chips. It's too big and too invasive to be reviewed as a single commit. The changes to `spi_poll_wip():spi25.c` were not noticed in the original review that were from the similarly named function and file `s25f_poll_status():s25f.c` in the downstream Chromium fork. V.2: Rebase and rephrase commit msg to reflect how the issue slipped in. Change-Id: Id2a4593bdb654f8a26957d69d52189ce61621d93 Signed-off-by: Edward O'Callaghan <quasisec@google.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/40626 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Shiyu Sun <sshiyu@google.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
* const'ify flashctx to align signatures with cros flashromEdward O'Callaghan2020-04-301-2/+2
| | | | | | | | | | | | | | | | The ChromiumOS flashrom fork has since const'ify flashctx in a few places. This aligns the function signatures to match with downstream to ease forward porting patches out of downstream back into mainline flashrom. This patch is minimum viable alignment and so feedback is welcome. Change-Id: Iff6dbda13cb0d941481c0d204b9c30895630fbd1 Signed-off-by: Edward O'Callaghan <quasisec@google.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/40324 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* flashchips: port S25FS(128S) chip from chromiumossibradzic2020-04-221-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This may seem too big just to support yet another flash chip, but in reality it brings support for whole new family of S25FS Spansion/Cypress flash chips. These chips require handling of some special status registers for erasing or writing, with very specific timing checks in place. For example, WIP status bit will remain being set to 1 if erase or programming errors occur, and in that case chip 'software reset' has to be performed otherwise the chip will remain unresponsive to all further commands. Also, special CR3NV register (Configuration Register 3 Nonvolatile) status bits needs to be read and set by using RDAR (ReaD Any Register) and WRAR (WRite Any Register) OP commands, and these states are needed to determine which type of reset feature is enabled at the time (legacy or S25FS type) in the first place, determine whether Uniform or Hybrid sector architecture is used at the time, or set programming buffer address wrap point (256 or 512 bytes). Furthermore, S25FS chip status register has to be restored to its original state (hence that ugly CHIP_RESTORE_CALLBACK) following erasing or writing, failing to do so may result in host being unable to access data on the chip at all. Finally, although this brings support for the whole family of chips, I only have one such chip to do the actual testing, S25FS128S (Small Sectors), which I had fully tested on ch341a and FT4232H programmers, with confirmed working probe, read, erase and write. Full summary of changes are here: flashchips: add new flashchip sctructure property: .reset add chip definitions: S25FS128S Large Sectors S25FS128S Small Sectors flash: add macro (chip_restore_func_data call-back): CHIP_RESTORE_CALLBACK flashrom: add struct: chip_restore_func_data add call-back function: register_chip_restore spi: add OP codes: CMD_RDAR, CMD_WRAR, CMD_WRAR_LEN, CMD_RSTEN, CMD_RST add register bit function definitions: CR3NV_ADDR, CR3NV_20H_NV add timers: T_W, T_RPH, T_SE spi25: refactor (based on chromiumos implementation) function: spi_poll_wip port these functions from chromiumos: probe_spi_big_spansion s25fs_software_reset s25f_legacy_software_reset s25fs_block_erase_d8 spi25_statusreg: port these functions from chromiumos: spi_restore_status s25fs_read_cr s25fs_write_cr s25fs_restore_cr3nv Most of the ported functions are originally from s25f.c found at https://chromium.googlesource.com/chromiumos/third_party/flashrom with exception of spi_restore_status which is defined in spi25_statusreg.c. The rest of macros and OP codes are defined in same files as in this commit. Change-Id: If659290874a4b9db6e71256bdef382d31b288e72 Signed-off-by: Samir Ibradzic <sibradzic@gmail.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/39822 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
* helpers: Implement strndup() for MinGWMiklós Márton2019-10-041-0/+1
| | | | | | | | | | | Provide strndup implementation if compiled with MinGW because it is a POSIX only method Signed-off-by: Miklós Márton <martonmiklosqdev@gmail.com> Change-Id: If418080bffff1f5961cacf2a300ea9c666682458 Reviewed-on: https://review.coreboot.org/c/flashrom/+/34621 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
* Fix -Wsign-compare troubleNico Huber2019-07-311-1/+5
| | | | | | | | | | | Mostly by changing to `unsigned` types where applicable, sometimes `signed` types, and casting as a last resort. Change-Id: I08895543ffb7a48058bcf91ef6500ca113f2d305 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/flashrom/+/30409 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jacob Garber <jgarber1@ualberta.ca>
* spi: Move 16MiB partitioning up into spi_chip_read()Nico Huber2019-06-211-0/+6
| | | | | | | | | | | | | We enforced a 16MiB limit in spi_read_chunked() for multi-die flash chips that can't be fully read at once. The same limit can be useful for dediprog programmers. So move it into a more generic place. Change-Id: Iab1fd5b2ea550b4b3ef3e8402e0b6ca218485a51 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/flashrom/+/33613 Reviewed-by: Ryan O'Leary Reviewed-by: ron minnich <rminnich@gmail.com> Reviewed-by: David Hendricks <david.hendricks@gmail.com>
* layout.c: Don't use global variables for included regionsArthur Heymans2019-06-171-2/+2
| | | | | | | | | | | This removes the use of global variables for included region arguments and also uses a linked list to store the arguments. Change-Id: I6534cc58b8dcc6256c2730c809286d8083669a6c Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/flashrom/+/31247 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
* Enable 4BA mode for Spansion 25FL256SNico Huber2018-10-031-6/+8
| | | | | | | | | | | 4BA mode is entered by setting bit 7 for the extended address register. Change-Id: I807bf55d65763a9f48a6a3377f14f4e5288a7a4c Signed-off-by: Nico Huber <nico.h@gmx.de> Tested-by: Michael Fuckner <michael@fuckner.net> Reviewed-on: https://review.coreboot.org/25133 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: David Hendricks <david.hendricks@gmail.com>
* flashchips: Add Spansion 25FL256S......0Nico Huber2018-10-031-0/+3
| | | | | | | | | | | | | | | | The Spansion 25SFL256S supports 4BA through an extended address register, a 4BA mode set by bit 7 of that register, or native 4BA instructions. Enable the former only for now. Unfortunately the S25SF256S uses another instruction to write the exten- ded address register. So we add an override for the instruction byte. Change-Id: I0a95a81dfe86434f049215ebd8477392391b9efc Signed-off-by: Nico Huber <nico.h@gmx.de> Tested-by: Michael Fuckner <michael@fuckner.net> Reviewed-on: https://review.coreboot.org/25132 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: David Hendricks <david.hendricks@gmail.com>
* helpers: Add reverse_byte() and reverse_bytes()Marc Schink2018-08-301-0/+2
| | | | | | | | Change-Id: I9d2e1e2856c835d22eed3b3a34bc0379773dd831 Signed-off-by: Marc Schink <flashrom-dev@marcschink.de> Reviewed-on: https://review.coreboot.org/28086 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
* linux_mtd: Import driver from ChromiumOSDavid Hendricks2018-05-171-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This imports a series of patches from chromiumos for MTD support. The patches are squashed to ease review and original Change-Ids have been removed to avoid confusing Gerrit. There are a few changes to integrate the code: - Conflict resolution - Makefile changes - Remove file library usage from linux_mtd. We may revisit this and use it for other Linux interfaces later on. - Switch to using file stream functions for reads and writes. This consolidated patch is Signed-off-by: David Hendricks <dhendricks@fb.com> The first commit's message is: Initial MTD support This adds MTD support to flashrom so that we can read, erase, and write content on a NOR flash chip via MTD. BUG=chrome-os-partner:40208 BRANCH=none TEST=read, write, and erase works on Oak Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/272983 Reviewed-by: Shawn N <shawnn@chromium.org> This is the 2nd commit message: linux_mtd: Fix compilation errors This fixes compilation errors from the initial import patch. Signed-off-by: David Hendricks <dhendricks@fb.com> This is the 3rd commit message: linux_mtd: Suppress message if NOR device not found This just suppresses a message that might cause confusion for unsuspecting users. BUG=none BRANCH=none TEST=ran on veyron_mickey, "NOR type device not found" message no longer appears under normal circumstances. Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/302145 Commit-Ready: David Hendricks <dhendrix@chromium.org> Tested-by: David Hendricks <dhendrix@chromium.org> Reviewed-by: Shawn N <shawnn@chromium.org> This is the 4th commit message: linux_mtd: Support for NO_ERASE type devices Some mtd devices have the MTD_NO_ERASE flag set. This means these devices don't require an erase to write and might not have implemented an erase function. We should be conservative and skip erasing altogether, falling back to performing writes over the whole flash. BUG=b:35104688 TESTED=Zaius flash is now written correctly for the 0xff regions. Signed-off-by: William A. Kennington III <wak@google.com> Reviewed-on: https://chromium-review.googlesource.com/472128 Commit-Ready: William Kennington <wak@google.com> Tested-by: William Kennington <wak@google.com> Reviewed-by: Brian Norris <briannorris@chromium.org> This is the 5th commit message: linux_mtd: do reads in eraseblock-sized chunks It's probably not the best idea to try to do an 8MB read in one syscall. Theoretically, this should work; but MTD just relies on the SPI driver to deliver the whole read in one transfer, and many SPI drivers haven't been tested well with large transfer sizes. I'd consider this a workaround, but it's still good to have IMO. BUG=chrome-os-partner:53215 TEST=boot kevin; `flashrom --read ...` TEST=check for performance regression on oak BRANCH=none Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/344006 Reviewed-by: David Hendricks <dhendrix@chromium.org> This is the 6th commit message: linux_mtd: make read/write loop chunks consistent, and documented Theoretically, there should be no maximum size for the read() and write() syscalls on an MTD (well, except for the size of the entire device). But practical concerns (i.e., bugs) have meant we don't quite do this. For reads: Bug https://b/35573113 shows that some SPI-based MTD drivers don't yet handle very large transactions. So we artificially limit this to block-sized chunks. For writes: It's not clear there is a hard limit. Some drivers will already split large writes into smaller chunks automatically. Others don't do any splitting. At any rate, using *small* chunks can actually be a problem for some devices (b:35104688), as they get worse performance (doing an internal read/modify/write). This could be fixed in other ways by advertizing their true "write chunk size" to user space somehow, but this isn't so easy. As a simpler fix, we can just increase the loop increment to match the read loop. Per David, the original implementation (looping over page chunks) was just being paranoid. So this patch: * clarifies comments in linux_mtd_read(), to note that the chunking is somewhat of a hack that ideally can be fixed (with bug reference) * simplifies the linux_mtd_write() looping to match the structure in linux_mtd_read(), including dropping several unnecessary seeks, and correcting the error messages (they referred to "reads" and had the wrong parameters) * change linux_mtd_write() to align its chunks to eraseblocks, not page sizes Note that the "->page_size" parameter is still somewhat ill-defined, and only set by the upper layers for "opaque" flash. And it's not actually used in this driver now. If we could figure out what we really want to use it for, then we could try to set it appropriately. BRANCH=none BUG=b:35104688 TEST=various flashrom tests on Kevin TEST=Reading and writing to flash works on our zaius machines over mtd Change-Id: I3d6bb282863a5cf69909e28a1fc752b35f1b9599 Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/505409 Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-by: Martin Roth <martinroth@chromium.org> Reviewed-by: William Kennington <wak@google.com> Reviewed-on: https://review.coreboot.org/25706 Tested-by: David Hendricks <david.hendricks@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
* Remove address from GPLv2 headersElyes HAOUAS2018-04-241-4/+0
| | | | | | | | Change-Id: I7bfc339673cbf5ee2d2ff7564c4db04ca088d0a4 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/25381 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
* Fix compilation with older MinGW versionsAntonio Ospite2018-03-231-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | The __MINGW_PRINTF_FORMAT constant has been defined back in 2012 https://sourceforge.net/p/mingw-w64/mingw-w64/ci/77bc5d6103b5fb9f59fbddab1583e69549913312/ However older toolchains are still around and some user reported the following compilation failure: flash.h:336:1: error: '__MINGW_PRINTF_FORMAT' is an unrecognized format function  type [-Werror=format=]  __attribute__((format(__MINGW_PRINTF_FORMAT, 2, 3))); Fix this by defining the constant when it isn't already; the change does not affect other compilers because it's guarded by "#ifdef __MINGW32__". Setting __MINGW_PRINTF_FORMAT to gnu_printf is exactly what newer MinGW versions do when __USE_MINGW_ANSI_STDIO is defined, which it is in flashrom Makefile. Change-Id: I48de3e4303b9a389c515a8ce230282d9210576fd Tested-by: Miklos Marton <martonmiklosqdev@gmail.com> Signed-off-by: Antonio Ospite <ao2@ao2.it> Reviewed-on: https://review.coreboot.org/25130 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
* Add support for reading the current flash contents from a filePaul Kocialkowski2018-02-111-1/+1
| | | | | | | | | | | | | | | | | | | When developing software that has to be flashed to a flash chip to be executed, it often takes a long time to read the current flash contents (for flashrom to know what pages to erase and reprogram) each time when writing the new image. However, when the flash was just reprogrammed, its current state is known to be the previous image that was flashed (assuming it was verified). Thus, it makes sense to provide that image as a file for the flash contents instead of wasting valuable time read the whole flash each time. Change-Id: Idf153b6955f37779ae9bfb228a434ed10c304947 Signed-off-by: Mike Banon <mikebdp2@gmail.com> Signed-off-by: Paul Kocialkowski <contact@paulk.fr> Reviewed-on: https://review.coreboot.org/23263 Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* Add support for the ENE Embedded Debug Interface EDI and KB9012 ECPaul Kocialkowski2018-02-111-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | The ENE Embedded Debug Interface (EDI) is a SPI-based interface for accessing the memory of ENE embedded controllers. The ENE KB9012 EC is an embedded controller found on various laptops such as the Lenovo G505s. It features a 8051 microcontroller and has 128 KiB of internal storage for program data. EDI can be accessed on the KB9012 through pins 59-62 (CS-CLK-MOSI-MISO) when flash direct access is not in use. Some firmwares disable EDI at runtime so it might be necessary to ground pin 42 to reset the 8051 microcontroller before accessing the KB9012 via EDI. The example of flashing KB9012 at Lenovo G505S laptop could be found here: http://dangerousprototypes.com/docs/Flashing_KB9012_with_Bus_Pirate Change-Id: Ib8b2eb2feeef5c337d725d15ebf994a299897854 Signed-off-by: Mike Banon <mikebdp2@gmail.com> Signed-off-by: Paul Kocialkowski <contact@paulk.fr> Reviewed-on: https://review.coreboot.org/23259 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
* Add support for selecting the erased bit value with a flagPaul Kocialkowski2018-02-111-1/+8
| | | | | | | | | | | | Most flash chips are erased to ones and programmed to zeros. However, some other chips, such as the ENE KB9012 internal flash, work the opposite way. Change-Id: Ia7b0de8568e31f9bf263ba0ad6b051e837477b6b Signed-off-by: Mike Banon <mikebdp2@gmail.com> Signed-off-by: Paul Kocialkowski <contact@paulk.fr> Reviewed-on: https://review.coreboot.org/23258 Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* Add a SPI command class to `struct flashchip`Mike Banon2018-02-111-0/+11
| | | | | | | | | | | | | | | | | | | | By default, we want to probe for SPI25 chips only. Other SPI use cases, like the ENE/EDI protocol, might use commands that can confuse these common chips. Now, flashrom will probe for a chip only if one of these conditions is true: 1) no chip has been specified AND the chip uses the SPI25 commands 2) this chip has been specified by -c | --chip <chipname> The CLI can later be extended to probe for a specific class of chips. Change-Id: I89a53ccaef2791a2ac32904d7ab813da7478a6f0 Signed-off-by: Mike Banon <mikebdp2@gmail.com> Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/23262 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Kocialkowski <contact@paulk.fr>
* flashchips: Revise all 4BA chipsNico Huber2018-01-021-3/+8
| | | | | | | | | | | | | | | | Advertise all 4BA features that are currently supported by flashrom, plus add a new feature flag for the 4BA fast-read instruction. Also, list all supported 3BA and 4BA erase-block functions. As this adds a lot of new code paths that could be taken for these chips, mark them all as untested again. Change-Id: I0598496ee7058e3b170684d366f58e4014e0e871 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/22423 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: David Hendricks <david.hendricks@gmail.com>
* spi25: Revise decision when to enter/exit 4BA modeNico Huber2018-01-021-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of arbitrarily deciding whether to enter 4BA mode in the flash chip's declaration, advertise that entering 4BA mode is supported and only enter it if the SPI master supports 4-byte addresses. If not, exit 4BA mode (the chip might be in 4BA mode after reset). If we can't assure the state of 4BA mode, we bail out to simplify the code (we'd have to ensure that we don't run any instructions that can usually be switched to 4BA mode otherwise). Two new feature flags are introduced: * FEATURE_4BA_ENTER: Can enter/exit 4BA mode with instructions 0xb7/0xe9 w/o WREN. * FEATURE_4BA_ENTER_WREN Can enter/exit 4BA mode with instructions 0xb7/0xe9 after WREN. FEATURE_4BA_SUPPORT is dropped, it's completely implicit now. Also, draw the with/without WREN distinction into the enter/exit functions to reduce code redundancy. Change-Id: I877fe817f801fc54bd0ee2ce4e3ead324cbb3673 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/22422 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: David Hendricks <david.hendricks@gmail.com>
* spi: Move ICH BBAR quirk out of the wayNico Huber2017-12-281-1/+0
| | | | | | | | | | | | | | | | | | | | | Get rid of the layering violations around ICH's BBAR. Move all the weird address handling into (surprise, surprise) `ichspi.c`. Might fix writes for the `BBAR != 0` case by accident. Background: Some ICHs have a BBAR (BIOS Base Address Configuration Register) that, if set, limits the valid address range to [BBAR, 2^24). Current code lifted addresses for REMS, RES and READ operations by BBAR, now we do it for all addresses in ichspi. Special care has to be taken if the BBAR is not aligned by the flash chip's size. In this case, the lower part of the chip (from BBAR aligned down, up to BBAR) is inacces- sible (this seems to be the original intend behind BBAR) and has to be left out in the address offset calculation. Change-Id: Icbac513c5339e8aff624870252133284ef85ab73 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/22396 Reviewed-by: David Hendricks <david.hendricks@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* spi25: Remove now obsolete `four_bytes_addr_funcs` pathNico Huber2017-12-281-8/+1
| | | | | | | | Change-Id: Idb7c576cb159630da2268813388b497cb5f46b43 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/22386 Reviewed-by: David Hendricks <david.hendricks@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* spi25: Enable native 4BA read and write using feature bitsNico Huber2017-12-281-0/+2
| | | | | | | | | | | Prefer the native 4BA instruction when they are supported. In this case, override our logic to decide to use a 4BA address. Change-Id: I2f6817ca198bf923671a7aa67e956e5477d71848 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/22385 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* spi25: Integrate 4BA supportNico Huber2017-12-281-0/+8
| | | | | | | | | | | | | | | | | | Allow 4-byte addresses for instructions usually used with 3-byte addresses. Decide in which way the 4th byte will be communicated based on the state of the chip (i.e. have we enabled 4BA mode) and a new feature bit for an extended address register. If we are not in 4BA mode and no extended address register is available or the write to it fails, bail out. We cache the state of 4BA mode and the extended address register in the flashctx. Change-Id: I644600beaab9a571b97b67f7516abe571d3460c1 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/22384 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* spi25: Introduce spi_simple_write_cmd()Nico Huber2017-12-281-0/+1
| | | | | | | | | | | | spi_simple_write_cmd() executes WREN plus a single byte write and polls WIP afterwards. It's used to replace current spi_erase_chip_*() imple- mentations. Change-Id: Ib244356fa471e15863b52e6037899d19113cb4a9 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/22382 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: David Hendricks <david.hendricks@gmail.com>
* Fix standalone ich_descriptor_tool compilation with MinGW and DJGPPStefan Tauner2017-11-031-1/+1
| | | | | | | | | | | | | | | | TARGET_OS as well as EXEC_SUFFIX were only set when called via the main makefile and even then __USE_MINGW_ANSI_STDIO was not set for MinGW. While at it, also replace the hardcoded gnu_printf printf format attribute with __MINGW_PRINTF_FORMAT which is set according to __USE_MINGW_ANSI_STDIO respectively. Change-Id: Id146f5ba06a0e510397c6f32a2bd7c819a405a25 Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at> Reviewed-on: https://review.coreboot.org/21838 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
* 4BA: Allow disabling 4-byte address mode for SPI flashEd Swierk2017-10-151-9/+2
| | | | | | | | | | | | | | | | | | | | This allows us to support flash chips in any of the following configurations, regardless of whether the chip powers up in 3-byte or 4-byte address mode. - standard commands with extended address register (*_4ba_ereg) or direct commands (*_4ba_direct) in 3-byte address mode (.set_4ba = spi_exit_4ba_*) - standard commands (*_4ba) or direct commands (*_4ba_direct) in 4-byte address mode (.set_4ba = spi_enter_4ba_*) - direct commands (*_4ba_direct) in either address mode (.set_4ba = NULL) Change-Id: I0b25309d731426940fc50956b744b681ab599e87 Signed-off-by: Ed Swierk <eswierk@skyportsystems.com> Reviewed-on: https://review.coreboot.org/20510 Reviewed-by: David Hendricks <david.hendricks@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-06 19:25:26 +0000