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

[Adrian Freihofer <adrian.freihofer@gmail.com>]

On Thu, 2024-07-18 at 11:28 +0100, Jose Quaresma wrote:
> 
> 
> 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.

I don't think adding images to the sstate cache can help much. But it
comes at a high cost. It definitely wouldn't help in the case that
should be optimized with my patches here:
 * If the initramfs changes it needs to be re-built and cannot be taken
   from the sstate-cache anyway.
 * The issue is: If the initramfs changes, the kernel gets re-built.
   What we need is an sstate for the kernel artifacts but not for the
   initramfs artifacts.

Adrian

> 
> [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