[OE-core] [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that.
Alex Kiernan
alex.kiernan at gmail.com
Tue Sep 18 06:10:28 UTC 2018
Thanks Leon
I guess the reason that the deployment happens in kernel.bbclass is so
you only have all the symlinking logic in one place.
Are in agreement that this change should be reverted and the
"fitImage" deployed here:
http://git.openembedded.org/openembedded-core/tree/meta/classes/kernel-fitimage.bbclass#n495
is the one which we should remove?
On Mon, Sep 17, 2018 at 7:05 PM Leon Woestenberg <leon at sidebranch.com> wrote:
>
> Hi Alex,
>
> I expected it to be kernel-fitimage.bbclass’s responsibility to deploy the fitImage.
>
> Regards, Leon
>
>
>
>
> On 16 Sep 2018, at 16:22, Alex Kiernan <alex.kiernan at gmail.com> wrote:
>
> On Sun, Sep 16, 2018 at 11:41 AM Alex Kiernan <alex.kiernan at gmail.com> wrote:
>
>
> Hi Leon
>
>
> On Sun, Sep 16, 2018 at 10:18 AM Leon Woestenberg <leon at sidebranch.com> wrote:
>
>
> Hi Alex,
>
>
> On 15 Sep 2018, at 19:45, Alex Kiernan <alex.kiernan at gmail.com> wrote:
>
>
> On Mon, Sep 10, 2018 at 10:57 PM Leon Woestenberg <leon at sidebranch.com> wrote:
>
>
> kernel-fitimage.bbclass replaces an occurance of "fitImage" in
>
> KERNEL_IMAGETYPE_FOR_MAKE by an image type that is buildable for the
>
> architecture (such as zImage). The kernel-fitimage.bbclass packs that
>
> image as sub-image in a flattened image tree image (fitImage) and
>
> deploys this fitImage along with the image tree source file (.its).
>
>
> kernel-fitimage.bbclass does not alter KERNEL_IMAGETYPES, which thus
>
> also contains "fitImage", which kernel.bbclass will also deploy
>
> redundantly with different naming.
>
>
> The result is a dual deployment with slightly different naming,
>
> each with a set of symlinks.
>
>
> The solution chosen is to have fitImage deployment be handled by
>
> kernel-fitimage.bbclass, and have kernel.bbclass ignore fitImage
>
> types during deployment.
>
>
> Signed-off-by: Leon Woestenberg <leon at sidebranch.com>
>
>
> This looks completely plausible, but the two "FIT" images that are
>
> installed aren't identical... after this I end up with no FIT image
>
> and only a bare image in the deploy dir.
>
>
> What was in your KERNEL_IMAGETYPES? Did it at least contain “fitImage”??
>
>
>
> Yes, in fact only fitImage (and no initramfs).
>
>
> Digging into it, the logic between the two classes is a bit odd... in
>
> the case of a non initramfs build, the fitImage is actually installed
>
> here.
>
>
> If ‘here’ means kernel-fitimage, then I’ld say ALL versions of a FIT image containing AT LEAST a Linux kernel are installed by kernel-fitimage.
>
>
> The one that's installed in kernel-fitimage is the bare
>
> linux.bin, but named fitImage-...
>
>
> which is totally broken. If you want the bare kernel binary (which naming depends on architecture, so it should NOT be hard-coded to linux.bin anyway), you would need to specify that type *also* in KERNEL_IMAGETYPES, next to “fitImage”.
>
>
> Totally agree...
>
>
>
> I'll send a patch reverting this and removing the other one as I'd
>
> agree that it appears to have no purpose (and if you did want it, I
>
> guess you could list it in KERNEL_IMAGETYPES).
>
>
> I’m sorry I cannot follow what this and the other one is, and it. Let’s first understand all cases correctly.
>
>
>
> Sorry I've not described it well... the code in
>
> kernel-fitimage.bbclass that inserts the kernel into the its happens
>
> here http://git.openembedded.org/openembedded-core/tree/meta/classes/kernel-fitimage.bbclass#n371
>
>
> fitimage_emit_section_kernel ${1} "${kernelcount}" linux.bin "${linux_comp}"
>
>
> inside fitimage_emit_section_kernel we create a kernel section which
>
> has `data = /incbin/("${3}");` so linux.bin is our bare image.
>
>
> Then we have the installation of fitImage-linux-bin that happens here
>
> http://git.openembedded.org/openembedded-core/tree/meta/classes/kernel-fitimage.bbclass#n495
>
>
> echo "Copying linux.bin file..."
>
> install -m 0644 ${B}/linux.bin
>
> ${DEPLOYDIR}/fitImage-linux.bin-${KERNEL_FIT_NAME}.bin
>
> ln -snf fitImage-linux.bin-${KERNEL_FIT_NAME}.bin
>
> ${DEPLOYDIR}/fitImage-linux.bin-${KERNEL_FIT_LINK_NAME}
>
>
> i.e. the bare linux.bin file which we used to pack into the FIT image,
>
> not a fitImage.
>
>
> The output FIT image from kernel-fitimage.bbclass is created here
>
> http://git.openembedded.org/openembedded-core/tree/meta/classes/kernel-fitimage.bbclass#n450
>
>
> uboot-mkimage \
>
> ${@'-D "${UBOOT_MKIMAGE_DTCOPTS}"' if len('${UBOOT_MKIMAGE_DTCOPTS}') else ''} \
>
> -f ${1} \
>
> arch/${ARCH}/boot/${2}
>
>
> i.e. in arch/${ARCH}/boot/${2}
>
>
> It's that image which is then picked up by kernel.bbclass to install
>
> into deploydir (because KERNEL_OUTPUT_DIR ?= "arch/${ARCH}/boot"):
>
>
> for imageType in ${KERNEL_IMAGETYPES} ; do
>
> # kernel-fitimage class deploys fitImages, skip here
>
> if [ "$imageType" != "fitImage" ]; then
>
> base_name=${imageType}-${KERNEL_IMAGE_NAME}
>
> install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType}
>
> $deployDir/${base_name}.bin
>
> fi
>
> done
>
>
> Only it's doesn't because of the filter against fitImage.
>
>
>
> To check I'm not seeing some strange artefact of our BSP or
> linux-ti-staging (or any other layer we're using):
>
> $ git clone git://git.yoctoproject.org/poky
> $ cd poky
> $ . oe-init-build-env
> $ cat << EOF >> conf/local.conf
> MACHINE = "beaglebone-yocto"
> KERNEL_CLASSES += " kernel-fitimage"
> KERNEL_IMAGETYPES = "fitImage"
> EOF
> $ bitbake linux-yocto
>
> The FIT images we then have:
>
> $ find tmp/deploy/images/beaglebone-yocto -name 'fit*.bin' -type f
> tmp/deploy/images/beaglebone-yocto/fitImage-linux.bin--4.18.3+git0+7341720391_eba03655e8-r0-beaglebone-yocto-20180916134100.bin
>
> And what is:
>
> $ bitbake u-boot-mkimage-native -caddto_recipe_sysroot
> $ oe-run-native u-boot-mkimage-native mkimage -l
> tmp/deploy/images/beaglebone-yocto/fitImage-linux.bin--4.18.3+git0+7341720391_eba03655e8-r0-beaglebone-yocto-20180916134100.bin
> Running bitbake -e u-boot-mkimage-native
> GP Header: Size a0e1 LoadAddr a0e1
>
> Revert c2d00e2f83cdf3d2923660448756ed29296a06a6 and try again:
>
> $ git revert c2d00e2f83cdf3d2923660448756ed29296a06a6
> $ bitbake linux-yocto
>
> This time there's two images:
>
> $ find tmp/deploy/images/beaglebone-yocto -name 'fit*.bin' -type f
> tmp/deploy/images/beaglebone-yocto/fitImage--4.18.3+git0+7341720391_eba03655e8-r0-beaglebone-yocto-20180916141923.bin
> tmp/deploy/images/beaglebone-yocto/fitImage-linux.bin--4.18.3+git0+7341720391_eba03655e8-r0-beaglebone-yocto-20180916141923.bin
>
> And what they are:
>
> $ oe-run-native u-boot-mkimage-native mkimage -l
> tmp/deploy/images/beaglebone-yocto/fitImage--4.18.3+git0+7341720391_eba03655e8-r0-beaglebone-yocto-20180916141923.bin
> Running bitbake -e u-boot-mkimage-native
> FIT description: U-Boot fitImage for Poky (Yocto Project Reference
> Distro)/4.18.3+gitAUTOINC+7341720391_eba03655e8/beaglebone-yocto
> Created: Sun Sep 16 14:14:47 2018
> Image 0 (kernel at 1)
> Description: Linux kernel
> Created: Sun Sep 16 14:14:47 2018
> Type: Kernel Image
> Compression: uncompressed
> Data Size: 6381368 Bytes = 6231.80 KiB = 6.09 MiB
> Architecture: ARM
> OS: Linux
> Load Address: 0x80008000
> Entry Point: 0x80008000
> Hash algo: sha1
> Hash value: 909137524ffd28b5b0ac51ea39c648b09902dc18
> Image 1 (fdt at am335x-bone.dtb)
> Description: Flattened Device Tree blob
> Created: Sun Sep 16 14:14:47 2018
> Type: Flat Device Tree
> Compression: uncompressed
> Data Size: 33030 Bytes = 32.26 KiB = 0.03 MiB
> Architecture: ARM
> Hash algo: sha1
> Hash value: 0fece12f15fc5ac6c452d9308cd374c2c0cfea47
> Image 2 (fdt at am335x-boneblack.dtb)
> Description: Flattened Device Tree blob
> Created: Sun Sep 16 14:14:47 2018
> Type: Flat Device Tree
> Compression: uncompressed
> Data Size: 34782 Bytes = 33.97 KiB = 0.03 MiB
> Architecture: ARM
> Hash algo: sha1
> Hash value: 337f6843020cb8fbaf119b43fd748222d32e72df
> Image 3 (fdt at am335x-bonegreen.dtb)
> Description: Flattened Device Tree blob
> Created: Sun Sep 16 14:14:47 2018
> Type: Flat Device Tree
> Compression: uncompressed
> Data Size: 33286 Bytes = 32.51 KiB = 0.03 MiB
> Architecture: ARM
> Hash algo: sha1
> Hash value: 4974e8b1656cd7f52829ac3c01f6747bece87cbc
> Default Configuration: 'conf at am335x-bone.dtb'
> Configuration 0 (conf at am335x-bone.dtb)
> Description: 1 Linux kernel, FDT blob
> Kernel: kernel at 1
> FDT: fdt at am335x-bone.dtb
> Hash algo: sha1
> Hash value: unavailable
> Configuration 1 (conf at am335x-boneblack.dtb)
> Description: 0 Linux kernel, FDT blob
> Kernel: kernel at 1
> FDT: fdt at am335x-boneblack.dtb
> Hash algo: sha1
> Hash value: unavailable
> Configuration 2 (conf at am335x-bonegreen.dtb)
> Description: 0 Linux kernel, FDT blob
> Kernel: kernel at 1
> FDT: fdt at am335x-bonegreen.dtb
> Hash algo: sha1
> Hash value: unavailable
> $ oe-run-native u-boot-mkimage-native mkimage -l
> tmp/deploy/images/beaglebone-yocto/fitImage-linux.bin--4.18.3+git0+7341720391_eba03655e8-r0-beaglebone-yocto-20180916141923.bin
> Running bitbake -e u-boot-mkimage-native
> GP Header: Size a0e1 LoadAddr a0e1
>
> --
> Alex Kiernan
--
Alex Kiernan
More information about the Openembedded-core
mailing list