[U-Boot] UBIFS Problems with U-boot 2018.1 & 4.14 Linux

Richard Weinberger
2018-05-18T09:21:54Z

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