Stefan Roese authored 6 years ago and Heiko Schocher committed 6 years ago

I just stumbled over some cluttered UBIFS messages. It seems some
newline chars are missing in the current U-Boot UBI source.

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Heiko Schocher <hs@denx.de>

Masahiro Yamada authored 6 years ago and Tom Rini committed 6 years ago

In int-ll64.h, we always use the following typedefs:

  typedef unsigned int         u32;
  typedef unsigned long        uintptr_t;
  typedef unsigned long long   u64;

This does not need to match to the compiler's <inttypes.h>.
Do not include it.

The use of PRI* makes the code super-ugly.  You can simply use
"l" for printing uintptr_t, "ll" for u64, and no modifier for u32.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Andreas Dannenberg authored 6 years ago and Tom Rini committed 6 years ago

In order to make the debug print in file_fat_read_at() a tad more useful,
show the offset the file is being read at alongside the filename.

Suggested-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

Heinrich Schuchardt authored 6 years ago and Tom Rini committed 6 years ago

%s/dumm /dummy /

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

fs_fat_write() is not able to write to subdirectories.

Currently if a filepath with a leading slash is passed, the slash is
treated as part of the filename to be created in the root directory.

Strip leading (back-)slashes.

Check that the remaining filename does not contain any illegal characters
(<>:"/\|?*). This way we will throw an error when trying to write to a
subdirectory.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>

Marek Behún authored 6 years ago and Tom Rini committed 6 years ago

The comparison
  logical > item->logical + item->length
in btrfs_map_logical_to_physical is wrong and should be instead
  logical >= item->logical + item->length
For example, if
  item->logical = 4096
  item->length = 4096
and we are looking for logical = 8192, it is not part of item (item is
[4096, 8191]). But the comparison is false and we think we have found
the correct item, although we should be searing in the right subtree.

This fixes some bugs I encountered.

Signed-off-by: Marek Behun <marek.behun@nic.cz>

Christophe Kerello authored 6 years ago and Heiko Schocher committed 6 years ago

By checking ubifs source code, s_instances parameter is not
used anymore. So, set this parameter and the associated source
code under __UBOOT__ compilation.

Signed-off-by: Christophe Kerello <christophe.kerello@st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>

Yevgeny Popovych authored 6 years ago and Tom Rini committed 6 years ago

This is the case when reading freshly created filesystem.
The error message is like the following:
    btrfs_read_superblock: No valid root_backup found!

Since the data from super_roots/root_backups is not actually used -
decided to rework btrfs_newest_root_backup() into
btrfs_check_super_roots() that will only check if super_roots
array is valid and correctly handle empty scenario.

As a result:
* btrfs_read_superblock() now only checks if super_roots array is valid;
  the case when it is empty is considered OK.
* removed root_backup pointer from btrfs_info,
  which would be NULL in case of empty super_roots.
* btrfs_read_superblock() verifies number of devices from the superblock
  itself, not newest root_backup.

Signed-off-by: Yevgeny Popovych <yevgenyp@pointgrab.com>
Cc: Marek Behun <marek.behun@nic.cz>
Cc: Sergey Struzh <sergeys@pointgrab.com>

Alexey Brodkin authored 6 years ago and Tom Rini committed 6 years ago

Often during debugging session it's very interesting to see
what data we were dealing with. For example what we write or read
to/from memory or peripherals.

This change introduces functions that allow to dump binary
data with one simple function invocation like:
------------------->8----------------
print_hex_dump_bytes("", DUMP_PREFIX_OFFSET, buf, len);
------------------->8----------------

which gives us the following:
------------------->8----------------
00000000: f2 b7 c9 88 62 61 75 64 72 61 74 65 3d 31 31 35  ....baudrate=115
00000010: 32 30 30 00 62 6f 6f 74 61 72 67 73 3d 63 6f 6e  200.bootargs=con
00000020: 73 6f 6c 65 3d 74 74 79 53 33 2c 31 31 35 32 30  sole=ttyS3,11520
00000030: 30 6e 38 00 62 6f 6f 74 64 65 6c 61 79 3d 33 00  0n8.bootdelay=3.
00000040: 62 6f 6f 74 66 69 6c 65 3d 75 49 6d 61 67 65 00  bootfile=uImage.
00000050: 66 64 74 63 6f 6e 74 72 6f 6c 61 64 64 72 3d 39  fdtcontroladdr=9
00000060: 66 66 62 31 62 61 30 00 6c 6f 61 64 61 64 64 72  ffb1ba0.loadaddr
00000070: 3d 30 78 38 32 30 30 30 30 30 30 00 73 74 64 65  =0x82000000.stde
00000080: 72 72 3d 73 65 72 69 61 6c 30 40 65 30 30 32 32  rr=serial0@e0022
00000090: 30 30 30 00 73 74 64 69 6e 3d 73 65 72 69 61 6c  000.stdin=serial
000000a0: 30 40 65 30 30 32 32 30 30 30 00 73 74 64 6f 75  0@e0022000.stdou
000000b0: 74 3d 73 65 72 69 61 6c 30 40 65 30 30 32 32 30  t=serial0@e00220
000000c0: 30 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00  00..............
...
------------------->8----------------

Source of hexdump.c was copied from Linux kernel v4.7-rc2.

Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Anatolij Gustschin <agust@denx.de>
Cc: Mario Six <mario.six@gdsys.cc>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Stefan Roese <sr@denx.de>

Yevgeny Popovych authored 6 years ago and Tom Rini committed 6 years ago

This causes errors when translating logical addresses to physical:
  btrfs_map_logical_to_physical: Cannot map logical address <addr> to physical
  btrfs_file_read: Error reading extent

The behavior of btrfs_map_logical_to_physical() is to stop traversing
CHUNK_TREE when it encounters first non-CHUNK_ITEM, which makes
only some portion of CHUNK_ITEMs being read.
Change it to skip over non-chunk items.

Signed-off-by: Yevgeny Popovych <yevgenyp@pointgrab.com>
Cc: Marek Behun <marek.behun@nic.cz>
Cc: Sergey Struzh <sergeys@pointgrab.com>
Reviewed-by: Marek Behun <marek.behun@nic.cz>

Alex Kiernan authored 6 years ago and Marek Vasut committed 6 years ago

Add fs_get_type_name so we can get the current filesystem type.

Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Joe Hershberger <joe.hershberger@ni.com>

Eugen Hristev authored 6 years ago and Tom Rini committed 6 years ago

Found a crash while issuing ext4ls with a non-existent directory.
Crash test:

=> ext4ls mmc 0 1
** Can not find directory. **
data abort
pc : [<3fd7c2ec>]          lr : [<3fd93ed8>]
reloc pc : [<26f142ec>]    lr : [<26f2bed8>]
sp : 3f963338  ip : 3fdc3dc4     fp : 3fd6b370
r10: 00000004  r9 : 3f967ec0     r8 : 3f96db68
r7 : 3fdc99b4  r6 : 00000000     r5 : 3f96dc88  r4 : 3fdcbc8c
r3 : fffffffa  r2 : 00000000     r1 : 3f96e0bc  r0 : 00000002
Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...

resetting ...

Tested on SAMA5D2_Xplained board (sama5d2_xplained_mmc_defconfig)

Looks like crash is introduced by commit:
"fa9ca8a5" fs/ext4/ext4fs.c: Free dirnode in error path of ext4fs_ls

Issue is that dirnode is not initialized, and then freed if the call
to ext4_ls fails. ext4_ls will not change the value of dirnode in this case
thus we have a crash with data abort.

I added initialization and a check for dirname being NULL.

Fixes: "fa9ca8a5" fs/ext4/ext4fs.c: Free dirnode in error path of ext4fs_ls
Cc: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Cc: Tom Rini <trini@konsulko.com>
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

Patrice Chotard authored 6 years ago and Heiko Schocher committed 6 years ago

This patch solves assert failed displayed in the console during a boot.
The root cause is that the ubifs_inode is not already allocated when
ubifs_printdir and ubifs_finddir functions are called.

Trace showing the issue:
feed 'boot.scr.uimg', ino 94, new f_pos 0x17b40ece
dent->ch.sqnum '7132', creat_sqnum 3886945402880
UBIFS assert failed in ubifs_finddir at 436
INODE ALLOCATION: creat_sqnum '7129'
Found U-Boot script /boot.scr.uimg

Signed-off-by: Christophe Kerello <christophe.kerello@st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>

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>

Bradley Bolen authored 6 years ago and Heiko Schocher committed 6 years ago

The mutex lock and unlock functions are stubbed out and mutex_is_locked
was 0.  This caused asserts to fail in ubifs code when checking that the
mutex was locked.  For example,

UBIFS assert failed in ubifs_change_lp at 540
UBIFS assert failed in ubifs_release_lprops at 278

Assume that the "mutex" is locked since that is the normal case when it
is checked in the ubifs code.

Signed-off-by: Bradley Bolen <bradleybolen@gmail.com>

Marek Behún authored 7 years ago and Tom Rini committed 6 years ago

Signed-off-by: Marek Behun <marek.behun@nic.cz>

Andre Heider authored 7 years ago and Simon Glass committed 6 years ago

The value at the end of the rom is not a pointer, it is an offset
relative to the end of rom.

Signed-off-by: Andre Heider <a.heider@gmail.com>

Petr Vorel authored 7 years ago and Heiko Schocher committed 7 years ago

Introduce another difference from upstream (kernel) source in
fs/ubifs/super.c: adding preprocessor condition as y variable in
mount_ubifs() depends on CONFIG_UBIFS_SILENCE_MSG:
fs/ubifs/super.c:1337:15: error: variable ?y? set but not used [-Werror=unused-but-set-variable]
  long long x, y;

Not setting CONFIG_UBIFS_SILENCE_MSG in am335x_igep003x_defconfig and
igep0032_defconfig. Although it was defined in their config headers, it
depends on CMD_UBIFS which is not set for them.

Signed-off-by: Petr Vorel <petr.vorel@gmail.com>
Cc: Joe Hershberger <joe.hershberger@ni.com>
Cc: Heiko Schocher <hs@denx.de>

Petr Vorel authored 7 years ago and Heiko Schocher committed 7 years ago

Use of CONFIG_UBIFS_SILENCE_MSG was added in
147162da ("ubi: ubifs: Turn off verbose prints")

Then it was removed in
ff94bc40 ("mtd, ubi, ubifs: resync with Linux-3.14")

Cc: Joe Hershberger <joe.hershberger@ni.com>
Cc: Heiko Schocher <hs@denx.de>
Signed-off-by: Petr Vorel <petr.vorel@gmail.com>

Marek Behún authored 7 years ago and Tom Rini committed 7 years ago

Other filesystem drivers don't do this.

Signed-off-by: Marek Behun <marek.behun@nic.cz>

Heinrich Schuchardt authored 7 years ago and Tom Rini committed 7 years ago

The iterator of list_for_each() is never NULL.

Identified with coccinelle.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

When printing a size_t value we need to use %zu for portability between
32bit and 64bit targets.

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Marek Behun <marek.behun@nic.cz>

Alberto Sánchez Molero authored 7 years ago and Tom Rini committed 7 years ago

Loading files stored with lzo compression from a btrfs filesystem was
producing unaligned memory accesses, which were causing a data abort
and a reset on an Orange Pi Zero.

The change in hash.c is not triggered by any error but follows the
same pattern. Please confirm.

Fixed according to doc/README.unaligned-memory-access.txt

Signed-off-by: Alberto Sánchez Molero <alsamolero@gmail.com>
Tested-by: Robert Nelson <robertcnelson@gmail.com>

Tuomas Tynkkynen authored 7 years ago and Tom Rini committed 7 years ago

fat.h unconditionally defines CONFIG_SUPPORT_VFAT (and has done since
2003), so as a result VFAT support is always enabled regardless of
whether a board config defines it or not. Drop this unnecessary option.

Signed-off-by: Tuomas Tynkkynen <tuomas@tuxera.com>

Tuomas Tynkkynen authored 7 years ago and Tom Rini committed 7 years ago

Signed-off-by: Tuomas Tynkkynen <tuomas@tuxera.com>

Tuomas Tynkkynen authored 7 years ago and Tom Rini committed 7 years ago

Migrate the following symbols to Kconfig:

CONFIG_FS_EXT4
CONFIG_EXT4_WRITE

The definitions in config_fallbacks.h can now be expressed in Kconfig.

Signed-off-by: Tuomas Tynkkynen <tuomas@tuxera.com>

Heinrich Schuchardt authored 7 years ago and Tom Rini committed 7 years ago

The message "reading %s\n" may be interesting when
debugging but otherwise it is superfluous.

Only output the message when debugging.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>

Heinrich Schuchardt authored 7 years ago and Tom Rini committed 7 years ago

The message
"** %s shorter than offset + len **\n"
may be interesting when debugging but it does not indicate an
error.

So we should not write it if we are not in debug mode.

Fixes: 7a3e70cf fs/fs.c: read up to EOF when len would read past EOF
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>

Jean-Jacques Hiblot authored 7 years ago and Tom Rini committed 7 years ago

commit 21a24c3b ("fs/fat: fix case for FAT shortnames") made it
possible that get_name() returns file names with some upper cases.
find_directory_entry() must be updated to take this account, and use
case-insensitive functions to compare file names.

Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

This header was renamed to rawnand.h in Linux.

The following is the corresponding commit in Linux.

  commit d4092d76a4a4e57b65910899948a83cc8646c5a5
  Author: Boris Brezillon <boris.brezillon@free-electrons.com>
  Date:   Fri Aug 4 17:29:10 2017 +0200

      mtd: nand: Rename nand.h into rawnand.h

      We are planning to share more code between different NAND based
      devices (SPI NAND, OneNAND and raw NANDs), but before doing that
      we need to move the existing include/linux/mtd/nand.h file into
      include/linux/mtd/rawnand.h so we can later create a nand.h header
      containing all common structure and function prototypes.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Neil Armstrong authored 7 years ago and Tom Rini committed 7 years ago

Before this patch one could receive following errors when executing "fatls"
command on machine with cache enabled (ex i.MX6Q) :

=> fatls mmc 0:1
CACHE: Misaligned operation at range [4f59dfc8, 4f59e7c8]
CACHE: Misaligned operation at range [4f59dfc8, 4f59e7c8]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x4f59dfc8
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x4f59e7c8
CACHE: Misaligned operation at range [4f59dfc8, 4f59e7c8]
CACHE: Misaligned operation at range [4f59dfc8, 4f59e7c8]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x4f59dfc8
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x4f59e7c8

To alleviate this problem - the calloc()s have been replaced with
malloc_cache_aligned() and memset().

After those changes the buffers are properly aligned (with both start
address and size) to SoC cache line.

Fixes: 09fa964b ("fs/fat: Fix 'CACHE: Misaligned operation at range' warnings")
Suggested-by: Lukasz Majewski <lukma@denx.de>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>

Heinrich Schuchardt authored 7 years ago and Tom Rini committed 7 years ago

It is unwise to first dereference a variable
and then to check if it was NULL.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Marek Behun <marek.behun@nic.cz>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

Heinrich Schuchardt authored 7 years ago and Tom Rini committed 7 years ago

The iterator variable of list_for_each is never NULL.
if (1 || A) is always true.
Use break if entry found.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

Heinrich Schuchardt authored 7 years ago and Heiko Schocher committed 7 years ago

kfree() calls free.
free() checks if the parameter is NULL.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

Ian Ray authored 7 years ago and Stefano Babic committed 7 years ago

Some fixes when reading EXT files and directory entries were identified
after using e2fuzz to corrupt an EXT3 filesystem:

 - Stop reading directory entries if the offset becomes badly aligned.

 - Avoid overwriting memory by clamping the length used to zero the buffer
   in ext4fs_read_file.  Also sanity check blocksize.

Signed-off-by: Ian Ray <ian.ray@ge.com>
Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk>
Reviewed-by: Stefano Babic <sbabic@denx.de>

Masahiro Yamada authored 7 years ago and Tom Rini committed 7 years ago

All users of this macro have been converted.  Remove MTDDEBUG and
related CONFIG options.

ubifs_dbg_msg_key() is kept.  It is silent unless DEBUG is defined.

I am not touching scripts/config_whitelist.txt.  The deprecated options
will be dropped by the next resync.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Vagrant Cascadian authored 7 years ago and Tom Rini committed 7 years ago

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>

Engling, Uwe authored 7 years ago and Tom Rini committed 7 years ago

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

Marek Behún authored 7 years ago and Tom Rini committed 7 years ago

Otherwise fs_opendir will fault.

Signed-off-by: Marek Behun <marek.behun@nic.cz>

Marek Behún authored 7 years ago and Tom Rini committed 7 years ago

I accidentaly left a foreign language note in the code from development.

Signed-off-by: Marek Behun <marek.behun@nic.cz>