* [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: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: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: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
* 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
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.