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

[Richard Weinberger]

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