Age | Commit message (Collapse) | Author |
|
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
Signed-off-by: Richard Weinberger <richard@nod.at>
|
|
This _entire_ file is dead code. The download packages on the FTP
server contain it all the way back to mtd-utils 1.0, but it isn't
built in any of them. The git history (which dates back to 2006)
contains no instance where that file was ever used in a build process.
A quick look at various distribution packages didn't reveal any that
contained a jffs-dump utilty. There have been no major changes to this
file since the initial commit. It won't even compile as it doesn't have
a PROGRAM_NAME defined required by common.h at least since 2010.
At this point, it can be safeley assumed that nobody will miss this.
They had at least 10 years to do something about it.
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
Signed-off-by: Richard Weinberger <richard@nod.at>
|
|
The mtd_get_dev_info1 function reads (among other things) name and type
string into coresponding struct mtd_dev_info fields.
The struct mtd_dev_info has the string fields marked const, requiring
them to be cast to non-const version during initialization.
This cast was previously omitted from the dev_read_data calls,
triggering warnings during compilation.
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
Signed-off-by: Richard Weinberger <richard@nod.at>
|
|
Errors may happen, it's e.g. easy on embedded devices to run out of space
when dumping big partitions. This patch adds a helper function for
writing. It deals with partial writes and just returns 0 on success or
error number.
The old code didn't check for errors at all which could result in
incomplete dumps without exiting with an error.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
|
|
This fix was initialially part of a patch submitted by Carsten Schlote
in January 2009. It didn't get merged back then because of coding style
issues and a proposed buffer size change guessed by shotgun debugging.
I was unable to reproduce the claimed segfaults in the compression
function that lead to the proposed buffer size change. Valgrind did
not issue any errors or warnings about the code in question either,
so I didn't include the proposed buffer size change.
The original patch also added a call to lzo_init(), which (according
to LZO documentation & source code) does not actually perform any
initialization, but only checks at runtime that the data type sizes and
endianness of the library code match those in the caller code and
should be unnecessary.
Other fixes from the original patch have already been added over
the years.
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
Signed-off-by: Richard Weinberger <richard@nod.at>
|
|
In commit ca7a5eda221d("integck.c: Fix buffer overflow in save_file")
we started including header <bits/stdio_lim.h>.
But with musl C library, we get following build error
integck.c:37:28: fatal error: bits/stdio_lim.h: No such file or directory
#include <bits/stdio_lim.h>
^
compilation terminated.
make[2]: *** [integck] Error 1
Header <bits/stdio_lim.h> is not available in musl C library. However
<stdio.h> has all definition that <bits/stdio_lim.h> supposed to be
providing. Moreover <bits/stdio_lim.h> shouldn't be included directly
instead we should be using <stdio.h>.
Since we already include <stdio.h> and in case of uClibc or glibc
<bits/stdio_lim.h> gets included internally, we can safely remove it.
This build issue is found by Buildroot autobuilder
http://autobuild.buildroot.net/results/175/1754861457af520480cc34d7d2d0edff2868ff66/
Fixes: ca7a5eda221d("integck.c: Fix buffer overflow in save_file")
Signed-off-by: Rahul Bedarkar <rahul.bedarkar@imgtec.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
|
|
This patch fixes the follwing compiler warnings:
flash_erase.c: In function 'show_progress':
flash_erase.c:56:22: warning: format '%lx' expects argument of type 'long unsigned int', but argument 3 has type 'off_t {aka long long int}' [-Wformat=]
bareverbose(!quiet, "\rErasing %d Kibyte @ %"PRIxoff_t" -- %2i %% complete ",
^
./include/common.h:81:10: note: in definition of macro 'bareverbose'
printf(fmt, ##__VA_ARGS__);
which are linked to the following buggy numerical output:
Erasing 128 Kibyte @ 0 -- 917504 % complete flash_erase: Cleanmarker written at 0
Erasing 128 Kibyte @ 0 -- 1048576 % complete flash_erase: Cleanmarker written at 0
Signed-off-by: Mathias Kresin <dev@kresin.me>
Signed-off-by: Richard Weinberger <richard@nod.at>
|
|
The kernel refuses to read more data from a MTD device than the device
size. However, mtd_debug does not check the amount of data read as
returned by read(2) and assumes the requested amount is always read when
there is no error. Reading 8M data from a 4M flash chip results in 8M
file containing the flash data at the start.
Signed-off-by: Michal Suchanek <hramrach@gmail.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
|
|
nanddump was always writing a whole page of data into the output
discarding the length actually requested. This patch allows to
write only the remaining length if oob is omitted. In case oob
is needed, it makes sense to copy the entire page.
Signed-off-by: Richard Weinberger <richard@nod.at>
|
|
This patch fixes the return status of the mtd_torture function
in libmtd.
The torture test function is currently only used by the ubiformat
utility to check if a block is bad after a write fails (blocks are
marked bad if the function returns an error status). However, the
way the function was written, it ALWAYS returns an error value
regardless of whether it failed or not.
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
Signed-off-by: Richard Weinberger <richard@nod.at>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
The _BSD_SOURCE define has been deprecated for a while now. Instead,
code should be defining _DEFAULT_SOURCE. By defining both, it'll work
with both new & old versions warning-free.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
These functions have always been defined in sys/sysmacros.h under
Linux C libraries. For some, including sys/types.h implicitly
includes that as well, but glibc wants to deprecate that, and some
others already have. Include the header explicitly for the funcs.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
Our ${SCRIPTS} (e.g., flash_eraseall) are not found in the build
directory; they should be found in their original location.
This fixes a typo in the Makefile refactoring, which caused 'make
install' to fail with messages like:
make: *** No rule to make target '[...my source-build directory...]/armv7a-cros-linux-gnueabi/misc-utils/flash_eraseall'. Stop.
because the install target is looking in the wrong place for
flash_eraseall.
Fixes: 7d81790ced34 ("mtd-utils: Restructure the mtd-utils source.")
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Dongsheng Yang <yangds.fnst@cn.fujitsu.com>
|
|
To be consistent with mkfs.jffs2, and to get this to build on my
machine, it looks like we should use <sys/xattr.h>, not <attr/xattr.h>.
Fixes this error, seen on an Ubuntu 14.04 build system:
ubifs-utils/mkfs.ubifs/mkfs.ubifs.c:30:24: fatal error: attr/xattr.h: No such file or directory
#include <attr/xattr.h>
^
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Marc Kleine-Budde <mkl@pengutronix.de>
Reviewed-by: Richard Weinberger <richard@nod.at>
|
|
If the devtable is used then the tool uses uid twice and doesn't
consider gid at all. This changes it to use gid & uid.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
Assuming the read() call does not return zero and the result is less
than len, the current implementation will overwrite the data already
read in buf which doesn't seem correct.
With this patch, subsequent calls to read() within the loop will now no
longer overwrite the existing contents of buf.
Signed-off-by: Marcus Prebble <marcus.prebble@axis.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
filestat.st_size type is off_t.
For some paltforms, off_t can be 32 or 64bit but there is no C99 format specifier for off_t.
The best way to print it with printf is to cast it to long long and print with %llu
Signed-off-by: Fabien Proriol <fabien.proriol@jdsu.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
Fix compiler warning about an unused variable.
ubifs-utils/mkfs.ubifs/compr.c:41:27: warning: ‘c’ defined but not used [-Wunused-variable]
static struct ubifs_info *c = &info_;
Signed-off-by: Daniel Walter <dwalter@sigma-star.at>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
mkfs.jffs2 is using an old assignment-allocation
modifier for scanf(). Add a check so this modifier
does not get confused with a float formatstring
on newer C standard (C99 onwards).
Signed-off-by: Daniel Walter <dwalter@sigma-star.at>
Signed-off-by: Richard Weinberger <richard@nod.at>
|
|
Make mkfs.ubifs honor the WITHOUT_LZO flag, too.
Fixes this build error:
mkfs.ubifs/compr.c:27:23: lzo/lzo1x.h: No such file or directory
mkfs.ubifs/compr.c: In function `lzo_compress':
mkfs.ubifs/compr.c:92: error: `lzo_uint' undeclared (first use in this function)
mkfs.ubifs/compr.c:92: error: (Each undeclared identifier is reported only once
mkfs.ubifs/compr.c:92: error: for each function it appears in.)
mkfs.ubifs/compr.c:92: error: syntax error before "len"
mkfs.ubifs/compr.c:95: error: `len' undeclared (first use in this function)
mkfs.ubifs/compr.c:96: warning: implicit declaration of function `lzo1x_999_compress'
mkfs.ubifs/compr.c:99: error: `LZO_E_OK' undeclared (first use in this function)
mkfs.ubifs/compr.c: In function `init_compression':
mkfs.ubifs/compr.c:201: error: `LZO1X_999_MEM_COMPRESS' undeclared (first use in this function)
Signed-off-by: Rolf Eike Beer <eb@emlix.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
|
|
This is done to allow creating images suitable for IMA directory
appraisal. IMA creates a hash for directories and attaches this
hash to the directory itself as an extended attribute. Among other
things the inode numbers of the files are hashed. So, to create
a valid hash in the UBIFS image the evmctl tool needs to know
the inode numbers which the files in the UBIFS image will have.
evmctl will read the inode numbers from the user.image-inode-number
extended attribute. Since extended attributes are inodes themselves
the inode numbers for the generated image will change when the
extended attributes change, so to generate a correctly hashed
UBIFS image, both evmctl and mkfs.ubifs must be run twice:
1) execute evmctl to iterate over the directory tree. This will
create the security.ima and security.evm extended attributes.
The existence of the attributes makes sure that subsequent
calls to mkfs.ubifs will use the same inode numbers. evmctl
will use the inode numbers from the host filesystem in this
step which makes the resulting image unusable
2) execute mkfs.ubifs -a. This will create the user.image-inode-number
extended attributes on files/directories added to the image.
3) execture evmctl again. This time evmctl will pick the inode
numbers from the user.image-inode-number extended attribute
instead of the ones from the host filesystem
4) execute mkfs.ubifs again. This will create the correct image.
The now existing user.image-inode-number extended attributes
are ignored and not added to the image.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Richard Weinberger <richard@nod.at>
|
|
This adds extended attribute support to mkfs.ubifs. When creating
an image from a directory tree the existing extended attributes are
added to the UBIFS image.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Richard Weinberger <richard@nod.at>
|
|
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: Daniel Walter <dwalter@sigma-star.at>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Richard Weinberger <richard@nod.at>
|
|
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: Daniel Walter <dwalter@sigma-star.at>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Richard Weinberger <richard@nod.at>
|
|
A 'non_existing' argument which is only used with !non_existing
is just too confusing. Change this to positive logic.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: Daniel Walter <dwalter@sigma-star.at>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Richard Weinberger <richard@nod.at>
|
|
* There is no code modification in this commit, only moving
* the files to proper place.
The user tools looks a little messy as we place almost
the all tools in the root directory of mtd-utils. To make
it more clear, I propose to introduce the following structure
for our source code.
mtd-utils/
|-- lib
|-- include
|-- misc-utils
|-- jffsX-utils
|-- nand-utils
|-- nor-utils
|-- ubi-utils
|-- ubifs-utils
`-- tests
Signed-off-by: Dongsheng Yang <yangds.fnst@cn.fujitsu.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
These utilities have accepted -1 as a block count to mean "all blocks."
Let's document that.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
A lock/unlock/islocked ioctl() should be prevented from anything past
the last byte, inclusive. But we were doing an exclusive check.
This isn't a big deal, as the kernel MTD APIs would be guarding this
anyway, but let's do this for completeness.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
Use the simple_* helpers to improve error checking.
Also fixup brace style at the same time.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
With the -i / --islocked flags.
Sample output:
# flash_lock --islocked /dev/mtd0
Device: /dev/mtd0
Start: 0
Len: 0x400000
Lock status: unlocked
Return code: 0
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
Add new --lock/--unlock flags, so we can do either with the same binary.
This will prepare for the addition of other features, so we don't have
to keep duplicating the same binary via #include "flash_unlock.c".
The defaults still work as expected: flash_unlock will default to
REQUEST_UNLOCK, and flash_lock will default to REQUEST_LOCK.
Eventually, we might deprecate one of the two (flash_unlock, probably),
so we only have to ship one flash_{un,}lock binary.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
Previously, there were no options (besides stand-alone --help and
--version), so we just used fixed-position argv indexes. Let's change
that.
Also clean up the sanity checks a bit to make them more verbose and
specific.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
Just use the common helper macro.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
We will be adding some more flags, so the getopt library can help.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
block count should be nested within the optional offset listing. That
is, we require offset before we accept a block count.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
These two options are handled inconsistently, which caused an
unnecessary amount of head scratching. Let's just use the simple helpers
too, so we get the error handling right.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
struct addrinfo and friends conform to POSIX.1-2001, not earlier.
This patch fixes linking against latest glibc 2.22
Signed-off-by: Kirill Smirnov <kirill.k.smirnov@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
The calculation of the CRC in /tests/checkfs/makefiles.c was writing the CRC
Into the produced files in host byte-order which would cause CRC validation
to fail on big-endian systems as the validation is performed bytewise.
Signed-off-by: Paul McGougan <pmcgougan AT topcon.com>
[Brian: add endian.h]
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
ubinize should not fail silenty, this can be very annoying when using
it from other tools that rely on the exit code for determining the
success of their operation.
Signed-off-by: Enrico Jorns <ejo@pengutronix.de>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
System library headers are not strictly part of our build. If they are
changing beneath our feet, then we probably have bigger problems.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Suggested-by: Mike Frysinger <vapier@gentoo.org>
Acked-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
TL;DR
Acked-by: Mike Frysinger <vapier@gentoo.org>
=====
Auto-generated dependency rules are not being written correctly, so
changes to dependent files (e.g., headers) do not actually trigger
rebuilds.
The problem
===========
It appears that when a dependency generation flag is passed directly to
the preprocessor (with '-Wp,...'), it loses information about the output
path. So, it just makes up the output name as $(basename).o, with no
path information. This yields .*.c.dep files that look like this:
flash_lock.o: flash_lock.c /usr/include/stdc-predef.h flash_unlock.c \
(...)
and
nanddump.o: nanddump.c /usr/include/stdc-predef.h /usr/include/ctype.h \
(...)
include/libmtd.h
This is the case for both in-tree *and* out-of-tree builds. Naturally,
this is a problem for out-of-tree builds. But it is also a problem for
in-tree builds, because we use rules like this for builds:
$(BUILDDIR)/%.o: %.c
and make doesn't recognize $(BUILDDIR)/%.o as the same as %.o even when
$(BUILDDIR) == $(PWD).
Example failures
================
## Rebuilding after touching common header doesn't recompile anything
$ make
(...)
$ touch include/libmtd.h
$ make
CHK include/version.h
## Same for out-of-tree builds
$ BUILDDIR=test make
(...)
$ touch include/libmtd.h
$ BUILDDIR=test make
CHK include/version.h
I noticed this when seeing that flash_lock would not get rebuilt when
modifying flash_unlock.c (where 99% of the source code lies):
$ make
(...)
$ touch flash_unlock.c
$ make
CHK include/version.h
CC flash_unlock.o
LD flash_unlock
The fix
=======
Just pass -MD straight to the compiler, and make sure to specify the
output file for the dependency info with -MF.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
There is a typo in lpt to memset nnode by the
size in sizeof(stuct ubifs_pnode).
Signed-off-by: Dongsheng Yang <yangds.fnst@cn.fujitsu.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
Signed-off-by: Dongsheng Yang <yangds.fnst@cn.fujitsu.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
Signed-off-by: Dongsheng Yang <yangds.fnst@cn.fujitsu.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
Signed-off-by: Dongsheng Yang <yangds.fnst@cn.fujitsu.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|