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.
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 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.
I am using an arm board using TFTP and NFS but it got stuck at kernel loading as shown in the screenshot and I have to input the run uenvcmd then the process will keep going and everything is OK.
Below is my uEnv.txt:
# This uEnv.txt file can contain additional environment settings that you
# want to set in U-Boot at boot time. This can be simple variables such
# as the serverip or custom variables. The format of this file is:
# variable=value
# NOTE: This file will be evaluated after the bootcmd is run and the
# bootcmd must be set to load this file if it exists (this is the
# default on all newer U-Boot images. This also means that some
# variables such as bootdelay cannot be changed by this file since
# it is not evaluated until the bootcmd is run.
autoload=no
ipaddr=192.168.1.100
serverip=192.168.1.13
gatewayip=192.168.1.1
staticip=${ipaddr}:${serverip}:${gatewayip}:255.255.255.0:::off
bootpath=/tftpboot
rootfspath=/opt/ti-processor-sdk-linux-rt-am57xx-evm-03.00.00.04/targetNFS
#setting for kernel loading
kernel_addr=0x82000000
fdt_addr=0x88000000
nfs_args=setenv bootargs console=ttyO0,115200n8 root=/dev/nfs rw nfsroot=${serverip}:${rootfspath} ip=${staticip}
load_zimage=tftp ${kernel_addr} ${bootpath}/zImage
loadfdt=tftp ${fdt_addr} ${bootpath}/am572x-idk.dtb
boot_zimage=bootz ${kernel_addr} - ${fdt_addr}
uenvcmd=run load_zimage; run loadfdt; run nfs_args; run boot_zimage
these is a strange file called uboot.env beside the uEnv.txt, too long to paste here, uboot.env
Problem solved: Just delete the file uboot.env
This should be a bug of SDK. I will report this to TI. Thanks #Notlikethat