@@ -41,10 +41,6 @@ python __anonymous () {
if image:
d.appendVarFlag('do_assemble_fitimage_initramfs', 'depends', ' ${INITRAMFS_IMAGE}:do_image_complete')
- ubootenv = d.getVar('UBOOT_ENV')
- if ubootenv:
- d.appendVarFlag('do_assemble_fitimage', 'depends', ' virtual/bootloader:do_populate_sysroot')
-
#check if there are any dtb providers
providerdtb = d.getVar("PREFERRED_PROVIDER_virtual/dtb")
if providerdtb:
@@ -607,15 +603,6 @@ fitimage_assemble() {
# Step 3: Prepare a u-boot script section
#
- if [ -n "${UBOOT_ENV}" ] && [ -d "${STAGING_DIR_HOST}/boot" ]; then
- if [ -e "${STAGING_DIR_HOST}/boot/${UBOOT_ENV_BINARY}" ]; then
- cp ${STAGING_DIR_HOST}/boot/${UBOOT_ENV_BINARY} ${B}
- bootscr_id="${UBOOT_ENV_BINARY}"
- fitimage_emit_section_boot_script $1 "$bootscr_id" ${UBOOT_ENV_BINARY}
- else
- bbwarn "${STAGING_DIR_HOST}/boot/${UBOOT_ENV_BINARY} not found."
- fi
- fi
if [ -n "${FIT_UBOOT_ENV}" ]; then
cp ${UNPACKDIR}/${FIT_UBOOT_ENV} ${B}
bootscr_id="${FIT_UBOOT_ENV}"
The kernel-fitimage.bbclass evaluates the UBOOT_ENV variable from the u-boot recipe. Based on this variable an u-boot script might be added to the fitImage. However, the UBOOT_ENV variable is also used to install the script as an old u-boot image, usually named boot.scr into the /boot directory of the target device. This dual usage of one variable leads to several strange side effects. Some examples: - If UBOOT_ENV_SUFFIX is set to the default value scr, the boot.cmd script gets added as a legacy uImage to the fitImage. That does not look useful. - If the UBOOT_ENV_SUFFIX is set to e.g. txt the script is not converted into a legacy uImage and a usable plain text script gets added to the fitImage. But the same script ends up redundant in /boot. Another strange detail is that the UBOOT_ENV_BINARY gets set to e.g. boot.txt for this configuration. - Appending the script to the u-boot recipe and then hand it over to the kernel recipe via the staged /boot directory looks like over complicated. Such kind of over complications and u-boot kernel inter-dependencies lead to an almost unmaintainable kernel-fitimage.bbclass. - A single variable does not allow you to add a text file to the fitImage and at the same time place boot.scr file in the /boot directory of the target device. - It is not documented or obvious how the UBOOT_ENV variable should be used together with the kernel-fitimage.bbclass. The commit which introduced this feature (among other features...) is: https://git.yoctoproject.org/poky/commit/?id=8a2f4e143b52109fbd0ee8d792e327d460b8c1e6 This commit is going to remove the u-boot script part of it. The removal of this function requires a note in the migration guide. The migration should be straightforward: If UBOOT_ENV and the kernel-fitimage.bbclass are used, the u-boot script must now be appended to the kernel recipe and the new FIT_UBOOT_ENV variable must be used. Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com> --- meta/classes-recipe/kernel-fitimage.bbclass | 13 ------------- 1 file changed, 13 deletions(-)