[U-Boot] UBI on NAND flash again

[Daniel Mack]

I know there has been some traffic regaring the UBI layer recently,
however, reading the conversations didn't solve the issue I'm facing.

With a current U-Boot (git as of today) and 128MB NAND flash on a
PXA303, I get the following:

$ mtdparts

device nand0 <nand0>, # parts = 5
#: name size offset mask_flags
0: u-boot 0x00080000 0x00000000 0
1: env 0x00020000 0x00080000 0
2: splash 0x00060000 0x000a0000 0
3: kernel 0x00300000 0x00100000 0
4: ubilayer 0x07c00000 0x00400000 0

active partition: nand0,0 - (u-boot) 0x00080000 @ 0x00000000

defaults:
mtdids : nand0=nand0
mtdparts: mtdparts=nand0:512k(u-boot),128k(env),384k(splash),3M(kernel),-(ubilayer)
$ ubi part ubilayer
Creating 1 MTD partitions on "nand0":
0x00400000-0x08000000 : "mtd=4"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 126976 bytes
UBI: smallest flash I/O unit: 2048
UBI: VID header offset: 2048 (aligned 2048)
UBI: data offset: 4096
UBI error: ubi_init: cannot attach mtd1
UBI error: ubi_init: UBI error: cannot initialize UBI, error -12
UBI init error -12
exit not allowed from main input shell.


What puzzles me is this 'UBI: attaching mtd1 to ubi0' - shouldn't that
be 'mtd4'?

The same layout works well under Linux, btw.

Any hints?

Daniel

[Stefan Roese]

Post by Daniel Mack
I know there has been some traffic regaring the UBI layer recently,
however, reading the conversations didn't solve the issue I'm facing.
With a current U-Boot (git as of today) and 128MB NAND flash on a
$ mtdparts
device nand0 <nand0>, # parts = 5
#: name size offset mask_flags
0: u-boot 0x00080000 0x00000000 0
1: env 0x00020000 0x00080000 0
2: splash 0x00060000 0x000a0000 0
3: kernel 0x00300000 0x00100000 0
4: ubilayer 0x07c00000 0x00400000 0
mtdids : nand0=nand0
mtdparts=nand0:512k(u-boot),128k(env),384k(splash),3M(kernel),-(ubilayer) $
ubi part ubilayer
0x00400000-0x08000000 : "mtd=4"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 126976 bytes
UBI: smallest flash I/O unit: 2048
UBI: VID header offset: 2048 (aligned 2048)
UBI: data offset: 4096
UBI error: ubi_init: cannot attach mtd1
UBI error: ubi_init: UBI error: cannot initialize UBI, error -12
UBI init error -12
exit not allowed from main input shell.

Did you erase the FLASH partition? If not please try again after erasing.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: [phone] Fax: [phone] Email: office at denx.de
=====================================================================

[Daniel Mack]

Post by Stefan Roese

Post by Daniel Mack
mtdids : nand0=nand0
mtdparts=nand0:512k(u-boot),128k(env),384k(splash),3M(kernel),-(ubilayer) $
ubi part ubilayer
0x00400000-0x08000000 : "mtd=4"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 126976 bytes
UBI: smallest flash I/O unit: 2048
UBI: VID header offset: 2048 (aligned 2048)
UBI: data offset: 4096
UBI error: ubi_init: cannot attach mtd1
UBI error: ubi_init: UBI error: cannot initialize UBI, error -12
UBI init error -12
exit not allowed from main input shell.

Did you erase the FLASH partition? If not please try again after erasing.

I used ubiformat from Linux using /dev/ubi0 which is attached to
/dev/mtd4 which again points to the same area in the flash than
'ubilayer' does in U-Boot. So I should be able to access that same
volume from the bootloader, right? Or do I miss some important point?

Thanks,
Daniel

[Stefan Roese]

Post by Daniel Mack

Post by Stefan Roese

