Re: [OE-core] [PATCH v2 0/6] Use the kernel from sstate when building fitImages

Jose Quaresma
2024-07-18T10:28:20Z

[-- Attachment #1: Type: text/plain, Size: 5424 bytes --]

Adrian Freihofer via lists.openembedded.org <adrian.freihofer=
gmail.com@lists.openembedded.org> escreveu (quinta, 18/07/2024 à(s) 09:00):

> Hi Martin
>
> Thank you for looking at my patches.
>
> On Mon, 2024-07-15 at 16:32 +0200, Martin Jansa wrote:
> > Doesn't it still rebuild from scratch when IMAGE_VERSION_SUFFIX
> > changes?
>
> I wonder why this happens in WebOS. I think that this line
> kernel_do_deploy[vardepsexclude] = "DATETIME"
> prevents such unnecessary rebuilds.
>
> So far we haven't had any problems with rebuilding kernels. The trouble
> started when we started using fitImages with initramfs for some
> devices. It is also worth noting that we build from sstate, but with an
> empty TMPDIR.
>
> In such a scenario bitbake does:
>
> * The initramfs gets assembled. This is expected because images are
> not sstate cached. This runs quickly because all the packages which
> are required to build the initramfs come from sstate-cache.
> * Since the initramfs changes, the fitImage which includes it must be
> re-assembled as well.
>

I have faced this problem and sent a patch [1] to support storing the full
images on the sstate.
As it was not a tested and widely used case, it was rejected.
We continue using this in our distro but without the patch we need to
change more parts on our side.

[1] https://lists.openembedded.org/g/openembedded-core/message/184243

> * Now the hassle starts: The do_assemble_fitimage_initramfs needs the
> kernel binaries (linux.bin, DTBs...) which are not available from
> sttate. Bitbake has to start with kernel do_fetch in case of an
> empty TMPDIR just to get the fitImage assembled.
>
> With my patches the kernel binaries used for the fitImage come from
> sstate (if the initramfs is not bundled).
>

Anyway your overwall patch set is still a good improvement to not
rebuilding the kernel.
That was my concern also and the main reason for my patch.

Jose

>
> I tested this like that:
>
> cat build/conf/local.conf
>
> KERNEL_IMAGETYPE = "Image"
> KERNEL_IMAGETYPES += " fitImage "
> KERNEL_CLASSES = " kernel-fitimage "and RAM disk
> IMAGE_FSTYPES += "cpio.gz"
> INITRAMFS_IMAGE = "core-image-minimal"
> IMAGE_NAME_SUFFIX:pn-core-image-minimal = ""
> UBOOT_RD_LOADADDRESS = "0x88000000"
> UBOOT_RD_ENTRYPOINT = "0x88000000"
> UBOOT_LOADADDRESS = "0x80080000"
> UBOOT_ENTRYPOINT = "0x80080000"
> FIT_DESC = "A model description"
>
> # Allow to change the initramfs
> FOO_VAR = "1"
> INHERIT += "image-buildinfo"
> IMAGE_BUILDINFO_VARS:append = " FOO_VAR"
>
>
> bitbake virtual/kernel
>
> mv build/tmp build/tmp-old-1
>
> bitbake virtual/kernel
> -> bitbake does:
> - setscene tasks
> - core-image-minimal do_rootfs ...
> - kernel do_deploy (from sstate)
> - kernel do_deploy_fitimage_unbundled
>
>
> bitbake virtual/kernel
> -> bitbake does: nothing
>
>
> # Enforce a re-build of the initramfs
> mv build/tmp build/tmp-old-2
> echo 'FOO_VAR = "1"' >> build/conf/local.conf
>
> bitbake virtual/kernel
> -> bitbake does:
> - setscene tasks
> - core-image-minimal do_rootfs ...
> - kernel do_deploy (from sstate)
> - kernel do_deploy_fitimage_unbundled
>
>
> bitbake virtual/kernel
> -> bitbake does: nothing
>
>
> diff \
> <(ls build/tmp-old-2/deploy/images/qemux86-64 -1) \
> <(ls build/tmp/deploy/images/qemux86-64/ -1)
> 4,10c4,10
> < core-image-minimal-qemux86-64-20240718065105.cpio.gz
> < core-image-minimal-qemux86-64-20240718065105.ext4
> < core-image-minimal-qemux86-64-20240718065105.manifest
> < core-image-minimal-qemux86-64-20240718065105.qemuboot.conf
> < core-image-minimal-qemux86-64-20240718065105.spdx.tar.zst
> < core-image-minimal-qemux86-64-20240718065105.tar.bz2
> < core-image-minimal-qemux86-64-20240718065105.testdata.json
> ---
> > core-image-minimal-qemux86-64-20240718073341.cpio.gz
> > core-image-minimal-qemux86-64-20240718073341.ext4
> > core-image-minimal-qemux86-64-20240718073341.manifest
> > core-image-minimal-qemux86-64-20240718073341.qemuboot.conf
> > core-image-minimal-qemux86-64-20240718073341.spdx.tar.zst
> > core-image-minimal-qemux86-64-20240718073341.tar.bz2
> > core-image-minimal-qemux86-64-20240718073341.testdata.json
> 20c20
> < fitImage-core-image-minimal-qemux86-64--6.6.35+git-r0-qemux86-64-
> 20240718065105.bin
> ---
> > fitImage-core-image-minimal-qemux86-64--6.6.35+git-r0-qemux86-64-
> 20240718073341.bin
> 22c22
> < fitImage-its-core-image-minimal-qemux86-64--6.6.35+git-r0-qemux86-64-
> 20240718065105.its
> ---
> > fitImage-its-core-image-minimal-qemux86-64--6.6.35+git-r0-qemux86-64-
> 20240718073341.its
>
>
>
> The answer is then: No it does not re-build. At least not in the
> scenario which I would like to fix it, it does not rebuild from
> scratch.
>
> Does that make sense?
>
> Regards,
> Adrian
>
> > >
> > >
> > >
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#202191):
> https://lists.openembedded.org/g/openembedded-core/message/202191
> Mute This Topic: https://lists.openembedded.org/mt/107231736/5052612
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [
> quaresma.jose@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

--
Best regards,

José Quaresma

[-- Attachment #2: Type: text/html, Size: 7479 bytes --]