UBI assert failed in ubi_wl_init

[Richard Weinberger]

Timo,

Am Freitag, 23. März 2018, 10:26:30 CET schrieb Timo Ketola:
> On 22.03.2018 17:48, Richard Weinberger w> rote:
> > Am Donnerstag, 22. März 2018, 16:40:42 CET schrieb Timo Ketola:
> >> 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.
> 
> Dumps show that the two blocks per chip are really bad block tables. The
> other two are empty. Could it be that the mtd reserves the other two for
> bbt mirrors?

This can be.

> Anyway, I configured the bbt off and now there is full 15872 good PEBs
> but the issue stays. Here is a dump after full erase ('nand scrub' from
> U-Boot), ubiformat, ubiattach, ubimkvol -m -N user and a couple of reboots:
> 
> https://drive.google.com/open?id=1QGUIxarow3mGXbiJYgsLzc-a_Y5oN5XS
> 
> Is there any documents about the structure of fastmap blocks? google was
> no friend for me...

See ubi-media.h.
 
> > Fastmap does not care about bad block itself, all it cares about the total
> > number of good blocks.
> 
> How does it record the block references, absolute or relative to good
> blocks?
> 
> | a | b | bad | c |
> 
> Would it record c as block 3 (as absolute) or 2 (as third good one)?

As I said, Fastmap does not care at all. It takes the PEB numbers from UBI.
And UBI just skips bad blocks. So c will be 3.

The big difference between Fastmap and non-Fastmap is that PEB numbers are 
stored on flash.
So maybe we have bug in this area.

Thanks,
//richard

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