diff options
| author | Cyril Bur <cyril.bur@au1.ibm.com> | 2016-03-10 13:35:05 +1100 |
|---|---|---|
| committer | Stewart Smith <stewart@linux.vnet.ibm.com> | 2016-03-11 15:24:39 +1100 |
| commit | 8c419564953f04ff7bae8e076a1cd8ebc67a0822 (patch) | |
| tree | cbf5769e00483745affae329637ad24fdbc9c4eb /libflash | |
| parent | 8dcb68e5ddb5db926c0c9a97c99d5e31cbc405ff (diff) | |
| download | skiboot-8c419564953f04ff7bae8e076a1cd8ebc67a0822.zip skiboot-8c419564953f04ff7bae8e076a1cd8ebc67a0822.tar.gz skiboot-8c419564953f04ff7bae8e076a1cd8ebc67a0822.tar.bz2 | |
libflash/libffs: Reporting seeing all 0xFF bytes during init.
When flash controllers get deconfigured or yanked out from under these
tools flash accesses tend to just return all 0xFF bytes.
libffs is usually the first thing to do reads and will fail parsing its
partition structures. This patch adds reporting when it fails to parse
because it got all 0xFF bytes.
The idea is that this will help debugging by splitting the possible reasons
for a failed init into 1) flash controller issue or reading erased flash 2)
flash corruption or not valid reading partition data. These two cases are
nice to be able to separate as early as possible as they usually mean two
quite different type of bugs.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Diffstat (limited to 'libflash')
| -rw-r--r-- | libflash/libffs.c | 19 |
1 files changed, 19 insertions, 0 deletions
diff --git a/libflash/libffs.c b/libflash/libffs.c index 51d9856..4d57992 100644 --- a/libflash/libffs.c +++ b/libflash/libffs.c @@ -15,6 +15,7 @@ */ /* */ +#include <limits.h> #include <stdlib.h> #include <stdio.h> #include <string.h> @@ -75,6 +76,7 @@ int ffs_init(uint32_t offset, uint32_t max_size, struct blocklevel_device *bl, struct ffs_handle **ffs, bool mark_ecc) { struct ffs_hdr hdr; + struct ffs_hdr blank_hdr; struct ffs_handle *f; uint32_t total_size; int rc, i; @@ -101,6 +103,23 @@ int ffs_init(uint32_t offset, uint32_t max_size, struct blocklevel_device *bl, return rc; } + /* + * Flash controllers can get deconfigured or otherwise upset, when this + * happens they return all 0xFF bytes. + * An ffs_hdr consisting of all 0xFF cannot be valid and it would be + * nice to drop a hint to the user to help with debugging. This will + * help quickly differentiate between flash corruption and standard + * type 'reading from the wrong place' errors vs controller errors or + * reading erased data. + */ + memset(&blank_hdr, UINT_MAX, sizeof(struct ffs_hdr)); + if (memcmp(&blank_hdr, &hdr, sizeof(struct ffs_hdr)) == 0) { + FL_ERR("FFS: Reading the flash has returned all 0xFF.\n"); + FL_ERR("Are you reading erased flash?\n"); + FL_ERR("Is something else using the flash controller?\n"); + return FLASH_ERR_BAD_READ; + } + /* Allocate ffs_handle structure and start populating */ f = malloc(sizeof(*f)); if (!f) |