Post by Daniel Mack
UBI error: ubi_init: cannot attach mtd1
UBI error: ubi_init: UBI error: cannot initialize UBI, error -12
UBI init error -12
exit not allowed from main input shell.

Did you erase the FLASH partition? If not please try again after erasing.

I used ubiformat from Linux using /dev/ubi0 which is attached to
/dev/mtd4 which again points to the same area in the flash than
'ubilayer' does in U-Boot. So I should be able to access that same
volume from the bootloader, right? Or do I miss some important point?

I have to admit that I never used it this way. Using "ubi part" on an erased
partition works fine. I suggest you give it a try.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: [phone] Fax: [phone] Email: office at denx.de
=====================================================================

[Daniel Mack]

Post by Stefan Roese

Post by Daniel Mack

Post by Stefan Roese

Post by Daniel Mack
UBI error: ubi_init: cannot attach mtd1
UBI error: ubi_init: UBI error: cannot initialize UBI, error -12
UBI init error -12
exit not allowed from main input shell.

Did you erase the FLASH partition? If not please try again after erasing.

I used ubiformat from Linux using /dev/ubi0 which is attached to
/dev/mtd4 which again points to the same area in the flash than
'ubilayer' does in U-Boot. So I should be able to access that same
volume from the bootloader, right? Or do I miss some important point?

I have to admit that I never used it this way. Using "ubi part" on an erased
partition works fine. I suggest you give it a try.

Hmm. That still doesn't work for me, and I still wonder about the
'attaching mtd1 to ubi0' string, which looks like a mismatch to me.

Any idea?

Thanks,
Daniel


$ mtdparts

device nand0 <nand0>, # parts = 5
#: name size offset mask_flags
0: u-boot 0x00080000 0x00000000 0
1: env 0x00020000 0x00080000 0
2: splash 0x00060000 0x000a0000 0
3: kernel 0x00300000 0x00100000 0
4: ubilayer 0x07c00000 0x00400000 0

active partition: nand0,0 - (u-boot) 0x00080000 @ 0x00000000

defaults:
mtdids : nand0=nand0
mtdparts: mtdparts=nand0:512k(u-boot),128k(env),384k(splash),3M(kernel),-(ubilayer)

$ nand erase 0x00400000 0x07c00000

NAND erase: device 0 offset 0x400000, size 0x7c00000
Erasing at 0x7fe0000 -- 100% complete.
OK
$ ubi part ubilayer
Creating 1 MTD partitions on "nand0":
0x00400000-0x08000000 : "mtd=4"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 126976 bytes
UBI: smallest flash I/O unit: 2048
UBI: VID header offset: 2048 (aligned 2048)
UBI: data offset: 4096
UBI error: ubi_init: cannot attach mtd1
UBI error: ubi_init: UBI error: cannot initialize UBI, error -12
UBI init error -12
exit not allowed from main input shell.

[Stefan Roese]

Post by Daniel Mack

Post by Stefan Roese
I have to admit that I never used it this way. Using "ubi part" on an
erased partition works fine. I suggest you give it a try.

Hmm. That still doesn't work for me, and I still wonder about the
'attaching mtd1 to ubi0' string, which looks like a mismatch to me.

I would have to check in more details here. But I'm pretty sure this is not
the reason for your failure. Here a log from one of mine UBI systems:

=> mtdparts

device nand0 <nand>, # parts = 6
#: name size offset mask_flags
0: u-boot 0x00080000 0x00000000 0
1: env 0x00040000 0x00080000 0
2: kernel 0x00200000 0x000c0000 0
3: rootfs 0x01000000 0x002c0000 0
4: fs 0x02000000 0x012c0000 0
5: ubifs 0x04d40000 0x032c0000 0

active partition: nand0,0 - (u-boot) 0x00080000 @ 0x00000000

defaults:
mtdids : nand0=nand
mtdparts: mtdparts=nand:512k(u-
boot),256k(env),2m(kernel),16m(rootfs),32m(fs),-(ubifs)
=> nand erase 2c0000 1000000

