All of lore.kernel.org
 help / color / mirror / Atom feed
From: Renaud Barbier <renaud.barbier@ge.com>
To: linux-mtd@lists.infradead.org
Subject: Re: UBI/UBIFS: debugging help
Date: Tue, 17 Mar 2015 18:31:01 +0000	[thread overview]
Message-ID: <550872E5.7040106@ge.com> (raw)
In-Reply-To: <5503285A.5090500@ge.com>

 I have added debug messages in the Linux UBIFS driver (I am using Linux
3.14) and noticed as well that read_block returns -ENOENT several times
toward the end of the copy of a file (512KB). Though, the Linux system
is able to read the whole file correctly (checksum is correct).

The boot loader however bails out on error.

The read_block  issue disappears if I delete, copy it back and remount
the UBIFS file system.

Below is the way I create the UBI image before formatting the SPI-nor:
# mkfs.ubifs -vv -F -d boot -m 1 -e 65408 -c 380  -U -x lzo -o boot.img
# ubinize -v -o test3_nor.img -p 64KiB -m 1 ubinize.cfg

with ubinize.cfg:
# Section header
[boot]
mode=ubi
# Source image
image=boot.img
# Volume ID in UBI image
vol_id=0
# Volume size
vol_size=25MiB
# Allow for static resize
vol_type=dynamic
# Volume name
vol_name=boot

So in summary, if I ubiformat the partition from Linux with a ubi image,
the Linux UBIFS driver function read_block returns ENOENT during file
copy and it completes.
However, if I copy a file to the UBIFS partition and read back after
re-mounting there is no issue.

Would somebody know whether the parameters to mkfs.ubifs and ubinize
have anything to do with read_block failing?

I created UBI images before for a flash with 128KB sectors and not seen
this problem.

Cheers.


On 13/03/2015 18:11, Renaud Barbier wrote:
> My platform is based on a ARM Cortex-A9 and boots barebox from a spi-nor.
> 
> I have tested UBI/UBIFS from Linux on this platform with no issue after
> disabling 4KB support for the spi nor I am using.
> 
> However, I got problem on the boot loader side. UBI/UBIFS has been
> ported by the barebox community from Linux and I used it successfully
> on a previous project on a PPC platform.
> 
> On the ARM platform I can ubiattach, mount the mtd partition and copy a
> small file (~65KB spanning two sectors). The issue comes when I copy out
> a larger file (512KB) out. It fails to copy the whole file.
> 
> At the point of failure, ubifs_tnc_locate fails resulting in the
> function read_block to return -ENOENT.
> 
> Debugging shows that in the function ubifs_search_zbranch no keys match
> is found prior to the failure.
> 
> I know this list is called linux-mtd but I was hoping that somebody
> could give me a pointer on where to look next. I am currently going
> through git logs and mailing list.
> 
> I am pretty confident the boot loader spi driver is working properly as
> raw write-read-compare have not failed.
> 
> cheers.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 

      parent reply	other threads:[~2015-03-17 18:31 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-13 18:11 UBI/UBIFS: debugging help Renaud Barbier
2015-03-13 18:42 ` Richard Weinberger
2015-03-16 18:10   ` Renaud Barbier
2015-03-17 18:31 ` Renaud Barbier [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=550872E5.7040106@ge.com \
    --to=renaud.barbier@ge.com \
    --cc=linux-mtd@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.