Age | Commit message (Collapse) | Author | Files | Lines |
|
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
See https://github.com/lucasdemarchi/codespel
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
fixes.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
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>
|
|
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>
|
|
Fun-sized version of the MXxxL25635F.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Currently blocklevel_erase() will let any erase of any size get passed down
to the backend. Not strictly a problem since libflash does do this check
as well, however, not all future backends will.
This is very much a sanity check to save from a likely mistake.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Converted all the libflash calls to use the blocklevel interface, modified all
callers to libflash to use the blocklevel interface.
This patch should introduce next to no functional change.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
libflash core is really good at accessing hardware flash devices. libffs is
really good at read FFS partitioned data and has been designed to use libflash
to read data.
Problems arise when FFS partitioned data exists on something other than
flash hardware, or the hardware cannot be accessed directly.
This interface should bridge the gap, allowing libffs to be used no matter
what the backing is for the data. This should allow for greater flexibility
for reading and writing, such as adding support read-only areas at a global
level as well as more straight forward usage of libffs for userspace bypassing
libflash entirely.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The accessor for ffs partition entries should be adding the offset of the TOC
to the absolute address of the partition entries as the TOC is not necessarily
at 0 within in the flash.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Reviewed-By: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The word offset can be ambiguous, it can be unclear what offset the variable
refers to or what it is the offset of. As this library now has to deal with
flash with more than one libffs TOC, it makes sense to rename all uses of
'offset' to 'toc_offset' which relate to the offset of the TOC within in the
flash.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Reviewed-By: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
doesn't exist
commit 237f9d1a51eaed260119346dfddc044395267154
Author: Cyril Bur <cyril.bur@au1.ibm.com>
libflash: don't use the low level interface if it doesn't exist
In the review process a less invasive version was reworked.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The functionality provided by libflash and libffs are useful and it would be
good to use them on dumps of flash or even access flash from userland through
MTD devices which are presented as files.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
During init libflash calls low level functions without checking.
libflash states to backends that if they implement all the higher level
functions the lower level functions are optional (from libflash-priv.h):
If all functions of the high level interface are
implemented then the low level one is optional. A
controller can implement some of the high level one
in which case the missing ones will be handled by
libflash using the low level interface.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
memboot uses bmc system memory instead of a real flash chip. This
patch adds a flash backend for bmc system memory to allow use of the
memboot tool (in external/memboot) to boot the system.
Signed-off-by: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This patch is twofold.
1. Improves the low level ecc memcpy code to better
specify that we're reading/writing buffers with ecc bytes.
2. Improves/creates the libflash interfaces for ecc.
This patch also includes some tests
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The flash is in big endian and the ecc code must be aware of this when
performing ecc checks on a little endian cpu.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
ffs_open_image is like ffs_open_flash, but it can operate on a file
descriptor to a pnor image instead of a flash device.
It is currently disabled in skiboot as it does not provide the read
and lseek used by libffs.
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Let's wrap it with __SKIBOOT__ to avoid the warning. libflash_debug is
still being used by libflash in userspace, eg. pflash and opal-prd.
Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
Suggested-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We have ffs_flash_read to do optionally-ecc-ed reads of flash data.
However, this isn't really related to the ffs partitioning.
This change moves ffs_flash_read into libflash.c, named
flash_read_corrected. The function itself isn't changed.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Reviewed-By: Joel Stanley <joel@jms.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
libflash should be compilable without the skiboot definitions.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Reviewed-By: Joel Stanley <joel@jms.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
The ecc.h header is used by libflash, so should sit in libflash, to
allow non-skiboot tools to access it.
This change is a simple move of the header file - no changes are made to
the header itself.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Reviewed-By: Joel Stanley <joel@jms.id.au>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
We don't have prerror / prlog functions when compiling outside of
skiboot. Use the FL_* macros instead.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Add ffs_flash_read() which mimics flash_read() but handles ECC checking,
correction and uncorrectable errors.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Add ecc parmenter to ffs_part_info() to indicate if the partition is ECC
protected or not. Fix all call sites.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This adds the correct user structure to ffs_entry as defined from hostboot.
No functional changes.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Add ECC checking code. This code is based on the hostboot code.
Unused currently, but will be soon. This uses __builtin_parityl() hence adding
libgcc linking previously.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
In some parts of libffs we access struct ffs_entry with endian access and in
other parts we don't. This adds a comment to clarify why we do this.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
This way we get a true representation from the lcov coverage-report
about what firmware code we're testing (besides, test cases are always
going to only have 50% of branches hit - we're asserting the tests pass!)
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|