The function jffs2_1pass_read_inode() was discarding the summary
inodes and dirent because the value in datacrc flag wasn't
initialized in function jffs2_sum_process_sum_data().

This fix initializes the status of all summary records to indicate
that the CRC needs to be verified when they are loaded.

Before this fix, the behaviors produced by the undefined value of
datacrc was:
- Summary's registries were discarded when 'b->datacrc' is equal
  as 'CRC_BAD'.
- Summary's registries were not checked when b->datacrc differs of
  'CRC_BAD' and 'CRC_UNKNOWN'

So, almost all of the time the crc just isn't checked, and in some
cases the registries are discarded.

Signed-off-by: Wagner Popov dos Santos <wpopov@gmail.com>

Fixes address violation in functions read_nand_cached() and
read_onenand_cached(). This happens because these functions
try to read a fixed amount
of data even when the offset+length
is above the nand's limit.

Signed-off-by: Wagner Popov dos Santos <wpopov@gmail.com>

Move this uncommon header out of the common header.

Fix up some style problems in flash.h while we are here.

Signed-off-by: Simon Glass <sjg@chromium.org>

The inode list uses version and ino, the dirent list uses version and pino.
This information is collected during scanning, reducing accesses to flash
and significantly speeding up ls and read.

Signed-off-by: Petr Borsodi <petr.borsodi@i.cz>

Obsolete nodes (ie. without the JFFS2_NODE_ACCURATE flag) were ignored
because they had seemingly invalid crc. This could lead to finding
the phantom node header in obsolete node data.

Signed-off-by: Petr Borsodi <petr.borsodi@i.cz>

Drop inclusion of crc.h in common.h and use the correct header directly
instead.

With this we can drop the conflicting definition in fw_env.h and rely on
the crc.h header, which is already included.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

I failed to find where these two files are used and a few test compile
runs with JFFS2 enabled succeeded also without these.

When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from.  So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry.  Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.

In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.

This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents.  There's also a few places where I found we did not have a tag
and have introduced one.

Signed-off-by: Tom Rini <trini@konsulko.com>

This makes gcc no longer expect an out-of-line version of the
functions being present elsewhere.

This fixes a failure to build on several marvell targets with gcc-7 on
Debian:

  https://bugs.debian.org/877963

Signed-off-by: Adrian Bunk <bunk@debian.org>
Signed-off-by: Vagrant Cascadian <vagrant@debian.org>

Hello,

I ran into a problem with the JFFS2 filesystem driver implemented in U-Boot.

I've got a NAND device that has correctable ECC errors (corrected somewhere in mtd/nand/nand_base.c).
The NAND driver tells the filesystem layer (jffs2_1pass.c) above that there occurred correctable ECC errors and returns with a "value > 0".
The JFFS2 driver recognizes the corrected ECC errors as real error and skips this block because the only accepts a "return value == 0" as correct.

This problem exists for over 8 years (I checked version 2010.09) so I'm a little bit worried that I interpreted something wrong or didn't get the whole context.

Can someone confirm this bug (and the bugfix) in the u-boot jffs2 driver?

There was a mail in 2012 that mentioned the same problem, but there was no patch:
http://u-boot.10912.n7.nabble.com/JFFS2-seems-to-drop-nand-data-with-ECC-corrections-td142008.html
Sometime after this discussion the return value of nand_read() changed from -EUCLEAN as correctable ECC error to a positive value with the count of ECC corrected errors.

With kind reguards,
Uwe Engling