| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With recent changes to flash drivers in linux not all erase blocks are
4K anymore. While most level of the pflash/gard tool stacks were written
to not mind, it turns out there are bugs which means not 4K erase block
backing stores aren't handled all that well. Part of the problem is the
FFS layout that is 4K aligned and with larger block sizes pflash and the
gard tool don't check if their erase commands are erase block aligned -
which they are usually not with 64K erase blocks.
This patch aims to add common functionality to blocklevel so that (at
least) pflash and the gard tool don't need to worry about the problem
anymore.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
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>
|
