public inbox for u-boot@lists.denx.de
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox