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
next prev parent 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.