talos-skiboot/libflash, branch master

libflash/blocklevel: Add missing newline to debug messages

2018-04-16T03:18:50+00:00

Signed-off-by: Pridhiviraj Paidipeddi Signed-off-by: Stewart Smith

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/ecc: Add helpers to align a position within an ecc buffer

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

As part of ongoing work to make ECC invisible to higher levels up the stack this function converts a 'position' which should be ECC agnostic to the equivalent position within an ECC region starting at a specified location. Signed-off-by: Cyril Bur Signed-off-by: Stewart Smith

libflash/ecc: Add functions to deal with unaligned ECC memcpy

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

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

libffs: Fix bad checks for partition overlap

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

Not all TOCs are written at zero Signed-off-by: Cyril Bur Signed-off-by: Stewart Smith

external/ffspart: Use new interface

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

This also updated the pflash tests which use ffspart to generate pnors Signed-off-by: Cyril Bur Signed-off-by: Stewart Smith

libflash/libffs: Allow caller to specifiy header partition

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

An FFS TOC is comprised of two parts. A small header which has a magic and very minimmal information about the TOC which will be common to all partitions, things like number of patritions, block sizes and the like. Following this small header are a series of entries. Importantly there is always an entry which encompases the TOC its self, this is usually called the 'part' partition. Currently libffs always assumes that the 'part' partition is at zero. While there is always a TOC and zero there doesn't actually have to be. PNORs may have multiple TOCs within them, therefore libffs needs to be flexible enough to allow callers to specify TOCs not at zero. The 'part' partition is otherwise a regular partition which may have flags associated with it. libffs should allow the user to set the flags for the 'part' partition. This patch achieves both by allowing the caller to specify the 'part' partition. The caller can not and libffs will provide a sensible default. Signed-off-by: Cyril Bur Signed-off-by: Stewart Smith

libflash/libffs: Refcount ffs entries

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

Currently consumers can add an new ffs entry to multiple headers, this is fine but freeing any of the headers will cause the entry to be freed, this causes double free problems. Even if only one header is uses, the consumer of the library still has a reference to the entry, which they may well reuse at some other point. libffs will now refcount entries and only free when there are no more references. This patch also removes the pointless return value of ffs_hdr_free() Signed-off-by: Cyril Bur Signed-off-by: Stewart Smith

libflash/libffs: Switch to storing header entries in an array

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

Since the libffs no longer needs to sort the entries as they get added it makes little sense to have the complexity of a linked list when an array will suffice. Signed-off-by: Cyril Bur Signed-off-by: Stewart Smith