aboutsummaryrefslogtreecommitdiff
path: root/libflash
AgeCommit message (Collapse)AuthorFilesLines
2016-11-11libflash/libffs: Fix possible NULL dereferenceCyril Bur1-0/+2
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-11-08libflash/file: Use 64bit ioctl() to erase from MTDCyril Bur1-2/+2
While we'll 'never' have flash chips larger than 32bit, work was recently done to blocklevel for it to be 64bit compatible for other backends. Since there is a 64bit ioctl() lets use it. There is currently no known case where 32bit is not sufficient but this doesn't mean someone might not do something strange in the future. Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Reviewed-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-11-02core/flash: Don't do anything clever for OPAL_FLASH_{READ, WRITE, ERASE}Cyril Bur2-19/+46
These OPAL calls are exposing the host flash chip to linux as a flash device. The host is expected to understand that it is raw flash and use it appropriately, it isn't skiboots place to strip ecc bytes or perform erase before writes. Over the course of other developments blocklevel has gotten quite clever but in this case the cleverness is inappropriate. Fixes: https://github.com/open-power/skiboot/issues/44 Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-10-25libflash/libffs: Use blocklevel_smart_write() when updating partitionsCyril Bur1-1/+1
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-10-11libflash/blocklevel: Allow double ecc protecting a regionCyril Bur3-51/+119
Currently the policy for calling ECC protecting a range at the blocklevel layer is that the requested region be completely unprotected otherwise the call will return an error. It turns out that duplicate calls to ffs_init() with true as the last parameter (for the same blocklevel structure) will cause duplicate attempts to ecc_protect() ranges. Change the policy within blocklevel to allow duplicate protecting. In fact the new policy almost guarantees no failure (baring something odd like malloc() failing). It will detect that the range is currently already fully protected and do nothing, detect that part of the range is or is not and extend the existing range or detect that a range fits perfectly between two ranges in which case it will merge the ranges. Also adjust tests to match the new policy. Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-09-15libflash: add 128MB MX66L1G45G partJoel Stanley1-0/+1
Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-09-02consolidate gcov flags into HOSTGCOVFLAGS for host binariesStewart Smith1-1/+1
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-08-25flash: Rework error paths and messages for multiple flash controllersMichael Neuling1-1/+1
The current flash code was written with only one flash chip, which is a system_flash (ie. the PNOR image), in mind. Now that we have mambo bogusdisk flash, we can have many flash chips. This is resulting in some confusing output messages. This reworks some of the error paths and warnings to make this more coherent when we have multiple flash chips. We assume everything can be a system flash, so I've removed the is_system_flash parameter from flash_register(). We'll use the first system flash we find and warn if we find another since discovery order is not a guaranteed API. Signed-off-by: Michael Neuling <mikey@neuling.org> Acked-by: Jeremy Kerr <jk@ozlabs.org> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-08-02flash: Make size 64 bit safeMichael Neuling9-52/+60
This makes the size of flash 64 bit safe so that we can have flash devices greater than 4GB. This is especially useful for mambo disks passed through to Linux. Fortunately the device tree interface and the linux device driver are 64bit safe so no changes are required there. Userspace gard and flash tools are also updated to ensure "make check" still passes. Signed-off-by: Michael Neuling <mikey@neuling.org> Reviewed-by: Cyril Bur <cyrilbur@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-08-02flash: Add documentation for blocklevel_smart_write()Michael Neuling1-1/+8
A function called "smart" doesn't give the user any clues as to why they would want to use it over other calls. This adds some documentation so users can determine when to best use this call. Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-07-12make check: make test runs less noisyStewart Smith1-2/+2
Run a small wrapper around some unit tests with the QTEST makefile macro (QTEST=Quiet TEST). Also, wrap boot tests in mambo and qemu to be quiet by default. Both ./test/run.sh and the modified mambo/qemu test runner scripts output full stdout and stderr in the event of error. Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-07-05libflash: Add sanity checks to ffs init code.Cyril Bur1-0/+22
Quite a lot of code relies on values read from flash. These values shouldn't be totally trusted without at least basic sanity checks. Fixes coverity bug: 119719 Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-05-18libflash: fix bug on reading truncated flash fileStewart Smith1-1/+1
If we had a truncated file where libflash would attempt to read past the end, instead of erroring out, we'd get stuck in an infinite loop. Why? Because we weren't acknowledging that read() returns 0 on EOF. Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com> Reviewed-by: Cyril Bur <cyril.bur@au1.ibm.com>
2016-03-30*/test/*: Added '<subdir>-check' make targetsOliver O'Halloran1-2/+5
Currently these exist for some parts of the source tree, but not all of it. They're nice if you are only modifing code in a one part of the tree as the full test suite can be a little slow. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-03-11libflash/libffs: Reporting seeing all 0xFF bytes during init.Cyril Bur1-0/+19
When flash controllers get deconfigured or yanked out from under these tools flash accesses tend to just return all 0xFF bytes. libffs is usually the first thing to do reads and will fail parsing its partition structures. This patch adds reporting when it fails to parse because it got all 0xFF bytes. The idea is that this will help debugging by splitting the possible reasons for a failed init into 1) flash controller issue or reading erased flash 2) flash corruption or not valid reading partition data. These two cases are nice to be able to separate as early as possible as they usually mean two quite different type of bugs. Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-02-18libflash: Support for Micron N25Q256Ax and Winbond W25Q256BV NOR flashAdriana Kobylak1-0/+6
These 32MB chips are used in the Barreleye OpenBMC BMC. Signed-off-by: Adriana Kobylak <anoo@us.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-01-15libflash/blocklevel: Add keep_alive parameterCyril Bur5-26/+150
Currently the file backend will keep a file descriptor open until the structure is destroyed. This is undesirable for daemons and long running processes that only have a very occasional need to access the file. Keeping the file open requires users of blocklevel to close and reinit their structures every time, doing is isn't disastrous but can easily be managed at the interface level. This has been done at the blocklevel_device interface so as to provide minimal changes to arch_flash_init(). At the moment there isn't a need for the actually flash driver to be able to do this, this remains unimplmented there. Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-01-12libflash/libffs: Check for NULL and set return pointer in ffs_next_side()Cyril Bur1-0/+6
Currently there are two error cases that ffs_next_side() may hit and will leave the return pointer untouched. This isn't a huge problem as the caller should be checking the return value anyway but as we know, callers don't always do that. It doesn't hurt for ffs_next_side() to make it as clear as possible that it encountered a problem. Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Reviewed-by: Sam Mendoza-Jonas <sam@mendozajonas.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-01-12libflash/libffs: Rename ffs_cmp() to ffs_equal()Cyril Bur2-2/+2
Some confusion has arisen from the first consumer of ffs_cmp() in that they expected a strcmp style less than one, zero or greater than one return value. This has been addressed in this patch in two ways, by changing the return type to a boolean in order to (attempt) to alert the programmer that this is not the case and by renaming it to equal to avoid the implied comparison and imply very much a boolean outcome. Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Reviewed-by: Sam Mendoza-Jonas <sam@mendozajonas.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-01-08libffs: Add helper get ffs_handle to the "OTHER_SIDE"Cyril Bur2-3/+56
Some FFS structures will have a partition called "OTHER_SIDE", this is a pointer to another ffs TOC on which another ffs_handle can be instantiated. Currently users of libffs would have to query for the presence of this partition and then initialise a new ffs_handle themselves. As accessing the "other" side appears to be becoming a common operation this convenience function should prove useful. Furthermore, it is possible for these multiTOC flash chips to be circular, that is the "OTHER_SIDE" partition of 'secondary' TOC points back to the initial TOC. The solution is to add a comparison function capable of detecting when repeated calls to ffs_next_side() go full circle. It should be noted here that this is all the comparator function is designed to detect, it will not be able to detect two identical TOCs opened with different blocklevel_devices as this would require the ability to compare blocklevel_devices. Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-01-08libffs: Remove unused function ffs_open_image()Cyril Bur2-88/+0
The utility of this function has been superceeded by blocklevel code and is no longer called from anywhere, it can be removed. Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-01-08libffs: Remove struct flash_chip from struct ffs_handleCyril Bur1-4/+0
Simply isn't used anymore since libffs knows how to use the blocklevel interface. Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-11-26libflash: Support Micron N25Q256Ax NOR flashJoel Stanley1-0/+3
This 32MB part is used for the Barreleye OpenBMC BMC. Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Cédric Le Goater <clg@fr.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-11-26libflash: put message on one lineJoel Stanley1-2/+1
This way it can be grep'd for. Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Cédric Le Goater <clg@fr.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-11-17libflash: fix resource leaks on errors in ffs_open_imageStewart Smith1-1/+5
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-11-13libflash: Provide an internal parity implementation, to remove libgcc dependencyJeremy Kerr1-1/+17
In commit 8f5b8616, we introduced a dependency on libgcc, for the __builtin_parityl() function in commit 6cfaa3ba. However, if we're building with a biarch compiler, we may not have a libgcc available. This commit removes the __builtin_parityl() call, and replaces with the equivalent instructions, and removes the dependency on libgcc. Although this is untested, I have confirmed that the __builtin_parityl() functions emits the same instructions (on power7 and power8, with gcc-4.9) as we're using in the parity() function. Signed-off-by: Jeremy Kerr <jk@ozlabs.org> [stewart@linux.vnet.ibm.com: only use inline asm for skiboot build] Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-11-09Free bl_prot_range on file_exit_close()Samuel Mendoza-Jonas1-0/+1
Signed-off-by: Samuel Mendoza-Jonas <sam.mj@au1.ibm.com> Reviewed-by: Cyril Bur <cyrilbur@gmail.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-09-08libflash/test: Attempted fix of Coverity defect 98799Cyril Bur1-1/+1
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-09-08libflash/test: Fix Coverity defect 98827Cyril Bur1-1/+1
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-09-08libflash: Fix Coverity defect 97867Cyril Bur1-2/+2
CID 97867 (#1 of 1): Uninitialized scalar variable (UNINIT) 5. uninit_use: Using uninitialized value rc. Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-09-07libflash/blocklevel: Smarten up blocklevel_smart_write()Cyril Bur1-3/+40
Blocklevel_smart_write() can write in a smart fashion which avoids the need for the caller to erase the flash before writing, except it never actually does the erase if it needs to. Furthermore, a very simple optimisation can be made where it should detect if it doesn't actually need to clear the flash, but still needs to write. This optimisation is from flash_smart_write(), which, for reasons, should continue to exist at least for now. In the process, this also addresses a bug. blocklevel_smart_write() operates on erase block covered by the write, detects to see if an erase needs to be performed and if so, performs the erase and then performs the write. Currently blocklevel_smart_write() won't detect that a write can span two erase blocks and that it should split this process in two. This patch fixes that. Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Reviewed-by: Samuel Mendoza-Jonas <sam.mj@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-08-28libflash: Reintroduce typesafety in lowlevel libflash callsCyril Bur2-6/+4
Previous work did away with some typesafety when adding the blocklevel_device abstraction, this has resulted in the ability to accidently call libflash low level code with a blocklevel_device which has not been initialised by the libflash backend. The end result will not be good. Best to reintroduce that low level calls be called with libflashes own structures. Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-08-28external/common: Create common code for initialising libflash componentsCyril Bur2-0/+13
In order to access the flash on ARM (presumably code running on a BMC), the hardware is involved. In order to access the flash on POWER (presumably code running on a host), opal calls through the Linux MTD driver are involved. In order to access the flash on x86 (presumably on a developer/admin system), you can't but it would be nice to be able to manipulate data which has come from the flash or will go onto the flash. The pflash and the gard tool both can read and write to the 'flash' and with the introduction of the blocklevel interface the details of how the flash is read from and written to is sufficiently abstracted that these tools don't need to know what they're running on. What does differ is the setup, and not by too much either. This common code pulls out the setup of the flash hardware on ARM, the searching for the appropriate MTD device on power and generic blocklevel device init for all three architectures. Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-08-28libflash: Return a pointer to internal structure.Cyril Bur3-3/+8
There are some functions (notably: erase_chip and set_4b_mode) which cannot be abstracted away by the blocklevel interface, this means that if they are really needed (by pflash for example) then at the moment a program like pflash would need to pass a blocklevel_device struct to libflash. This forces libflash to trust that it was given a blocklevel that it did init. If it didn't init it the container_of call will return junk and libflash has no way to protect its self. This method (while very useful) has destroyed type safety. As such, this commit reintroduces some typesafety back into this stack. Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-08-28libflash/blocklevel: Fix blocklevel read ECC failure return codeCyril Bur1-1/+4
If an ECC check fails in blocklevel_read(), the return code from blocklevel_read() won't be correct. Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-08-26Fix spelling mistakesStewart Smith1-1/+1
See https://github.com/lucasdemarchi/codespel Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-08-19in skbioot-5.1.0 commit, accidentally somehow removed two compiler warning ↵Stewart Smith1-1/+7
fixes. Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-08-17Add skiboot-5.1.0 release notesskiboot-5.1.0Stewart Smith1-7/+1
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-08-17libflash: check ffs_part_info return value in ffs_initJeremy Kerr1-1/+7
Current packaging builds (which specify -O2) fail for me, with: CC libffs.o ../../libflash/libffs.c: In function ffs_init: ../../libflash/libffs.c:149:8: error: start may be used uninitialized in this function [-Werror=maybe-uninitialized] rc = blocklevel_ecc_protect(bl, start, total_size); ^ ../../libflash/libffs.c:149:8: error: total_size may be used uninitialized in this function [-Werror=maybe-uninitialized] ../../libflash/libffs.c:148:7: error: ecc may be used uninitialized in this function [-Werror=maybe-uninitialized] if (ecc) { ^ cc1: all warnings being treated as errors This is because we're not checking for the return value of ffs_part_info, which may return with start/total_size/ecc uninitialised. Signed-off-by: Jeremy Kerr <jk@ozlabs.org> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-07-10Introduce blocklevel_ecc_protect() return value checkKamalesh Babulal1-3/+9
Check for the return value from blocklevel_ecc_protect(), while registering regions of the flash and log error incase the return registration of region fails. Fixes Coverity defect#101019 Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> Reviewed-By: Cyril Bur <cyril.bur@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-07-07libflash: Add support for Macronix 128Mb flash chipsJeremy Kerr1-0/+1
Fun-sized version of the MXxxL25635F. Signed-off-by: Jeremy Kerr <jk@ozlabs.org> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-06-23libffs: init with ecc protection at blocklevel levelCyril Bur2-3/+13
Passing a flag on libffs init will register all regions of the flash with ecc (as per the libffs partition information) as being ecc protected (or not). This saves the consumer needing to know or care about the presence of ecc. Reviewed-By: Alistair Popple <alistair@popple.id.au> Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-06-23libflash/blocklevel: add a smart write function which wraps up eraseing and ↵Cyril Bur2-0/+74
writing For consumers who can't do better or who aren't to phased about performance, having to book keep erasing in order to be able to write data can be painful. Blocklevel can do it, possibly naively but its a convenience function Reviewed-By: Alistair Popple <alistair@popple.id.au> Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-06-23libflash: Delete file_file.[ch] filesCyril Bur2-235/+0
The new backend for blocklevel does this in a much neater way as much this hacky code is no longer needed. Reviewed-By: Alistair Popple <alistair@popple.id.au> Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-06-23libflash/file: Add a file access backend to for the blocklevel interface.Cyril Bur2-0/+339
Currently libflash reads from files by using the dodgy file_flash.c which implements a very flash hardware themed interface but subverts it to read, write and erase from a file descriptor. With the introduction of this file backend, this will no longer be needed. Reviewed-By: Alistair Popple <alistair@popple.id.au> Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-06-23libflash/blocklevel: add blocklevel flags.Cyril Bur2-0/+6
It has become apparent that communication between blocklevel and its backend may be necessarily, at least so that the backend can inform blocklevel as to if an erase must be done before a write. An erase before flag isn't strictly necessary as erases can be performed regardless of whether they need to be or not, however, the caveat with that is that when erases don't need to be performed, this is likely due to the backend not having erase blocks and therefore it may be impossible to set a sane value for erase blocks which would be used to erase before write. This flag saves backends that don't need erases before write to have to lie about an erase block size. Reviewed-By: Alistair Popple <alistair@popple.id.au> Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-06-23libflash/blocklevel: Extend the block level to be able to do eccCyril Bur6-36/+411
At the moment ECC reads and writes are still being handled by the low level core of libflash. ECC should be none of libflashes concern, it is primarily a hardware access backend. It makes sense for blocklevel to take care of ECC but currently it has no way of knowing. With some simple modifications (which are rudimentary at the moment and will need a performance improvement) blocklevel can handle ECC, and with a little more effort this can be extended to provide read and write protection in blocklevel. Reviewed-By: Alistair Popple <alistair@popple.id.au> Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-06-23libflash/ecc: Simplify and cleanup ecc code.Cyril Bur4-60/+78
The ecc 'memcpy' style functions return success or fail in terms of the ECC enum. This doesn't really make sense, use true or false. As the result the ecc enum doesn't need to be exposed anymore, which makes more sense, not clear why it was exposed in the first place. Convert some of the ecc #defines to static inlines, shouldn't make any difference but feels safer. Fix minor stylistic and typo issues. Reviewed-By: Alistair Popple <alistair@popple.id.au> Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-06-16libflash: Fix 32-bit ecc build of pflashBenjamin Herrenschmidt1-8/+8
uint64_t is a long long, the constants need the "ull" suffix. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-06-09libflash: Blocklevel sanity checking of erase block sizesCyril Bur1-1/+10
Blocklevel has no way to check that backends init the erase_mask correctly and as such must trust them. When a user calls blocklevel_get_info(), blocklevel has a chance to inspect the return value and warn if the values do not match. This check happens on every call which should be fine as it is doubtful that blocklevel_get_info() will be called much. Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
generated by cgit v1.1 at 2024-11-14 14:46:29 +0000