talos-skiboot/libflash/test/test-blocklevel.c, branch master

libflash/blocklevel: Make read/write be ECC agnostic for callers

2018-04-10T00:02:11+00:00

The blocklevel abstraction allows for regions of the backing store to be marked as ECC protected so that blocklevel can decode/encode the ECC bytes into the buffer automatically without the caller having to be ECC aware. Unfortunately this abstraction is far from perfect, this is only useful if reads and writes are performed at the start of the ECC region or in some circumstances at an ECC aligned position - which requires the caller be aware of the ECC regions. The problem that has arisen is that the blocklevel abstraction is initialised somewhere but when it is later called the caller is unaware if ECC exists in the region it wants to arbitrarily read and write to. This should not have been a problem since blocklevel knows. Currently misaligned reads will fail ECC checks and misaligned writes will overwrite ECC bytes and the backing store will become corrupted. This patch add the smarts to blocklevel_read() and blocklevel_write() to cope with the problem. Note that ECC can always be bypassed by calling blocklevel_raw_() functions. All this work means that the gard tool can can safely call blocklevel_read() and blocklevel_write() and as long as the blocklevel knows of the presence of ECC then it will deal with all cases. This also commit removes code in the gard tool which compensated for inadequacies no longer present in blocklevel. Signed-off-by: Cyril Bur Tested-by: Pridhiviraj Paidipeddi [stewart: core/flash: Adapt to new libflash ECC API Signed-off-by: Stewart Smith

libflash/blocklevel: Return region start from ecc_protected()

2018-04-09T08:45:23+00:00

Currently all ecc_protected() does is say if a region is ECC protected or not. Knowing a region is ECC protected is one thing but there isn't much that can be done afterwards if this is the only known fact. A lot more can be done if the caller is told where the ECC region begins. Knowing where the ECC region start it allows to caller to align its read/and writes. This allows for more flexibility calling read and write without knowing exactly how the backing store is organised. Signed-off-by: Cyril Bur Signed-off-by: Stewart Smith

libflash/test/test-blocklevel: fix memory leak on exit

2017-08-24T02:59:15+00:00

==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

libflash: Adding debugging output

2017-08-01T03:57:02+00:00

Also add usage text to pflash. Signed-off-by: Cyril Bur Reviewed-by: Samuel Mendoza-Jonas Signed-off-by: Stewart Smith

libflash: Add tests for blocklevel_smart_erase()

2017-04-07T04:51:34+00:00

Signed-off-by: Cyril Bur Signed-off-by: Stewart Smith

libflash/blocklevel: Allow double ecc protecting a region

2016-10-11T03:42:23+00:00

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 Signed-off-by: Stewart Smith

flash: Make size 64 bit safe

2016-08-02T08:12:49+00:00

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 Reviewed-by: Cyril Bur Signed-off-by: Stewart Smith

libflash/blocklevel: Extend the block level to be able to do ecc

2015-06-23T03:38:42+00:00

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 Signed-off-by: Cyril Bur Signed-off-by: Stewart Smith