On 9/25/19 2:23 AM, akuster808 wrote: > On 9/24/19 12:23 AM, Bedel, Alban wrote: >> On Tue, 2019-09-03 at 09:41 +0000, Bedel, Alban wrote: >>> On Wed, 2019-07-31 at 13:53 +0000, Bedel, Alban wrote: >>>> AArch64 images are not self-decompressing, thus usually much >>>> larger. >>>> Boot times can be reduced by compressing them in FIT and uImages. >>>> >>>> This commit is a backport of commit a725d188b5 (kernel-uboot: >>>> compress >>>> arm64 kernels) and commit 60bc7e180e (kernel-uboot: remove useless >>>> special casing of arm64 Image) from master. Both commit were melted >>>> into one to avoid some useless churn. >>> Was this patch overlooked, or is there a reason it is not considered >>> in >>> the next round of update for warrior? Without this patch kernel >>> images >>> are too large to fit in the flash of the system I'm using. >>> Furthermore >>> it is not trivial to fix this in my own layer. >> Please, I really like to get an answer here. I'm fine if there is a >> reason why this patch is not considered for warrior, but just getting >> ignored is very frustrating. > This appears to be a performance enhancement which does not fall into > the criteria for back porting to a stable branch. > > - armin
Just to bring all the elements on the table: It's possible to argue that it is more of a fix for a performance regression, as the sub-optimal approach was introduced in 1aa417df604d2627c56232a7a2c396c6b085d74b and the patch in question is equivalent to a revert. For example, the pyro branch does not seem to have the issue. I don't know if it makes a difference in terms of criteria for a backport but I agree that the problem is indeed made worse because it is quite hard to override in user layers. Laurent -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
