Skip to contentSkip to conversation

Regression with ubifs initialization

U-Boot Andrew Ruder 3 participants 4 messages Oct 27, 2014

lore
Share & tools
lore
#0 lore raw

Hey all,

It appears that 2014.10 has some issues with UBIFS initialization (details at bottom). git-bisect results in one of the following commits being broken. Surely it is the mtd one, but its parent commit (compat.h) does not compile.

[ff94bc40af3] mtd, ubi, ubifs: resync with Linux-3.14 [0c06db59836] lib, linux: move linux specific defines to linux/compat.h

A little background for the errors below. My MTD table:

device nor0 <0.flash>, # parts = 5

#: name                size            offset          mask_flags
0: uboot               0x00080000      0x00000000      0
1: env                 0x00020000      0x00080000      0
2: env_redund          0x00020000      0x000a0000      0
3: env_factory         0x00020000      0x000c0000      0
4: data                0x00400000      0x000e0000      0

=========================================================
Older (2014.07) U-Boot, I can do something like this:

$ erase nor0,4
Erase Flash Partition nor0,4, bank 0, 0x000e0000 - 0x004dffff 
................................ done
Erased 32 sectors
$ ubi part data
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:    130944 bytes
UBI: smallest flash I/O unit:    1
UBI: VID header offset:          64 (aligned 64)
UBI: data offset:                128
UBI: empty MTD device detected
UBI: create volume table (copy #1)
UBI: create volume table (copy #2)
UBI: attached mtd1 to ubi0
UBI: MTD device name:            "mtd=4"
UBI: MTD device size:            4 MiB
UBI: number of good PEBs:        32
UBI: number of bad PEBs:         0
UBI: max. allowed volumes:       128
UBI: wear-leveling threshold:    4096
UBI: number of internal volumes: 1
UBI: number of user volumes:     0
UBI: available PEBs:             28
UBI: total number of reserved PEBs: 4
UBI: number of PEBs reserved for bad PEB handling: 0
UBI: max/mean erase counter: 1/0
$

=========================================================
Newer (2014.10) U-Boot, I get the following

$ erase nor0,4
Erase Flash Partition nor0,4, bank 0, 0x000e0000 - 0x004dffff 
................................ done
Erased 32 sectors
$ ubi part data
UBI: attaching mtd1 to ubi0
$ ubi info
UBI: MTD device name:            "(a"
UBI: MTD device size:            18446742253448744536 MiB
UBI: physical eraseblock size:   -443412400 bytes (-433020 KiB)
UBI: logical eraseblock size:    -442945536 bytes
UBI: number of good PEBs:        -494718944
UBI: number of bad PEBs:         -444399596
UBI: smallest flash I/O unit:    -452780024
UBI: VID header offset:          -444391424 (aligned -390234000)
UBI: data offset:                -443207680
UBI: max. allowed volumes:       -509550577
UBI: wear-leveling threshold:    4096
UBI: number of internal volumes: 1
UBI: number of user volumes:     479
UBI: available PEBs:             -443686912
UBI: total number of reserved PEBs: -450899448
UBI: number of PEBs reserved for bad PEB handling: -514859008
UBI: max/mean erase counter: -450944464/-393084916

- Andy

#1 lore raw

Dear Andrew,

Quoted 5 lines · In message <20141027140241.GA7726@og3k> you wrote:

It appears that 2014.10 has some issues with UBIFS initialization (details at bottom). git-bisect results in one of the following commits being broken. Surely it is the mtd one, but its parent commit (compat.h) does not compile.

Which board are you talking about?

And which toolchain(s) are/have you been using to build U-Boot?

Best regards,

Wolfgang Denk

Signature · 5 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Most people would like to be delivered  from  temptation  but  would
like it to keep in touch."                             - Robert Orben
#2 lore raw
Quoted 6 lines · Wolfgang Denk
Quoted 4 lines

It appears that 2014.10 has some issues with UBIFS initialization (details at bottom). git-bisect results in one of the following commits being broken. Surely it is the mtd one, but its parent commit (compat.h) does not compile.

Which board are you talking about?

I have a board with a PXA270 and NOR flash. I am happy to submit the patches which add the board support, but they aren't really ready and cleaned up for submission.

Quoted 1 line

And which toolchain(s) are/have you been using to build U-Boot?

A crosstools-ng compiled gcc 4.8.2.

Would be interested to know if this is expected behavior:

a.) erase flash partition
b.) Call out erased partition as a ubi partition
c.) ubi triggers a initialization.

Because if so, that seems to no longer happen and it blindly attempts to use the erased flash as valid ubi data.

- Andy

#3 lore raw
Quoted 8 lines · Andrew Ruder
Quoted 6 lines · Wolfgang Denk
Quoted 4 lines

It appears that 2014.10 has some issues with UBIFS initialization (details at bottom). git-bisect results in one of the following commits being broken. Surely it is the mtd one, but its parent commit (compat.h) does not compile.

Which board are you talking about?

Quoted 7 lines

I have a board with a PXA270 and NOR flash. I am happy to submit the patches which add the board support, but they aren't really ready and cleaned up for submission.

Quoted 1 line

And which toolchain(s) are/have you been using to build U-Boot?

A crosstools-ng compiled gcc 4.8.2.

Wolfgang and I talked quite a bit on IRC and just catching up anyone else looking at this with a few additional details that came out of this.

The problem appears to stem from 'ubi part data' completing with no errors while also not filling in any of the ubi_devices[] array. This in turn results in the global 'ubi' variable being NULL (on PXA270 this is u-boot in flash). At this point display_ubi_info() gets passed NULL and ends up printing compiler-dependent junk for all the values.

That being said, I tried 4.9.1 and had the same issue (display_ubi_info() being passed NULL) with different symptoms (complete lock up because it ends up hitting data alignment issues when it starts treating opcodes as pointers).

- Andy