* [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that. @ 2018-09-10 21:56 Leon Woestenberg 2018-09-15 17:45 ` Alex Kiernan 0 siblings, 1 reply; 19+ messages in thread From: Leon Woestenberg @ 2018-09-10 21:56 UTC (permalink / raw) To: openembedded-core 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@sidebranch.com> --- meta/classes/kernel.bbclass | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass index b57832c..1f69091 100644 --- a/meta/classes/kernel.bbclass +++ b/meta/classes/kernel.bbclass @@ -669,8 +669,11 @@ kernel_do_deploy() { fi for imageType in ${KERNEL_IMAGETYPES} ; do - base_name=${imageType}-${KERNEL_IMAGE_NAME} - install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType} $deployDir/${base_name}.bin + # 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 if [ ${MODULE_TARBALL_DEPLOY} = "1" ] && (grep -q -i -e '^CONFIG_MODULES=y$' .config); then mkdir -p ${D}/lib @@ -687,10 +690,13 @@ kernel_do_deploy() { if [ ! -z "${INITRAMFS_IMAGE}" -a x"${INITRAMFS_IMAGE_BUNDLE}" = x1 ]; then for imageType in ${KERNEL_IMAGETYPES} ; do - initramfs_base_name=${imageType}-${INITRAMFS_NAME} - initramfs_symlink_name=${imageType}-${INITRAMFS_LINK_NAME} - install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType}.initramfs $deployDir/${initramfs_base_name}.bin - ln -sf ${initramfs_base_name}.bin $deployDir/${initramfs_symlink_name}.bin + # kernel-fitimage class deploys fitImages, skip here + if [ "$imageType" != "fitImage" ]; then + initramfs_base_name=${imageType}-${INITRAMFS_NAME} + initramfs_symlink_name=${imageType}-${INITRAMFS_LINK_NAME} + install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType}.initramfs $deployDir/${initramfs_base_name}.bin + ln -sf ${initramfs_base_name}.bin $deployDir/${initramfs_symlink_name}.bin + fi done fi } -- 2.7.4 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that. 2018-09-10 21:56 [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that Leon Woestenberg @ 2018-09-15 17:45 ` Alex Kiernan 2018-09-16 9:18 ` Leon Woestenberg 0 siblings, 1 reply; 19+ messages in thread From: Alex Kiernan @ 2018-09-15 17:45 UTC (permalink / raw) To: leon; +Cc: openembedded-core On Mon, Sep 10, 2018 at 10:57 PM Leon Woestenberg <leon@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@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. 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. The one that's installed in kernel-fitimage is the bare linux.bin, but named fitImage-... 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). > --- > meta/classes/kernel.bbclass | 18 ++++++++++++------ > 1 file changed, 12 insertions(+), 6 deletions(-) > > diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass > index b57832c..1f69091 100644 > --- a/meta/classes/kernel.bbclass > +++ b/meta/classes/kernel.bbclass > @@ -669,8 +669,11 @@ kernel_do_deploy() { > fi > > for imageType in ${KERNEL_IMAGETYPES} ; do > - base_name=${imageType}-${KERNEL_IMAGE_NAME} > - install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType} $deployDir/${base_name}.bin > + # 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 > if [ ${MODULE_TARBALL_DEPLOY} = "1" ] && (grep -q -i -e '^CONFIG_MODULES=y$' .config); then > mkdir -p ${D}/lib > @@ -687,10 +690,13 @@ kernel_do_deploy() { > > if [ ! -z "${INITRAMFS_IMAGE}" -a x"${INITRAMFS_IMAGE_BUNDLE}" = x1 ]; then > for imageType in ${KERNEL_IMAGETYPES} ; do > - initramfs_base_name=${imageType}-${INITRAMFS_NAME} > - initramfs_symlink_name=${imageType}-${INITRAMFS_LINK_NAME} > - install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType}.initramfs $deployDir/${initramfs_base_name}.bin > - ln -sf ${initramfs_base_name}.bin $deployDir/${initramfs_symlink_name}.bin > + # kernel-fitimage class deploys fitImages, skip here > + if [ "$imageType" != "fitImage" ]; then > + initramfs_base_name=${imageType}-${INITRAMFS_NAME} > + initramfs_symlink_name=${imageType}-${INITRAMFS_LINK_NAME} > + install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType}.initramfs $deployDir/${initramfs_base_name}.bin > + ln -sf ${initramfs_base_name}.bin $deployDir/${initramfs_symlink_name}.bin > + fi > done > fi > } > -- > 2.7.4 > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- Alex Kiernan ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that. 2018-09-15 17:45 ` Alex Kiernan @ 2018-09-16 9:18 ` Leon Woestenberg 2018-09-16 10:41 ` Alex Kiernan 0 siblings, 1 reply; 19+ messages in thread From: Leon Woestenberg @ 2018-09-16 9:18 UTC (permalink / raw) To: Alex Kiernan; +Cc: openembedded-core [-- Attachment #1: Type: text/plain, Size: 4903 bytes --] Hi Alex, > On 15 Sep 2018, at 19:45, Alex Kiernan <alex.kiernan@gmail.com> wrote: > >> On Mon, Sep 10, 2018 at 10:57 PM Leon Woestenberg <leon@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@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”?? > 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”. > > 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. Regards, Leon > >> --- >> meta/classes/kernel.bbclass | 18 ++++++++++++------ >> 1 file changed, 12 insertions(+), 6 deletions(-) >> >> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass >> index b57832c..1f69091 100644 >> --- a/meta/classes/kernel.bbclass >> +++ b/meta/classes/kernel.bbclass >> @@ -669,8 +669,11 @@ kernel_do_deploy() { >> fi >> >> for imageType in ${KERNEL_IMAGETYPES} ; do >> - base_name=${imageType}-${KERNEL_IMAGE_NAME} >> - install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType} $deployDir/${base_name}.bin >> + # 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 >> if [ ${MODULE_TARBALL_DEPLOY} = "1" ] && (grep -q -i -e '^CONFIG_MODULES=y$' .config); then >> mkdir -p ${D}/lib >> @@ -687,10 +690,13 @@ kernel_do_deploy() { >> >> if [ ! -z "${INITRAMFS_IMAGE}" -a x"${INITRAMFS_IMAGE_BUNDLE}" = x1 ]; then >> for imageType in ${KERNEL_IMAGETYPES} ; do >> - initramfs_base_name=${imageType}-${INITRAMFS_NAME} >> - initramfs_symlink_name=${imageType}-${INITRAMFS_LINK_NAME} >> - install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType}.initramfs $deployDir/${initramfs_base_name}.bin >> - ln -sf ${initramfs_base_name}.bin $deployDir/${initramfs_symlink_name}.bin >> + # kernel-fitimage class deploys fitImages, skip here >> + if [ "$imageType" != "fitImage" ]; then >> + initramfs_base_name=${imageType}-${INITRAMFS_NAME} >> + initramfs_symlink_name=${imageType}-${INITRAMFS_LINK_NAME} >> + install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType}.initramfs $deployDir/${initramfs_base_name}.bin >> + ln -sf ${initramfs_base_name}.bin $deployDir/${initramfs_symlink_name}.bin >> + fi >> done >> fi >> } >> -- >> 2.7.4 >> >> -- >> _______________________________________________ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-core > > > > -- > Alex Kiernan [-- Attachment #2: smime.p7s --] [-- Type: application/pkcs7-signature, Size: 2346 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that. 2018-09-16 9:18 ` Leon Woestenberg @ 2018-09-16 10:41 ` Alex Kiernan 2018-09-16 14:22 ` Alex Kiernan 0 siblings, 1 reply; 19+ messages in thread From: Alex Kiernan @ 2018-09-16 10:41 UTC (permalink / raw) To: leon; +Cc: openembedded-core Hi Leon On Sun, Sep 16, 2018 at 10:18 AM Leon Woestenberg <leon@sidebranch.com> wrote: > > Hi Alex, > > > On 15 Sep 2018, at 19:45, Alex Kiernan <alex.kiernan@gmail.com> wrote: > > > >> On Mon, Sep 10, 2018 at 10:57 PM Leon Woestenberg <leon@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@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. > Regards, Leon > > > >> --- > >> meta/classes/kernel.bbclass | 18 ++++++++++++------ > >> 1 file changed, 12 insertions(+), 6 deletions(-) > >> > >> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass > >> index b57832c..1f69091 100644 > >> --- a/meta/classes/kernel.bbclass > >> +++ b/meta/classes/kernel.bbclass > >> @@ -669,8 +669,11 @@ kernel_do_deploy() { > >> fi > >> > >> for imageType in ${KERNEL_IMAGETYPES} ; do > >> - base_name=${imageType}-${KERNEL_IMAGE_NAME} > >> - install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType} $deployDir/${base_name}.bin > >> + # 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 > >> if [ ${MODULE_TARBALL_DEPLOY} = "1" ] && (grep -q -i -e '^CONFIG_MODULES=y$' .config); then > >> mkdir -p ${D}/lib > >> @@ -687,10 +690,13 @@ kernel_do_deploy() { > >> > >> if [ ! -z "${INITRAMFS_IMAGE}" -a x"${INITRAMFS_IMAGE_BUNDLE}" = x1 ]; then > >> for imageType in ${KERNEL_IMAGETYPES} ; do > >> - initramfs_base_name=${imageType}-${INITRAMFS_NAME} > >> - initramfs_symlink_name=${imageType}-${INITRAMFS_LINK_NAME} > >> - install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType}.initramfs $deployDir/${initramfs_base_name}.bin > >> - ln -sf ${initramfs_base_name}.bin $deployDir/${initramfs_symlink_name}.bin > >> + # kernel-fitimage class deploys fitImages, skip here > >> + if [ "$imageType" != "fitImage" ]; then > >> + initramfs_base_name=${imageType}-${INITRAMFS_NAME} > >> + initramfs_symlink_name=${imageType}-${INITRAMFS_LINK_NAME} > >> + install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType}.initramfs $deployDir/${initramfs_base_name}.bin > >> + ln -sf ${initramfs_base_name}.bin $deployDir/${initramfs_symlink_name}.bin > >> + fi > >> done > >> fi > >> } > >> -- > >> 2.7.4 > >> > >> -- > >> _______________________________________________ > >> Openembedded-core mailing list > >> Openembedded-core@lists.openembedded.org > >> http://lists.openembedded.org/mailman/listinfo/openembedded-core > > > > > > > > -- > > Alex Kiernan -- Alex Kiernan ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that. 2018-09-16 10:41 ` Alex Kiernan @ 2018-09-16 14:22 ` Alex Kiernan 2018-09-17 18:05 ` Leon Woestenberg 0 siblings, 1 reply; 19+ messages in thread From: Alex Kiernan @ 2018-09-16 14:22 UTC (permalink / raw) To: leon; +Cc: openembedded-core On Sun, Sep 16, 2018 at 11:41 AM Alex Kiernan <alex.kiernan@gmail.com> wrote: > > Hi Leon > > On Sun, Sep 16, 2018 at 10:18 AM Leon Woestenberg <leon@sidebranch.com> wrote: > > > > Hi Alex, > > > > > On 15 Sep 2018, at 19:45, Alex Kiernan <alex.kiernan@gmail.com> wrote: > > > > > >> On Mon, Sep 10, 2018 at 10:57 PM Leon Woestenberg <leon@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@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@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@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@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@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@am335x-bone.dtb' Configuration 0 (conf@am335x-bone.dtb) Description: 1 Linux kernel, FDT blob Kernel: kernel@1 FDT: fdt@am335x-bone.dtb Hash algo: sha1 Hash value: unavailable Configuration 1 (conf@am335x-boneblack.dtb) Description: 0 Linux kernel, FDT blob Kernel: kernel@1 FDT: fdt@am335x-boneblack.dtb Hash algo: sha1 Hash value: unavailable Configuration 2 (conf@am335x-bonegreen.dtb) Description: 0 Linux kernel, FDT blob Kernel: kernel@1 FDT: fdt@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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that. 2018-09-16 14:22 ` Alex Kiernan @ 2018-09-17 18:05 ` Leon Woestenberg 2018-09-18 6:10 ` Alex Kiernan 0 siblings, 1 reply; 19+ messages in thread From: Leon Woestenberg @ 2018-09-17 18:05 UTC (permalink / raw) To: Alex Kiernan; +Cc: openembedded-core [-- Attachment #1.1: Type: text/plain, Size: 9163 bytes --] 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@gmail.com> wrote: > >> On Sun, Sep 16, 2018 at 11:41 AM Alex Kiernan <alex.kiernan@gmail.com> wrote: >> >> Hi Leon >> >>> On Sun, Sep 16, 2018 at 10:18 AM Leon Woestenberg <leon@sidebranch.com> wrote: >>> >>> Hi Alex, >>> >>>>> On 15 Sep 2018, at 19:45, Alex Kiernan <alex.kiernan@gmail.com> wrote: >>>>> >>>>> On Mon, Sep 10, 2018 at 10:57 PM Leon Woestenberg <leon@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@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@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@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@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@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@am335x-bone.dtb' > Configuration 0 (conf@am335x-bone.dtb) > Description: 1 Linux kernel, FDT blob > Kernel: kernel@1 > FDT: fdt@am335x-bone.dtb > Hash algo: sha1 > Hash value: unavailable > Configuration 1 (conf@am335x-boneblack.dtb) > Description: 0 Linux kernel, FDT blob > Kernel: kernel@1 > FDT: fdt@am335x-boneblack.dtb > Hash algo: sha1 > Hash value: unavailable > Configuration 2 (conf@am335x-bonegreen.dtb) > Description: 0 Linux kernel, FDT blob > Kernel: kernel@1 > FDT: fdt@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 [-- Attachment #1.2: Type: text/html, Size: 22359 bytes --] [-- Attachment #2: smime.p7s --] [-- Type: application/pkcs7-signature, Size: 2346 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that. 2018-09-17 18:05 ` Leon Woestenberg @ 2018-09-18 6:10 ` Alex Kiernan 2018-09-18 9:40 ` Leon Woestenberg 0 siblings, 1 reply; 19+ messages in thread From: Alex Kiernan @ 2018-09-18 6:10 UTC (permalink / raw) To: leon; +Cc: openembedded-core 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@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@gmail.com> wrote: > > On Sun, Sep 16, 2018 at 11:41 AM Alex Kiernan <alex.kiernan@gmail.com> wrote: > > > Hi Leon > > > On Sun, Sep 16, 2018 at 10:18 AM Leon Woestenberg <leon@sidebranch.com> wrote: > > > Hi Alex, > > > On 15 Sep 2018, at 19:45, Alex Kiernan <alex.kiernan@gmail.com> wrote: > > > On Mon, Sep 10, 2018 at 10:57 PM Leon Woestenberg <leon@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@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@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@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@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@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@am335x-bone.dtb' > Configuration 0 (conf@am335x-bone.dtb) > Description: 1 Linux kernel, FDT blob > Kernel: kernel@1 > FDT: fdt@am335x-bone.dtb > Hash algo: sha1 > Hash value: unavailable > Configuration 1 (conf@am335x-boneblack.dtb) > Description: 0 Linux kernel, FDT blob > Kernel: kernel@1 > FDT: fdt@am335x-boneblack.dtb > Hash algo: sha1 > Hash value: unavailable > Configuration 2 (conf@am335x-bonegreen.dtb) > Description: 0 Linux kernel, FDT blob > Kernel: kernel@1 > FDT: fdt@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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that. 2018-09-18 6:10 ` Alex Kiernan @ 2018-09-18 9:40 ` Leon Woestenberg 2018-09-18 9:44 ` Marek Vasut 0 siblings, 1 reply; 19+ messages in thread From: Leon Woestenberg @ 2018-09-18 9:40 UTC (permalink / raw) To: Alex Kiernan, Marek Vasut; +Cc: OE Core mailing list [-- Attachment #1: Type: text/plain, Size: 11491 bytes --] Hi Alex, 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? 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. 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@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@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@gmail.com> wrote: > > > > On Sun, Sep 16, 2018 at 11:41 AM Alex Kiernan <alex.kiernan@gmail.com> > wrote: > > > > > > Hi Leon > > > > > > On Sun, Sep 16, 2018 at 10:18 AM Leon Woestenberg <leon@sidebranch.com> > wrote: > > > > > > Hi Alex, > > > > > > On 15 Sep 2018, at 19:45, Alex Kiernan <alex.kiernan@gmail.com> wrote: > > > > > > On Mon, Sep 10, 2018 at 10:57 PM Leon Woestenberg <leon@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@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@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@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@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@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@am335x-bone.dtb' > > Configuration 0 (conf@am335x-bone.dtb) > > Description: 1 Linux kernel, FDT blob > > Kernel: kernel@1 > > FDT: fdt@am335x-bone.dtb > > Hash algo: sha1 > > Hash value: unavailable > > Configuration 1 (conf@am335x-boneblack.dtb) > > Description: 0 Linux kernel, FDT blob > > Kernel: kernel@1 > > FDT: fdt@am335x-boneblack.dtb > > Hash algo: sha1 > > Hash value: unavailable > > Configuration 2 (conf@am335x-bonegreen.dtb) > > Description: 0 Linux kernel, FDT blob > > Kernel: kernel@1 > > FDT: fdt@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@sidebranch.com T: +31 40 711 42 76 M: +31 6 472 30 372 Sidebranch Embedded Systems Eindhoven, The Netherlands http://www.sidebranch.com [-- Attachment #2: Type: text/html, Size: 15977 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that. 2018-09-18 9:40 ` Leon Woestenberg @ 2018-09-18 9:44 ` Marek Vasut 2018-09-18 10:01 ` Leon Woestenberg 0 siblings, 1 reply; 19+ messages in thread From: Marek Vasut @ 2018-09-18 9:44 UTC (permalink / raw) To: Leon Woestenberg, Alex Kiernan; +Cc: OE Core mailing list 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@gmail.com > <mailto:alex.kiernan@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@sidebranch.com <mailto:leon@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@gmail.com > <mailto:alex.kiernan@gmail.com>> wrote: > > > > On Sun, Sep 16, 2018 at 11:41 AM Alex Kiernan > <alex.kiernan@gmail.com <mailto:alex.kiernan@gmail.com>> wrote: > > > > > > Hi Leon > > > > > > On Sun, Sep 16, 2018 at 10:18 AM Leon Woestenberg > <leon@sidebranch.com <mailto:leon@sidebranch.com>> wrote: > > > > > > Hi Alex, > > > > > > On 15 Sep 2018, at 19:45, Alex Kiernan <alex.kiernan@gmail.com > <mailto:alex.kiernan@gmail.com>> wrote: > > > > > > On Mon, Sep 10, 2018 at 10:57 PM Leon Woestenberg > <leon@sidebranch.com <mailto:leon@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@sidebranch.com > <mailto:leon@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 (fdt@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@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@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@am335x-bone.dtb' > > Configuration 0 (conf@am335x-bone.dtb) > > Description: 1 Linux kernel, FDT blob > > Kernel: kernel@1 > > FDT: fdt@am335x-bone.dtb > > Hash algo: sha1 > > Hash value: unavailable > > Configuration 1 (conf@am335x-boneblack.dtb) > > Description: 0 Linux kernel, FDT blob > > Kernel: kernel@1 > > FDT: fdt@am335x-boneblack.dtb > > Hash algo: sha1 > > Hash value: unavailable > > Configuration 2 (conf@am335x-bonegreen.dtb) > > Description: 0 Linux kernel, FDT blob > > Kernel: kernel@1 > > FDT: fdt@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@sidebranch.com <mailto:leon@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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that. 2018-09-18 9:44 ` Marek Vasut @ 2018-09-18 10:01 ` Leon Woestenberg 2018-09-18 10:03 ` Marek Vasut 2018-09-18 10:21 ` Leon Woestenberg 0 siblings, 2 replies; 19+ messages in thread From: Leon Woestenberg @ 2018-09-18 10:01 UTC (permalink / raw) To: Marek Vasut; +Cc: OE Core mailing list [-- Attachment #1: Type: text/plain, Size: 15331 bytes --] Hi Marek, one of the issues I saw was that both kernel.bbclass and kernel-fitImage.bbclass deployed the FIT image into the deploy/images/ subfolder. My fix was to make the kernel.bbclass ignore "fitImage" during deployment. This is also the fix I saw from Xilinx. (Another fix I have pending is that bundled initramfs images (i.e that go inside the kernel binary) where also seperately packed inside the FIT image.) In general, I am trying to fix all bugs and issues that match "kernel-fitimage.bbclass" on the mailing list. Regards, Leon. On Tue, Sep 18, 2018 at 11:44 AM Marek Vasut <marex@denx.de> wrote: > 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@gmail.com > > <mailto:alex.kiernan@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@sidebranch.com <mailto:leon@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@gmail.com > > <mailto:alex.kiernan@gmail.com>> wrote: > > > > > > On Sun, Sep 16, 2018 at 11:41 AM Alex Kiernan > > <alex.kiernan@gmail.com <mailto:alex.kiernan@gmail.com>> wrote: > > > > > > > > > Hi Leon > > > > > > > > > On Sun, Sep 16, 2018 at 10:18 AM Leon Woestenberg > > <leon@sidebranch.com <mailto:leon@sidebranch.com>> wrote: > > > > > > > > > Hi Alex, > > > > > > > > > On 15 Sep 2018, at 19:45, Alex Kiernan <alex.kiernan@gmail.com > > <mailto:alex.kiernan@gmail.com>> wrote: > > > > > > > > > On Mon, Sep 10, 2018 at 10:57 PM Leon Woestenberg > > <leon@sidebranch.com <mailto:leon@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@sidebranch.com > > <mailto:leon@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 (fdt@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@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@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@am335x-bone.dtb' > > > Configuration 0 (conf@am335x-bone.dtb) > > > Description: 1 Linux kernel, FDT blob > > > Kernel: kernel@1 > > > FDT: fdt@am335x-bone.dtb > > > Hash algo: sha1 > > > Hash value: unavailable > > > Configuration 1 (conf@am335x-boneblack.dtb) > > > Description: 0 Linux kernel, FDT blob > > > Kernel: kernel@1 > > > FDT: fdt@am335x-boneblack.dtb > > > Hash algo: sha1 > > > Hash value: unavailable > > > Configuration 2 (conf@am335x-bonegreen.dtb) > > > Description: 0 Linux kernel, FDT blob > > > Kernel: kernel@1 > > > FDT: fdt@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@sidebranch.com <mailto:leon@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 > -- Leon Woestenberg leon@sidebranch.com T: +31 40 711 42 76 M: +31 6 472 30 372 Sidebranch Embedded Systems Eindhoven, The Netherlands http://www.sidebranch.com [-- Attachment #2: Type: text/html, Size: 23098 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that. 2018-09-18 10:01 ` Leon Woestenberg @ 2018-09-18 10:03 ` Marek Vasut 2018-09-18 10:22 ` Leon Woestenberg 2018-09-18 10:21 ` Leon Woestenberg 1 sibling, 1 reply; 19+ messages in thread From: Marek Vasut @ 2018-09-18 10:03 UTC (permalink / raw) To: Leon Woestenberg; +Cc: OE Core mailing list On 09/18/2018 12:01 PM, Leon Woestenberg wrote: > Hi Marek, Could you _please_ stop top-posting ? > one of the issues I saw was that both kernel.bbclass and > kernel-fitImage.bbclass deployed the FIT image into the deploy/images/ > subfolder. > > My fix was to make the kernel.bbclass ignore "fitImage" during > deployment. This is also the fix I saw from Xilinx. If I recall correctly, meta-xilinx had their own horribly hacked fitImage bbclass, are you sure it's not interfering here ? > (Another fix I have pending is that bundled initramfs images (i.e that > go inside the kernel binary) where also seperately packed inside the FIT > image.) Separate initrd is already supported. > In general, I am trying to fix all bugs and issues that match > "kernel-fitimage.bbclass" on the mailing list. > > Regards, > > Leon. > > > On Tue, Sep 18, 2018 at 11:44 AM Marek Vasut <marex@denx.de > <mailto:marex@denx.de>> wrote: > > 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@gmail.com <mailto:alex.kiernan@gmail.com> > > <mailto:alex.kiernan@gmail.com <mailto:alex.kiernan@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@sidebranch.com <mailto:leon@sidebranch.com> > <mailto:leon@sidebranch.com <mailto:leon@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@gmail.com <mailto:alex.kiernan@gmail.com> > > <mailto:alex.kiernan@gmail.com > <mailto:alex.kiernan@gmail.com>>> wrote: > > > > > > On Sun, Sep 16, 2018 at 11:41 AM Alex Kiernan > > <alex.kiernan@gmail.com <mailto:alex.kiernan@gmail.com> > <mailto:alex.kiernan@gmail.com <mailto:alex.kiernan@gmail.com>>> wrote: > > > > > > > > > Hi Leon > > > > > > > > > On Sun, Sep 16, 2018 at 10:18 AM Leon Woestenberg > > <leon@sidebranch.com <mailto:leon@sidebranch.com> > <mailto:leon@sidebranch.com <mailto:leon@sidebranch.com>>> wrote: > > > > > > > > > Hi Alex, > > > > > > > > > On 15 Sep 2018, at 19:45, Alex Kiernan > <alex.kiernan@gmail.com <mailto:alex.kiernan@gmail.com> > > <mailto:alex.kiernan@gmail.com > <mailto:alex.kiernan@gmail.com>>> wrote: > > > > > > > > > On Mon, Sep 10, 2018 at 10:57 PM Leon Woestenberg > > <leon@sidebranch.com <mailto:leon@sidebranch.com> > <mailto:leon@sidebranch.com <mailto:leon@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@sidebranch.com > <mailto:leon@sidebranch.com> > > <mailto:leon@sidebranch.com <mailto:leon@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> > > <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 (fdt@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@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@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@am335x-bone.dtb' > > > Configuration 0 (conf@am335x-bone.dtb) > > > Description: 1 Linux kernel, FDT blob > > > Kernel: kernel@1 > > > FDT: fdt@am335x-bone.dtb > > > Hash algo: sha1 > > > Hash value: unavailable > > > Configuration 1 (conf@am335x-boneblack.dtb) > > > Description: 0 Linux kernel, FDT blob > > > Kernel: kernel@1 > > > FDT: fdt@am335x-boneblack.dtb > > > Hash algo: sha1 > > > Hash value: unavailable > > > Configuration 2 (conf@am335x-bonegreen.dtb) > > > Description: 0 Linux kernel, FDT blob > > > Kernel: kernel@1 > > > FDT: fdt@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@sidebranch.com <mailto:leon@sidebranch.com> > <mailto:leon@sidebranch.com <mailto:leon@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 > > > > -- > Leon Woestenberg > leon@sidebranch.com <mailto:leon@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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that. 2018-09-18 10:03 ` Marek Vasut @ 2018-09-18 10:22 ` Leon Woestenberg 2018-09-18 10:35 ` Marek Vasut 0 siblings, 1 reply; 19+ messages in thread From: Leon Woestenberg @ 2018-09-18 10:22 UTC (permalink / raw) To: Marek Vasut; +Cc: OE Core mailing list Hi Marek, On Tue, Sep 18, 2018 at 12:12 PM Marek Vasut <marex@denx.de> wrote: > > On 09/18/2018 12:01 PM, Leon Woestenberg wrote: > > Hi Marek, > Could you _please_ stop top-posting ? Yes. > > > one of the issues I saw was that both kernel.bbclass and > > kernel-fitImage.bbclass deployed the FIT image into the deploy/images/ > > subfolder. > > > > My fix was to make the kernel.bbclass ignore "fitImage" during > > deployment. This is also the fix I saw from Xilinx. > > If I recall correctly, meta-xilinx had their own horribly hacked > fitImage bbclass, are you sure it's not interfering here ? > Yes I am sure it's not. > > > (Another fix I have pending is that bundled initramfs images (i.e that > > go inside the kernel binary) where also seperately packed inside the FIT > > image.) > > Separate initrd is already supported. There is no exception for INITRAMFS_IMAGE_BUNDLE in kernel-fitimage.bbclass. The initramfs will be packed inside the FIT, in addition of also being packed inside the kernel. My local fix has this: diff --git a/meta/classes/kernel-fitimage.bbclass b/meta/classes/kernel-fitimage.bbclass index a4d7aca..17addab 100644 --- a/meta/classes/kernel-fitimage.bbclass +++ b/meta/classes/kernel-fitimage.bbclass @@ -475,7 +475,9 @@ addtask assemble_fitimage before do_install after do_compile do_assemble_fitimage_initramfs() { if echo ${KERNEL_IMAGETYPES} | grep -wq "fitImage" && \ - test -n "${INITRAMFS_IMAGE}" ; then + test -n "${INITRAMFS_IMAGE}" && \ + test ! -n "${INITRAMFS_IMAGE_BUNDLE}"; then + cd ${B} fitimage_assemble fit-image-${INITRAMFS_IMAGE}.its fitImage-${INITRAMFS_IMAGE} 1 fi @@ -483,6 +485,18 @@ do_assemble_fitimage_initramfs() { addtask assemble_fitimage_initramfs before do_deploy after do_install +do_assemble_fitimage_bundled_initramfs() { + if echo ${KERNEL_IMAGETYPES} | grep -wq "fitImage" && \ + test -n "${INITRAMFS_IMAGE}" && \ + test -n "${INITRAMFS_IMAGE_BUNDLE}"; then + + cd ${B} + fitimage_assemble fit-image-${INITRAMFS_IMAGE}.its fitImage-${INITRAMFS_IMAGE} + fi +} + +addtask assemble_fitimage_bundled_initramfs before do_deploy after do_bundle_initramfs + Regards, Leon. ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that. 2018-09-18 10:22 ` Leon Woestenberg @ 2018-09-18 10:35 ` Marek Vasut 2018-09-18 10:59 ` Leon Woestenberg 0 siblings, 1 reply; 19+ messages in thread From: Marek Vasut @ 2018-09-18 10:35 UTC (permalink / raw) To: Leon Woestenberg; +Cc: OE Core mailing list On 09/18/2018 12:22 PM, Leon Woestenberg wrote: > Hi Marek, Hi, > On Tue, Sep 18, 2018 at 12:12 PM Marek Vasut <marex@denx.de> wrote: >> >> On 09/18/2018 12:01 PM, Leon Woestenberg wrote: >>> Hi Marek, >> Could you _please_ stop top-posting ? > > Yes. > >> >>> one of the issues I saw was that both kernel.bbclass and >>> kernel-fitImage.bbclass deployed the FIT image into the deploy/images/ >>> subfolder. >>> >>> My fix was to make the kernel.bbclass ignore "fitImage" during >>> deployment. This is also the fix I saw from Xilinx. >> >> If I recall correctly, meta-xilinx had their own horribly hacked >> fitImage bbclass, are you sure it's not interfering here ? >> > Yes I am sure it's not. > >> >>> (Another fix I have pending is that bundled initramfs images (i.e that >>> go inside the kernel binary) where also seperately packed inside the FIT >>> image.) >> >> Separate initrd is already supported. > > > There is no exception for INITRAMFS_IMAGE_BUNDLE in > kernel-fitimage.bbclass. The initramfs will be packed inside the FIT, > in addition of also being packed inside the kernel. So why would you use initramfs_image_bundle with fitImage when you can pack the initrd into the fitImage instead ? > My local fix has this: > > diff --git a/meta/classes/kernel-fitimage.bbclass > b/meta/classes/kernel-fitimage.bbclass > index a4d7aca..17addab 100644 > --- a/meta/classes/kernel-fitimage.bbclass > +++ b/meta/classes/kernel-fitimage.bbclass > @@ -475,7 +475,9 @@ addtask assemble_fitimage before do_install after do_compile > > do_assemble_fitimage_initramfs() { > if echo ${KERNEL_IMAGETYPES} | grep -wq "fitImage" && \ > - test -n "${INITRAMFS_IMAGE}" ; then > + test -n "${INITRAMFS_IMAGE}" && \ > + test ! -n "${INITRAMFS_IMAGE_BUNDLE}"; then > + > cd ${B} > fitimage_assemble fit-image-${INITRAMFS_IMAGE}.its > fitImage-${INITRAMFS_IMAGE} 1 > fi > @@ -483,6 +485,18 @@ do_assemble_fitimage_initramfs() { > > addtask assemble_fitimage_initramfs before do_deploy after do_install > > +do_assemble_fitimage_bundled_initramfs() { > + if echo ${KERNEL_IMAGETYPES} | grep -wq "fitImage" && \ > + test -n "${INITRAMFS_IMAGE}" && \ > + test -n "${INITRAMFS_IMAGE_BUNDLE}"; then > + > + cd ${B} > + fitimage_assemble fit-image-${INITRAMFS_IMAGE}.its > fitImage-${INITRAMFS_IMAGE} > + fi > +} > + > +addtask assemble_fitimage_bundled_initramfs before do_deploy after > do_bundle_initramfs > + > > > Regards, > > Leon. > -- Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that. 2018-09-18 10:35 ` Marek Vasut @ 2018-09-18 10:59 ` Leon Woestenberg 2018-09-18 11:12 ` Marek Vasut 0 siblings, 1 reply; 19+ messages in thread From: Leon Woestenberg @ 2018-09-18 10:59 UTC (permalink / raw) To: Marek Vasut; +Cc: OE Core mailing list Hi Marek, On Tue, Sep 18, 2018 at 12:38 PM Marek Vasut <marex@denx.de> wrote: > On 09/18/2018 12:22 PM, Leon Woestenberg wrote: > > > > There is no exception for INITRAMFS_IMAGE_BUNDLE in > > kernel-fitimage.bbclass. The initramfs will be packed inside the FIT, > > in addition of also being packed inside the kernel. > > So why would you use initramfs_image_bundle with fitImage when you can > pack the initrd into the fitImage instead ? > To be honest, I do not know that use-case anymore but it's a valid configuration that shouldn't give an unexpected outcome. We also found a use-case for non-compressed kernels in the FIT image; that was for very small delta-upgrades even when kernels are FIT packed. Currently kernel-fitimage.bbclass hard-selects a compressed kernel (such as zImage). Regards, Leon/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that. 2018-09-18 10:59 ` Leon Woestenberg @ 2018-09-18 11:12 ` Marek Vasut 2018-09-18 11:23 ` Leon Woestenberg 0 siblings, 1 reply; 19+ messages in thread From: Marek Vasut @ 2018-09-18 11:12 UTC (permalink / raw) To: Leon Woestenberg; +Cc: OE Core mailing list On 09/18/2018 12:59 PM, Leon Woestenberg wrote: > Hi Marek, Hi, > On Tue, Sep 18, 2018 at 12:38 PM Marek Vasut <marex@denx.de> wrote: >> On 09/18/2018 12:22 PM, Leon Woestenberg wrote: >>> >>> There is no exception for INITRAMFS_IMAGE_BUNDLE in >>> kernel-fitimage.bbclass. The initramfs will be packed inside the FIT, >>> in addition of also being packed inside the kernel. >> >> So why would you use initramfs_image_bundle with fitImage when you can >> pack the initrd into the fitImage instead ? >> > To be honest, I do not know that use-case anymore but it's a valid > configuration that shouldn't give an unexpected outcome. True > We also found a use-case for non-compressed kernels in the FIT image; > that was for very small delta-upgrades even when kernels are FIT > packed. Currently kernel-fitimage.bbclass hard-selects a compressed > kernel (such as zImage). Patches are welcome -- Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that. 2018-09-18 11:12 ` Marek Vasut @ 2018-09-18 11:23 ` Leon Woestenberg 2018-09-18 14:55 ` Alex Kiernan 0 siblings, 1 reply; 19+ messages in thread From: Leon Woestenberg @ 2018-09-18 11:23 UTC (permalink / raw) To: Marek Vasut; +Cc: OE Core mailing list Hi Marek, Alex, On Tue, Sep 18, 2018 at 1:19 PM Marek Vasut <marex@denx.de> wrote: > On 09/18/2018 12:59 PM, Leon Woestenberg wrote: > > On Tue, Sep 18, 2018 at 12:38 PM Marek Vasut <marex@denx.de> wrote: > >> On 09/18/2018 12:22 PM, Leon Woestenberg wrote: > >>> > >>> There is no exception for INITRAMFS_IMAGE_BUNDLE in > >>> kernel-fitimage.bbclass. The initramfs will be packed inside the FIT, > >>> in addition of also being packed inside the kernel. > >> > >> So why would you use initramfs_image_bundle with fitImage when you can > >> pack the initrd into the fitImage instead ? > >> > > To be honest, I do not know that use-case anymore but it's a valid > > configuration that shouldn't give an unexpected outcome. > > True > > > We also found a use-case for non-compressed kernels in the FIT image; > > that was for very small delta-upgrades even when kernels are FIT > > packed. Currently kernel-fitimage.bbclass hard-selects a compressed > > kernel (such as zImage). > > Patches are welcome > Thanks for explaining the rationale behind the deploy stage, it confirms Alex's suspicion I was solving the problem at the wrong place. Alex, if you are still reading this: the answer is yes, please revert. Regards, Leon. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that. 2018-09-18 11:23 ` Leon Woestenberg @ 2018-09-18 14:55 ` Alex Kiernan 0 siblings, 0 replies; 19+ messages in thread From: Alex Kiernan @ 2018-09-18 14:55 UTC (permalink / raw) To: Leon Woestenberg; +Cc: Marek Vasut, openembedded-core On Tue, Sep 18, 2018 at 12:23 PM Leon Woestenberg <leon@sidebranch.com> wrote: > > Hi Marek, Alex, > > On Tue, Sep 18, 2018 at 1:19 PM Marek Vasut <marex@denx.de> wrote: > > On 09/18/2018 12:59 PM, Leon Woestenberg wrote: > > > On Tue, Sep 18, 2018 at 12:38 PM Marek Vasut <marex@denx.de> wrote: > > >> On 09/18/2018 12:22 PM, Leon Woestenberg wrote: > > >>> > > >>> There is no exception for INITRAMFS_IMAGE_BUNDLE in > > >>> kernel-fitimage.bbclass. The initramfs will be packed inside the FIT, > > >>> in addition of also being packed inside the kernel. > > >> > > >> So why would you use initramfs_image_bundle with fitImage when you can > > >> pack the initrd into the fitImage instead ? > > >> > > > To be honest, I do not know that use-case anymore but it's a valid > > > configuration that shouldn't give an unexpected outcome. > > > > True > > > > > We also found a use-case for non-compressed kernels in the FIT image; > > > that was for very small delta-upgrades even when kernels are FIT > > > packed. Currently kernel-fitimage.bbclass hard-selects a compressed > > > kernel (such as zImage). > > > > Patches are welcome > > > Thanks for explaining the rationale behind the deploy stage, it > confirms Alex's suspicion I was solving the problem at the wrong > place. > > Alex, if you are still reading this: the answer is yes, please revert. > I am :) Thanks for the discussion... I'll send the series I've got - whilst I was about it I cleaned up a bunch of other small things in the same area. -- Alex Kiernan ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that. 2018-09-18 10:01 ` Leon Woestenberg 2018-09-18 10:03 ` Marek Vasut @ 2018-09-18 10:21 ` Leon Woestenberg 2018-09-18 10:33 ` Marek Vasut 1 sibling, 1 reply; 19+ messages in thread From: Leon Woestenberg @ 2018-09-18 10:21 UTC (permalink / raw) To: Marek Vasut; +Cc: OE Core mailing list Hello Marek, On Tue, Sep 18, 2018 at 12:01 PM Leon Woestenberg <leon@sidebranch.com> wrote: > On Tue, Sep 18, 2018 at 11:44 AM Marek Vasut <marex@denx.de> wrote: >> On 09/18/2018 11:40 AM, Leon Woestenberg wrote: >> 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. Am I mistaken or is my assumption correct that kernel-fitimage.bbclass should deploy the fitImages? Regards, Leon. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that. 2018-09-18 10:21 ` Leon Woestenberg @ 2018-09-18 10:33 ` Marek Vasut 0 siblings, 0 replies; 19+ messages in thread From: Marek Vasut @ 2018-09-18 10:33 UTC (permalink / raw) To: Leon Woestenberg; +Cc: OE Core mailing list On 09/18/2018 12:21 PM, Leon Woestenberg wrote: > Hello Marek, Hi, > On Tue, Sep 18, 2018 at 12:01 PM Leon Woestenberg <leon@sidebranch.com> wrote: >> On Tue, Sep 18, 2018 at 11:44 AM Marek Vasut <marex@denx.de> wrote: >>> On 09/18/2018 11:40 AM, Leon Woestenberg wrote: >>> 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. > > Am I mistaken or is my assumption correct that kernel-fitimage.bbclass > should deploy the fitImages? Nope, the fitImages should be deployed by the generic mechanism. The fitImage bbclass only deploys the artifacts from which the fitImage is constructed (its, initrd, linux.bin, dtb etc) -- Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2018-09-18 14:55 UTC | newest] Thread overview: 19+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-09-10 21:56 [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that Leon Woestenberg 2018-09-15 17:45 ` Alex Kiernan 2018-09-16 9:18 ` Leon Woestenberg 2018-09-16 10:41 ` Alex Kiernan 2018-09-16 14:22 ` Alex Kiernan 2018-09-17 18:05 ` Leon Woestenberg 2018-09-18 6:10 ` Alex Kiernan 2018-09-18 9:40 ` Leon Woestenberg 2018-09-18 9:44 ` Marek Vasut 2018-09-18 10:01 ` Leon Woestenberg 2018-09-18 10:03 ` Marek Vasut 2018-09-18 10:22 ` Leon Woestenberg 2018-09-18 10:35 ` Marek Vasut 2018-09-18 10:59 ` Leon Woestenberg 2018-09-18 11:12 ` Marek Vasut 2018-09-18 11:23 ` Leon Woestenberg 2018-09-18 14:55 ` Alex Kiernan 2018-09-18 10:21 ` Leon Woestenberg 2018-09-18 10:33 ` Marek Vasut
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox