[OE-core] [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that.
Leon Woestenberg
leon at sidebranch.com
Mon Sep 17 18:05:29 UTC 2018
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20180917/4809e847/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2346 bytes
Desc: not available
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20180917/4809e847/attachment-0002.p7s>
More information about the Openembedded-core
mailing list