mtd-utils.git/lib, branch v2.3.1

Import a more recent version of libiniparser

2024-12-17T12:51:35+00:00

We use a vendored library for parsing ini files. Our copy of this library has not been updated since 2007. This commit imports the recent version of the ini parsing library from upstream source at https://gitlab.com/iniparser/iniparser Signed-off-by: David Oberhollenzer

libubi: Add new interface ubi_leb_map()

2024-11-11T09:32:45+00:00

Add ubi_leb_map() implementation, it is used in UBIFS linux kernel libs. This is a preparation for replacing implementation of UBIFS utils with linux kernel libs. Signed-off-by: Zhihao Cheng Signed-off-by: David Oberhollenzer

mtd-utils: Extract rbtree implementation to common lib

2024-09-25T13:03:08+00:00

Current rbtree implementation code is put under jffs utils, extract it into common lib, and add more rbtree operations(eg. rb_first_postorder, rb_next_postorder, etc.). This is a preparation for replacing implementation of UBIFS utils with linux kernel libs. Signed-off-by: Zhihao Cheng Signed-off-by: David Oberhollenzer

mtd-utils: Extract list implementation to common lib and add list_sort support

2024-09-25T13:03:08+00:00

Current list implementation code is put under jffs utils, extract it into common lib, and add more list operations(eg. list_move, list_splice, etc.). Besides, add list sorting support in new source file lib/list_sort.c. This is a preparation for replacing implementation of UBIFS utils with linux kernel libs. Signed-off-by: Zhihao Cheng Signed-off-by: David Oberhollenzer

ubiattach: introduce need_resv_pool in UBI_IOCATT

2023-11-20T06:43:34+00:00

The ioctl UBI_IOCATT has been extended with need_resv_pool parameter in [1]. This parameter is used for deciding whether to reserve PEBs for filling pool/wl_pool for target ubi device. This parameter will be effective when fastmap is enabled, which will slow down the frequency of updating fastmap by filling more free PEBs in pool/wl_pool. See details in [2]. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ac085cfe57df2cc1d7a5c4c5e64b8780c8ad452f [2] https://bugzilla.kernel.org/show_bug.cgi?id=217787 Signed-off-by: Zhihao Cheng Signed-off-by: David Oberhollenzer

ubiattach: introduce disable_fm in UBI_IOCATT

2023-11-20T06:43:30+00:00

The ioctl UBI_IOCATT has been extended with disable_fm parameter after [1]. This parameter is used for disabling fastmap for target ubi device. If 'disable_fm' is set, ubi doesn't create new fastmap even the module param 'fm_autoconvert' is set, and existed old fastmap will be destroyed after attaching process. A simple test case in [2]. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=669d204469c46e91d99da24914130f78277a71d3 [2] https://bugzilla.kernel.org/show_bug.cgi?id=216278 Signed-off-by: Zhihao Cheng Signed-off-by: David Oberhollenzer

mtd-utils: Add new syntax to get devices by name

2023-05-30T09:12:12+00:00

This introduces a new feature to the MTD command line utilities that allows MTD devices to be referenced by name instead of device node. For example this looks like: > # Display info for the MTD device with name "data" > mtdinfo mtd:data > # Copy file to MTD device with name "data" > flashcp /my/file mtd:data This follows the syntax supported by the kernel which allows MTD device's to be mounted by name[1]. Add the function mtd_find_dev_node() that accepts an MTD "identifier" and returns the MTD's device node. The function accepts a string starting with "mtd:" which it treats as the MTD's name. It then attempts to search for the MTD, and if found maps it back to the /dev/mtdX device node. If the string does not start with "mtd:", then assume it's the old style and refers directly to a MTD device node. The function is then hooked into existing tools like flashcp, mtdinfo, flash_unlock, etc. To load in the new MTD parsing code in a consistent way across programs. [1] http://www.linux-mtd.infradead.org/faq/jffs2.html#L_mtdblock Signed-off-by: Brandon Maier Signed-off-by: David Oberhollenzer

libmtd: Add function to get MTD info by device name

2023-05-30T09:12:12+00:00

This is a convenience function for end users. In some situations it's easier to reference MTD device's by their name then by MTD number, as the name may be more reliable if device partitioning is dynamic or for porting between systems. Signed-off-by: Brandon Maier Signed-off-by: David Oberhollenzer

libmtd: do not ignore non-zero eraseblock size when MTD_NO_ERASE is set

2022-09-27T06:32:46+00:00

In 54d68799, mtd->eb_cnt was enforced to be '1' if MTD_NO_ERASE is set. This was done with the aim of preventing divisions by zero. However, even if MTD_NO_ERASE is set, mtd->eb_size (eraseblock size) can still be set to a non-zero value which would not cause a division by zero. Instead, enforcing an eraseblock count of '1' here even leads to inconsistent eraseblock counting in mtd-utils and lets for example a 'flash_erase' on an mtdnand device fail: | # flash_erase /dev/mtd0 0 0 | Erasing 32768 Kibyte @ 0 -- 0 % complete libmtd: error!: bad eraseblock number 255, mtd0 has 1 eraseblocks | flash_erase: error!: /dev/mtd0: MTD Erase entire chip failureTrying one by one each sector. | error 22 (Invalid argument) | Erasing 128 Kibyte @ 0 -- 0 % complete libmtd: error!: bad eraseblock number 1, mtd0 has 1 eraseblocks | flash_erase: error!: /dev/mtd0: MTD get bad block failed | error 22 (Invalid argument) Also mtdinfo would look inconsistent (eraseblock size vs amount): | # mtdinfo /dev/mtd0 | mtd0 | Name: mtdram test device | Type: ram | Eraseblock size: 131072 bytes, 128.0 KiB | Amount of eraseblocks: 1 (33554432 bytes, 32.0 MiB) | Minimum input/output unit size: 1 byte | Sub-page size: 1 byte | Character device major/minor: 90:0 | Bad blocks are allowed: false | Device is writable: true Fix this by enforcing mtd->eb_cnt to be '1' only when mtd->eb_size is actually zero and would lead to a division by zero otherwise. Fixes: 54d68799 ("libmtd: avoid divide by zero") Signed-off-by: Enrico Jorns Signed-off-by: David Oberhollenzer

mtd-utils: flash_erase: Add flash erase chip

2021-05-05T06:29:50+00:00

Some flash types support full erase chip command which can reduce the flash erase time. Try first to erase the entire flash and fall back to the old method if the operation fails. Signed-off-by: Larisa Ileana Grigore Signed-off-by: David Oberhollenzer