[PATCH RFC v2] UBI: New ioctl() to support ubidump
Bill Pringlemeir
bpringlemeir at nbsps.com
Tue Jul 29 07:48:05 PDT 2014
On 29 Jul 2014, hujianyang at huawei.com wrote:
> An ioctl() return pnum of a specified leb.
> Signed-off-by: hujianyang <hujianyang at huawei.com>
> ---
> drivers/mtd/ubi/cdev.c | 26 ++++++++++++++++++++++++++
> include/uapi/mtd/ubi-user.h | 12 ++++++++++++
> 2 files changed, 38 insertions(+)
Please look at 'ubi_scan()',
http://sourcecodebrowser.com/mtd-utils/20110107/libscan_8c.html
http://sourcecodebrowser.com/mtd-utils/20110107/libscan_8h.html
After this call info->ec[pnum] is,
EB_EMPTY (ffffffff) - erased
EB_CORRUPTED (fffffffe) - inconsistent UBI data.
EB_ALIEN (fffffffd) - non-ubi erase sector
EB_BAD (fffffffc) - bad block
or the LNUM.
To write your code, you can either scan the array (~32-2048 entries)
each time you want an 'lnum' or you could run through the array and
construct the opposite table; a 'logical index' gives a 'physical eb';
this would require keeping track of the 'generation' count.
I think a patch to 'ubi_scan()' to create an 'pmap' array might be
better or more accepted than a Linux/MTD/UBI patch? Then only the
'ubidump' code is needed and not a properly configured/versioned kernel;
or at least only the nandsim module which is similar to some other
utilities. If you had a 'ubi_scan()' which has an 'info->pmap[leb]'
which had,
EB_EMPTY (ffffffff) - not mapped
or the PNUM.
Would you need to patch the kernel?
Fwiw,
Bill Pringlemeir.
More information about the linux-mtd
mailing list