]> git.sur5r.net Git - u-boot/commit
ubi: fastmap: Implement produce_free_peb()
authorPatrice Chotard <patrice.chotard@st.com>
Tue, 22 May 2018 08:10:51 +0000 (10:10 +0200)
committerHeiko Schocher <hs@denx.de>
Tue, 22 May 2018 09:39:05 +0000 (11:39 +0200)
commit65c3d25a6a21b5cf4d978f05f84aaeb6b250e636
treeb318f654612e97f63e84c19be8a5420e48a8688b
parent624d2cae3401c2e4d43c571a9b81d1f650e7703d
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>
drivers/mtd/ubi/fastmap-wl.c