UBI assert failed in ubi_wl_init

[Richard Weinberger]

Timo,

Am Donnerstag, 22. März 2018, 16:40:42 CET schrieb Timo Ketola:
> On 22.03.2018 17:05, Richard Weinberger wrote:
> > Timo,
> 
> > Am Donnerstag, 22. März 2018, 14:57:57 CET schrieb Timo Ketola:
> ...
> 
> >> Here is a dump after the second boot:
> >> 
> >> https://drive.google.com/open?id=1oa2lV_OB_tC-SX_c4jylnMXK6x1xhj2o
> >> 
> >> After I dumped it I erased the whole mtd, wrote the dump back there,
> >> dumped another dump and verified that it was identical with the first
> >> one. Then I rebooted and observed that the issue was still there just as
> >> before.
> > 
> > This image contains a Fastmap, but it is invalid.
> > The image has a length of 2079326208 bytes, your PEB size is 128KiB.
> > Therefore PEB count is 15864.
> > But the Fastmap references PEBs 15865, 15866 and 15867.
> > 
> > This explains the failing assert, Fastmap talks about PEBs which are
> > unknown to UBI.
> > 
> > Can it be that your mtd partition layout is bad/broken?
> 
> The partition spans two chips and they both have four blocks of bad
> block tables at the end of the chips. Would that explain?

If this setup works correctly, it should work.

> I'm slightly confused though, because flash_erase reports total of eight
> blocks:
> 
> # flash_eraseall /dev/mtd1
> Erasing 128 Kibyte @ 3bf60000 - 48% complete.
> Skipping bad block at 0x3bf80000
> 
> Skipping bad block at 0x3bfa0000
> 
> Skipping bad block at 0x3bfc0000
> 
> Skipping bad block at 0x3bfe0000
> Erasing 128 Kibyte @ 7bf60000 - 99% complete.
> Skipping bad block at 0x7bf80000
> 
> Skipping bad block at 0x7bfa0000
> 
> Skipping bad block at 0x7bfc0000
> 
> Skipping bad block at 0x7bfe0000
> Erasing 128 Kibyte @ 7c000000 - 100% complete.
> 
> 
> but, log tells only about four blocks:
> 
> [    1.549699] Bad block table found at page 524224, version 0x01
> [    1.554241] Bad block table found at page 1048512, version 0x01
> [    1.561314] Bad block table found at page 524160, version 0x01
> [    1.565853] Bad block table found at page 1048448, version 0x01
> [    1.573232] 2 ofpart partitions found on MTD device gpmi-nand
> [    1.577688] Creating 2 MTD partitions on "gpmi-nand":
> [    1.581499] 0x000000000000-0x000004000000 : "system"
> [    1.595001] 0x000004000000-0x000080000000 : "user"

Now things get interesting.
Can it be that the number of bad blocks is not stable?
IOW sometimes 4 and sometimes 8 are reported?
This would more or less explain what you see.

Fastmap does not care about bad block itself, all it cares about the total 
number of good blocks.

Thanks,
//richard

-- 
sigma star gmbh - Eduard-Bodem-Gasse 6 - 6020 Innsbruck - Austria
ATU66964118 - FN 374287y