[U-Boot] UBI on NAND flash again
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
On Wednesday 03 June 2009 20:05:51 Daniel Mack wrote:
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.
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: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
On Thu, Jun 04, 2009 at 08:42:40AM +0200, Stefan Roese wrote:
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.
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
On Thursday 04 June 2009 08:50:21 Daniel Mack wrote:
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: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
On Thu, Jun 04, 2009 at 08:56:51AM +0200, Stefan Roese wrote:
On Thursday 04 June 2009 08:50:21 Daniel Mack wrote:
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.
On Thursday 04 June 2009 10:06:55 Daniel Mack wrote:
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 =>
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: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
Dear Stefan Roese,
In message 200906041015.30536.sr@denx.de you wrote:
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:
...
=> ubi part rootfs Creating 1 MTD partitions on "nand0": 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
On Thu, Jun 04, 2009 at 10:15:30AM +0200, Stefan Roese wrote:
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:
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
On Thursday 04 June 2009 11:07:40 Daniel Mack wrote:
On Thu, Jun 04, 2009 at 10:15:30AM +0200, Stefan Roese wrote:
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:
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: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
Dear Daniel Mack,
In message 20090604090740.GD26688@buzzloop.caiaq.de you wrote:
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
On Thu, Jun 04, 2009 at 11:27:07AM +0200, Wolfgang Denk wrote:
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
Dear Stefan Roese,
In message 200906040856.51774.sr@denx.de you wrote:
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
participants (3)
-
Daniel Mack -
Stefan Roese -
Wolfgang Denk