| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
==8304==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 4096 byte(s) in 1 object(s) allocated from:
#0 0x7f70eda8f850 in malloc (/lib64/libasan.so.4+0xde850)
#1 0x408ba0 in main libflash/test/test-blocklevel.c:298
#2 0x7f70ec8e1509 in __libc_start_main (/lib64/libc.so.6+0x20509)
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
|
|
Also add usage text to pflash.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Reviewed-by: Samuel Mendoza-Jonas <sam@mendozajonas.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>
|
|
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>
|
|
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>
|
|
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>
|
