[U-Boot] Current status of UBI?
Hi, I'm using the latest U-Boot GIT snapshot (4/28), and trying to get UBI/UBIFS working. I'm wondering what the current status of UBI support in U-Boot is, and whether what I'm doing will work.
The goal is to get a single R/W filesystem on a large NAND partition. If I understand correctly, I should be able to:
1. [In U-Boot]: Use "mtdparts" to partition my NAND device 2. [In U-Boot]: Use "ubi part" to setup UBI on a partition 3. [In U-Boot]: Use "ubi create" to create a volume which fills the whole partition 4. [On my PC]: Use "mkfs.ubifs" & "ubinize" to create a UBIFS image 5. [In U-Boot]: Use "ubi write" to write the UBIFS image to the volume 6. [In Linux]: Boot using the UBIFS image as my rootfs
Is this more or less correct?
The problem I'm currently running into is step 2, which throws an error in ubi_io_write() (see below). Googling around turned up a few hits that suggested turning off sub-page writes, so I tried adding NAND_NO_SUBPAGE_WRITE to NAND_SAMSUNG_LP_OPTIONS, but that causes a crash. Actually, it gets to volume table copy #2 in that case, so the crash may be unrelated to subpage writes.
Anyway, I'm mainly wondering whether this is a good approach before I go chasing down this crash, and also whether others are using UBIFS on large-page flash devices successfully in U-Boot. Any feedback is appreciated, thanks!
====
=> mtdparts
device nand0 <flash>, # parts = 2 #: name size offset mask_flags 0: uboot 0x00500000 0x00000000 0 1: root 0x3fb00000 0x00500000 0
active partition: nand0,0 - (uboot) 0x00500000 @ 0x00000000
defaults: mtdids : nand0=flash mtdparts: mtdparts=flash:5M(uboot),-(root) => ubi part root Creating 1 MTD partitions on "nand0": 0x00500000-0x40000000 : "mtd=1" Bad block table found at page 524224, version 0x01 Bad block table found at page 524160, version 0x01 nand_read_bbt: Bad block at 0x01fc0000 nand_read_bbt: Bad block at 0x03440000 nand_read_bbt: Bad block at 0x03460000 nand_read_bbt: Bad block at 0x21fc0000 nand_read_bbt: Bad block at 0x21fe0000 nand_read_bbt: Bad block at 0x3a000000 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 error: ubi_io_write: error -5 while writing 512 bytes to PEB 0:512, written 0 bytes UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 1:512, written 0 bytes UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 2:512, written 0 bytes UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 3:512, written 0 bytes UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 4:512, written 0 bytes UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 5:512, written 0 bytes UBI error: ubi_init: cannot attach mtd1 UBI error: ubi_init: UBI error: cannot initialize UBI, error -5 UBI init error -5 exit not allowed from main input shell. =>
On Thu, Apr 30, 2009 at 3:36 PM, Matthew L. Creech mlcreech@gmail.com wrote:
The problem I'm currently running into is step 2, which throws an error in ubi_io_write() (see below). Googling around turned up a few hits that suggested turning off sub-page writes, so I tried adding NAND_NO_SUBPAGE_WRITE to NAND_SAMSUNG_LP_OPTIONS, but that causes a crash. Actually, it gets to volume table copy #2 in that case, so the crash may be unrelated to subpage writes.
It seems like disabling subpage writes might be the right thing to do, because once in a while now I _can_ at least attach to a UBI partition ("ubi part") without error. But it usually crashes. The backtraces for the crash vary, but here's a typical example:
0x00144280 -- 0x00143cd0 + 0x05b0 ubi_read_volume_table 0x00143130 -- 0x00142d54 + 0x03dc ubi_attach_mtd_dev 0x001435ec -- 0x001434e4 + 0x0108 ubi_init 0x0011ec24 -- 0x0011e9e4 + 0x0240 do_ubi 0x00126234 -- 0x00125a9c + 0x0798 run_list_real 0x00125754 -- 0x00125198 + 0x05bc parse_stream_outer 0x00125960 -- 0x00125910 + 0x0050 parse_file_outer 0x00128854 -- 0x0012874c + 0x0108 main_loop 0x001048e0 -- 0x0010470c + 0x01d4 board_init_r 0x001035e8 -- 0x001035e8 + 0x0000 trap_init
Nothing special. ubi_read_volume_table is always in the backtrace, though sometimes there's 1 or 2 nested calls above it. Sometimes the crashes are at or around create_empty_lvol() -> create_vtbl() -> ubi_scan_find_seb(), so the problem occurs no later than that in the call sequence. And this is always with copy #2 of the volume table.
Anyone familiar with UBI care to chime in? :)
On Thursday 30 April 2009, Matthew L. Creech wrote:
On Thu, Apr 30, 2009 at 3:36 PM, Matthew L. Creech mlcreech@gmail.com
wrote:
It seems like disabling subpage writes might be the right thing to do, because once in a while now I _can_ at least attach to a UBI partition ("ubi part") without error. But it usually crashes. The backtraces for the crash vary, but here's a typical example:
0x00144280 -- 0x00143cd0 + 0x05b0 ubi_read_volume_table 0x00143130 -- 0x00142d54 + 0x03dc ubi_attach_mtd_dev 0x001435ec -- 0x001434e4 + 0x0108 ubi_init 0x0011ec24 -- 0x0011e9e4 + 0x0240 do_ubi 0x00126234 -- 0x00125a9c + 0x0798 run_list_real 0x00125754 -- 0x00125198 + 0x05bc parse_stream_outer 0x00125960 -- 0x00125910 + 0x0050 parse_file_outer 0x00128854 -- 0x0012874c + 0x0108 main_loop 0x001048e0 -- 0x0010470c + 0x01d4 board_init_r 0x001035e8 -- 0x001035e8 + 0x0000 trap_init
Nothing special. ubi_read_volume_table is always in the backtrace, though sometimes there's 1 or 2 nested calls above it. Sometimes the crashes are at or around create_empty_lvol() -> create_vtbl() -> ubi_scan_find_seb(), so the problem occurs no later than that in the call sequence. And this is always with copy #2 of the volume table.
Anyone familiar with UBI care to chime in? :)
Which platform are you using? PPC? And which NAND chip?
And again, please make sure that the MTD partition referenced by "ubi part" is erased.
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 Thursday 30 April 2009, Matthew L. Creech wrote:
Hi, I'm using the latest U-Boot GIT snapshot (4/28), and trying to get UBI/UBIFS working. I'm wondering what the current status of UBI support in U-Boot is, and whether what I'm doing will work.
Current status: I'm successfully using UBI and UBIFS on multiple platforms (mostly PPC based).
The goal is to get a single R/W filesystem on a large NAND partition.
You are aware that the U-Boot UBIFS implementation is (intentionally) read-only?
If I understand correctly, I should be able to:
- [In U-Boot]: Use "mtdparts" to partition my NAND device
- [In U-Boot]: Use "ubi part" to setup UBI on a partition
- [In U-Boot]: Use "ubi create" to create a volume which fills the
whole partition 4. [On my PC]: Use "mkfs.ubifs" & "ubinize" to create a UBIFS image 5. [In U-Boot]: Use "ubi write" to write the UBIFS image to the volume
No. If you used "ubinize" then your image is already an "UBI" image which has to be written to FLASH with the "usual" FLASH commands (e.g. cp.b for NOR, nand write for NAND etc).
- [In Linux]: Boot using the UBIFS image as my rootfs
Is this more or less correct?
The problem I'm currently running into is step 2, which throws an error in ubi_io_write() (see below). Googling around turned up a few hits that suggested turning off sub-page writes, so I tried adding NAND_NO_SUBPAGE_WRITE to NAND_SAMSUNG_LP_OPTIONS, but that causes a crash. Actually, it gets to volume table copy #2 in that case, so the crash may be unrelated to subpage writes.
Anyway, I'm mainly wondering whether this is a good approach before I go chasing down this crash, and also whether others are using UBIFS on large-page flash devices successfully in U-Boot. Any feedback is appreciated, thanks!
I have to admit that I never used UBIFS on large page NAND chips yet. One thing you should make sure is to erase the FLASH before calling "ubi part". I suggest you start a again with step 2 after erasing this UBI partition.
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 Mon, May 4, 2009 at 3:59 AM, Stefan Roese sr@denx.de wrote:
The goal is to get a single R/W filesystem on a large NAND partition.
You are aware that the U-Boot UBIFS implementation is (intentionally) read-only?
Yes, I understand that. Read-only from U-Boot is fine (sorry, should have been more specific).
No. If you used "ubinize" then your image is already an "UBI" image which has to be written to FLASH with the "usual" FLASH commands (e.g. cp.b for NOR, nand write for NAND etc).
Ah, ok. That's actually really useful for our manufacturing process. But skipping the "ubinize" step, then, the other steps look ok?
I have to admit that I never used UBIFS on large page NAND chips yet. One thing you should make sure is to erase the FLASH before calling "ubi part". I suggest you start a again with step 2 after erasing this UBI partition.
Right, I'm being sure to erase it each time before I try "ubi part", just to limit the number of variables. I'm trying to do:
nand erase 500000 (0x500000 is the start of my UBI partition) mtdparts default (assigns 0x500000 and up to "root" partition) ubi part root
and getting what seems like stack corruption around ubi_read_volume_table() for table copy #2. Is there anything I can do to try and narrow down what's going wrong, other than selectively removing code paths to see what helps? I've never had to debug at the U-Boot level before.
Thanks for the response
Right, I'm being sure to erase it each time before I try "ubi part", just to limit the number of variables. I'm trying to do:
nand erase 500000 (0x500000 is the start of my UBI partition) mtdparts default (assigns 0x500000 and up to "root" partition) ubi part root
Should you have to pass the nand offset too? I'm using UBI and my erase command is:
nand erase clean 0x0 0x40000000 (the start of my nand physical address)
On Mon, May 4, 2009 at 12:12 PM, Matthew L. Creech mlcreech@gmail.comwrote:
On Mon, May 4, 2009 at 3:59 AM, Stefan Roese sr@denx.de wrote:
The goal is to get a single R/W filesystem on a large NAND partition.
You are aware that the U-Boot UBIFS implementation is (intentionally) read-only?
Yes, I understand that. Read-only from U-Boot is fine (sorry, should have been more specific).
No. If you used "ubinize" then your image is already an "UBI" image which
has
to be written to FLASH with the "usual" FLASH commands (e.g. cp.b for
NOR,
nand write for NAND etc).
Ah, ok. That's actually really useful for our manufacturing process. But skipping the "ubinize" step, then, the other steps look ok?
I have to admit that I never used UBIFS on large page NAND chips yet. One thing you should make sure is to erase the FLASH before calling "ubi
part". I
suggest you start a again with step 2 after erasing this UBI partition.
Right, I'm being sure to erase it each time before I try "ubi part", just to limit the number of variables. I'm trying to do:
nand erase 500000 (0x500000 is the start of my UBI partition) mtdparts default (assigns 0x500000 and up to "root" partition) ubi part root
and getting what seems like stack corruption around ubi_read_volume_table() for table copy #2. Is there anything I can do to try and narrow down what's going wrong, other than selectively removing code paths to see what helps? I've never had to debug at the U-Boot level before.
Thanks for the response
-- Matthew L. Creech _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
On Mon, May 4, 2009 at 3:33 PM, Werner Nedel wmnedel@gmail.com wrote:
Should you have to pass the nand offset too? I'm using UBI and my erase command is:
nand erase clean 0x0 0x40000000 (the start of my nand physical address)
I think it should erase to the end of the device by default. Seems to work that way, anyway. :)
participants (3)
-
Matthew L. Creech -
Stefan Roese -
Werner Nedel