The value of the RPI_KERNEL_VERSION can change between None and the
kernel version which can result in taskhash mismatch errors while
building images.
The taskhash mismatch errors can be reproduced using:
bitbake -c cleansstate virtual/kernel core-image-minimal && bitbake core-image-minimal
The get_dts() and split_overlays() functions are modified so that the
kernel version argument is optional. If the version is not supplied to
these functions, they will fallback to the Python equivalent of the
expression used for RPI_KERNEL_VERSION.
Signed-off-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
oe-core's commit d54339d4b1a7e884de636f6325ca60409ebd95ff creates image in
IMGDEPLOYDIR and copies through sstate to DEPLOY_DIR_IMAGE. That causes
DEPLOY_DIR_IMAGE not valid when calling IMAGE_CMD. Therefore use
IMGDEPLOYDIR for sdcard creation too.
Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com>
Kernel 4.4.6+ on RaspberryPi support .dtbo files for overlays, instead of .dtb.
Add support for both extensions for overlays (".dtb" and ".dtbo")
CAUTION: in IMAGE_CMD_rpi-sdimg, 'TMPDIR' is not set, causing 'STAGING_KERNEL_BUILDDIR' to not be expanded, causing get_dts() to not being able to get the kernel version!
To avoid this problem, the kernel version is added in a new variable outside the scope of IMAGE_CMD_rpi-sdimg, and its value passed to get_dts() and split_overlays()!
Signed-off-by: Herve Jourdain <herve.jourdain@neuf.fr>
Kernel 4.4.6+ on RaspberryPi support .dtbo files for overlays, instead of .dtb.
Add support for both variants of overlays ("-overlay.dtb" and ".dtbo")
Change which variant needs to be supported based on the kernel version
CAUTION: when called from IMAGE_CMD_rpi-sdimg, 'TMPDIR' is not set, causing 'STAGING_KERNEL_BUILDDIR' to not be expanded, causing get_kernelversion_file() to fail!
To avoid this problem, get_dts() and split_overlays() MUST be called with the kernel version parameter set, when called from IMAGE_CMD_rpi-sdimg!
Signed-off-by: Herve Jourdain <herve.jourdain@neuf.fr>
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>
The repository used by u-boot-rpi has not been updated since 2012. In the
meantime, mailine u-boot has gained Raspberry Pi support. All we need to do is
set UBOOT_MACHINE to an appropriate value in the machine config files.
Currently configs are only provided for raspberrypi and raspberrypi2. The master
branch of u-boot now also appears to have a config file for raspberrypi3 so
support for this can be added in the future when u-boot is upgraded in oe-core.
The mainline u-boot recipe creates the file "u-boot.bin" instead of
"u-boot.img".
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
IMAGE_CMD_rpi-sdimg() uses the IMAGEDATESTAMP variable, so the taskhash
of the function keeps changing. This results in a taskhash mismatch
error.
Fix this by excluding the IMAGEDATESTAMP variable from the checksum.
Change-Id: Ie6f30ad29e279d5312ec655ac4a3bf246c8a04de
Signed-off-by: Jonathan Liu <net147@gmail.com>
SD image is expecting dtb files to be deployed in deploy area, this step
however is done when do_deploy of kernel is finished and we need to pin that in
dependency list, otherwise there are build race conditions during builds
especially visible when building with initramfs enabled.
Signed-off-by: Khem Raj <raj.khem@gmail.com>
The boot partition currently has a size of 20 MiB but just the start elf
binaries account almost 12 MiB, which means that only 8 MiB is left for
the kernel image. A recent kernel with many of its options built-in can
easily be more than 4 MiB so let's double the boot partition size to 40
MiB to make sure that it has enough room for the kernel image, the DTBs
and possible even a backup kernel.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
[javier: Extended the commit message]
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Recent updates to the MSDOS tools (OE-core is now at 3.0.28) have made
it an error to overwrite an image using mkfs.vfat. This patch fixes
that problem by removing any old/stale images, thus starting from scratch.
Signed-off-by: Gary Thomas <gary@mlbassoc.com>
After '6392a63 rpi-base.inc: Use KERNEL_DEVICETREE by default' was
introduced, kernel versions < 3.18 might not be buildable. Since full
device tree support was introduced in 3.18 this change ensures that all
kernel < 3.18 will automatically disable device tree.
Signed-off-by: Petter Mabäcker <petter@technux.se>
Add machine configuration file.
Change the kernel image name on SD card.
Use the defconfig for this machine (bcm2709_defconfig).
Change-Id: I6549d5f49b1ed32ef4d44aca6f7af4234618c1a8
Signed-off-by: Andrei Gherzan <andrei@gherzan.ro>
Compile overlay device trees and put them in 'overlays/' folder
on sdcard RPi boot partition.
Change-Id: I3da0032b3c2618165008eec1fc94e97824d09099
Signed-off-by: Francois Muller <francois@concept-embarque.fr>
[RPi DT info] https://github.com/raspberrypi/documentation/blob/master/configuration/device-tree.md#part-3-using-device-trees-on-raspberry-pi
RPi bootloader detects a DT-ready kernel by checking for a specific trailer in kernel.img.
Using latest raspberrypi/firmware (firmware.inc) enables this check ability.
Using latest raspberrypi/tools (rpi-mkimage.bb) gives access to mkknlimg for adding the
required trailer to kernel image.
If KERNEL_DEVICETREE is filled in, the trailer is added to the kernel image before
kernel install task. While creating the SDCard image, this modified kernel is
put on boot partition (as kernel.img) as well as DeviceTree blobs (.dtb files).
If KERNEL_DEVICETREE is empty, this new process isn't operated, legacy one does.
KERNEL_DEVICETREE for RPi is really supported only starting from linux-rapsberry 3.18+
kernels, so as for now it defaults to empty (in machine config file).
Change-Id: Ifea71bbda729b8f3c47be7ba0ba03be5ad2ceeaa
Signed-off-by: Francois Muller <francois@concept-embarque.fr>
The rootfs may be using a filesystem type other than ext3 so it should
not be hardcoded.
Change-Id: I71c1a96831ce4617b24de7743fe3b70ec5822a33
Signed-off-by: Jonathan Liu <net147@gmail.com>
Permit to build an image with initramfs.
Add information in README to build with initramfs.
Change-Id: Icb812151a22771717805ec0a82feb7993f462b47
Signed-off-by: Sébastien Mennetrier <s.mennetrier@innotis.org>
If KERNEL_IMAGETYPE is uImage, use u-boot image as kernel.img and copy uImage
too. Otherwise, use kernel image as kernel.img (as we did until now
unconditionally).
Change-Id: Iac46a57e4266299f2fe5746cb6957dcfc0e90443
Signed-off-by: Andrei Gherzan <andrei@gherzan.ro>
Image files will typically contain lots of null blocks and should compress well.
This will help with distribution of images over slow network links.
Change-Id: Icec7454ff61cd81a2872037037a93ce01191ece5
Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
When the shell tests for rootfs type I was seeing "[[: not found". I
use echo and egrep to test for the xz rootfs type to work around this
error.
Signed-off-by: Seth Bollinger <seth.boll@gmail.com>
Signed-off-by: Andrei Gherzan <andrei@gherzan.ro>
When constructing the SD card image, the code was using
the inherited ROOTFS_SIZE, which is the size of the
rootfs contents. When building (for example) a compressed
rootfs, this allocates a partition much larger than necessary.
Instead, take the size of the generated rootfs file that is
about to be written into the generated image, and round it
up to the IMAGE_ROOTFS_ALIGNMENT size.
Fix some comments - the alignment is 4MiB, not 4KiB.
Signed-off-by: Jan Schmidt <thaytan@noraisin.net>
Signed-off-by: Andrei Gherzan <andrei@gherzan.ro>
start_cd.elf and fixup_cd.dat are required when running the system with
a 16MB GPU memory configuration. This change copies all files contained
in bcm2835-bootfiles instead of cherry picking.
Signed-off-by: Seth Bollinger <seth.boll@gmail.com>
Signed-off-by: Andrei Gherzan <andrei@gherzan.ro>
SD image file was 4G in size but actually the rootfs partition was only
60MB (ex.: rpi-basic-image).
The image file size is not fixed anymore but calculated inside this
class. In this way we will setup the partition for rootfs to fit the
ext file used as SDIMG_ROOTFS. By default the free space is calculated
with IMAGE_OVERHEAD_FACTOR which is by default 1.3. If more free space
is needed this can be overwritten.
IMAGE_ROOTFS_ALIGNMENT set at 4096. This should be the best value for a
SD card.
[GITHUB #20]
[GITHUB #59]
Signed-off-by: Andrei Gherzan <andrei@gherzan.ro>
When burning the rootfs partition we use dd if rootfs file is not
compressed and xzcat piped with dd if rootfs file is a .xz file.
[GITHUB #39]
Signed-off-by: Andrei Gherzan <andrei@gherzan.ro>
${KERNEL_IMAGETYPE} symlink was introduced after denzil so we use
${KERNEL_IMAGETYPE}-${MACHINE} to be able to satisfy the existence in denzil and master
as well.
Signed-off-by: Andrei Gherzan <andrei@gherzan.ro>
Instead of being inherited by a specific image recipe, this class can
now be inherited globally in the machine configuration, allowing it to
be used with any image. This means we can remove "inherit image", and
we can also remove the IMAGE_FSTYPES modification since the machine
config does this already.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Andrei Gherzan <andrei@gherzan.ro>
This implementation doesn't use loop mounts, it uses mcopy to copy files to partitions.
The partition creation is done with parted. Because of using these tools the
IMAGE_DEPENDS was modified accordingly.
Added a way of selecting the desired GPU firmware.
Because we don't create the rootfs image but we rely on an already created rootfs
image, the stamp is available only in the boot partition.
By default the class needs an ext3 rootfs image. This is because we don't have yet
a way of generating cmdline.txt in order to pass the partition type to the kernel.
By default ext3 is mounted so we use this fs type until this will be selectable while
generating a cmdline file.
Signed-off-by: Andrei Gherzan <andrei@gherzan.ro>
