diff options
author | Patrice Chotard <patrice.chotard@st.com> | 2018-05-22 10:10:51 +0200 |
---|---|---|
committer | Heiko Schocher <hs@denx.de> | 2018-05-22 11:39:05 +0200 |
commit | 65c3d25a6a21b5cf4d978f05f84aaeb6b250e636 (patch) | |
tree | b318f654612e97f63e84c19be8a5420e48a8688b /include/configs/smdk5250.h | |
parent | 624d2cae3401c2e4d43c571a9b81d1f650e7703d (diff) |
ubi: fastmap: Implement produce_free_peb()
Since 'commit f82290afc847 ("mtd: ubi: Fix worker handling")',
when booting from NAND, on a fresh NAND just after being flashed (and
only in this case), we got the following log:
ubi0: default fastmap pool size: 200
ubi0: default fastmap WL pool size: 100
ubi0: attaching mtd2
ubi0: scanning is finished
ubi0 error: ubi_update_fastmap: could not find any anchor PEB
ubi0 error: ubi_update_fastmap: could not find any anchor PEB
ubi0 error: ubi_wl_get_peb: Unable to get a free PEB from user WL pool
ubi0 error: autoresize: cannot auto-resize volume 1
UBI error: cannot attach mtd2UBI error: cannot initialize UBI, error
-28UBI init error 28
After analysis, in ubi_wl_init(), when performing schedule_erase(),
thread_enabled flag is not yet set to 1, which forbids ubi_do_worker()
to execute pending works.
This has to effect to not populate ubi->free with free physical
eraseblocks.
Following Richard Weinberger's advice, this patch has been
backported from kernel tree :
'commit 1cb8f9776c7d ("ubi: fastmap: Implement produce_free_peb()")'
Tested-by: Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Acked-by: Heiko Schocher <hs@denx.de>
Diffstat (limited to 'include/configs/smdk5250.h')
0 files changed, 0 insertions, 0 deletions