On Thu, 2024-07-18 at 11:28 +0100, Jose Quaresma wrote: > > > Adrian Freihofer via lists.openembedded.org > <[email protected]> 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 > > > > > > > > > > > > > > > > > > > > > > > > > -- > Best regards, > > José Quaresma
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#202208): https://lists.openembedded.org/g/openembedded-core/message/202208 Mute This Topic: https://lists.openembedded.org/mt/107231736/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