NAND erase: device 0 offset 0x2c0000, size 0x1000000
Skipping bad block at 0x004e0000
Erasing at 0x12a0000 -- 100% complete.
OK
=> ubi part rootfs
Creating 1 MTD partitions on "nand0":
0x002c0000-0x012c0000 : "mtd=3"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 129024 bytes
UBI: smallest flash I/O unit: 2048
UBI: sub-page size: 512
UBI: VID header offset: 512 (aligned 512)
UBI: data offset: 2048
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=3"
UBI: MTD device size: 16 MiB
UBI: number of good PEBs: 127
UBI: number of bad PEBs: 1
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: 121
UBI: total number of reserved PEBs: 6
UBI: number of PEBs reserved for bad PEB handling: 2
UBI: max/mean erase counter: 0/0
=>

Post by Daniel Mack
Any idea?

Sorry, no. You need to further debug this problem to see where the failure is
generated.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: [phone] Fax: [phone] Email: office at denx.de
=====================================================================

[Wolfgang Denk]

Dear Stefan Roese,

Post by Stefan Roese
I would have to check in more details here. But I'm pretty sure this is not

...

Post by Stefan Roese
=> ubi part rootfs
0x002c0000-0x012c0000 : "mtd=3"
UBI: attaching mtd1 to ubi0

But then this is a bug that definitely needs to be fixed. Especially
when bringing up such a system such misleading output is unacceptable.

Best regards,

Wolfgang Denk

[Daniel Mack]

Post by Stefan Roese

Post by Daniel Mack
Hmm. That still doesn't work for me, and I still wonder about the
'attaching mtd1 to ubi0' string, which looks like a mismatch to me.

I would have to check in more details here. But I'm pretty sure this is not

Oh well - you're right. The code failed in vmalloc() due to a too small
CONFIG_SYS_MALLOC_LEN which I needed to augment to 512kB.

The 'mtd1' totally mislead me. Sorry for the noise, and thanks for your
help :)

Daniel

[Stefan Roese]

Post by Daniel Mack

Post by Stefan Roese

Post by Daniel Mack
Hmm. That still doesn't work for me, and I still wonder about the
'attaching mtd1 to ubi0' string, which looks like a mismatch to me.

I would have to check in more details here. But I'm pretty sure this is

Oh well - you're right. The code failed in vmalloc() due to a too small
CONFIG_SYS_MALLOC_LEN which I needed to augment to 512kB.

Yes, you're not the first person to stumble over this malloc problem. :)

I'll add some #warning/#error to the code to warn the user if such a mis-
configuration is happening.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: [phone] Fax: [phone] Email: office at denx.de
=====================================================================

[Wolfgang Denk]

Dear Daniel Mack,

Post by Daniel Mack
Oh well - you're right. The code failed in vmalloc() due to a too small
CONFIG_SYS_MALLOC_LEN which I needed to augment to 512kB.

But then a big, fat error message is needed there!

Best regards,

Wolfgang Denk

[Daniel Mack]

Post by Wolfgang Denk

Post by Daniel Mack
Oh well - you're right. The code failed in vmalloc() due to a too small
CONFIG_SYS_MALLOC_LEN which I needed to augment to 512kB.

But then a big, fat error message is needed there!

In vmalloc(), yes. That bug could hit any code that deals with
dynamically allocated memory.

Daniel

[Wolfgang Denk]

Dear Stefan Roese,

Post by Stefan Roese

Post by Daniel Mack
I used ubiformat from Linux using /dev/ubi0 which is attached to
/dev/mtd4 which again points to the same area in the flash than
'ubilayer' does in U-Boot. So I should be able to access that same
volume from the bootloader, right? Or do I miss some important point?

I have to admit that I never used it this way. Using "ubi part" on an erased
partition works fine. I suggest you give it a try.

But that seems a perfectly valid, and actually pretty resonable test
szenario. I think you should include this in your tests.

Best regards,

Wolfgang Denk