[U-Boot] Current status of UBI?

[U-Boot] Current status of UBI?

[Matthew L. Creech]

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.
=>

-- 
Matthew L. Creech

[U-Boot] Current status of UBI?

[Matthew L. Creech]

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?  :)

-- 
Matthew L. Creech

[U-Boot] Current status of UBI?

[Stefan Roese]

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:
>
> 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

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).

> 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!

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 at denx.de
=====================================================================

[U-Boot] Current status of UBI?

[Stefan Roese]

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 at denx.de
=====================================================================

[U-Boot] Current status of UBI?

[Matthew L. Creech]

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] Current status of UBI?

[Werner Nedel]

 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.com>wrote:

> 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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>

[U-Boot] Current status of UBI?

[Matthew L. Creech]

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.  :)

-- 
Matthew L. Creech