All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: u-boot@lists.denx.de
Subject: [U-Boot] UBIFS Problems with U-boot 2018.1 & 4.14 Linux
Date: Fri, 18 May 2018 11:21:54 +0200	[thread overview]
Message-ID: <3011236.5s9ed8DPq5@blindfold> (raw)
In-Reply-To: <bca825bd-d21e-f9e3-40da-53a9946286a0@denx.de>

Otto, Heiko,

Am Freitag, 18. Mai 2018, 10:44:43 CEST schrieb Heiko Schocher:
> Hello Otto,
> 
> Am 17.05.2018 um 23:12 schrieb Otto Blom:
> > Hi There !
> > 
> > I'm seeing a strange problem with u-boot 2018.1 and Linux 4.14 (Xilinx
> > Petalinux 2018.1).
> > If I write a ubifs image to flash using Linux 4.9 I can mount and read
> > files from the image
> > in both u-boot 2018.1 and Linux 4.14. However as soon as I write a new
> > file to the file-system
> > from Linux, U-boot can no longer read the file. The filesystem still
> > mounts, but when
> > I attempt to read the file I get the following error

If you write with Linux 4.14, is Linux 4.9 able to read the file?

> > UBIFS error (ubi0:0 pid 0): read_block: bad data node (block 661, inode 5763)
> >          magic          0x6101831
> >          crc            0x8e6aff1a
> >          node_type      1 (data node)
> >          group_type     0 (no node group)
> >          sqnum          63819
> >          len            3075
> >          key            (5763, data, 661)
> >          size           4096
> >          compr_typ      1
> >          data size      3027
> >          data:
> > UBIFS error (ubi0:0 pid 0): do_readpage: cannot read page 661 of inode
> > 5763, error -22
> 
> err = -EINVAL ...
> 
> > The file can still be read correctly from Linux, leading me to believe
> > there is some form
> > of incompatibility going on. I noticed that the ubifs version number
> > was bumped from 4 to 5
> > in this commit

Did you create a version 5 filesystem and tried to read it with u-boot?

> Hmm... looking into fs/ubifs/ubifs.c read_block() it seems code breaks
> here (line 702 ff):
> 
>          len = le32_to_cpu(dn->size);
>          if (len <= 0 || len > UBIFS_BLOCK_SIZE)
>                  goto dump;
> 
>          dlen = le32_to_cpu(dn->ch.len) - UBIFS_DATA_NODE_SZ;
>          out_len = UBIFS_BLOCK_SIZE;
>          err = ubifs_decompress(c, &dn->data, dlen, addr, &out_len,
>                                 le16_to_cpu(dn->compr_type));
>          if (err || len != out_len)
>                  goto dump;
> 
> len is 3075 ... so it would be nice to see a printf after ubifs_decompress()
> call, and print the values from out_len, err, len ...
> 
> It seems to me only ubifs_decompress() can fail here ... looking into
> ubifs_decompress()... Hmm... as we see no ubifs_err output from ubifs_decompress()
> only the case "len != out_len" can happen in your case ...
> 
> You use UBIFS_COMPR_LZO ... may a problem there?
> 
> No real idea why ...
> 
> > http://git.infradead.org/linux-ubifs.git/commit/fc4b891bbefa73b496bb44b076bb5274b6bfba68
> > 
> > Both Linux 4.9 and U-boot 18.1 still have version 4. Could that have
> > something do to with it ?
> 
> I think not, but may I miss here something...
> 
> @Richard: any idea?

Not really. Like you said, I'm interested in len, out_len too.
If this also not enlightens us, I'd like to have a dump of the UBIFS.

Thanks,
//richard

  reply	other threads:[~2018-05-18  9:21 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-17 21:12 [U-Boot] UBIFS Problems with U-boot 2018.1 & 4.14 Linux Otto Blom
2018-05-18  8:44 ` Heiko Schocher
2018-05-18  9:21   ` Richard Weinberger [this message]
2018-05-18 21:02     ` Otto Blom
2018-05-18 21:20       ` Richard Weinberger
2018-05-18 23:56         ` Otto Blom
2018-05-19  8:37           ` Richard Weinberger
2018-05-22  1:30             ` Otto Blom
2018-05-22  6:24               ` Richard Weinberger
2018-05-22  9:31                 ` Heiko Schocher
2018-05-22 17:23                   ` Otto Blom
2018-12-20 20:12                     ` jbd1986

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=3011236.5s9ed8DPq5@blindfold \
    --to=richard@nod.at \
    --cc=u-boot@lists.denx.de \
    /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.