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.kier...@gmail.com > <mailto:alex.kier...@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 > <l...@sidebranch.com <mailto:l...@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.kier...@gmail.com > <mailto:alex.kier...@gmail.com>> wrote: > > > > On Sun, Sep 16, 2018 at 11:41 AM Alex Kiernan > <alex.kier...@gmail.com <mailto:alex.kier...@gmail.com>> wrote: > > > > > > Hi Leon > > > > > > On Sun, Sep 16, 2018 at 10:18 AM Leon Woestenberg > <l...@sidebranch.com <mailto:l...@sidebranch.com>> wrote: > > > > > > Hi Alex, > > > > > > On 15 Sep 2018, at 19:45, Alex Kiernan <alex.kier...@gmail.com > <mailto:alex.kier...@gmail.com>> wrote: > > > > > > On Mon, Sep 10, 2018 at 10:57 PM Leon Woestenberg > <l...@sidebranch.com <mailto:l...@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 <l...@sidebranch.com > <mailto:l...@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@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 (f...@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 (f...@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 (f...@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: 'c...@am335x-bone.dtb' > > Configuration 0 (c...@am335x-bone.dtb) > > Description: 1 Linux kernel, FDT blob > > Kernel: kernel@1 > > FDT: f...@am335x-bone.dtb > > Hash algo: sha1 > > Hash value: unavailable > > Configuration 1 (c...@am335x-boneblack.dtb) > > Description: 0 Linux kernel, FDT blob > > Kernel: kernel@1 > > FDT: f...@am335x-boneblack.dtb > > Hash algo: sha1 > > Hash value: unavailable > > Configuration 2 (c...@am335x-bonegreen.dtb) > > Description: 0 Linux kernel, FDT blob > > Kernel: kernel@1 > > FDT: f...@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 > l...@sidebranch.com <mailto:l...@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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
