I would like to load a few kernel modules, and activate framebuffer access prior to Plymouth launch. This is normally done using /etc/initramfs-tools directory provided with the initramfs-tools. However, when building an initramfs image with Yocto, no such directory is available. This means that whatever initramfs-tools does for loading modules and initializing framebuffer, has to be done manually in the initramfs image as far as I could understand.
The tasks I want to accomplish is very delicately explained by notro in https://github.com/notro/fbtft/wiki/Bootsplash
. I'd like to do the equivalent of what's done below:
Access to /etc/initramfs-tools/scripts/init-top/spi and modprobe a module.
Access to /etc/initramfs-tools/modules and list further modules to be launched by modules daemon
Enable framebuffer which is done via echo "export FRAMEBUFFER=/dev/fb1" | sudo tee /etc/initramfs-tools/conf.d/fb1
With my research, I could find initramfs-framework-base package which features some scripts that initramfs boot uses. I think this might be a good starting point. However, I do not know how to explicitly tell initramfs to do what I want to accomplish (tasks above).
Note: Currently, my initramfs image is generated by the following recipe:
include recipes-core/images/rpi-basic-image.bb
BASEPACKS = " \
base-passwd \
busybox \
initramfs-live-boot \
initramfs-framework-base \
udev \
${ROOTFS_BOOTSTRAP_INSTALL} \
"
IMAGE_INSTALL = " ${BASEPACKS} \
plymouth plymouth-set-default-theme \
"
# Do not pollute the initrd image with rootfs features
IMAGE_FEATURES = "splash"
SPLASH = "plymouth"
IMAGE_LINGUAS = ""
LICENSE = "MIT"
IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"
IMAGE_ROOTFS_SIZE = "8192"
IMAGE_OVERHEAD_FACTOR = "1.0"
IMAGE_ROOTFS_EXTRA_SPACE = "0"
IMAGE_ROOTFS_MAXSIZE = "12288"
CMDLINE_append = " quiet splash nomodeset plymouth.ignore-serial-consoles consoleblank=0"
BAD_RECOMMENDATIONS += "busybox-syslog"
Also Note: I'm using an ARMv6-based machine with U-boot bootloader. Compiling the original initramfs-tools (that is originally developed for Debian) generates 0 byte images. I'm guessing this is an issue with its compatibility. So I'll have to resort to generating initramfs with yocto's internal tools.
Any help is appreciated. Thanks in advance.
Related
I am using Yocto to create a Linux build for an IMX6. This is going great and I am not looking into using SWUpdate to perform kernel and device tree updates. So far I have a bitbake script which does the following.
source setup-environment build-fb/
bitbake -c cleanall swupdate
bitbake swupdate
bitbake -c cleanall swupdate-image
bitbake swupdate-image
bitbake -c cleanall mainapplication-dev
bitbake mainapplication-dev
bitbake -c cleanall smg-image-swu
bitbake smg-image-swu
This properly configures my build and creates a .swu file containing three items
mainapplication-dev-imx6ull14x14evk.tar.bz2
sw-description
update.sh
I followed a guide by Variscite and referenced their GitHub. In their guide they mention that
This leads me to believe that after they run a build, the .swu file contains the files I listed above with the addition that in /boot lies a zimage and a .dtb file. I have replicated their bb files. In my mainapplication-dev-imx6ull14x14evk.tar.bz2 in the /boot directory, I only have a zimage. I cannot get this to package the device tree.
Has anyone done this before? Can anyone guide me here? For reference I am adding my bitbake files below.
smg-image-swu.bb:
DESCRIPTION = "Example compound image for Variscite boards"
SECTION = ""
# Note: sw-description is mandatory
SRC_URI = " \
file://sw-description \
file://update.sh \
"
inherit swupdate
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
# IMAGE_DEPENDS: list of Yocto images that contains a root filesystem
# it will be ensured they are built before creating swupdate image
IMAGE_DEPENDS = "mainapplication-dev"
# SWUPDATE_IMAGES: list of images that will be part of the compound image
# the list can have any binaries - images must be in the DEPLOY directory
SWUPDATE_IMAGES = "mainapplication-dev"
SWUPDATE_IMAGES_FSTYPES[mainapplication-dev] = ".tar.bz2"
smg-image-swupdate.bb
DESCRIPTION = ""
LICENSE = "MIT"
require recipes-core/images/core-image-minimal.bb
CORE_IMAGE_EXTRA_INSTALL += " \
swupdate \
swupdate-www \
kernel-image \
kernel-devicetree \
"
IMAGE_FSTYPES = "tar.gz"
To add the device tree and modules to my .swu image I made the following change to smg-image-swu.bb
DESCRIPTION = "Example compound image for Variscite boards"
SECTION = ""
# Note: sw-description is mandatory
SRC_URI = " \
file://sw-description \
file://update.sh \
"
inherit swupdate
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
# IMAGE_DEPENDS: list of Yocto images that contains a root filesystem
# it will be ensured they are built before creating swupdate image
IMAGE_DEPENDS = "mainapplication-dev virtual/kernel"
# SWUPDATE_IMAGES: list of images that will be part of the compound image
# the list can have any binaries - images must be in the DEPLOY directory
SWUPDATE_IMAGES = "mainapplication-dev \
modules-imx6ull14x14evk \
imx6ull-14x14-evk"
SWUPDATE_IMAGES_FSTYPES[mainapplication-dev] = ".tar.bz2"
SWUPDATE_IMAGES_FSTYPES[modules-imx6ull14x14evk] = ".tgz"
SWUPDATE_IMAGES_FSTYPES[imx6ull-14x14-evk] = ".dtb"
I'm trying to create a custom recipe to sign a u-boot image generated from u-boot.bb.
I have 2 custom recipes:
1. u-boot.bb - clones, compiles and deploys u-boot resulting u-boot.elf.
2. u-boot-sign.bb - depends on u-boot.bb. Gets u-boot.elf, passes it through
custom signing procedure and deploys the result.
For signing I am forced to use a custom procedure which is in a form of python scripts located in external repository.
The part which causes a problem is accessing a deployed u-boot.elf binary file from u-boot.bb recipe. I cannot find a way to expose u-boot.elf binary file to a u-boot-sign.bb recipe.
What should be the correct way of exposing an image binary file from one recipe, to be accessed, signed and deployed in another recipe?
For the purpose of sharing the files between recipes and between cross-compilation scope, I used ${datadir} when installing the binaries (via do_install). This allowed me to access all files described by FILES:${PN} via recipe-sysroot.
u-boot.bb - exporting recipe:
…
do_install() {
install -d ${D}${datadir}/u-boot-2016/
install -m 0644 ${B}/${UBOOT_ELF_BINARY} ${D}${datadir}/u-boot-2016
}
FILES:${PN} = "${datadir}/u-boot-2016"
…
u-boot-sign.bb - depending recipe
…
DEPENDS += " u-boot python3-native"
do_sign() {
${STAGING_BINDIR_NATIVE}/python3-native/python3 sign.py \
-i ${RECIPE_SYSROOT}${datadir}/u-boot-2016/${UBOOT_ELF_BINARY}
}
…
Inspiration from Here
Edit
I was advised not to transfer files like this using ${datadir}. For intermediate files the better approach would be to use to use /firmware as it is done in meta-arm.
u-boot.bb - exporting recipe:
…
do_install() {
install -D -p -m 0644 ${B}/${UBOOT_ELF_BINARY} ${D}/firmware/${UBOOT_ELF_BINARY}
}
FILES:${PN} = "/firmware"
SYSROOT_DIRS += "/firmware"
…
u-boot-sign.bb - depending recipe
…
DEPENDS += " u-boot python3-native"
do_sign() {
${STAGING_BINDIR_NATIVE}/python3-native/python3 sign.py \
-i ${RECIPE_SYSROOT}/firmware/u-boot-2016/${UBOOT_ELF_BINARY}
}
…
It also requires to add /firmware to SYSROOT_DIRS.
I'm attempting to create an image with
bitbake core-image-minimal
For my jetson nano (nvidia tegra). I've added the meta-layer for tegra devices from https://github.com/madisongh/meta-tegra
and added it to bblayer.conf. I have also added lines
IMAGE_CLASSES += "image_types_tegra"
IMAGE_FSTYPES = "tegraflash"
to the local.conf file to be able to flash it later.
When I attempt to run the bitbake command to create the image, I get the error message:
ERROR: No recipes available for:
/home/mci/yocto/jetson-nano/meta-tegra/recipes-graphics/vulkan/vulkan-loader_1.1.%.bbappend
/home/mci/yocto/jetson-nano/meta-tegra/recipes-graphics/vulkan/vulkan-tools_1.1.%.bbappend
/home/mci/yocto/jetson-nano/meta-tegra/recipes-graphics/wayland/weston_7.0.0.bbappend
But aren't the files it says there is no recipes for the same recipes it's looking for? Isn't "vulkan-loader_1.1.%.bbappend" a recipe?
How do I solve this problem? Is it because it can't find the files or is the bbappend not the recipes but something else?
Michael,
I don't have an answer for the vulkan pieces but I do have a few pointers since we seem to be going down a similar path with the nano.
Use the warrior branch of yocto
You'll need to download the binary pieces of the nvidia sdk through the SDK manager
Point to these sdk packages in your local.conf with the NVIDIA_DEVNET_MIRROR variable. ex: "file:///home/nvidia/yocto/git/poky/devnet/nano-dev"
Because of the binary pieces in step 2, you need to use an older gcc version which isn't really supported in warrior. I used the linaro-7.2 layer.
Since gcc7 is not supported in warrior, yocto / openembedded will attempt to pass flags to gcc which will make the build fail. Here's a summary, which I hope is complete, to help you through this.
Add DEBUG_PREFIX_MAP="" to local.conf and apply the following patch.
diff --git a/meta/recipes-core/busybox/busybox.inc b/meta/recipes-core/busybox/busybox.inc
index 174ce5a8c0..e8d651a010 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
## -128,7 +128,7 ## do_prepare_config () {
${S}/.config.oe-tmp > ${S}/.config
fi
sed -i 's/CONFIG_IFUPDOWN_UDHCPC_CMD_OPTIONS="-R -n"/CONFIG_IFUPDOWN_UDHCPC_CMD_OPTIONS="-R -b"/' ${S}/.config
- sed -i 's|${DEBUG_PREFIX_MAP}||g' ${S}/.config
+ #sed -i 's|${DEBUG_PREFIX_MAP}||g' ${S}/.config
}
# returns all the elements from the src uri that are .cfg files
diff --git a/meta/recipes-core/libxcrypt/libxcrypt.bb b/meta/recipes-core/libxcrypt/libxcrypt.bb
index 3b9af6d739..350f7807a7 100644
--- a/meta/recipes-core/libxcrypt/libxcrypt.bb
+++ b/meta/recipes-core/libxcrypt/libxcrypt.bb
## -24,7 +24,7 ## FILES_${PN} = "${libdir}/libcrypt*.so.* ${libdir}/libcrypt-*.so ${libdir}/libowc
S = "${WORKDIR}/git"
BUILD_CPPFLAGS = "-I${STAGING_INCDIR_NATIVE} -std=gnu99"
-TARGET_CPPFLAGS = "-I${STAGING_DIR_TARGET}${includedir} -Wno-error=missing-attributes"
-CPPFLAGS_append_class-nativesdk = " -Wno-error=missing-attributes"
+TARGET_CPPFLAGS = "-I${STAGING_DIR_TARGET}${includedir} "
+CPPFLAGS_append_class-nativesdk = " "
BBCLASSEXTEND = "nativesdk"
Best of luck! I apologize if this is a bit rough, but I'm just getting through this myself.
I deleted everything and started with a fresh build, did the EXACT same procedure and added all the same lines to the local.conf and bblayer.conf... But this time, bitbake command is running with no errors at all.
I've been running a Yocto build in bitbake for a few days, but I've noticed it sometimes stops producing the zImage file of my kernel. Most of the changes I'm making are to the kernel config, and the machine.conf file. when this happens, I still get updated tar.gz files with each build, but the zImage stops being updated. Running the do_clean, do_cleanall and do_cleansstate tasks do not help, and neither does deleting the old zImage file from build/tmp/deploy. The only thing that helps is deleting the entire pocky/build/tmp directory and rebuilding the entire project from scratch. Here is my current machine.conf file:
##TYPE: Machine
##Name: EMAC, Inc. SoM-9G45M Module
##DESCRIPTION: Machine.inc configuration for the SoM-9G45M board with a at91sam9g45 processor
TARGET_ARCH = "arm"
PREFERRED_PROVIDER_virtual/kernel = "linux-2.6.30-at91-emac"
PREFERRED_PROVIDER_xserver = "xserver-kdrive"
KERNEL_IMAGETYPE = "zImage"
KERNEL_EXTRA_ARGS = "LOADADDR=0x74000000"
#don't try to access tty1
USE_VT = "0"
MACHINE_FEATURES = "kernel26 apm alsa ext2 usbhost usbgadget"
KERNEL_DEVICETREE = "at91som9g45.dtb"
# used by sysvinit_2
#SERIAL_CONSOLE = "115200 ttyS1"
SERIAL_CONSOLE = "115200 ttyS0"
#SERIAL_CONSOLES = "115200;ttyS0 115200;ttyS1"
#SYSLINUX_DEFAULT_CONSOLE = "console=ttyS0"
#SYSLINUX_SERIAL = "0 115200"
#SYSLINUX_SERIAL_TTY = "console=ttyS0,115200"
#EXTRA_IMAGECMD_jffs2 = "--pad=0xA00000 --little-endian --eraseblock=0x20000"
# NAND
MKUBIFS_ARGS = " -e 129024 -c 2047 -m 2048 -x lzo"
UBINIZE_ARGS = " -m 2048 -p 128KiB -s 512"
UBI_VOLNAME = "rootfs"
UBOOT_MACHINE = "${MACHINE}_nandflash_config"
UBOOT_ENTRYPOINT = "0x74000000"
UBOOT_LOADADDRESS = "0x74000000"
require include/at91sam9.inc
What can cause a bitbake build to stop producing the specified kernel image, and how do I fix it?
The answer ended up having two parts.
First, running bitbake -c do_cleansstate linux-at91 and then bitbake core-image-sato successfully regenerated the zImage file.
Second, linux-2.6.30-at91-emac was incorrect since my kerenl was just called linux-at91. So my kernel build was likely only being run when I ran builds for other machines.
So my full image build wasn't rebuilding the kernel because I had referenced a different kernel. Once I fixed that, the kernel build would start running again. I'm not sure how I got a zImage in the first place, or why bitbake never threw an error after being told to build a kernel that didn't exist.
I have been researching online for a proper way to create a bootable SD card (through USB adapter) for my raspberry pi from files created by "bitbake qt5-image" command. The build process finished successfully with no warnings or errors. Resulting files that I assume are relevant to my goal are:
in ~/rpi/build/tmp/deploy/images/raspberrypi:
` "modules-raspberrypi.tgz" link to
modules-1-4.14.73+git0+e117f3e9fd-r0-raspberrypi-20181009142103.tgz 17.mb
"qt5-image-raspberrypi.tar.xz" link to
qt5-image-raspberrypi-20181009142103.rootfs.tar.xz 92.8 mb
"zImage" link to
zImage-1-4.14.73+git0+e117f3e9fd-r0-raspberrypi-20181009142103.bin 4.7mb
I also took some advice from this tutorial (https://jumpnowtek.com/rpi/Raspberry-Pi-Systems-with-Yocto.html) for steps before the build.
Any advice on the matter would be greatly appreciated!
Edit (I changed KERNEL_IMAGETYPE to = "Image" in build/conf/local.conf from zimage) which produced this
Content (excluding btbo files) of tmp/deploy/images/raspberrypi/
bcm2708-rpi-0-w.dtb
bcm2708-rpi-b.dtb
bcm2708-rpi-b-plus.dtb
bcm2708-rpi-cm.dtb
bcm2709-rpi-2-b.dtb
bcm2710-rpi-3-b.dtb
bcm2710-rpi-3-b-plus.dtb
bcm2710-rpi-cm3.dtb
bcm2835-bootfiles
**Image Link to Image-1-4.14.73+git0+e117f3e9fd-r0-raspberrypi-20181010131555.bin**
Image-1-4.14.73+git0+e117f3e9fd-r0-bcm2708-rpi-0-w-20181010131555.dtb
Image-1-4.14.73+git0+e117f3e9fd-r0-bcm2708-rpi-b-20181010131555.dtb
Image-1-4.14.73+git0+e117f3e9fd-r0-bcm2708-rpi-b-plus-20181010131555.dtb
Image-1-4.14.73+git0+e117f3e9fd-r0-bcm2708-rpi-cm-20181010131555.dtb
Image-1-4.14.73+git0+e117f3e9fd-r0-bcm2709-rpi-2-b-20181010131555.dtb
Image-1-4.14.73+git0+e117f3e9fd-r0-bcm2710-rpi-3-b-20181010131555.dtb
Image-1-4.14.73+git0+e117f3e9fd-r0-bcm2710-rpi-3-b-plus-20181010131555.dtb
Image-1-4.14.73+git0+e117f3e9fd-r0-bcm2710-rpi-cm3-20181010131555.dtb
Image-bcm2708-rpi-0-w.dtb
Image-bcm2708-rpi-b.dtb
Image-bcm2708-rpi-b-plus.dtb
Image-bcm2708-rpi-cm.dtb
Image-bcm2709-rpi-2-b.dtb
Image-bcm2710-rpi-3-b.dtb
Image-bcm2710-rpi-3-b-plus.dtb
Image-bcm2710-rpi-cm3.dtb
modules-1-4.14.73+git0+e117f3e9fd-r0-raspberrypi-20181010131555.tgz
modules-raspberrypi.tgz
qt5-image-raspberrypi-20181009142103.testdata.json
qt5-image-raspberrypi-20181010131555.rootfs.manifest
qt5-image-raspberrypi-20181010131555.rootfs.tar.xz
qt5-image-raspberrypi-20181010131555.testdata.json
qt5-image-raspberrypi.manifest
qt5-image-raspberrypi.tar.xz
qt5-image-raspberrypi.testdata.json
Content of build/conf/bblayers.conf
# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf /bblayers.conf
# changes incompatibly
POKY_BBLAYERS_CONF_VERSION = "2"
BBPATH = "${TOPDIR}"
BBFILES ?= ""
BBLAYERS ?= " \
${HOME}/poky/meta \
${HOME}/poky/meta-poky \
${HOME}/poky/meta-openembedded/meta-oe \
${HOME}/poky/meta-openembedded/meta-multimedia \
${HOME}/poky/meta-openembedded/meta-networking \
${HOME}/poky/meta-openembedded/meta-perl \
${HOME}/poky/meta-openembedded/meta-python \
${HOME}/poky/meta-qt5 \
${HOME}/poky/meta-raspberrypi \
${HOME}/poky/meta-security \
${HOME}/rpi/meta-rpi \
"
If you are using latest meta-raspberrypi layer as machine layer, then you will be getting WIC image as output in tmp/deploy/images/raspberrypi.
This image can be directly flashed into SD card as it already partitioned as,
# short-description: Create Raspberry Pi SD card image
# long-description: Creates a partitioned SD card image for use with
# Raspberry Pi. Boot files are located in the first vfat partition.
part /boot --source bootimg-partition --ondisk mmcblk0 --fstype=vfat --label boot --active --align 4096 --size 20
part / --source rootfs --ondisk mmcblk0 --fstype=ext4 --label root --align 4096
So you don't need to manually partition the SD card and copy the respective files.