aboutsummaryrefslogtreecommitdiffstats
path: root/linux_mtd.c
Commit message (Collapse)AuthorAgeFilesLines
* libflashrom,linux_mtd: add linux_mtd writeprotect supportNikolai Artemiev2022-04-051-0/+120
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit adds a generic framework to allow opaque programmers to implement writeprotect operations and uses the framework to support writeprotect operations on linux MTD device files. The generic framework comprises three new functions in `struct opaque_master` that are called from libflashrom: - wp_write_cfg() - wp_read_cfg() - wp_get_ranges() For linux_mtd, only the read/write functions are implemented. Linux's MTD interface doesn't provide a way to get available ranges, so calling get_wp_ranges() on the linux_mtd master will return FLASHROM_WP_ERR_RANGE_LIST_UNAVAILABLE. BUG=b:182223106 BRANCH=none TEST=WP ops on hana DUT (MT8173) with W25Q32DW flash TEST=flashrom --wp-enable --wp-range <non-empty> succeeds TEST=flashrom --wp-enable --wp-range <empty> fails as expected TEST=flashrom --wp-disable --wp-range <empty> succeeds TEST=flashrom --wp-disable --wp-range <non-empty> fails as expected TEST=flashrom --wp-status succeeds Change-Id: I5c86e28cdec44bec49ba1d36f8ab62241b9b01da Signed-off-by: Nikolai Artemiev <nartemiev@google.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/61897 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Anastasia Klimchuk <aklm@chromium.org> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
* linux_mtd: check ioctl() return value properlyNikolai Artemiev2022-01-141-3/+5
| | | | | | | | | | | | | | | | Make the linux_mtd driver treat any negative return value from the MEMERASE ioctl as an error. Previously it only treated -1 as an error. BUG=b:213561594,b:210973586,b:182223106 BRANCH=none TEST=builds Change-Id: I40cfbdee2ab608fbe6c17d9cac6ec53ff224d9a4 Signed-off-by: Nikolai Artemiev <nartemiev@google.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/60996 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
* opaque_master: Use new API to register shutdown functionAnastasia Klimchuk2021-08-251-8/+2
| | | | | | | | | | | | | | | | | | | | | | | This allows opaque masters to register shutdown function in opaque_master struct, which means there is no need to call register_shutdown in init function, since this call is now a part of register_opaque_master. As a consequence of using new API, two things are happening here: 1) No resource leakage anymore in case register_shutdown() would fail, 2) Fixed propagation of register_opaque_master() return values. BUG=b:185191942 TEST=1) builds and ninja test including CB:56413 2) on ARMv7 device flashrom -p linux_mtd -V -> using linux_mtd, chip found Change-Id: Id8471a117556edcbf9694752fabe05cf4501ce70 Signed-off-by: Anastasia Klimchuk <aklm@chromium.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/56825 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
* opaque_master: Move shutdown function above opaque_master structAnastasia Klimchuk2021-08-171-11/+11
| | | | | | | | | | | | | | | | | | This patch prepares opaque masters to use new API which allows to register shutdown function in opaque_master struct. See also later patch in this chain, where opaque masters are converted to new API. BUG=b:185191942 TEST=builds and ninja test Comparing flashrom binary before and after the patch, make clean && make CONFIG_EVERYTHING=yes VERSION=none binary is the same Change-Id: I5000cfceeba859a76177a17c1cb7d1c1e9fc03fe Signed-off-by: Anastasia Klimchuk <aklm@chromium.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/56824 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
* linux_mtd: Free param right after its last usageAnastasia Klimchuk2021-08-171-4/+6
| | | | | | | | | | | | | | | | | Param is only used in the first half of init function, and it is local, so there is no need to keep it until the end. This makes handling error paths in the second half of init function shorter, because those paths can just return 1 instead of going to a label. BUG=b:185191942 TEST=builds and ninja test from CB:56413 Change-Id: I126a8d06297ef4d42bc93a73f7067ccc1352d1e9 Signed-off-by: Anastasia Klimchuk <aklm@chromium.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/56822 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com>
* programmer_table: move each entry to the associated programmer sourceThomas Heijligen2021-06-101-3/+13
| | | | | | | | | Change-Id: I3d02bd789f0299e936eb86819b3b15b5ea2bb921 Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.de> Reviewed-on: https://review.coreboot.org/c/flashrom/+/52946 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Anastasia Klimchuk <aklm@chromium.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
* treewide: Drop unnecessary uses of memset/memcpyAngel Pons2021-06-091-2/+1
| | | | | | | | | | Simply provide an initialiser or use a direct assignment instead. Change-Id: I07385375cd8eec8a95874001b402b2c17ec09e09 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/55267 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
* programmer: Make use of new register_opaque_master() APIAnastasia Klimchuk2021-05-231-3/+2
| | | | | | | | | | | | | | | Pass pointers to dynamically allocated data to register_opaque_master(). This way we can avoid a mutable global. BUG=b:185191942 TEST=builds Change-Id: I160810cd67f782131962e96fc6d20e2987fb0390 Signed-off-by: Anastasia Klimchuk <aklm@chromium.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/54171 Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* programmer: Smoothen register_opaque_master() APIAnastasia Klimchuk2021-05-231-1/+1
| | | | | | | | | | | | | | | | It was impossible to register a const struct opaque_master that would point to dynamically allocated `data`. Fix that so that we won't have to create more mutable globals. BUG=b:185191942 TEST=builds Change-Id: Id3adb4cf04ae04dbe87ddb96f30871cb5f7c8ff0 Signed-off-by: Anastasia Klimchuk <aklm@chromium.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/54170 Reviewed-by: Edward O'Callaghan <quasisec@chromium.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* linux_mtd: drop 'mtd_' prefix from variable/field namesNikolai Artemiev2021-05-131-27/+27
| | | | | | | | | | | | | BUG=b:161951062 BRANCH=none TEST=builds Change-Id: I2503c98e9111d1fecd911473f65eeea7031cfdc3 Signed-off-by: Nikolai Artemiev <nartemiev@google.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/53953 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
* linux_mtd: move global state into programmer data fieldNikolai Artemiev2021-05-131-45/+65
| | | | | | | | | | | | | | BUG=b:161951062 BRANCH=none TEST=builds, reading /dev/mtd0 on Oak succeeds Change-Id: I5ce6900e4892ed5687cfddb245dfe5461a3e2e84 Signed-off-by: Nikolai Artemiev <nartemiev@google.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/53947 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Anastasia Klimchuk <aklm@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
* linux_mtd: Disable buffering on the mtd deviceDouglas Anderson2021-02-011-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We open the device node for the MTD device with this: dev_fp = fopen(dev_path, "r+") In C fopen() is allowed to provide _buffered_ access to the file. That means that the standard library is allowed to read ahead and/or return cached data. That's really not what we want for something like this. Let's turn it off. This fixes a problem where flashrom would sometimes fail to "verify" that it erased the flash. The error message would look something like this: Erasing and writing flash chip... FAILED at 0x0000e220! Expected=0xff, Found=0xe9, failed byte count from 0x0000e200-0x0000e2ff: 0xdc failed byte count from 0x0000e000-0x0000efff: 0xffffffff ERASE_FAILED FAILED! Uh oh. Erase/write failed. Checking if anything changed. After the failure I could read the flash device with a new invocation of flashrom and I would see that, indeed, the erase had worked. Tracing in the kernel showed that when the failure happened we saw a pattern that looked like this: * Read 0x0b00 bytes starting at 0x0000d000 * Read 0x1000 bytes starting at 0x0000db00 * Erase 0x1000 bytes starting at 0x0000e000 ...and then there was _not_ a read after the erase. It can be assumed that, since userspace had already read 0xdb00 - 0xeaff that it was looking at old buffered data after the erase. Signed-off-by: Douglas Anderson <dianders@chromium.org> Change-Id: I989afd83a33013b2756a0090d6b08245613215c6 Reviewed-on: https://review.coreboot.org/c/flashrom/+/50155 Reviewed-by: Hung-Te Lin <hungte@chromium.org> Reviewed-by: Patrick Rudolph <siro@das-labor.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* linux_mtd: Fix param memory leakJacob Garber2019-09-241-0/+1
| | | | | | | | | | | | extract_programmer_param() stores allocated memory in param, so make sure it is freed at the end of the function. Change-Id: I363e66b49c1ed4034ac058b94a938c8bb197e048 Signed-off-by: Jacob Garber <jgarber1@ualberta.ca> Found-by: Coverity CID 1403823 Reviewed-on: https://review.coreboot.org/c/flashrom/+/34847 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: David Hendricks <david.hendricks@gmail.com>
* linux_mtd: Bail out early if sysfs node doesn't existDavid Hendricks2018-06-241-0/+18
| | | | | | | | | | | | | | | | | | This checks that the MTD sysfs node we will use actually exists prior to calling setup code. Although the setup code will eventually catch such an error, we need to think about the use case before printing a possibly irrelevant/confusing error message to the terminal. This patch makes it so that we only print an error message if the user specifies a non-existent MTD device. Otherwise, the failure is considered benign and we only print a debug message prior to bailing out. Change-Id: I8dc965eecc68cd305a989016869c688fe1a3921f Signed-off-by: David Hendricks <dhendricks@fb.com> Reviewed-on: https://review.coreboot.org/26500 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/+390
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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-17 18:03:55 +0000