| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
|
|
|
|
|
|
|
|
|
|
|
| |
With the ROOTFS_TARGET conversion, EXT2_OPTS gets evaluated very early
(before TARGET_DIR is populated with files), so the calculated
blocks/inodes numbers are wrong.
Fix it by moving the calculation to a shell script wrapper around
genext2fs, so it only gets executed just before genext2fs runs.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
|
|
|
|
|
|
|
| |
BR2_TARGET_ROOTFS_EXT2_RESBLKS is an int, so test against 0 rather than
the empty string - Otherwise the test is always true and a -m option
without arguments is added to the argument list, causing genext2fs to
get confused.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
|
|
| |
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now, the location of the device table was specified by a
variable in board Makefiles. Unfortunately, this variable is not
accessible from fs/common.mk, since the target/ code is included
*after* fs/common.mk.
Anyway, the general idea is to move away from these boards Makefile,
and provide configuration option for things like the device table
location.
Therefore, this patch adds a BR2_ROOTFS_DEVICE_TABLE option which
allows to specify which device table should be used.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
|
|
|
|
| |
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
|
|
|
| |
Signed-off-by: Will Wagner <will_wagner@carallon.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
|
|
|
|
| |
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
|
|
|
|
|
|
|
| |
The dependency on gzip, bzip2 and lzma are properly handled
automatically. No need to tell the user about this.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
|
|
|
|
| |
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
|
|
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
|