[OE-core] [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that.
Marek Vasut
marex at denx.de
Tue Sep 18 09:44:31 UTC 2018
On 09/18/2018 11:40 AM, Leon Woestenberg wrote:
> Hi Alex,
Hi,
> Adding Marek Vasut, original author of kernel-fitimage.bbclass.
>
>> I guess the reason that the deployment happens in kernel.bbclass is so
>> you only have all the symlinking logic in one place
>
> The deployment happens in both kernel.bbclass and
> kernel-fitimage.bbclass. That was exactly one of the bugs I wanted to
> solve. I am not sure what the intention was, though.
>
> Marek: can you comment of the exact purpose of the deploy task in
> kernel-fitimage.bbclass?
> Which class should deploy the FIT images themselves?
It seems to have to do with deploying of the ITS files and the symlinks
for then .
It's hard to make any sense from the discussion below due to the
constant top-posting and mixing of email history, so I'll just not do
that, sorry.
What bug is it that you're seeing ?
> Whilst cleaning things up, my understanding was that
> kernel_do_deploy_append() in kernel-fitimage.bbclass deploys the
> fitImages, along with the .its file etc.
> Maybe I was mistaken.
That's the case, yes.
> I have several other fixed piled up; for example initramfs's supposed to
> get bundled inside the kernel get also packed into the FIT; this takes
> double the amount of space in the FIT image...
>
> Regards,
>
> Leon.
>
>
>
>
> On Tue, Sep 18, 2018 at 8:10 AM Alex Kiernan <alex.kiernan at gmail.com
> <mailto:alex.kiernan at gmail.com>> wrote:
>
> 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 <mailto: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
> <mailto:alex.kiernan at gmail.com>> wrote:
> >
> > On Sun, Sep 16, 2018 at 11:41 AM Alex Kiernan
> <alex.kiernan at gmail.com <mailto:alex.kiernan at gmail.com>> wrote:
> >
> >
> > Hi Leon
> >
> >
> > On Sun, Sep 16, 2018 at 10:18 AM Leon Woestenberg
> <leon at sidebranch.com <mailto:leon at sidebranch.com>> wrote:
> >
> >
> > Hi Alex,
> >
> >
> > On 15 Sep 2018, at 19:45, Alex Kiernan <alex.kiernan at gmail.com
> <mailto:alex.kiernan at gmail.com>> wrote:
> >
> >
> > On Mon, Sep 10, 2018 at 10:57 PM Leon Woestenberg
> <leon at sidebranch.com <mailto: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
> <mailto: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
> <http://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
>
>
>
> --
> Leon Woestenberg
> leon at sidebranch.com <mailto:leon at sidebranch.com>
> T: +31 40 711 42 76
> M: +31 6 472 30 372
>
> Sidebranch
> Embedded Systems
> Eindhoven, The Netherlands
> http://www.sidebranch.com <http://www.sidebranch.com/>
>
>
>
>
--
Best regards,
Marek Vasut
More information about the Openembedded-core
mailing list