Defaulting to the $MACHINE may lead to failure if the name was
longer than the limit of allowed volume label of fat (11 chars).
Signed-off-by: Marius Kriegerowski <marius.kriegerowski@gmail.com>
Modify sdcard_image-sunxi bbclass to support both sun50i and older
SoC families. Major changes are as follows:
- update comments: disk layout info
- increase boot partition size: aarch64 unified kernels can be large
- kernel image in boot partition: replace explicit name by KERNEL_IMAGETYPE
- SPL image: replace explicit name by SPL_BINARY
- implement flexible DTB file location in boot partition
-- e.g. by defaut sun50i u-boot looks for dtb in allwinner subdirectory
-- follow kernel dtb naming conventions, e.g. allwinner/<board>.dtb
- copy aarch64 u-boot image to image
-- sunxi arm boards use unified u-boot/spl image
-- sunxi aarch64 boards use two different images
Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com>
The older "IMAGE_DEPENDS_*" notation has been deprecated in favour of the
"do_image_...[depends]" notation.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
As suggested by Andrei Gherzan (see #178):
"The current implementation inherits sdcard_image-sunxi.bbclass
unconditionally which in turn, sets two depends on do_rootfs
unconditionally again.
This means that if I want to build an initramfs image in the
kernel image I will get a dependency loop."
Signed-off-by: Enrico Butera <ebutera@users.sourceforge.net>
The IMAGE_NAME variable already contains the date and time so it is
redundant to also include the date again with IMAGEDATESTAMP
when writing to image-version-info in the boot partition.
Signed-off-by: Jonathan Liu <net147@gmail.com>
IMAGEDATESTAMP may change while bitbake is running which can result in
a taskhash mismatch error for do_image_sunxi_sdimg.
Signed-off-by: Jonathan Liu <net147@gmail.com>
The image class assumes the working directory is the directory
containg the kernel and device tree files but this isn't always the
case.
Signed-off-by: Jonathan Liu <net147@gmail.com>
Remove image dependency on building fex files which are not needed
any more for mainline kernel (replaced by devicetree).
Add dependency for fex to linux-sunxi kernel.
Also update to latest sunxi-linux revision.
Signed-off-by: Jens Lucius <info@jenslucius.com>
ext3 filesystem is getting deprecated in favor of ext4 and openembedded
will default to ext4 in the next release, so switch to ext4 as well.
Signed-off-by: Jens Lucius <info@jenslucius.com>
oe-core has updated dosfstools to the latest version 3.0.28 with mkfs.vfat
returning an error when a file already exists. Remove the old file before
creating a new one.
Issue discovered and fixed by Gary Thomas <gary@mlbassoc.com> for
RaspberryPi and Freescale layers.
Signed-off-by: Jens Lucius <info@jenslucius.com>
Move device tree configuration to machine files. Check for device tree
in sd card creation and include device tree file in first partition.
Signed-off-by: Jens Lucius <info@jenslucius.com>
To resolve the race condition described in #15,
a patch was introduced to use the kernel source from staging dir
rather than deploy dir.
After the reorganization of the kernel source location by
6a1ff0e7ea
this no longer works.
Reverting the previous patch,
and introducing explicit rootfs dependency instead.
Signed-off-by: Kristof Robot <krirobo@gmail.com>
Without this explicit dependency,
a race condition would be present between the generation of the sd image
and the generation of the ext3 file,
which leads to corrupt SD images in some circumstances.
Based on meta-raspberrypi commit a760ea5fa2
Fixing a race condition with virtual/kernel:do_deploy,
which needs to deploy the image before the IMAGE_CMD_sunxi-sdimg () code is being run
as part of image:do_rootfs, otherwise the following error would sometimes occur
when compiling with multiple threads (BB_NUMBER_THREADS=2):
"[..]/deploy/images/cubieboard2/uImage-cubieboard2.bin: No such file or directory"
Fixing this by using the kernel image in sysrootfs instead.
At the same time, also adding an explicit rootfs dependency on sunxi-board-fex:do_deploy because of
"${DEPLOY_DIR_IMAGE}/fex.bin", although this never seems to pose problems in practice.
