On 1/13/25 12:10 PM, Adrian Freihofer wrote:
Hi Marek
Hi,
The issue is known and already discussed here:
https://lists.yoctoproject.org/g/yocto/message/64428. It probably hits many
users and a fix would be more than welcome.
Indeed.
A more general discussion about issues related to the
kernel-fitimage.bbclass is here:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=12912.
[...]
diff --git a/meta/classes-recipe/kernel-fitimage.bbclass
b/meta/classes-recipe/kernel-fitimage.bbclass
index 67c98adb23..81245446a2 100644
--- a/meta/classes-recipe/kernel-fitimage.bbclass
+++ b/meta/classes-recipe/kernel-fitimage.bbclass
@@ -42,7 +42,7 @@ python __anonymous () {
ubootenv = d.getVar('UBOOT_ENV')
if ubootenv:
- d.appendVarFlag('do_assemble_fitimage', 'depends', '
virtual/bootloader:do_populate_sysroot')
+ d.appendVarFlag('do_assemble_fitimage', 'depends', '
virtual/bootloader:do_compile')
This is definitely one of the problematic lines of code. See also
https://lists.yoctoproject.org/g/yocto/message/64428.
However, I guess even if you write the env script from the do_compile task
to the sysroot directory, the dependency here should be on
do_populate_sysroot so that the env file is properly cached by the sstate
cache.
Right, that is one of the things I am not sure about in this patch --
how to stage the mkimage'd env blob into sstate cache early.
The other alternative would be, if the kernel-fitimage-bbclass could
somehow gain access to the UBOOT_ENV source file in the
virtual/bootloader recipe (is that even possible?) , it would be able to
run its own mkimage invocation to convert the UBOOT_ENV source file into
the env blob, but that is not awesome either.
And one more alternative would be to split the env blob generation into
separate u-boot-env_1.0.bb recipe , that would seem like the best way to
me, but that would break existing layers which bbappend u-boot_%.bb .
But unfortunately this is not the only problem the fitimage-kernel.bbclass
has when it comes to building from sstate-cache with empty TMPDIR. This is
also broken in other places, which means that this patch theoretically
makes the situation with the sstate even worse. But since this doesn't work
anyway and the patch fixes the circular dependencies issue, the majority of
users would probably benefit from this patch. And to fix the problem
properly, you would probably have to rewrite the fitimage generation, as
discussed on https://bugzilla.yoctoproject.org/show_bug.cgi?id=12912.
I am in full agreement with this statement, I had that fitimage bbclass
rewrite plan on my todo list for years, haven't gotten to it yet though,
sorry.
I also think the LTS releases will need some minimal fix.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#209742):
https://lists.openembedded.org/g/openembedded-core/message/209742
Mute This Topic: https://lists.openembedded.org/mt/110557812/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
